Where do architectures come from? They spring from the minds of architects, of course, but how? What must go into the mind of an architect for an architecture to come out? For that matter, what is a software architecture? Is it the same as design? If so, what's the fuss? If it's different, how so and why is it important?
In Part One, we focus on the forces and influences that are at work as the architect begins creating-envisioning-the central artifact of a system whose influences persist beyond the lifetime of the system. Whereas we often think of design as taking the right steps to ensure that the system will perform as expected-produce the correct answer or provide the expected functionality-architecture is additionally concerned with much longer-range issues. The architect is faced with a swarm of competing, if not conflicting, influences and demands, surprisingly few of which are concerned with getting the system to work correctly. The organizational and technical environment brings to bear a weighty set of sometimes implicit demands, and in practice these are as important as any of the explicit requirements for the software even though they are almost never written down.
Also surprising are the ways in which the architecture produces a deep influence on the organization that spawned it. It is decidedly not the case that the organization produces the architecture, ties it to the system for which it was developed, and locks it away in that compartment. Instead, architectures and their developing organizations dance an intricate waltz of influence and counterinfluence, helping each other to grow, evolve, and take on larger roles.
The Architecture Business Cycle (ABC) is the name we give to this waltz, and it is the theme of this book and the focus of Chapter 1. Chapter 2 lays the foundations for the study of software architecture, defines it, places it in the context of software engineering, and provides some conceptual tools for its consideration. Chief among the concepts is the notion that architectures consist of separate coordinated structures and that each structure provides an engineering leverage point in system development.
Chapter 3 is the first case study in the book. It illustrates how a particular architecture solved a unique set of requirements-in this case, a real-time embedded avionics system whose focus was on long-term modifiability-but also brings home the conceptual points made earlier. Three separate architectural structures-module decomposition, uses, and process structures-came together to provide the architectural solution for this system.
With this introduction, we begin our tour of the Architecture Business Cycle.
