Yesterday's software engineering class asked the question, "What is a software architect?" The class offered all sorts of answers, most involving some type of technical leadership. To me, the architect sets up the framework in which the other developers work. He or she makes the module- and application-spanning decisions that guide— and in some cases limit— the decisions of other developers.
The architect's main goal when making these decisions is to ensure the overall quality of the final product. However "quality" can be defined using any number of criteria: maintainability, security, speed, flexibility, reliability, etc. Professor Johnson refers to these as the "-ity" words. All involve tradeoffs and may indeed be mutually exclusive. The architect must decide which of the particular "-ities" to focus on and control the tradeoffs based on the client, business, or product needs.
We also discussed some of the many differences between architects of buildings and architects of software. The point that stuck in my mind was this: many years ago, a building architect used to be the designer, engineer, and on-site technical lead of a project. (who rebuilt the churches of London after the fire of 1666) and (who directed the construction of the Brooklyn Bridge from his sickbed via his wife) both seem to meet this criteria. This description sounds very similar to how we describe a software architect today.
As time went by, the roles seemed to diverge. An "architect" became responsible for the aesthetic design of a building, the "engineer" became responsible for making the design work, and the on-site technical lead became any number of contractors and subcontractors. Of course there will always be a great deal of overlap and interaction between these roles, but the differences certainly exist.
Software architecture is still such a young field that I cannot help speculating that it will one day undergo a similar divergence. Professional software architects love trying to make programming “more like engineering”, but I think many changes need to occur before that can happen. To illustrate, a building architectural firm can easily send a design to an architectural engineering firm to prepare technical blueprints, and the engineering firm can easily send the blueprints to any number of contractors. (I realize this is a gross simplification; bear with me.) In software architecture, however, it is very difficult to create a transferable, adaptable “blueprint” of a software system for others to implement. Formal specifications, UML, design/architectural patterns, and other tools try to meet this need, but they still have a long way to go.
Despite this speculation, I believe that a software architect will always remain closer to code (or some other problem-solving abstraction) than a building architect is to a hammer. Certainly part of this belief is personal in that I really like code. However the larger part is based on the observation that software architecture is fundamentally different from any other constructive profession:
- The final product can be duplicated infinitely. This means that there is no need to “mail the blueprint to all the contractors”. One can just email the executable.
- Code is the current “top” of many layers of abstractions. Software architecture can grow (and is growing) to accommodate new, more powerful layers of abstractions such as architectural patters or large, interconnected modules.
- The tools are constantly changing. Software architecture will use different tools, but these tools will still require a technical lead for the same reasons projects currently need a technical lead when writing code.
For these reasons, I believe that software architecture will evolve not toward greater speciality—like what happened in building architecture— but toward greater generality to encompass new abstractions and tools.