Architecture starts when you carefully put two bricks together. There it begins.
Ludwig Mies van der Rohe
Introduction
As with traditional architecture,
software architecture begins when the first lines of a
computer program are written. Whether the architecture is described by formal
documentation or a barely imagined “castle in the sky”, the author of those first few lines of code and all the lines which follow them is being guided by a software architecture.
The analogy continues to apply as the software development process continues to unfold. Just as a well architected building achieves its potential in form and function as it nears completion, so a well architected software system achieves its potential in form and function as it nears completion. In contrast, poorly architected buildings and poorly architected software systems never seem to achieve their potential (assuming that they are ever actually completed at all).
The extent to which the completed building meets or even exceeds the customers goals and expectations is not an accident. Rather, it is the direct result of the quality of the building’s architecture. Similarily, the extent to which a completed software system meets the customers goals and expectations is also not an accident. It is the direct result of the quality of the software system’s architecture.
Creating or developing an architecture is the task of an architect. Just as a building architect is responsible for a building’s architecture, a software architect is responsible for a software system’s architecture. They are both involved in very similar tasks:
- They work with the customer to develop a shared understanding of what the building or software system should do.
- They use this understanding to produce architectural diagrams and other documents which describe the building or software system in terms of both form1 and function2.
- They guide the process of developing engineering blueprints or system design documents.
- They continue to provide both overall guidance and often detailed input into issues that arise during the project’s construction/development phase.
They have near final accept/reject authority regarding changes to the building or software system’s architecture including the near absolute right to decide whether a change is architectural or not.
- They are ultimately responsible for ensuring that the finished result satisfies the customer’s expectations regarding function, form, time and budget (i.e. if the completed building or software system does not “work” then it is likely that the architect rather than the engineers/designers or the construction crew/developers who have failed).
There is one rather fundamental difference between the world of building architecture and the world of software architecture - a building architect generally concerns themselves with a single building or group of buildings whereas a software architect can find themselves dealing with either a single instance of a software system (i.e. a custom development scenario) or with a software system which will ultimately be reproduced many times over (i.e. a product development scenario).
The difference between a custom development scenario and a product development scenario is fundamentally the difference between being able to develop a shared understanding of the final result with the “real” customer or having to settle for trying to developing a shared understanding with the product visionary, the “marketing” folks and (hopefully) a selection of potential customers. The result tends to be a somewhat higher level of risk when developing a product’s architecture vs developing a custom system’s architecture3.
Architecture as a risk reduction tool
When one embarks on a building or a software system construction project, one enlists the services of an architect because one expects the architect to “add
value” to the project. This “value” can take many forms including, of course, the “value” that a building/system which has been properly architected simply “works better” because an architect notices and understands things that others miss.
Each of these forms of “value” really amount to the same thing - risk reduction.
The “risk reduction value” which an architect brings to the table can take many forms:
- a reduced risk that the project will fail outright.
- an improved likelihood that the customer(s) will be satisfied with the building/system.
- an improved likelihood the building/system will “work” as expected.
- a reduced risk that the building/system will be completed on schedule.
a reduced risk that project will be over budget.
Closing remarks
The analogy between building architecture and software architecture is surprisingly good. What’s more than a little disconcerting is that few companies would even consider embarking on a major building construction project without the services of a building architect and yet these same companies routinely embark on major software construction projects without any serious consideration being given to the architecture of the proposed software system.
Hmmm.
1 For example, a circular structure with a central atrium or web-browser like kiosks located in strategic locations.
2 For example, three million square feet of office space with a shopping mall on the lower level or provide theme park information and directions to the nearest toilets.
3 One must be careful to not over emphasize this issue as it is certainly not unusual for a custom system’s “real” customers to have little if any deep understanding of what the custom development project’s needs and goals are, a situation which effectively eliminates any real difference in the risks associated with custom vs product development scenarios.
The analogy between building architecture and software architecture is taken from the philosophy of the Worldwide Institute of Software Architects (www.wwisa.org).