Chapter 1

Architecture and Its Significance

1.1 Introduction

A system is a set of elements so connected or related that they perform a unique function that cannot be performed by the elements alone. The picture of a modern aircraft in Figure 1.1. illustrates this point. The aircraft has many constituent parts, but none of these parts by itself is capable of flight. Only when put together in a particular way do they enable an aircraft to fly.

We can examine other kinds of systems and make similar observations. A corporation is a social system that produces goods and services that individuals working for the corporation cannot produce individually. An individual is an animate system in which no single part of the body by itself can produce life. A clock is a mechanistic system; its individual parts together serve the purpose of showing time. An airline reservation system is an information system that as a whole manages flight reservations for passengers.

An architecture of a system is fundamentally concerned with how a system is organized into its constituent elements and how these elements relate to each other to achieve a given purpose (Bass et al., 2003). Given this perspective, every system has an architecture, but a suitable architecture is one that enables a system to achieve the purpose for which it was created. For instance, we can put together the wings, fuselage, engines, and the landing gear of an airplane, but this would do no good until they are put together in a way that makes the aircraft fly. Systems are not limited to just the hardware, however, and can also include people, software, facilities, policies, and documents. All of these elements may be required to produce the desired system outcome; for instance, a successful flight of a commercial airliner from its place of origin to its destination is as much a result of the aircraft and its crew as it is of the ground crew and air traffic control.

1.2 Rising Complexity

The complexity of modern-day systems continues to rise. These systems need to be created quicker, and new features need to be introduced faster. There is an increasing need to customize them for niche markets, and new requirements continue to surface so that systems must evolve to serve emerging market needs.

Much of this required complexity has made it necessary to incorporate a significant amount of software in many products. For instance, it is not atypical for a premium-class automobile today to contain close to 100 million lines of code. The same is true for chemical and nuclear power plants. As Figure 1.2 shows, avionics software in modern fighter aircraft has steadily increased and today controls 80% of what a pilot does (Reifer, 2001).

The complexity is not necessarily related to the size of a system, but it is related to the interrelationships among the elements that make up such a system. Figure 1.3 shows a dependency graph of a system for viewing chemical structures. The elements of the system are represented as nodes, and their dependencies are shown as edges. As one can see, the number of elements and the dependencies among them is rather large. In its current form, it would be rather challenging not only to understand these dependencies but also to maintain and evolve this system over time. An architecture brings to bear organizing principles that can help manage this complexity, making a system not only intellectually graspable but also easier to maintain and advance over time. Figure 1.4 is a different rendition of the system shown in Figure 1.3 using some of these organizing principles.

As Figure 1.4 shows, the structure appears less overwhelming and more modular, with the elements that are closely related clustered together. Modularity, of course, is only one of the many organizing principles used when creating architectures of complex systems. Also, this exercise was an afterthought by which we took a disorganized system and restructured it to make it appear more modular. Architectures require much forethought and planning so that systems developed do not end up a complicated mess from the beginning.

Although some complexity is inherent in the problem domain for which a system is being designed and therefore, cannot be avoided, a system can be designed in a way that makes it less complicated. Complexity that cannot be avoided is called incidental complexity, whereas complexity that can be avoided is termed accidental complexity (Brooks, 1995). The architecture of a system embodies design decisions that have an important part to play in effectively managing incidental complexity and avoiding accidental complexity.

1.3 Constant Change

Complex systems are realized over a long period of time. This development time can see a lot of change in not only the technology used to create the system but also the requirements of the system itself. Figure 1.5 shows how mobile technology evolved from first-generation (1G) to fourth-generation (4G) systems in a span of 25 years; the 1G systems were analog and supported only voice communication, but the 4G systems are digital, ultrabroadband and support multimedia capabilities.

In today’s rapidly evolving world, change is the only constant; therefore, we must learn to embrace this change rather than try to control it. Architecture can play a key role in achieving this objective. A system can be designed with a flexible architecture that anticipates these changes. The value of creating such an architecture is the cost of not addressing the technical aspects that can help a system adapt to these changes when they happen. The Iridium fleet of communication satellites is an example of a system that was developed in the 1980s at a cost of about $4 billion and was launched in the late 1990s. Iridium phones cost as much as $3,000, with connection charges of up to $7 per minute, and failed in the short span of 9 months as they could not adapt in the face of less-expensive terrestrial cellular mobile phones that had swept the marketplace by then (De Neufville and Scholtes, 2011).

To mitigate the risk arising from constant change, most organizations develop systems incrementally over a number of iterations. Each increment produces a working fraction of a system that consists of a minimum marketable feature set and serves as a stable foundation for subsequent iterations. The architecture of a system plays a significant role in achieving this stability. It must anticipate the changes likely to happen in the foreseeable future and must accommodate these changes easily when they happen.

