Why Software Architecture is Important and Essential Activities
The architect should strive continually to simplify.
—Frank Lloyd Wright
Why is architecture important? What are the essential activities of architecture? And what practical implications do these activities have? These topics are addressed in this chapter. We already covered the definition of architecture and its relevance in Chapter 1, “Why Software Architecture Is More Important than Ever.”
To put architecture in perspective, let us focus on the development of a software system. This is an outcome of applying principle 1, Architect products; evolve from projects to products. For the remainder of this book, we use the term software system (or just system) to refer to the product being developed; in our case study, this is the Trade Finance eXchange (TFX) system.
As stated in our first book,1 there are three key sets of activities (or roles) for any successful software system (see Figure 2.1).
Figure 2.1 Balancing role of architecture
Within this context, the goal of architecture is to balance customer demand and delivery capacity to create a sustainable and coherent system. The system not only should meet its functional requirements but also should satisfy the relevant quality attributes, which we discuss later in this chapter.
A key aspect about the topic of architecture and architects is that it traditionally assumes one all-seeing and wise individual is doing architecture. In Continuous Architecture, we propose to move away from this model. We refer to “architecture work” and “architectural responsibility” instead. These terms point to the importance of the activities, while emphasizing the responsibility of the team rather than of a single person.
In his seminal book, The Mythical Man Month,2 Frederick Brooks puts a high priority on conceptual integrity and says that having the architecture come from a single mind is necessary to achieve that integrity. We wholeheartedly agree with the importance of the conceptual integrity but believe that the same can be achieved by close collaboration in a team.
Combining the Continuous Architecture principles and essential activities outlined in this section helps you protect the conceptual integrity of a software system while allowing the responsibility to be shared by the team. This should not be interpreted to mean that one individual should never undertake the role of architect, if that is appropriate for the team. What is key is that if people do undertake the role, they must be part of the team and not some external entity.
Essential Activities Overview
From a Continuous Architecture perspective, we define the following essential activities for architecture:
Focus on quality attributes, which represent the key cross-cutting requirements that a good architecture should address. Quality attributes—performance, scalability, and security, among others—are important because they drive the most significant architectural decisions that can make or break a software system. In subsequent chapters, we discuss in detail architectural tactics that help us address quality attributes.
Drive architectural decisions, which are the primary unit of work of architectural activities. Continuous Architecture recommends explicitly focusing on architectural decisions because if we do not understand and capture architectural decisions, we lose the knowledge of tradeoffs made in a particular context. Without this knowledge, the team is inhibited from being able to support the long-term evolution of the software product. As we refer to our case study, we highlight key architectural decisions the team has made.
Know your technical debt, the understanding and management of which is key for a sustainable architecture. Lack of awareness of technical debt will eventually result in a software product that cannot respond to new feature demands in a cost-effective manner. Instead, most of the team’s effort will be spent on working around the technical debt challenges—that is, paying back the debt.
Implement feedback loops, which enable us to iterate through the software development life cycle and understand the impact of architectural decisions. Feedback loops are required so that the team can react quickly to developments in requirements and any unforeseen impact of architectural decisions. In today’s rapid development cycles, we need to be able to course-correct as quickly as possible. Automation is a key aspect of effective feedback loops.
Figure 2.2 depicts the Continuous Architecture loop that combines these elements.
Figure 2.2 Essential activities of architecture
Clearly, the main objective of the essential activities of architecture is to influence the code running in the production environment.3 As stated by Bass, Clements, and Kazman, “Every software system has a software architecture.”4 The main relationships among the activities are summarized as follows:
Architectural decisions directly impact the production environment.
Feedback loops measure the impact of architectural decisions and how the software system is fulfilling quality attribute requirements.
Quality attribute requirements and technical debt help us prioritize architectural decisions.
Architectural decisions can add or remove technical debt.
It might come as a surprise that we do not talk about models, perspectives, views, and other architecture artifacts. These are incredibly valuable tools that can be leveraged to describe and communicate the architecture. However, if you do not undertake the essential activities we emphasize, architecture artifacts on their own will be insufficient. In other words, models, perspectives, views, and other architecture artifacts should be considered as a means to an end—which is to create a sustainable software system.
The following sections discuss each of the essential activities in more detail. We complete this chapter with a summary view of common themes we have observed in today’s software architectural practice that complement the essential activities.