Chapter 2. Software Architecture

Maps encourage boldness. They're like cryptic love letters. They make anything seem possible.

Mark Jenkins, "To Timbuktu"

The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds.

The software architecture of a system supports the most critical requirements for the system. For example, if a system must be accessible from a wireless device, or if the business rules for a system change on a daily basis, then these requirements drastically affect the software architecture for the system. It is necessary for an organization to characterize software architectures and the level of qualities that their systems support to fully understand the implications of these systems on the overall enterprise architecture.

Since this book has a focus on agile methodologies, it is important to discuss the relationship between software architecture and agile methodologies. The recent push in software development toward agile methodologies, such as eXtreme Programming (XP) (Beck 1999), in some ways counters the belief in an explicit and formal definition of software architecture. Many agile methodologists assert that software design is the result of iterative refactoring of a system by developers until a sufficiently workable design emerges. However, in XP these iterative refactorings are done in a small, easily understandable, conceptual framework for the system called the system metaphor. The system metaphor is a simple shared story for how the system works. It consists of the core concepts, classes, patterns, and external metaphors that shape the system being built. The system metaphor plays the same role in the development of a system as conceptual software architecture. It provides a vision for the development of the software, and it is the goal that each system stakeholder must strive toward. A formal definition of the software architecture is more technical than the system metaphor, but both play the same role in providing a central concept for system development. The extent to which an organization needs to provide a formal technical description of the architectures of its systems depends on many factors. Clearly, it would not be cost-effective to formally define the software architecture for a small noncritical departmental software application, and it would be unacceptable to not formally define the software architecture of a highly available telecommunications software system. Each organization is different and has a different need for detailed software architecture. The agile principle of "If you don't need it, then don't do it" applies to software architecture as well as to all the other parts of an organization's enterprise architecture. For more on agile methods and architecture, see Chapter 9, Agile Enterprise Architecture.