7. Other Design Methods

Over the past two decades, a number of architecture design methods have been proposed and documented. In this chapter we briefly present some of the most well-known methods, which we then relate and compare to ADD. We begin with a “general model” of architecture design, then briefly present five other design methods. We conclude the chapter with a discussion of how ADD differs from these other methods.

The derived general model, shown in Figure 7.1, consists of three main activities that are present in all five models reviewed:

Architectural analysis. In this activity, requirements (called concerns) and the system context are used as inputs to determine a set of architecturally significant requirements (ASRs).

Architectural synthesis. This activity is described as being the core of architecture design. It proposes architecture solutions to a set of ASRs, moving from the problem to the solution space. The results of this activity are candidate architectural solutions, which are partial or complete architecture designs and include information about the rationale.

Architectural evaluation. This activity ensures that the architectural decisions are the right ones. Candidate architectural solutions are measured against ASRs. Several evaluations of different architectural solutions are expected, but the eventual result is the validated architecture.

Hofmeister and her colleagues further explain that these activities do not proceed sequentially, but rather architects proceed in small “leaps” as they move from one activity to another. Progress is driven by an implicit or explicit backlog of smaller needs, issues, problems, and ideas that architects need to address (Figure 7.2).

This general model presented by Hofmeister et al. is not detailed, by intent, because it abstracts the specific techniques found in other design processes, including ADD. Thus the model can represent ADD, but also covers a bigger scope of architecture development, where architectural requirements gathering and analysis are performed using methods such as QAW, architectural synthesis is performed using methods such as the ones presented in the paper, and architectural evaluation is performed using methods such as ATAM.

Stage 3 is focused on design; it is where an initial architectural design is created or refined. For new systems, the first iteration of this process promotes the rapid creation of a “notional” or initial architecture. This iteration proceeds by first establishing the system context and then performing decomposition in an iterative manner to produce structures. In ACDM, decomposition is driven by quality attribute scenarios and constraints, but functional requirements are also considered. In subsequent iterations, issues uncovered in the architecture review (Stage 4) also serve as inputs. ACDM suggests using patterns to support decomposition and using more than one perspective (static, dynamic) during the process. After decomposition occurs, responsibilities are associated with the elements and interfaces are defined.

ACDM has a broader scope than ADD, as it encompasses the whole architecture development life cycle (requirements, design, evaluation, and documentation) in its 8 stages. Stage 3 of ACDM is the equivalent of ADD. However, ACDM provides less detailed guidance than ADD on how to perform this crucial step. ADD and ACDM can be used together, however. To do so, you can simply use ADD directly in stage 3 of ACDM.

Inception. In this phase, the project is conceived and feasibility is evaluated.

Elaboration. In this phase, many aspects that are necessary to successfully perform the project are handled. One of these aspects is the design of the architecture.

Construction. In this phase, the system is built iteratively.

Transition. In this phase, the completed system is transitioned from the development environment to the end-user environment.

For RUP, architecture is a fundamental aspect of system creation, and activities are associated with it across the different phases and, in particular, in the inception and elaboration phases. In the inception phase, RUP defines an activity called “perform architectural synthesis”, whose goal is to construct and assess an architectural proof-of-concept to demonstrate the feasibility of the system. This activity includes tasks such as defining a system context, performing architectural analysis (which actually refers to defining a candidate architecture), constructing an architectural proof-of-concept (a prototype), and evaluating the viability of the proof-of-concept.

The elaboration phase includes two activities associated with software architecture:

Define a candidate architecture. In this activity, an initial sketch of the software architecture is created. This includes defining architecturally significant elements, identifying a set of analysis mechanisms, defining the initial layering and organization of the system, and defining use-case realizations for the current iteration. The key tasks are performing architectural analysis and use case analysis; other tasks include operation analysis and identifying security patterns.