1.4 Distributed Development

Increasingly, complex product development requires the use of expertise of many teams; these teams are often geographically distributed. This has given rise to the additional complexity of communicating, coordinating, and controlling work across geographically distributed development teams. As shown in Figure 1.6, the additional complexity results from the many dimensions of distance that come into play when project teams are far apart (Sangwan, Bass, et al., 2006). Physical distance limits face-to-face interactions, temporal distance limits overlap in working hours, cultural distance introduces communication difficulties caused by language and cultural barriers, and cognitive distance limits shared understanding. The most noticeable effect of distance is a nearly total absence of informal or unplanned communication across the different sites, leading to difficulties in knowing who to contact about what, initiating contact, communicating effectively across sites, and establishing trust (Herbsleb and Grinter, 1999). This leads to conflicting assumptions or incorrect interpretation of communications across different sites, resulting in a delay in the resolution of work issues.

Constant change coupled with distributed development can create additional challenges. Change brings with it a lot of uncertainty and ambiguity. Although much of this uncertainty and ambiguity is addressed in colocated projects through informal communication among team members, geographically distributed teams do not have this luxury. Under such circumstances, architecture becomes the mechanism through which communication, coordination, and collaboration needs of distributed development projects are established. An architecture defines the relationship among the different elements of a system and captures their interdependencies. These interdependencies determine the volume, frequency, and type of communication, coordination, and collaboration needed among the participants in a globally distributed project. Architecture also helps create a shared level of understanding of the system context, its problem domain, and an overarching vision of the system to be designed. Establishing this shared context goes a long way in understanding dependencies across elements of the architecture and the allocation of their development to the distributed teams (Sangwan, Bass, et al., 2006). Lack of such a context leads to the creation of multiple realities promoting ignorance, confusion, and frustration, which subsequently undermine mutual trust and make interteam communications less effective. This vicious cycle leads to dysfunctional teams, inefficiencies in the project, and ultimately poorly designed systems (Sangwan and Ros, 2008).

The architecture of a system therefore can exert a strong influence on the structure of a project. Figure 1.7 shows the structure of a system as a network of elements and their interdependencies. Strongly connected elements of the system are displayed in the same shade of gray. It has been shown that a project structure typically mimics the system structure, as shown in this figure (Conway, 1968).

Although the architecture of a system and the structure of a project must be aligned, in a geographically distributed environment allocation of work across teams must also be planned by carefully examining dependencies among the elements of a system. Not only must strongly connected elements be allocated to a single colocated team, but also teams that have higher communication and coordination needs should not be located several time zones apart from each other.

1.5 Practice for Architecture-Centric Engineering

International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) 42010 (ISO/IEC, 2011) is an international standard that provides a conceptual framework for incorporating architectural thinking into the development of a system. Figure 1.8 captures the key elements of this framework using UML (Unified Modeling Language). Every system exhibits an architecture that addresses the concerns and constraints of its stakeholders and its environment. These concerns and constraints become the basis for creating the architecture, which is documented using an architecture description.

Architecture serves as a basis for not only development of a system but also its maintenance and operation (ISO/IEC, 2011). As a system continues to evolve, each iteration of its development brings in new requirements from its stakeholders and its environment in response to changing business needs and technology. The architecture a system exhibits must have the flexibility to adapt to these changes.

How central the focus on architecture is to a development process varies from one organization to another. Because architecture is associated with big design upfront (BDUF), many organizations following Agile processes place less emphasis on it than those that use a more plan-driven approach (Boehm and Turner, 2003). Advocates for Agile processes focus more on maximizing the flow of value to their customers and see architectural work as incurring cost and delaying delivery of value. However, plan-driven approaches suggest that ignoring architectural work in the short term can create conditions in the long term that make it difficult (or even impossible) to deliver value at a sustainable pace. This is more evident in large-scale projects; therefore, concepts such as Sprint 0 or architecture spike have been added for architectural envisioning to Agile development processes as well.

The practice of architecture-centric engineering (PACE) described in this book recognizes the significance of architecture in sustainable delivery of value throughout the life cycle of a product. PACE is more an approach to, rather than a process for, developing a system. It recognizes that a system must fulfill the purpose for which it was designed. The natural starting point for PACE, therefore, is a set of business goals or mission objectives of a system that define this purpose. By examining these goals, PACE essentially tries to answer the question, Why are we creating the given system? The answers to this and other questions become the basis for architecture envisioning for the given system.

