Why We Need Software Architecture | A Practical Guide to Enterprise Architecture

In cartography, a single map cannot fully characterize a place. There are many kinds of maps, such as highway maps, bike trail maps, and elevation maps. Each type explains and describes different aspects of the same physical place. Each map is relevant to a different user or stakeholder. The family on vacation is interested in having a highway map in its glove compartment. The cyclist needs the bike trail map, and a mountain climber needs the elevation map. In addition, a map doesn't have to be perfectly accurate to be useful. If a perfect scale map of rides and paths were given to visitors to Walt Disney World, it would be accurate and somewhat useful. However, the map that is actually handed out at Walt Disney World contains pretty pictures of the interesting rides and the paths are not to scale. For the Disney World visitor, this map is more interesting, though useful, and it imparts a better understanding of the layout of the park than a cartographer's map would. The same holds true in software architecture. The architecture that is presented to the end-user contains less information and is more interesting, but focuses on the critical aspects of the system that the particular stakeholder community should understand. The software architecture that is needed by developers can be more like a cartographer's depiction of the software architecture, with multiple maps outlining the multiple aspects of the system in more detail.

Just like maps, the purpose of software architecture is to impart an understanding of the design of the system to the reader. The point of software architecture is to communicate an idea. It takes the reader into the software and explains the important concepts. It helps them understand the important aspects of the system and gives them a feeling for a system without actually having to see inside it.

Despite the invention of satellite imagery, maps are still important. We can now get an exact picture of Earth at any level of detail we need. The pictures show rivers, oceans, and more, as well as the layout of Walt Disney World in their exacting detail.

"Maps have the character of being textual in that they have words associated with them, that they employ a system of symbols within their own syntax, that they function as a form of writing (inscription), and that they are discursively embedded within broader contexts of social action and power." John Pickles, "Text, Hermeneutics and Propaganda Maps," in Trevor J. Barnes and James S. Duncan, eds., Writing Worlds: Discourse and Metaphor in the Representation of Landscape, London: Routledge, 1992, 193.

Maps and architecture don't describe reality. They are representations of reality within a chronological and cultural context. They also have a distinct perspective on the place they describe. In other words, reverse engineering a Unified Modeling Language (UML) diagram from the source code of the system does not create an architectural model. The architectural model communicates the important design decisions that were made at a particular time and that were important to a particular group of people.

The cartography metaphor works, except for the fact that architecture is an upfront activity. In cartography, maps are created for existing places. They are meant to describe something that has already been created. In software architecture, the maps or models depict software that is yet to be created. The models embody the important design decisions that have been made about the system. By creating and contrasting different models of software that fulfill the same purpose, intelligent decisions can be made about which designs are better than others. This is the second purpose of software architecture.

The Two Extremes

Software development approaches vary between two extremes. The first method involves little or no upfront modeling or design. This is the "shanty town" method of system development in which a few developers code without a mental picture in their heads about the system they are building. Also, some managers believe that if developers aren't coding, they aren't working. These project managers also believe that the sooner developers begin coding, the sooner they will be done. This stems from the incorrect belief that a constant amount of time is involved in the coding of the system no matter what upfront process is used. In this type of environment, developers don't fully understand the requirements for the system. Some of these environments deliver decent software through heroics by developers and frequent rewrites, although this approach is not repeatable, and it is extremely risky.

The other extreme in software development is "ivory tower" software architecture in which a design team or a single architect design a system in every detail, down to the class and method level. The architect has a clear picture in his or her head about the design of the system but has not left many of the implementation details to the developers. The belief in these environments is that the architects are the most experienced developers and thus can design the best possible system from start to finish. No one person or small team can possibly understand all the requirements, predict every change in requirements, and have expertise in every technology that the project is built upon. Developers in these environments also suffer from low morale because they are perceived as somehow inferior to the designers of the system. Morale is also poor because the developers must implement the design in a prescriptive way with little or no input into the design of the system.

The Middle of the Road

So what does all this have to do with software architecture? Software architecture is the middle road between no design and complete design. It is a view of the system design that shows how the design satisfies the critical requirements of the system. It is the role of the software architect to design the structures of the software such that those critical requirements are satisfied. It is also the goal of the software architecture to facilitate the development of the system by multiple teams in parallel. In addition, if multiple teams or departments within an organization will support and maintain the software, the software architecture will allow those parts of the system to be managed and maintained separately. The most important role that the software architecture has is that of an organizing concept for the system. The software architect has an idea how the system should work. The software architecture is the communication of that idea to other system stakeholders so that everyone understands what the system does and how it does it.

In a practical sense, two rules determine whether or not a design detail should be included in the software architecture:

The design detail must support a quality requirement.
The design detail must not detract from stakeholder understanding of the software architecture.

If the design detail does not somehow improve on a quality requirement of the system, it should be left out. For example, the architect might not choose XML due to performance concerns. However, the system might benefit more from the modifiability of XML. Without an elicitation of the quality requirements for the system, these types of decisions might be made based on personal preference instead of quality requirements. Also, if a design detail is complex and cannot be described in a simple way that stakeholders can understand, it should not be included in the architecture. A design detail that is not understandable is also a sign of a bad design.