Refine the architecture. This activity is focused on completing the architecture for an iteration. It involves making a transition from analysis activities to design activities by identifying design elements from analysis elements and design mechanisms from analysis mechanisms. In addition, the runtime and deployment architecture is described, along with an implementation model to facilitate the transition between design and implementation. To achieve this, the RUP suggests performing tasks such as identifying design mechanisms, identifying design elements, performing operation analysis, incorporating existing design elements, structuring the implementation model and describing the runtime architecture, describing distribution, and reviewing the architecture.

RUP provides an extensive, detailed process for architectural development. It also makes clear distinctions between analysis, design, and implementation aspects. Initially, the architecture is designed in a conceptual fashion in the analysis tasks, and then it is made concrete in the design and implementation tasks. For example, initially an analysis mechanism such as persistence can be identified. This is refined into a design mechanism such as a DBMS, which is further refined into an implementation mechanism such as a specific Oracle or MySQL database.

The process in RUP is iterative by nature, as several iterations of the architectural activities defined in the inception and elaboration phases can be performed. A nice aspect of the process defined by RUP is that it provides detailed guidance with respect to architectural concerns such as defining the system context and establishing an initial structure for the system both in a logical and a physical way. The architecture process in RUP also has a strong focus on use cases. Even though quality attributes are mentioned (as “supplementary requirements”), they do not drive the architecture design process as much as the use cases. Also, this process explicitly considers the creation of an executable architectural prototype.

Even though the architecture process in RUP is comprehensive, it does not give as much detail as ADD in terms of the concrete steps to perform the design. In this sense, ADD and RUP can be seen as being complementary methods, and ADD can be integrated into RUP (as can other more detailed architecture-based methods such as the QAW, ATAM, and CBAM).

The process described by Eeles and Cripps includes three major activities: “define requirements”, “create logical architecture”, and “create physical architecture”. The last two are the activities where architectural design is performed. According to the authors, the logical architecture is “a stepping stone in getting from the requirements to the solution—a first step that considers the architecture in a largely technology-independent manner. A physical architecture, on the other hand, is more specific—and takes technology into account”. The creation of the logical architecture and the physical architecture comprises the same tasks (see Figure 7.4), but in the creation of the physical architecture the focus, not surprisingly, is on its physical aspects.

This process acknowledges the existence of different types of architects: lead, application, infrastructure, and data architects. Also, it makes a distinction between “outlining” tasks, which are associated with the most important architectural elements and are the responsibility of the lead architect, and “detailing” tasks, which are focused on less significant elements and are the responsibility of the other architects, depending on the task. For example, whereas outlining tasks deal with subsystems and components, detailing tasks deal with interfaces and operation signatures.

The method described by Eeles and Cripps also emphasizes two different models: (1) the functional model, which is composed of components with responsibilities and relationships and their collaborations to deliver the required functionality, and (2) the deployment model, which shows the configuration of nodes, communication links between them, and the components that are deployed on the nodes. Both functional and quality attribute requirements influence the functional and deployment models. The authors mention that they adopt the “systems engineering philosophy” of treating software and hardware as peers that collaborate to achieve system qualities.

The following list summarizes the purposes of the tasks in the create logical and physical architecture activities that are related to design. The role that has primary responsibility for the task appears in parentheses, while other types of architects may take a secondary role:

Survey architecture assets (lead architect). Identify reusable architecture assets that can be applied to the system under development.

Define architecture overview (lead architect). Identify and describe the major elements of the system under development from a functional and deployment perspective.

Document architecture decisions (lead architect). Capture key decisions made in shaping the architecture and the rationale behind them. This step includes assessing options and selecting a preferred option.

Outline functional elements (application architect). Identify the major functional elements (subsystems and components) of the system under development.

Outline deployment elements (infrastructure architect). Identify the locations to which the system under development will be deployed and the nodes within each location.

Verify architecture (lead architect). Verify that the architecture work products are consistent and ensure that any concerns that cut across the architecture work products have been addressed consistently.

