Why is software architecture important?

Author: [US] Len Bass et al.

Chapter 2 Why Software Architecture Matters

If architecture is the answer, what is the question?

This chapter mainly discusses why architecture is important from a technical perspective. We'll examine 13 important reasons why. You can use them to drive the creation of new architectures, or to analyze and optimize existing system architectures.

1) An architecture can inhibit or support quality properties of a system.

2) Decisions made in the architecture allow you to reason and change management as the system evolves.

3) The analysis of the architecture can predict the quality of the system in advance.

4) A documented architecture enhances communication among stakeholders.

5) Architecture is the vehicle for the earliest, and therefore most fundamental, and hardest-to-change design decisions.

6) Architecture defines a set of constraints for subsequent implementations.

7) Architecture determines the structure of the organization and vice versa.

8) Architecture can provide the basis for incremental development.

9) Architecture is the key artifact that allows architects and project managers to reason about cost and schedule.

10) Architecture can be created as a transferable, reusable model that forms the core of the product line.

11) Architecture-based development focuses on the incorporation of components rather than simply on their creation. 12) Architecture guides developer creativity and reduces design and system complexity by limiting the range of design alternatives. 13) Architecture can be the basis for training new team members.

Even if you already believe that architecture is important and don't have to repeat it 13 times, think of these 13 points (which form the outline of this chapter) as 13 useful ways to use architecture in your projects, or to justify the investment in architecture.

2.1 Inhibiting or supporting the quality properties of the system

The ability of a system to meet its desired (or required) quality attributes is essentially determined by the architecture. Keep this in mind if you can't recall anything else in this book.

This relationship is so important that we devote the second part of the book to elaborate on this information. Until then, keep the following examples in mind:

If your system requires high performance, then you need to focus on managing the time-based behavior of elements, their use of shared resources, and the frequency and amount of communication between elements.
If modifiability is important, then you need to be concerned with assigning responsibilities to elements and limiting the interaction (coupling) of these elements so that most changes to the system affect only a few of these elements. Ideally, each change will only affect a single element.
If your system must be highly secured, then you need to manage and secure communication between components and control which components can access which information. You may also need to introduce specialized elements into the architecture (such as authorization mechanisms) to set a strong "boundary" against intrusion.
If you want your system to be safe and reliable, you need to design safeguards and recovery mechanisms.
If you believe that performance scalability is important to the success of your system, then you need to localize the use of resources so that higher capacity resources are brought in instead, and you must avoid hardcoding in resource assumptions or resource limits.
If your project needs to deliver a subset of system increments, then you must manage usage between components.
If you want elements in your system to be reusable in other systems, then you need to limit the coupling between elements so that when you extract an element, it doesn't bring out too much that is relevant to the current environment.

Strategies for these and other quality attributes are very architectural. However, architecture alone cannot guarantee the required functionality or quality of a system. Bad downstream design or implementation decisions can always undermine sound architectural design. As we often say (mostly in jest): what the architecture gives, the implementation takes away. Decisions in all phases of the software lifecycle, from architectural design to coding, implementation, and testing, affect system quality. So quality is not exactly a function of architectural design, but it is the starting point.

2.2 Reasoning and Change Management

This is a corollary of the above point.

Modifiability—the ease with which changes can be made to the system—is a quality attribute (discussed in the previous section), but it is such an important one that we specifically mention it in 13 Reasons Why. The software development community is beginning to recognize the fact that approximately 80% of the total cost of a typical software system occurs after initial deployment. Most systems people use are at this stage. Many programmers and software designers never take on new development—they work within the constraints of existing architectures and code bodies. Virtually all software systems change during their life cycle to accommodate new features, new environments, fix bugs, etc. But the reality is that these changes are often fraught with difficulties.

Every architecture, whatever it is, divides possible changes into three categories: local, non-local, and architectural. Local changes can be done by modifying a single element. For example, add new business rules in the pricing logic module.

Non-local changes require modifications to multiple elements without affecting the underlying architecture. For example, add a new business rule in the pricing logic module, then add the fields required by the business rule in the database, and modify the user interface as needed. Architectural changes affect the fundamental way elements interact and may require changes to the entire system.

For example, changing a system from single-threaded to multi-threaded. Obviously, local changes are ideal, so the most common changes in effective architectures are local and therefore easy to make. Non-local changes are less desirable, but they do have the advantage that they can often be staged, that is, rolled out in an orderly fashion over time. For example, you might first make a change to add a new pricing rule, and then make a change to actually deploy the new rule.

