- An aside: Be gentle
- Complexities and contradictions
- Telling the truth
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Telling the truth
The stakeholders who have an interest in a software-intensive system are many, varied, and sometimes unexpected. The most obvious collection encompasses those who build the software itself; this includes the system's architects, project manager, code warriors, analysts, and testers. The most important group covers those who use the software, including its end users, third parties who extend or integrate other systems with the system, and its administrators. The not-quite-so-obvious-but-still-very-important stakeholders include those who fund the system and its other patrons. Beyond those orbits, we move out to more metaroles. As my list of contradictions suggests, any significant piece of software touches many classes of people, and they are impacted by and can impact software-intensive systems. Historians, legal professionals, criminals, artists, companies, and governments might all be drawn in by the gravitational pull.
The closer we are to a system's code, the more visible its architecture. A code warrior toiling away to introduce a new feature into that system will need to do so in the context of its architects' design decisions. Someone maintaining a piece of software must honor the system architecture or it will slowly rot away. A third party who wishes to extend a system must understand where its edges lay and have some sense of its underlying architecture to properly and cleverly use the resources it offers at the edge.
End users, for the most part, want software to be invisible. However, even for them, some essence of a system's architecture will emerge, because that architecture shapes the way users see the system and provides a model that enables users to interact with the system. At the outermost orbits, where all the unexpected stakeholders live, the fact that a software-intensive system even exists is irrelevant because all they really care about is the system's impact on their lives.
In IEEE Standard 1741, Recommended Practice for Architectural Description, a clear separation of concerns is made among stakeholders, their issues, their viewpoints, and the system's architectural description. According to the standard, we should organize the description of a system's architecture by a set of views, each of which consists of a set of models and conforms to a particular viewpoint. In turn, the set of concerns that are important to certain stakeholders determines that point of view.
Every system's architecture is molded by the forces that swirl around it, and the collective concerns of all the stakeholders represent the most dynamic forces shaping a system. (Other forces include limiting factors around the laws of physics and the laws of software.) The software development organization's unique task is to address all the essential concerns of all the important stakeholders and to ensure that they aren't blindsided by unexpected problems and stakeholders. This is why employing a process that incrementally and iteratively grows a system's architecture through the regular release of testable executables is so important. Such a process lets the software team engage the right stakeholders at the right time and to make the right decisions, neither too early nor too late.
In creating a software-intensive system that's both relevant and beautiful, every stakeholder, no matter how close or how far from the code, deserves the truth.
Grady Booch is an IBM Fellow and one of the Unified Modeling Language's original authors. He also developed the Booch method of software development, which he presents in Object-Oriented Analysis and Design. He's now working on a handbook of architectural patterns, available at www.booch.com/architecture. Contact him at architecture@booch.com.