Build architecture proof-of-concept (lead architect). Synthesize at least one solution (which can be conceptual) that satisfies the architecturally significant requirements to determine whether such a solution, as envisaged by the architects, exists.

Detail functional elements (application architect). Refine the functional elements to the point that they can be handed off to detailed design. This includes defining component interfaces in a detailed way (e.g., operation signatures, pre and post conditions) using sequence diagrams.

Detail deployment elements (infrastructure architect). Refine the deployment elements to the point they can be handed off to detailed design. This includes assigning components to nodes and defining connections between nodes and locations.

In a spirit that is similar to RUP, the Process of Software Architecting is a framework, and it needs to be adjusted according to the type of project that is being tackled. For instance, the amount of logical architecture that needs to be established can vary; indeed, in some cases, no logical architecture may be created if the system being designed is similar to existing ones. Also, the elaboration phase emphasizes the logical architecture, whereas the construction phase emphasizes the physical architecture. Finally, the logical and physical architectures need not be created sequentially and the process acknowledges that some technology choices may be made early.

The Process of Software Architecting is a comprehensive framework, and this book provides a detailed example of how to execute the different tasks. The tasks related to creating the logical/physical architecture are similar to the steps of ADD combined with the roadmap discussed in Section 3.3. The Process of Software Architecting, however, puts less emphasis on guiding iterations by specific scenarios and provides less guidance on how to actually make design decisions.

1. Identify architecture objectives. These goals and constraints shape the design process, provide scope, and help determine when you are finished. Examples include building a prototype, exploring technologies, and developing an architecture. Also, at this point, the consumers for the architecture are identified and the scope, time, and resources that will be dedicated to design activities are established.

2. Identify key scenarios. Key scenarios represent issues, architecturally significant use cases, intersections between quality attributes and functionality, or tradeoffs between quality attributes.

3. Create application overview. This step refers to creating an overview of what the application will look like when it is complete. At the end of this step, the process suggests “whiteboarding” the architecture—that is, creating an informal representation of the architecture. This step is divided into the following set of activities:

a. Determining application type: involves the selection of a reference architecture.

b. Identifying deployment constraints: involves the selection of a deployment topology.

c. Identifying important architecture design styles.

d. Determining relevant technologies: based on the application type and constraints.

4. Identify key issues. Key issues are grouped into quality attributes and crosscutting concerns. Crosscutting concerns are features of the design that may apply across all layers, components, and tiers, such as the following:

a. Authentication and authorization

b. Caching

c. Communication

d. Configuration management (information that must be configurable)

e. Exception management

f. Logging and instrumentation

g. Validation (of input data)

5. Define candidate solutions. Candidate architectures include an application type, deployment architecture, architectural style, technology choices, quality attributes, and crosscutting concerns. If a candidate architecture satisfies the requirements and issues, then it becomes a baseline architecture and is refined in further iterations.

Besides these five main steps, the technique discussed by the Microsoft team suggests performing reviews of the architecture and representing and communicating the design. This technique is independent of a particular development process and there is only a suggestion that, when using an Agile process, iterations should combine architecture and development activities.

The technique presented by the Microsoft team is not very detailed, but the discussion of this technique is only a small part of Microsoft’s book. The rest of the book provides pragmatic and detailed information on the considerations that must be taken into account for different types of applications, including web, rich client, rich internet, and mobile applications, among others. For example, the book devotes a chapter to the specific aspects of the design of the business layer. Although much of the information is technology agnostic, Microsoft has also done an excellent job of showing how its own technologies can be used in this process. In addition, the book provides an extensive discussion of the concerns that must be addressed for a series of reference architectures.

This technique is similar in purpose to ADD but less detailed in terms of how to perform the actual design steps. ADD can be used as an alternative, but it is a good idea to keep Microsoft’s book on hand to identify the many specific architectural concerns that you will need to address during design and to leverage all of the practical advice that is provided, particularly if you are designing one of the types of applications discussed in the book. The ideas presented in Microsoft’s book inspired us when creating several aspects of this book.