Deciding when to change is critical, deciding which change paths have the least risk, assessing the impact of changes, and deciding on the order and priority of changes all require a broad understanding of the relationships, capabilities, and behavior of software elements. These tasks are all part of the architect's job. Reasoning about and analyzing the architecture provides the insight necessary to make decisions about anticipated changes. If you don't take this step, and don't take care to maintain the conceptual integrity of your architecture, you will almost certainly accumulate architectural debt. We discuss this issue in Chapter 23.

2.3 Predicting System Quality

This point follows from the previous two points: Architecture not only imparts quality properties to a system, but does so in a predictable manner.

This might seem obvious, but it's not. Design an architecture, make a series of rather arbitrary design decisions, build the system, test for quality attributes, and hope for the best. Whoops — not fast enough and vulnerable? Start getting hacked.

Fortunately, it is possible to predict the quality of the system based on the results of the system architecture evaluation. If we know that certain types of architectural decisions will support certain quality attributes in the system, then we can make those decisions and reasonably expect to be rewarded with corresponding quality attributes. Later, when inspecting the architecture, we can determine whether a decision has been made and confidently predict that the architecture will exhibit the corresponding qualities.

This combined with the previous point means that architecture largely determines system quality, and even better! We know how it does it, and we know how to make it do it.

Even if you sometimes don't perform the quantitative analytical modeling necessary to ensure that you can deliver a compliant architecture, this assessment based on the meaning of quality attributes can be invaluable for early detection of potential problems.

2.4 Communication among stakeholders

As mentioned in Chapter 1, an architecture is an abstraction, which is useful because it represents a simplified model of the entire system (as opposed to an infinite detail of the entire system), which you can remember, and so do others on the team. can remember it. An architecture is a public abstraction of a system that most, if not all, of the stakeholders can use as a basis for creating mutual understanding, negotiating, forming consensus, and communicating with each other. Architecture (or at least parts of it) is so abstract that most non-technical people, especially if guided by an architect, can understand it. And this abstraction can be refined into a technical specification rich enough to guide implementation, integration, testing, and deployment.

Every stakeholder of a software system (clients, users, project managers, coders, testers, etc.) is concerned with different system characteristics that are affected by the architecture. For example:

Users care that the system is fast, reliable, and available when needed.
The customer (the person paying for the system) cares that the architecture can be implemented on schedule and on budget.
Managers are concerned with whether the architecture (besides cost and schedule aspects) maximizes the ability of teams to work independently, interacting in a disciplined and controlled manner.
Architects are concerned with strategies to achieve all of these goals.
Architectures provide a common language that can express, negotiate, and solve different problems, even for large and complex systems. Without such a common language, it is difficult to fully understand large systems, leading to early decisions that affect quality. As we will see in Chapter 21, architectural analysis both relies on some level of communication and enhances that communication.

Chapter 22 on Architecture Documentation covers stakeholders and their concerns in more depth.

"What Happens When I Push This Button": Architecture as a Tool for Stakeholder Communication

Project reviews go on endlessly. Government-funded programs are behind schedule, over budget, and large enough to attract the attention of Congress. Now the government is making up for past oversights with marathon one-on-one reviews. The contractor recently accepted a buyout, and things haven't improved. It was the afternoon of the second day, and the meeting agenda called for a presentation of the software architecture. The young architect (apprentice of the chief system architect) bravely explained how the software architecture of large-scale systems can meet the requirements of real-time, distributed, and high reliability. He has a solid statement and a solid structure. This is reasonable. The audience, some 30 government representatives with varying management and oversight roles in the tricky project, were weary. Some of them are even thinking that maybe they should get into real estate instead of enduring another marathon of "let's finally get this right" reviews.

The slide shows the main software elements of the system's runtime in semi-formal box-line notation. The young architects said the names were acronyms, uninterpreted and without any semantics. These lines show data flow, message passing, and process synchronization. As explained by the architects, these elements are internally redundant. "In the event of a malfunction," he said, marking one of the lines with a laser pointer, "a reset mechanism would be triggered along this path when..."

"What happens when you press the mode select button?" an audience member interrupted. He is a government attendee representing the users of this system.

"Can you say that again?" the architect asked.

"The mode select button, what happens when you press it?" he said.

"Well, this triggers an event in the device driver, here," the architect begins with a laser pointer, "and then reads the registry and interprets the event code. If it's a mode selection, it signals the blackboard, which in turn Objects subscribed to this event signal..."

"No, I mean what did the system do," interrupted the questioner, "does it reset the monitor? What happens if this happens while the system is reconfiguring?"