Business goals or mission objectives capture the concerns of the stakeholders of a system and become the basis for its quality attribute requirements. When using two different versions of a system, you may find them functionally equivalent but may develop a preference for one over the other because of its quick response time, ease of use, ease of modification, or high reliability. Such characteristics of a system are called quality attributes and are the predominant forces that shape its architecture. PACE uses quality attributes as the basis for determining the most significant requirements that drive the development of the architecture of a given system. These requirements are expressed in the form of quality attribute scenarios that are not only unambiguous but also testable so they can also serve as test cases for validating the architecture.

Once the architecture is in place, it must be validated against stakeholder concerns to see if the system meets its business goals or mission objectives. If it does not, then one of two things must happen: either the mission objectives need to be changed or the architecture needs to be modified. Thus, architecture design is an iterative process that is carried out until all stakeholder concerns are addressed.

Once the stakeholder concerns have been addressed, the architecture becomes a baseline for detailed design. However, what is detailed design to one person could be architecture design to another. The requirements associated with baseline architecture can become drivers for defining the architecture of individual elements that make up this baseline. Thus, architecture design is a recursive process that is repeatedly applied to drive the design to a level with details sufficient to build the final system.

As the design process is applied recursively, the design decisions at each level serve as a starting point and context for the subsequent level. Architecture is, therefore, discovered within the confines of decisions already made, and it is managed by ensuring that future design decisions conform to the constraints set forth by the current decisions.

Designing architecture is guided by patterns and tactics that are well-known solutions to commonly occurring design problems. In creating the architecture, attention must also be given to allocating functional responsibilities of the system to the different elements of the architecture. PACE uses the system context to determine all its actors, their use cases, and the corresponding functional responsibilities of the system. For ease of comprehension and consistency of expression of the use cases and functional responsibilities of the system, PACE uses the problem domain model. The model also plays a significant role in detailed design when functional responsibilities are ultimately allocated to the elements that realize the system.

1.6 Summary

Architecture plays a significant role in managing complexity, change, and distributed development of large-scale systems. It can be used for avoiding accidental complexity, adapting to change, and distributing development work commensurate with the communication, coordination, and collaboration needs of geographically distributed teams.

PACE is an approach described in this book for developing an architecture of a system that fulfills its business or mission objectives. The quality desired by these objectives is designed into the architecture using known architectural patterns and tactics, and the functionality is allocated to the elements of the architecture using the object-oriented analysis and design techniques.

1.7 Questions

1. Look at some of the other definitions of the term architecture. How are they similar? How are they different?
2. Conway’s law (Conway, 1968) suggests that the structure or architecture of a system being developed and the organization developing it must be closely aligned. Can you see some of the difficulties that might arise as a result of their misalignment?
3. Do you think an existing organizational structure will constrain the architectures of future products that might be developed?
4. Give some examples of incidental and accidental complexity to illustrate the difference between the two.
5. Modularity, splitting a system into units or modules that are structurally independent of one another, is one way of creating flexible systems that can manage change effectively. What do you understand by this statement? Illustrate with an example.

References

D. Avery, The evolution of flight management systems, IEEE Software 28 (1), 11–13, 2011.

L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, second edition. Boston: Addison-Wesley, 2003.

B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley, 2004.

F. Brooks, The Mythical Man-Month. Boston: Addison-Wesley, 1995.

S. Burger, O. Hummel, and M. Heinisch, Airbus cabin software, IEEE Software 30 (1), 21–25, 2013.

M. Conway, How do committees invent? Datamation 14 (5): 28–31, 1968.

R. De Neufville and S. Scholtes, Flexibility in Engineering Design. Cambridge, MA: MIT Press, 2011.

C. Hagen and J. Sorenson, Delivering military software affordably, Defense AT&L March–April 2013, pp. 30–34.

J. Herbsleb and R. Grinter, Splitting the organization and integrating the code: Conway’s law revisited, Proc. Int. Conf. Software Eng. 1999, pp. 85–95.

R. Sangwan, M. Bass, N. Mullick, D. Paulish, and J. Kazmeier, Global Software Development Handbook. Boca Raton, FL: Auerbach, 2006.

R. Sangwan, K. Jablokow, M. Bass, and D. Paulish, Asynchronous collaboration: Achieving shared understanding beyond the first 100 meters. In Proceedings of the ASEE Annual Conference and Exposition (CD-ROM), June 18–21, 2006, Chicago (19 pages).

R. Sangwan and J. Ros, Architecture leadership and management in globally distributed software development. In Proceedings of the First ACM Workshop on Leadership and Management in Software Architecture, International Conference of Software Engineering (ICSE), May 11, 2008, Leipzig, Germany, pp. 17–22.