A viewpoint is a collection of patterns, templates, and conventions for constructing one type of view. It defines the stakeholders whose concerns are reflected in the viewpoint and the guidelines, principles, and template models for constructing its views. The viewpoints defined include functional, information, concurrency, development, deployment, and operational.

An architectural perspective is a collection of activities, tactics, and guidelines that are used to ensure a system exhibits a set of quality properties that must be considered across the system’s architectural views. The primary perspectives that are covered in Rozanski and Woods’s book are security, performance and scalability, availability and resilience, and evolution.

Perspectives are orthogonal to viewpoints because a particular perspective can be applied across different viewpoints. For example, the security perspective involves aspects from the functional, information and operational viewpoints.

The architecture is established in the architecture definition process illustrated in Figure 7.6. The steps in this process are outlined here:

1. Consolidate the inputs. Understand, validate, and refine the initial inputs.

2. Identify the scenarios. Identify a set of scenarios that illustrate the system’s most important requirements.

3. Identify relevant architectural styles. Identify one or more proven architectural styles that could be used as a basis for the overall organization of the system.

4. Produce a candidate architecture. Create a first-cut architecture for the system that reflects its primary concerns (requirements and goals) and that can act as a basis for further architectural evaluation and refinement.

5. Explore architectural options. Explore various architectural possibilities for the system and make the key decisions to choose among them.

6. Evaluate the architecture with stakeholders. Work through an evaluation of the architecture with your key stakeholders, capture any problems or deficiencies, and gain the stakeholders’ acceptance of the architecture.

7. Two steps are performed in parallel at this point:

A. Rework the architecture. Address any concerns that have emerged during the evaluation task.

B. Revisit the requirements. Consider any changes to the system’s original requirements that may have to be made in light of architectural evaluations.

This method suggests the creation of a candidate architecture that is obtained from—or at least based on—architectural styles. This candidate architecture is further refined through a series of iterations until it is deemed acceptable after an evaluation is performed.

In comparison with ADD, this method does not provide step-by-step guidance on how to perform steps 4 and 5. One benefit of this approach, however, is that the six viewpoints it defines can be related to general architectural concerns in our approach. Furthermore, tactics and perspectives are related, and the idea of applying perspectives across the different viewpoints is valuable and may be a complement to a scenario-based approach. For example, if you have only one security scenario in your drivers list, you may consider only elements that support this particular scenario. Thinking of a security perspective, however, may be useful in making design decisions concerning security, which may not be directly related to the particular scenario but flow across different areas of concern such as deployment or operation.

ADD is focused specifically on design and, as such, provides more detailed guidance to an (aspiring) architect. This is not a weakness of ADD. Many other methods can guide you in the other phases of the architecture life cycle, such as QAW for eliciting and prioritizing architectural requirements, ATAM for analyzing an architecture, the Views and Beyond technique for documenting an architecture. In several parts of this book we have discussed how such methods can be seamlessly integrated into ADD.

In the interest of full disclosure, ADD 3.0 borrows from, benefits from, and owes a debt of gratitude to all of the approaches described in this chapter.

P. Eeles, P. Cripps. The Process of Software Architecting. Addison-Wesley Professional, 2009.

C. Hofmeister, P. Kruchten, R. Nord, H. Obbink, A. Ran, P. America. “A General Model of Software Architecture Design Derived from Five Industrial Approaches”, Journal of Systems and Software, 80:106–126, 2007.

A. Lattanze. Architecting Software Intensive Systems: A Practitioner’s Guide. CRC Press, 2009.

P. Kruchten. The Rational Unified Process: An Introduction, 3rd ed., Addison-Wesley, 2003.

Microsoft, Application Architecture Guide, 2nd ed. Microsoft Press, 2009.

N. Rozanski, E. Woods. Software Systems Architecture. Addison Wesley, 2005.