The architect looks a little surprised and shakes off the laser pointer. It's not an architectural question, but since he's an architectural software architecture practitioner and therefore familiar with the requirements, he knows the answer. He said, "If the command line is in setup mode, the display will reset. Otherwise, an error message will be displayed on the console, but the signal will be ignored." He put the laser pointer back and said, "What I just said The restart mechanism..."

"Well, I'm just wondering," said the user rep, "because I see from your diagram that the display is sending a signal to the target location module." "What happens?" another audience member said to the first questioner Asked, "Do you really want the user to get schema data on reconfiguration?" For the next 45 minutes, the architect watched the audience spend his time debating what the correct behavior of the system should be in various esoteric states —This is an absolutely necessary issue that should be clarified when the requirements are formulated, but it is not clarified for some reason. The debate wasn't about the architecture, but the architecture (and its graphical representation) sparked the debate.

It's natural to think of architecture as the basis for communication—between architects and some stakeholders other than developers, for example, managers use architecture to create teams and allocate resources. But what about users? After all, architecture is invisible to users, so why would they use architecture as a tool for understanding the system?

The truth is they do. In this example, the questioner has sat for two days looking at all the diagrams for functionality, operation, UI, and testing. Even though he was tired and wanted to go home, the first slide on architecture made him realize that there was something he didn't understand. Participating in many architecture reviews has convinced me that looking at systems in a new way stimulates people's thinking and brings up new questions.

Schemas are often a new approach to users. The questions users ask are behavioral in nature, and during a memorable architecture review a few years ago, user representatives were more interested in what the system was going to do than how it would do it, and quite naturally they were . Until then, the only connection a user has with a provider is with the latter's marketers. Architects are the first legitimate system experts users can approach, and they don't hesitate to jump at the opportunity.

Of course, a detailed and thorough requirements specification would improve this, but requirements are not always clear or available for various reasons. In the absence of such a requirements specification, architectural specifications often help to raise questions and improve requirements clarity. It is wiser to recognize this possibility than to resist it.

Sometimes such walkthroughs expose unreasonable needs whose utility can then be revisited. This type of review emphasizes the synergy between the requirements and the architecture, and it frees the young architect in the story by giving him the opportunity to process this type of information throughout the review session. And the user rep won't feel like a fish out of water, asking his question at an obviously inappropriate time. —PCC

2.5 Early Design Decisions

Software architecture is the expression of early design decisions about the system, and these early constraints have a huge impact on the subsequent development, deployment and maintenance of the system. This is also the earliest point in time for a detailed review of these important design decisions affecting the system.

Any design in any discipline can be viewed as a series of decisions. When painting, even before starting to paint, the artist begins to decide on the canvas and the material—oil, watercolor, or crayons. Once you start drawing, other decisions are made accordingly: where is the first line, what is its width, what is its shape? All of these early decisions have a big impact on how the final picture will look, and each decision constrains many that follow. Each individual decision may seem insignificant, but early decisions in particular have disproportionate importance because they affect and limit many things that follow.

The same goes for architectural design. Architecture design can also be seen as a series of decisions. Changing these earlier decisions will have a knock-on effect in terms of additional decisions that must be changed now. Yes, sometimes the architecture has to be refactored or redesigned, but this is not an easy task because one snowflake can start an avalanche.

What early design decisions are embodied in the software architecture? think about it:

Is the system running on one processor or distributed across multiple processors? Is the software layered? If yes, how many layers? What does each layer do? Is the communication between components synchronous or asynchronous? Do they interact through control flow or data flow, or both? Will the information flowing through the system be encrypted? Which operating system do you use? Which communication protocol to choose?

Imagine if you had to change one or other of the related decisions that dictated some structure of the architecture and how it interacted in the first place, changing the decisions would be a nightmare.

2.6 Implementation Constraints

If you want an implementation to be architecturally compliant, it must conform to the design decisions specified by the architecture, including that it must have the set of elements specified by the architecture, that the elements must interact with each other in the manner specified by the architecture, and that each element must behave as specified by the architecture. fulfill its duties. Each specification is a constraint on the implementer.

Element builders must be familiar with the specs corresponding to the elements, they may not understand the overall architectural trade-offs - the architecture (or architect) just constrains the element builders in such a way as to satisfy the trade-offs. Performance constraint assignment is a classic example where architects often assign the performance constraints of a large function to the involved software units. If each unit satisfies the constraints, then the whole will too. And implementers of each component may not know the overall performance constraints, but only their own.

In contrast, architects do not need to be proficient in all aspects of algorithm design or complex programming languages. Of course, they should have enough knowledge to avoid designing something that is difficult to implement. Architects are those responsible for making, analyzing, and implementing architectural decisions and trade-offs.

