Part 2 Analysis of System Architecture
We now begin the analysis of architecture in depth. In Part 1, we built up a framework for analyzing systems, and we introduced some of the tools that will be useful in that analysis. Here in Part 2: Analysis of System Architecture, we will work to develop a deep understanding of form and function and will show that these are the building blocks of system architecture.
What is architecture? Two possible definitions are:
The arrangement of the functional elements into physical blocks.
Ulrich and Eppinger [1]
The whole consists of parts; the parts have relationships to each other; when put together, the whole has a designed purpose and fills a need.
Reekie and McAdam [2]
What these two definitions have in common is that they describe the key elements of a system: form and function, parts and whole, relationships, and emergence.
Our experience is that there are many different definitions of architecture, which vary in their emphasis on form or function, and which vary enormously in the level of detail required. Consider two other definitions:
The fundamental organization of a system, embodied in its components, their relationships to each other and to the environment, and the principles governing its design and evolution.
ISO/IEC/IEEE Standard 42010 [3]
A formal description of a system, or a detailed plan of the system at component level to guide its implementation.
The Open Group Architecture Framework (TOGAF) [4]
Notice that one definition connotes a high-level description (“fundamental organization,” “principles”), while the other emphasizes detail and implementation. How much detail is required to capture architecture?
The architecture of the system should ensure that the function and performance that are linked to benefit emerge. Benefit is the worth, importance, or utility of a system as judged by a subjective observer. Value will be defined here as the delivery of benefit at cost. A system can deliver high value by producing benefit at low cost, or high benefit at modest cost. A deeper discussion of value identification and delivery will be conducted in Chapters 5 and 11. We will develop a more detailed definition of architecture in Chapter 6, as we build up the ideas necessary for the analysis of architecture.
Our approach in Part 2 is to start with very simple systems, even though this may seem counterintuitive for a text on complex systems. Our intent is to showcase the ideas of architecture in a context where the system can be fully represented—all the pieces are present. This alleviates concern that we have somehow left out the kernel of architecture by not representing enough detail, and we will show what information we believe is sufficient to capture the architecture of the system.
As we proceed through Part 2, we will work on progressively larger systems, but our intent remains to showcase methods and diagrams that can directly represent architecture. Then, in Part 3, we will turn to complex systems, where we will make use of the constituent ideas of architecture (such as form and function), but we will focus on architecture in a management context where specific diagram languages like OPM and SysML are not always appropriate.
In order to allow the reader to reason from the concrete to the abstract, we will begin Part 2 with a discussion of the form of a system and then work toward function in Chapter 5 and the mapping of form to function to define architecture in Chapter 6. This is the direction of reasoning in reverse engineering. We just assume that the architecture exists and proceed to analyze it. Learning analysis first creates the conditions for successful synthesis. Chapter 7 adopts a forward engineering approach, examining how systems derive from a solution-neutral statement of function and arrive at a concept. Finally, in Chapter 8, we demonstrate how this concept flows to an architecture.