The Case for a Software Architect's Profession
These days as projects go, the number of IS/IT projects far outnumber traditional engineering and building construction projects, albeit durations and budgets are probably much smaller on average. Moreover, the success rate of IS/IT projects are disappointing when measured against the traditional criteria of delivering to the tetrad targets of scope, quality, time and cost. So it should come as no surprise that there is much writing and discussion on project managing IS/IT projects in general and managing the associated software development in particular. But perhaps the management of the project, i.e. the project management processes themselves, is not so much at fault as the management of the technology involved.
Now, Marc and Laura Sewell have written a delightful book called "The Software Architect's Profession: An Introduction" (Prentice Hall, 2002). In this book, they make a compelling case for a properly established profession of software architecture by drawing a close analogy with the Building Architect's profession. Of itself this might not be so remarkable, but project managers in the construction arena have come to rely heavily on the established professions in the business and, indeed, much of the methodology of project management has evolved from the practical processes that have been forged in that and similar industries. The book is well researched and even "traditional" project managers could learn from it. Here's a small part of what the authors have to say:
"When clients make a decision to build a home, their minds fill with highly subjective wishes, visions and desires. Some clients are quite technical and want the latest innovations in window design, electronics, and construction methods. Others sit on their empty lot at sunrise to see how to best position the house to catch the beautiful morning rays of light. It's a safe bet, however, that few clients rhapsodize over their future septic tank - if they think of it at all. For our purposes, though, the septic tank is a wonderful illustration of the differentiation between the roles of construction professionals, and it is a truism that all the features so desired by clients will come to naught if the septic tank fails.
Like software, septic tanks can be intimidating to the uninitiated ('Yikes! All our water and waste stays on the lot?') But before a piece of land is even approved for sale as a residential lot, an engineering firm is contracted to perform a percolation test and a septic plan. The engineer documents the proposed septic area and certifies the lot as being feasible. Because a backhoe is needed to perform this engineering function, a septic construction company is typically used, and they either employ or contract the engineer.
The architect, in turn, needs to consider the septic field before siting or determining the size of the home. If the septic field is certified for only a four-bedroom home, a six-bedroom home cannot be built unless the septic field can be enlarged. Or, if the architect wants the house to be placed where the septic field is proposed, the entire septic field will need to be moved. The engineer returns to evaluate the technology needed to accomplish the architect's plan and to certify the modifications and obtain approval.
The fun can now begin. There are specialized firms dedicated to the building of septic systems. Heavy equipment operators dig the trenches and lower the concrete tank into place. Construction workers lay and connect the pipe in the trenches and make the connections. An electrician installs pumps. The complete system is inspected and tested by the engineer and certified as-built, in conformance with the engineering plan.
Notice that the architect would have just a summary outline of the septic field on the blueprint. The client approves and validates this plan. In turn the city engineer validates and approves the detailed plan completed by the septic engineer. And the septic construction company executes the septic engineer's plan. When the home is complete, the client can use the septic system without a conscious thought (hopefully) and just watch the grass grow.
In this example, the architect did not try to engineer the septic system. The engineer did not get involved in the layout or design of the home, even though the engineering results influenced those decisions. When the builders came to construct the system, neither the architect nor the engineer operated the heavy equipment or worked with the pipes. The client, in turn, did not have to know how to construct septic systems in order to validate the progress being made ...
Central to the role of architect is communication. The architect is a catalyst whose feet are planted firmly in two worlds: the client's and the builders'. The architect must communicate and enter the world of the client to arrive at the best design and then communicate that design to the builders in sufficient detail via plan or blueprint ... The role of architect is to design structures to meet client's needs. To meet those needs – to understand them and fulfill them through design – is both an art and a science learned from years of training and experience.
[Note that] the design process goes far beyond the pedantic exercise of requirements gathering, which tends to assume that clients and users of software systems possess the abilities to fully assess their needs, know what the design elements should be, and verbalize them accurately. If we all knew precisely what our requirements were and how to integrate them into a fine design – in a software system or our dream home – there would be no need for architects; the inhabitants could simply communicate their ideas directly to the builders and have their expectations met in the final structure.
As we know, that is how software is now built and why it fails. The very premise of this process is fatally flawed."
We couldn't have expressed it better ourselves. Come to think of it, software projects are not the only types of project to which this line of thinking applies – and with similar consequences.
Quoted text reproduced with permission and credited as follows: Sewell, M./Sewell, L., THE SOFTWARE ARCHITECT'S PROFESSIONS, ©2002. Electronically reproduced by permission of Pearson Education, Inc., Upper Saddle River, New Jersey. The book is available from Border's, B&N, online at Amazon.com and BarnesandNoble.com. Price quoted around USD $29.
|