2.7 Impact on organizational structure

Architecture not only dictates the structure of the system being developed, but also profoundly affects the structure of development projects (and sometimes the structure of the entire organization). In a large project, the usual way to divide the work is to assign different parts of the system to different groups. This so-called work breakdown structure is shown in Chapter 1. Because an architecture encompasses the broadest breakdown of a system, it is often used as the basis for a work breakdown structure. The work breakdown structure in turn determines the planning, scheduling, and budgeting units, communication channels between teams, configuration control and file system structures, integration and testing plans and procedures, and even project details, such as how the project intranet is organized, when the company picnic Who sits with whom. Teams communicate with each other based on interface specifications. When the operation and maintenance team is formed, the corresponding division of labor will also be carried out according to the specific elements in the software structure-database, business rules, user interface, device drivers, etc.

A side effect of establishing a work breakdown structure is that certain aspects of the software architecture are frozen. A group responsible for one of the subsystems may refuse to assign its responsibilities to other groups. If those responsibilities are already contractually established, changing responsibilities can become costly and even lead to litigation.

Therefore, once the architecture is agreed upon, it becomes very expensive to modify it significantly for management and business reasons. So for a large system, before making a specific choice, be sure to analyze its software architecture.

2.8 Enabling Incremental Development

Once the architecture is defined, it can be used as the basis for incremental development. The first increment can be a skeletal system with at least some infrastructure - initialization of elements, communication, shared data, accessing resources, reporting errors, logging activity, etc., but most of the application functionality of the system is absent.

Building infrastructure and building application capabilities can be done simultaneously. Design and build a small infrastructure to support a small number of end-to-end functions, iterating until complete.

Many systems are built as skeleton systems and then extended with plugins, packages, or extension libraries. Such as R language, VisualStudioCode and most web browsers. Whenever an extension is added, extra functionality is added. This approach entails ensuring that the system will perform early in the product lifecycle. As extensions continue to increase, earlier versions are replaced by more refined ones, and the system moves closer and closer to the final goal. In some cases, these are low-fidelity versions or prototypes of the final functionality; in other cases, they may be surrogates, consuming and generating data at a moderate rate, but doing little else. Among other things, this allows potential performance (and other) issues to be identified early in the product life cycle.

The practice gained attention in the early 2000s through the ideas of Alistair Cockburn and his "walking skeleton" concept. More recently, it has been adopted by those who employ MVP (Minimum Viable Product) as a risk reduction strategy.

The benefits of incremental development include reducing potential risks in the project. If the architecture is for a family of systems, the infrastructure can be reused across the family, reducing the cost per system.

2.9 Cost and Schedule Estimation

Cost and schedule estimates are an important tool for project managers. They help the project manager to obtain the necessary resources and monitor the progress of the project. One of the architect's responsibilities is to assist the project manager with cost and schedule estimates early in the project life cycle. While top-down estimating is useful for setting goals and allocating budgets, cost estimates based on bottom-up understanding of parts of the system are often more accurate than estimates based purely on top-down knowledge of the system.

As we said, the organization and work breakdown structure of a project is almost always based on its architecture. Each team or individual responsible for a work item will be able to make more accurate estimates of the work to be performed than the project manager and will have more autonomy in achieving those estimates. But the best cost and schedule estimates are usually agreed between top-down estimates (created by architects and project managers) and bottom-up estimates (created by developers). Estimates produced through discussion and negotiation during this process are much more precise than using either method.

It is helpful to review and verify system requirements. The more you know about the scope, the more accurate your cost and schedule estimates will be.

Chapter 24 delves into the role of architecture in project management.

2.10 Transferable, reusable models

The earlier you perform reuse in the software lifecycle, the greater the benefits. Code reuse is a good thing, while architectural reuse provides great opportunities for reuse of systems with similar needs. When architectural decisions can be reused across multiple systems, all of the earlier decision outcomes described earlier transfer to those systems as well.

A product line or product family is a group of systems built using the same set of shared assets (software components, requirements documents, test cases, etc.). Chief among these assets is the architecture designed for the entire product line. The product line architect chooses an architecture (or a series of closely related architectures) that serves all members of the product line, defining what is fixed and what is variable.

Product Lines represent a powerful approach to multi-system development with orders of magnitude payoffs in time-to-market, cost, productivity, and product quality. The power of architecture is at the heart of this approach. Like other capital investments, the architecture of a product line is a shared asset of the development organization.

2.11 Architecture allows combining independently developed elements

