A Bird’s-Eye View of Software Architecture Design

Requirements engineering and architecture design are two key factors for successful software development.

The risk of unwanted developments is particularly high in these areas, which is why they also offer the greatest potential for risk minimization and general optimization.

It’s not sufficient to address these two areas in isolation. On the contrary, it’s essential to ensure consistent integration of requirements engineering and architecture design if they are to influence each other positively. The so-called Twin Peaks Model emphasizes this relationship and requires iterative collaboration of requirements engineering and architecture design, as shown in this figure.

The impacts of requirements in terms of the effort involved can only be realistically assessed when an initial high-level architecture design is available. If the efforts assessed on the basis of the high-level architecture design are then presented to the customer, it’s not uncommon for them to waive certain requirements. However, existing design alternatives can indicate to those responsible for specifying the requirements that the requirements aren’t sufficiently precisely defined.

Objectives and Functions of Software Architecture Design

The central task of software architecture design is to find a design approach with which the functional and nonfunctional requirements defined by requirements engineering are implemented in a fully designed solution. This approach, however, isn’t a one-way street, as indicated by the Twin Peaks Model shown earlier.

Instead, the process involves continual compromise between the “request list” from requirements engineering and the software architect’s inventory of existing solutions, building blocks, and other architecture artifacts. As the next figure illustrates, this approach means the software architect develops the construction plan for the software system in coordination with relevant stakeholders (e.g., requirements engineer, customer, user, developer, tester, or administrator).

Because a new system or system enhancements should not be addressed in isolation, interfaces to other systems, affected organizations, execution platforms, and the implementation infrastructure also have to be taken into account. The interfaces, requirements, and constraints from the four adjacent areas found in the figure below must be considered and codesigned by the architect.

The architect must also take the entire lifecycle of the system and the adjacent areas referred to previously into account. Architecture always means investment in supporting elements to achieve flexibility and extensibility elsewhere. This, however, demands consideration of the corresponding lifecycles; otherwise, these investments may not be secure.

Overview of Software Architecture Design

Software architecture isn’t developed behind closed doors and demands teamwork from the many parties involved in the project. It’s therefore necessary to develop a common understanding of what forms part of a software architecture and what doesn’t, both within the current project and in its surrounding environment. This includes a common nomenclature for the most important terms such as interface or building block.

As shown in the previous figure, the architect has to consider interfaces not only with requirements engineering but also with other disciplines and roles involved in software development. A software architect designs an architecture starting from the conditions, constraints, and requirements of these surrounding areas, thus defining the essential aspects of the solution, such as the building block structure and interaction patterns. Viewed in isolation, the architecture design process isn’t sequential. Even the term “iterative approach” doesn’t sufficiently describe the nature of the architecture design process. The individual tasks involved in the process can’t be meaningfully brought into a linear sequence. Instead, as shown below, we subdivide architecture design into four activities of equal weighting.

These four activities are described as follows:

• Analysis of requirements and constraints: The central task of architecture analysis is to analyze the objectives, constraints, and the functional (and, in particular, nonfunctional) requirements that come from requirements engineering in the context of the other surrounding areas. This must include an analysis of quality, flexibility (the stakeholder is open to changes), and susceptibility to change (changes as a result of external influences over time) of the requirements. Gaps in the requirements must be identified. Particularly with regard to nonfunctional requirements, there is normally room for improvement because those responsible for specifying the requirements often regard them as being self-evident. All parties involved in the project—especially designers and developers—have to develop an initial understanding of the architecture style and the technical infrastructure. This is the central architectural metaphor of the system.
• Development of architecture views and technical concepts: Here, the architecture is developed in more detail. In particular the view-based description of the different architectural levels (functional and technical levels) also takes place here. The objective is to break down the functional requirements to the corresponding functional architecture level, and for the relevant aspects of the nonfunctional requirements to design and document appropriate cross-cutting solution building blocks at the technical architecture level. All the while, the fundamental solution framework given by the architecture style and the technical infrastructure must be taken into account.
• Evaluation of architecture and design decisions: The developed architecture must undergo quality assurance. Various methods can be used here, from diverse review techniques through technical prototypes and tests to analysis and evaluation. The critical aspect here is the derivation of specific scenarios from the requirements to ensure the quality of the resulting architecture.
• Implementation support and review: The importance of the communication of software architecture to all parties involved in the project is often underestimated. Only when all those involved—from the developer through to the customer—have understood and accepted the software architecture, can it be successfully implemented and achieve the desired effects. The software architecture must, of course, be communicated in such a way that it can be understood by the recipient. This means that the architecture is explained to the customer with a different level of detail than to the developer. This process isn’t a one-way street, but rather a process of learning from one another and understanding. During its implementation, the architecture continues to be discussed with the parties involved in the project and any open issues, potential for improvement, faults and errors, and approaches for further development continue to be identified.

