Preface

Modern-day projects require software and systems engineers to work together in realizing architectures of large and complex software-intensive systems. To date, the two have been using their own concepts, techniques, methods, and tools when it comes to requirements, design, testing, maintenance, and evolution of these architectures. This book looks at synergies between the disciplines of software and systems engineering and explores practices that can help software and systems engineers work together more effectively as a unified team.

The book illustrates an approach to architecture design that is driven from systemic quality attributes determined from both the business and the technical goals of the system rather than just its functional requirements. This ensures that the architecture of the final system clearly, and traceably, reflects the most important goals for the system. While superficially the most important goals of any system are its functions, in practicality it is the quality attribute requirements that have the greatest impact on a system’s lifetime value because it is these requirements that determine how easily the system accepts future change and how well the system meets the reliability and security needs of its operators and owners. By making these requirements “first-class citizens,” the architecture meets them first.

Furthermore, most quality attribute requirements are systemic properties: They are properties that the entire system must reflect rather than just one component or subsystem. They therefore cannot be easily built into an existing architecture. In essence, these properties must be designed into the architecture from the beginning. The architecture-centric design approach illustrated in this book addresses this directly by utilizing analytically derived patterns and tactics for quality attributes that inform the architect’s design choices and help shape the architecture of a given system.

The book is organized into eight chapters. Chapter 1 focuses on the importance of architecture in modern-day systems. The amount and complexity of software in these systems are on the rise. Avionics software in modern aircraft has tens of millions of lines of code. In fighter aircraft, this software controls 80% of what a pilot does. 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. A large proportion of software in these systems introduce design and operational complexity, making them high-risk systems. This chapter highlights the role of architecture in managing this complexity and a need for an architecture-centric engineering approach to designing complex systems that can be used consistently by software and systems engineers working on such projects.

Chapter 2 looks at the influence of business goals or mission objectives on the architecture of a system. Business goals correspond to quality attributes the end system must exhibit. 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 the architecture of a system. Understanding business goals and their implied quality concerns is therefore critical.

A system operates within a given context or an environment, and understanding a system’s operational aspects within its environment is also extremely important. Chapter 3 looks at the concept of operations or ConOps, a term used for the operational view of the system from the perspective of its users that gives a broad understanding of the capabilities a system must deliver to fulfill its mission objectives. An operational view helps clearly delineate where a system’s boundary is, what elements in its external environment a system must interact with, and what those interactions are.

If one must wait for a system to be developed to determine if it will meet the quality expectations of its stakeholders, there is an inherent risk that it may not. Architectural restructuring to achieve the desired qualities at this stage may be extremely difficult and costly. It is much more desirable to predict the systemic properties of a system from its design so corrections can be made before the system is committed to development. Patterns are known solutions to recurring design problems and therefore have qualities that can help predict the systemic properties of the system that is built using them. In prescribing solutions to problems, patterns may use many design decisions. These design decisions are known as tactics. Patterns and tactics are topics described in detail in Chapter 4.

When designing a system, one often must consider several requirements that have a strong influence on its architecture. Many of these requirements frequently conflict with each other. For instance, while one requirement may need the system to be highly secure, another may need the system to have quick response time. Making a system secure may introduce authentication, authorization, and encryption mechanisms that introduce latency, thereby slowing the system. Chapter 5 explores an approach to creating an architecture that systematically addresses the architecturally significant requirements while also dealing with trade-off situations created by requirements that conflict with each other.

Architecture is an artifact that serves many diverse needs for many diverse stakeholders. For instance, project managers use it for organizing projects and distributing the work among development teams, teams use it as a blueprint for their development work and for understanding how their work depends on those of others, and maintainers use it to understand the impact of change as the system evolves over time. Effectively communicating the architecture to meet the diverse needs of a broad set of stakeholders is the topic of discussion for Chapter 6.

Once the architecture has been designed, the development teams must then undertake detailed design and implementation of the individual components that make up the final product. What is detailed design for one, however, is architecture to another. It turns out that effort must be invested by the development teams to develop the internal architecture of these components as they create the final blueprint for implementation. The interplay between architectural work and the detailed design is explored in Chapter 7.

Complexity is the topic of the final chapter, Chapter 8, which shows how following architecture-centric practices outlined in this text can lead to significant reduction in accidental complexity that is a by-product of development methodologies that lack focus on systemic properties of a system that have a strong influence on its architecture.

The fundamental objective of the book is to explore and illustrate practices that can be helpful in the development of architectures of large-scale systems in which software is a major component. It should be particularly useful to those currently involved in such projects and who are looking at more effective ways to engage the software and systems engineers on their teams. The book can be also used as a source for an undergraduate or graduate-level course in software and systems architecture as it exposes the students to concepts and techniques used for creating and managing architectures of software-intensive systems.