Whereas earlier software paradigms had coding as the primary activity, with progress measured in lines of code, architecture-based development typically focused on combining or assembling elements that might have been developed separately, or even independently of each other. This combination is possible because an architecture defines elements that can be incorporated into a system. Architectures constrain possible substitutions (or Add to). We will elaborate on these points in Chapter 15.

Off-the-shelf commercial components, open source software, publicly available apps and web services are all independently developed elements. The complexity and ubiquity of integrating many independently developed elements into a system has spawned an entire industry of software tools such as Apache Ant, Apache Maven, MSBuild, and Jenkins.

For software, there are the following benefits:

Shorter time to market (using someone else's off-the-shelf solution is easier than developing your own).
Improved reliability (widely used software is better at eliminating bugs).
Lower costs (software vendors share development costs among their customer base).
Increased flexibility (if the element you want to buy is not extremely special, there may be multiple sources, thus increasing the room for bargaining).

An open system defines a set of standards for software elements—how they behave, how they interact with other elements, how they share data, and so on. Open systems support and even encourage many different suppliers to be able to produce elements. This avoids "supplier binding", where only a single supplier is able to supply elements and therefore charges extra. An open system is achieved by defining an architecture of elements and their interactions.

2.12 Limiting the range of design options

As architectural solutions proliferate, although software elements can be combined in more or less infinite ways, if we actively choose fewer elements and limit their interrelationships, we can minimize the design complexity of the system being built.

A software engineer is not a creative and libertarian artist. Instead, engineering is about procedures, and procedures are, to some extent, a substitute vocabulary for limiting proven solutions. These proven solutions include tactics and patterns, which are discussed extensively in Part II. Reusing ready-made elements is also another way to limit your design vocabulary.

Limiting your design vocabulary to proven solutions yields the following benefits: Improved reusability.

More regular, simpler designs are easier to understand and communicate, and lead to more reliably predictable results. Easier to analyze with more confidence. Shorter selection times. Broader interoperability.

Unprecedented designs are risky. A proven design is verifiable. This is not to say that software design can never innovate or provide new and exciting solutions, of course it can, but such solutions should not be invented just for novelty, when existing solutions are not sufficient for the problem at hand. Innovative solutions should be sought.

The characteristics of the software depend on the choice of architectural tactics or patterns. Selecting tactics and patterns that are more appropriate for a particular problem can improve the final solution, possibly by making it easier to arbitrate conflicting design constraints, improve one's understanding of the design environment, and help uncover inconsistencies in requirements. We'll discuss architectural tactics and patterns in Part II.

2.13 Basics of Training

Architecture, including a description of how elements interact to achieve desired behavior, can serve as a first lesson for new project members about the system. This is further evidence that an important use of software architecture is to support and encourage communication between different stakeholders and provide a common point of reference for all of them.

The module view is an excellent way to show people the project structure (eg who does what, which team is assigned to which part of the system, etc.). The Component and Connector views are excellent options for explaining how the system works and accomplishes its tasks. The Assignment view shows that a new project member is assigned an appropriate project development or deployment environment for him.

2.14 Further reading

The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise by Gregor Hohpe describes the architect's unique ability to interact with people at all levels inside and outside the organization and facilitate stakeholder communication [Hohpe20].

The granddaddy of the paper on architecture and organization is the literature [Conway68]. Conway's Law states: "Organizations that design systems . . . can design only replicas of those organizational communication structures."

Cockburn described the concept of a "walking skeleton" in Agile Software Development: The Cooperative Game [Cockburn06].

A good example of an open system architecture standard is AUTOSAR, which was developed for the automotive industry (autosar.org).

For a detailed treatment of building software product lines, see [Clements16]. Feature-based product line engineering is a modern, automation-centric approach to building product lines that extends the scope from software to systems engineering. A good summary can be found in the literature [INCOSE19].

2.15 Question Discussion

1. If you have no memory of this book, what do you remember?

2. Take the opposite stance against the 13 reasons why architecture is important as set forth in this chapter: propose a set of circumstances in which architecture is unnecessary to achieve the corresponding outcome. Prove your position. (Try to think of different scenarios for each of these 13 reasons.)

3. This chapter argues that architecture brings many tangible benefits. How would you measure the benefits of each of these 13 points in a given project?

4. Suppose you want to introduce architecture-centric practices to your organization, and your management is open to it, but wants to know the ROI of doing so. How would you respond?

5. Rank the 13 reasons listed in this chapter according to some criteria that is meaningful to you. Justify your answer. Or, if you could only choose two or three of them to facilitate the use of the architecture in a project, which ones would you choose and why?

Why is software architecture important?

Guess you like