Effective tool support should also be established on the basis of these concepts. This ensures optimal support for the individual areas of activity involved in the design of the software architecture—for example, analysis and management of requirements, handling of architecture models and documentation, quality assurance, and communication. Autonomous tool solutions already exist for these individual task areas. These stand-alone tools must be integrated as seamlessly as possible to ensure that the architect can use them effectively. Because the design process isn’t sequential but rather iterative and incremental (or even concurrent), it’s especially important to close the gaps between the individual tools.

Interplay Between Activities and Abstraction Levels within the Design

As already explained, the individual activities involved in the software architecture design process can’t be arranged linearly. They are areas of equal importance to which the software architect has to devote sufficient attention depending on the current project situation. The architecture design is a continuous interplay between the activities shown earlier:

• Analysis of requirements and constraints
• Development of architecture views and technical concepts
• Evaluation of architecture and design decisions
• Support and review of the implementation

During the architecture design process, the software architect carries out these four activities in a sequence that suits the needs and context of the project. This iterative and incremental interplay of activities is associated with a top-down and bottom-up change of the abstraction levels and perspectives shown earlier.

• Requirements and constraints of the surrounding areas
• Software architecture with abstraction levels, for example:
  • Architecture style and technical infrastructure
  • Functional and technical architecture levels
• Program design and implementation

This way, we can switch from the topmost abstraction level of the conditions, constraints, and requirements of the surrounding areas via the abstraction levels in the software architecture (architecture style and technical infrastructure, plus the functional and technical architecture levels) through to the bottommost abstraction level, which consist of the software program itself, the program’s design, and its implementation. The architecture design process is thus a continuous top-down and bottom-up flow within the abstraction levels, along with a continuous change of activities that are performed interactively and incrementally. This is illustrated in this figure.

Within this process, the project setting and constraints define the constraints of the architecture. In return, the architecture design provides data on technical project risks and planning information.

Requirements engineering describes the functional and nonfunctional requirements for the architecture design coming from those accountable for the system. As explained previously, this isn’t a one-way street, and the architecture design also provides feedback on the feasibility of implementing the requirements and their consequences for requirements engineering.

The partially or fully available technical infrastructure—for example, server infrastructure, operating systems (OSs), requirements for programming languages, and the operating organization—must also be taken into consideration during the architecture design process. The interface with operations is especially far too often neglected, which can result in major problems during system deployment. Once again, this isn’t a one-way street. The architecture design can produce new technical infrastructure requirements—for example, further expansion of the server landscape or the integration of additional middleware.

Finally, the architecture design provides the specifications for detailed design and programming. However, return flows of information are also necessary here. Unforeseen problems can arise during the implementation of the software architecture. If these problems aren’t communicated to the software architect and a supposedly simple solution is implemented instead, this can undermine the entire architecture. It’s therefore important to discuss such problems with the software architect and to jointly develop a solution that may result in changes to the architecture.

Side Note: A Software Architect’s Tasks and Relationships with Other Roles

The task of the architect is to develop a blueprint for the system based on the functional and nonfunctional requirements, while taking requirements and constraints of the surrounding areas into account. The subsequent implementation, maintenance, support, and enhancements are then based on this blueprint. This requires development of a complete and concise architectural description. On one hand, the architectural description serves as a communication and discussion platform, and, on the other hand, as a design and implementation plan. As shown in the next figure, the architect must provide a large number of interfaces to almost all the roles involved in a software development project.

• Communication and discussion platform: Based on the architecture, the architect presents the feasibility of the requirements to the requirements engineer, the customer, and possibly the user too. During this process, the architect provides support by correlating, prioritizing, and reflecting on functional and nonfunctional requirements. He can identify contradictions and discrepancies, and ultimately ensures that the requirements can be implemented. The architect identifies ways of integrating existing solutions and systems, and aligns the requirements to the existing system architecture and hardware. He develops, evaluates, and assesses alternative solution approaches. Finally, based on the software architecture, the architect advises the project manager on project and iteration planning, and supports risk analysis and mitigation, thus providing support for the definition of work structure and assignment.
• Design and implementation plan: The architect is a central point of contact for the system’s developers. He defines the system’s building blocks as well as their interfaces and interaction patterns. He has to encourage the integration of new technologies and innovative solution approaches and discuss them with the developers. He is in charge of the development, introduction, training, and reviewing of programming guidelines. The architect assists the developers in the development of prototypes and sample solutions, as well as accelerates reuse of existing (partial) implementations. He explains the architecture, provides development specifications, passes on his experience, and carries out code reviews. He also supports the testers. In an ideal situation, the architect even defines testing conditions and specific test cases for testing specific architecture objectives. He assists in the definition of test sequences and dependencies. Finally, he is the point of contact for fault and error reports that are relevant to the architecture. He is also the central point of contact for organizational roles such as operations staff, security experts, and the like.

Editor’s note: This post has been adapted from a section of the book Software Architecture Fundamentals: iSAQB-Compliant Study Guide for the Certified Professional for Software Architecture—Foundation Level Exam by Mahbouba Gharbi, Arne Koschel, Andreas Rausch, and Holger Tiemeyer.