9. The Architecture Design Process in the Organization
Chapter 1 introduced a set of software architecture life-cycle activities—things like collecting requirements, designing the architecture, and evaluating and implementing the architecture. We called these “life-cycle activities” because we recognize that not all organizations do all of them; those that do them might do them in different ways, and might embed them into different life-cycle models and organizational contexts. This chapter takes a closer look at those aspects of software development and considers how architecture design fits in with them.
9.1 Architecture Design and the Development Life Cycle
Two important phases that occur in most development projects, as illustrated in Figure 9.1, are pre-sales and development and operations.
During the pre-sales phase, the scope of the project is established and a business case is established. Although we call this phase “pre-sales”, it occurs in every organization, whether they engage in “sales” or not. One frequent and important product of this phase is an estimation of the cost and duration of the project. This estimation is used by the customers (or funders) to decide if they want to pursue the project.
The development and operations phase occurs when the pre-sales proposal has been accepted by the customer. Development can be performed following different methodologies including Agile, RUP, or TSP. Once the system (or part of it) is developed, it is put into operation. Newer approaches such as DevOps intend to reduce the gap that is usually present between development and operation.
Architectural design plays an important role in these two major phases, as we will now discuss.
9.1.1 Architecture Design During Pre-Sales
In many types of development projects, but particularly in the context of custom software development, organizations typically need to provide an initial estimate of the time and cost of the project during the pre-sales phase. Frequently the pre-sales activities must be performed in a short time period, and the information that is available to inform this process is always limited. For example, typically only high-level requirements or features (rather than detailed use cases) are available at this phase.
The problem with limited information is that the estimate that is produced frequently has a lot of uncertainty, as illustrated by the cone of uncertainty depicted in Figure 9.2. The cone of uncertainty refers to the uncertainty surrounding estimates in a project, typically those of cost and schedule, but also risk. All of these estimates get better as a project progresses, and the cone narrows. When the project is done, uncertainty is zero. The issue for any development methodology is how to narrow the cone of uncertainty earlier in the project’s life cycle.
Architectural practices can be applied in the pre-sales phase to help reduce the cone of uncertainty:
Architectural drivers can be identified in the pre-sales phase. Even if it may be complicated to describe detailed quality attribute scenarios at this point, the most important quality attributes with initial measures and constraints should be identified.
ADD can be used to produce an initial architecture that is then used as the basis for early cost and schedule estimates.
Sketches of this initial architecture are useful for communication with the customer. They are also useful as a basis to perform lightweight evaluations of this initial design.
Generating an initial architecture allows estimation to be performed using the “standard components” technique. Standard components are a type of proxy; they include web pages, business rules, and reports, among other things. When estimating with standard components, companies typically build historic databases that contain, for example, measurements and size data for components that have been built into previously developed systems. To estimate with standard components, you need to identify the components that will be required for the problem that you are trying to solve, and then use historical data (or some other technique such as Wideband Delphi) to estimate the size of these components. The total size can then be translated into effort, and these estimates can be rolled up to produce a project-level time and cost estimate.
Identifying the components that are required to create estimates with this technique can be achieved in a short time frame through the use of ADD. This approach is similar to what we just recommended for the design of greenfield systems:
The goal of your first design iteration should be to address the concern of establishing an initial overall structure for the application. The reference architecture, if you employ one, dictates the types of standard components that will be used in the estimation. At this point, the most relevant technologies to use in the project can also be selected, particularly if your historical data is tied to specific technologies.
The goal of your second design iteration should be to identify components to support all of the functionality that needs to be considered for the estimation. As opposed to what we discussed for the design of greenfield systems, when designing to produce an estimate, you need to consider more than just primary functionality. To identify the standard components, you need to consider all of the important functional requirements that are part of the scope and map them to the structure that you defined in the first iteration. Doing so ensures you will have a more accurate estimation.
This technique will help you estimate costs and schedule for meeting the most important functional requirements. At this point, however, you will likely not have taken quality attributes into account. As a consequence, you should perform a few more iterations focusing on where you will make design decisions to address the driving quality attributes. If the time available to perform the pre-sales process is limited, you will not be able to design it in much detail, so the decisions that you should take here are the ones that will have a significant impact in the estimate. Examples include identifying redundant hardware or additional standard components to address quality attributes such as performance, availability, and security.
When this technique is used in the pre-sales process, an initial architecture design is produced—the pre-sales architecture design (see Figure 9.1). If the project proposal is accepted by the customer and the project proceeds, this initial architecture can become one of the bases for a contract. This architecture should be used as a starting point in the subsequent architecture design activities that are performed during the Development and Operation phase of the project. In this case, the roadmap for designing brownfield systems (discussed in Section 3.3.3) can be used.
The preliminary documentation produced for this initial architecture can also be included as part of the technical proposal that is provided to the customer. Finally, this initial architecture design can be evaluated, preferably before estimation occurs. This can be performed using a technique such as the lightweight ATAM presented in Section 8.6.
9.1.2 Architecture Design During Development and Operation
The development of a software system can be performed using different methodologies. Architectural design, however, is performed independently of the chosen development methodology. For this reason, a design method such as ADD can be used in conjunction with different development methodologies. We now discuss the relationship between architectural design and some development methodologies that are commonly used in industry.
9.1.2.1 Agile Methods
The relationship between software architecture and agility has been the subject of some debate over the past decade. Although we believe, and much research has shown, that architectural practices and Agile practices are actually well aligned, this position has not always been universally accepted.
Agile practices, according to the original Agile Manifesto emphasize, “Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan”. None of these values is inherently in conflict with architectural practices. So why has the belief arisen—at least in some circles—that the two sets of practices are somehow incompatible? The crux of the matter is the one principle on which Agile practices and architectural practices differ.
The original creators of the Agile Manifesto described 12 principles behind the manifesto. While 11 of these are fully compatible with architectural practices, one of them is not: “The best architectures, requirements, and designs emerge from self-organizing teams”. While this principle may have held true for small and perhaps even medium-sized projects, we are unaware of any cases where it has been successful in large projects, particularly those with complex requirements and distributed development. The heart of the problem is this: Software architecture design is “up-front” work. You could always just start a project by coding and doing minimal or no up-front analysis or design. This is what we call the emergent approach, as shown in Figure 9.3b. In some cases—small systems, throw-away prototypes, systems where you have little idea of the customer’s requirements—this may, in fact, be the optimal decision. At the opposite extreme, you could attempt to collect all the requirements up front, and from that synthesize the ideal architecture, which you would then implement, test, and deploy. This so-called Big Design Up Front approach (BDUF; Figure 9.3a) is usually associated with the classic Waterfall model of software development. The Waterfall model has fallen out of favor over the past decade due to its complexity and rigidity, which led to many well-documented cases of cost overruns, schedule overruns, and customer dissatisfaction. With respect to architectural design, the downside of the BDUF approach is that it can end up producing an extensively documented but untested design that may not be appropriate. This occurs because problems in the design are often discovered late and may require a lot of rework, or the original design may end up being ignored and the true architecture is not documented.
Clearly, neither of these extremes makes sense for most real-world projects, where some (but not all) of the requirements are well understood up front but there is also a risk of doing too much too soon and hence becoming locked in to a solution that will inevitably need to be modified, at significant cost. So the truly interesting question is this: How much up-front work, in terms of requirements analysis, risk mitigation, and architecture, should a project do? Boehm and Turner have presented evidence arguing that there is no single right answer to this question, but that you can find a “sweet spot” for any given project. The “right” amount of project work depends on several factors, with the most dominant being project size, but other important factors include requirements complexity, requirements volatility (related to the precedentedness of the domain), and degree of distribution of development.
So how do architects achieve the right amount of agility? How do they find the right balance between up-front work and technical debt leading to rework? For small, simple projects, no up-front work on architecture is justifiable. It is easy and relatively inexpensive to turn on a dime and refactor. In projects where there is some understanding of the requirements, begin by performing a few ADD iterations. These design iterations can focus on choosing the major architectural patterns (including a reference architecture, if one is appropriate) and frameworks. This is the iteration 0 approach depicted in Figure 9.3c. This will help to structure the project, define work assignments and team formation, and address the most critical quality attributes. If and when requirements change—particularly if these are driving quality attribute requirements—adopt a practice of Agile experimentation, where spikes are used to address new requirements. A spike is a time-boxed task that is created to answer a technical question or gather information; it is not intended to lead to a finished product. Spikes are developed in a separate branch and, if successful, merged into the main branch of the code. In this way, emerging requirements can be welcomed and managed without being too disruptive to the overall process of development.
Agile architecture practices, however, help to tame some of the complexity, narrowing the cone of uncertainty and hence reducing project risk. A reference architecture defines families of technology components and their relationships. It guides integration and indicates where abstraction should be built into the architecture, to help reduce rework when a new technology (from within a family) replaces an existing one. Agile spikes allow prototypes to be built quickly and to “fail fast”, thereby guiding the eventual selection of technologies to be included on the main development branch.
9.1.2.2 Rational Unified Process
The Rational Unified Process (RUP) is a software development process framework that puts a strong emphasis on architecture. In the RUP (which we also discussed in Section 7.3), development projects are divided in four major phases, which are carried out sequentially; within these phases, a number of iterations are performed. The four phases of the RUP are as follows:
Inception. In this first phase, the goal is to achieve concurrence among project stakeholders. During this phase the scope of the project and a business architecture are defined. Also, a candidate architecture is established. This phase is the equivalent to the pre-sales phase discussed previously.
Elaboration. In the second phase, the goal is to baseline the architecture of the system and to produce architectural prototypes.
Construction. In the third phase, the goal is to incrementally develop the system from the architecture that was defined in the previous phase.
Transition. In the fourth phase, the goal is to ensure that the system is ready for delivery. The system is transitioned from the development environment to its final operation environment.
We could argue that, from the elaboration phase until the end of the project, RUP intrinsically follows the iteration 0 approach described earlier. RUP also provides some guidance with respect to architectural design, although this guidance is far less detailed than that offered by ADD. As a consequence, ADD can be used as a complement to the RUP. ADD iterations can be performed during inception to establish the candidate architecture by following the approach described in Section 9.1.1. Furthermore, during the elaboration phase, the initial architecture is taken as a starting point for performing additional design iterations until an architecture that can be baselined is produced. During construction, additional ADD iterations may be performed as part of the development iterations.
9.1.2.3 Team Software Process
The Team Software Process (TSP) is a development process that strongly emphasizes quality and measurement. A TSP software project proceeds through a series of development cycles, where each cycle begins with a planning process called a launch and ends with a closing process called a postmortem. Within each development cycle, activities belonging to different phases can be performed. These phases include requirements (REQ), high-level design (HLD), implementation (IMPL), and testing (TEST). The REQ phase of TSP focuses on producing a complete system requirements specification (SRS) document. The main goal of the HLD phase is to produce a high-level design that will guide product implementation. This high-level design must define the components (i.e., modules) that constitute the system and that have to be designed and developed independently following the Personal Software Process (PSP) in the IMPL phase. Finally, the TEST phase focuses on performing integration and system testing and on preparing the delivery of the system. Note that the life-cycle model of a particular project (Waterfall, incremental) is defined by the phases that are performed in each development cycle: An iterative project will typically include activities from all four phases in a single development cycle.
The TSP does not give full consideration to software architecture development. For instance, none of the roles defined in the TSP is that of software architect. There is also no emphasis on quality attributes in the REQ phase. Furthermore, the process script for the HLD phase (see Table 9.1) does not provide detailed guidance on how to design the system architecture. These issues can, however, be addressed by introducing ADD, and other architectural practices, into TSP.
ADD can be used in the context of TSP in a straightforward way. In step 1 of the HLD script, ADD can be used to produce the overall product design concept, similar to what was discussed for the pre-sales process. Furthermore, in each development cycle, one or more ADD iterations can be performed (steps 4 and 5 of the HLD script). Also, the HLD phase should consider a separation between architectural design and element interaction design (discussed in Section 2.2.2). A TSP development cycle can involve a few ADD iterations followed by the element interaction design activities that include identification of elements and their interfaces. These interfaces are later used in the development phase (IMPL) for performing detailed design and development of the elements.
9.1.2.4 DevOps
DevOps is a natural outgrowth of the Agile mindset. DevOps refers to a set of practices that help achieve continuous delivery of software. Such practices are intended to reduce the time between making a change to a system and the change being placed into normal production, while ensuring high quality. This term intentionally blurs the distinction between “development” and “operations”. While DevOps is not inherently tied to architectural practices, if architects do not consider DevOps as they design, build, and evolve the system, then critical activities such as continuous build integration, automated test execution, high availability, and scalable performance will be more challenging and less efficient. By embracing DevOps, small iterations are supported and encouraged, creating an environment where Agile spikes are easy to create, deploy, and test, thereby providing crucial feedback to the architect.
For example, a tightly coupled architecture can become a barrier to continuous integration because even small changes may require a rebuild of the entire system, which limits the number of builds possible in a day. To fully automate testing, the system needs to provide architectural (system-wide) test capabilities such as interfaces to record, play back, and control system state. To support high availability, the system must be self-monitoring, requiring architectural capabilities such as self-test, ping/echo, heartbeat, monitor, hot spares, and so forth.
In large-scale systems, DevOps can be achieved only with architectural support. Any ad hoc or manual process would put the growth and success of such a system at risk. Adopting the DevOps approach requires a small change in the mindset of an architect. Instead of just designing the system, you now need to think about the design of the entire deployment pipeline. Is the pipeline easy to change, and can these changes be deployed at the click of a button? Is the pipeline easy to scale? Is it easy to test? Fortunately, there are good answers to all of these questions, and they do not require a distinct mindset or strategy. ADD can help design a system to achieve DevOps goals, in exactly the same ways and employing exactly the same design primitives as in design for any other driver. The different aspects that need to be considered to allow DevOps to be performed successfully can be included as part of the system drivers, either as architectural concerns or as quality attributes. The design concepts that help us to achieve modifiability or testability or scalability or high availability in a system can also be applied to the deployment pipeline. To slightly misquote Gertrude Stein, “Architecture is architecture is architecture”.
9.2 Organizational Aspects
In addition to the choice of a specific development method and the introduction of a design method such as ADD into this method, other aspects of the design process can be supported by a software development organization to facilitate design activities. Here we briefly discuss some of these aspects.
9.2.1 Designing as an Individual or as a Team
In large and complex projects, it seems straightforward that an architecture team should be responsible for performing the design. Even in smaller projects, however, you may find that having more than one person participate in the design process yields important advantages. You can decide if only one person is the architect and the others are observers (as in the practice of pair programming) or if the group actively collaborates on design decisions (although even here we recommend that you have one lead architect).
There are various benefits from this approach:
Two (or more) heads can be better than one, particularly if the design problem that you are trying to solve is different from ones that you have addressed before.
Different people can have different areas of expertise that are useful in the design of the architecture. For example, you might have distinct software and infrastructure architects, or people who specialize in different domains or different types of design concepts.
Design decisions are reflected upon and reviewed as they are being made and, as a consequence, can be corrected immediately.
Less experienced people can participate in the design process, which can be an excellent mentoring practice.
You should, however, be aware of certain difficulties with this approach:
Design by committee can be complicated if agreement is not achieved in a reasonable time frame. The search for consensus can lead to “analysis paralysis”.
The cost of design increases and, in many cases, the time for design also increases.
Managing the logistics can be complex, because this approach requires the regular availability of the group of people.
You may encounter personality and political conflicts, resulting in resentment or hurt feelings or in design decisions being heavily influenced by the person who shouts longest and loudest (“design by bullying”).
9.2.2 Using a Design Concepts Catalog in Your Organization
Design concepts are used in the design process to satisfy drivers (see Section 2.5). In general, drivers can be seen as recurring design problems. Whether it is the concern of structuring an application, allocating functionality, or satisfying a particular quality attribute, these drivers have most certainly been addressed in other systems previously. Furthermore, people have taken the time to document ways to address these design problems or to develop components that serve this purpose. As we saw in Section 3.4, the selection of design concepts is one of the most challenging aspects of the design process. This problem is exacerbated by the fact that information is scattered in many places: Architects usually need to consult several pattern and tactics catalogs and do extensive research to find the design concepts that can be considered and used.
One possible way to resolve this issue is the creation of design concepts catalogs. These catalogs group collections of design concepts for particular application domains. Such catalogs are intended to facilitate the identification and selection of design concepts when performing design. They are also useful in enhancing consistency in the designs across the organization. For example, designers may be required to use the technologies in a particular catalog as much as possible because this facilitates estimation, reduces learning curves, and may lead to opportunities for reuse. Catalogs can also be useful for training purposes.
An example of a design concepts catalog appears in Appendix A. This catalog is oriented toward the design of enterprise applications. A similar catalog for the Big Data domain could be created from the technology families and specific technologies illustrated in Figure 2.10 (Section 2.5.5).
The creation of these catalogs involves considerable effort and, once created, they should be maintained as new design concepts, and particularly new technologies, are introduced or removed in the organization. This effort is worthwhile, however, as these catalogs are a valuable organizational asset.
9.3 Summary
In this chapter we discussed how ADD can be used in relation to several organizational aspects. ADD can be used from the project’s inception, when a pre-sales proposal is developed, to facilitate estimation using standard components. As the project evolves, ADD can be used in conjunction with any modern software development life-cycle method. In general, ADD is a valuable complement to life-cycle methods that do not provide detailed guidance on how to perform architectural design.
We also briefly reviewed some related concerns, such as the composition of the design team and the development of organizational assets, such as a design concepts catalog, that are useful during the design process.
9.4 Further Reading
Organizational structure and its influences on software architecture are addressed in the field of enterprise architecture management. Enterprise architecture frameworks are discussed in F. Ahlemann et al. (Eds.), Strategic Enterprise Architecture Management: Challenges, Best Practices, and Future Developments, Springer-Verlag Berlin Heidelberg, 2012.
A nice set of articles looking at the relationship between architecture and Agile methods can be found in the April 2010 IEEE Software magazine special issue on this topic.
A number of studies have looked at how architecture and agility methods complement and support each other, such as S. Bellomo, I. Gorton, and R. Kazman, “Insights from 15 Years of ATAM Data: Towards Agile Architecture”, IEEE Software, September/October 2015, and S. Bellomo, R. Nord, and I. Ozkaya, “A Study of Enabling Factors for Rapid Fielding: Combined Practices to Balance Speed and Stability”, Proceedings of ICSE 2013, 982–991, 2013.
Barry Boehm and Richard Turner have taken an empirical look at the topic of the relationship between agility and “discipline” (not just architecture) in their book Balancing Agility and Discipline: A Guide for the Perplexed (Boston: Addison-Wesley, 2004).
The practice of creating architectural “spikes” as a means of resolving uncertainty in Agile sprints is discussed in T. C. N. Graham, R. Kazman, and C. Walmsley, “Agility and Experimentation: Practical Techniques for Resolving Architectural Tradeoffs”, Proceedings of the 29th International Conference on Software Engineering (ICSE 29), (Minneapolis, MN), May 2007. A general discussion of spikes can be found at https://www.scrumalliance.org/community/articles/2013/march/spikes-and-the-effort-to-grief-ratio.
Many practitioners and researchers have thought deeply about how Agile methods and architectural practices fit together. Some of the best examples of this thinking can be found in the following sources:
S. Brown. Software Architecture for the Developers. LeanPub, 2013.
J. Bloomberg. The Agile Architecture Revolution. Wiley CIO, 2013.
Dean Leffingwell. “Scaled Agile Framework”. http://scaledagileframework.com/
A. Cockburn. “Walking Skeleton”. http://alistair.cockburn.us/Walking+skeleton
“Manifesto for Agile Software Development”. http://agilemanifesto.org/
Scott Ambler and Mark Lines. “Scaling Agile Software Development: Disciplined Agility at Scale”. http://disciplinedagileconsortium.org/Resources/Documents/ScalingAgileSoftwareDevelopment.pdf
An extensive treatment of estimation techniques, including estimation using standard components, is given in S. McConnell, Software Estimation: Demystifying the Black Art, Microsoft Press, 2006.
An overview of the Team Software Process can be found in W. Humphrey, The Team Software ProcessSM (TSPSM), Technical Report CMU/SEI-2000-TR-023, November 2000. Extensive details about TSP can be found in the different books written by Humphrey about this process.
The integration of ADD 2.0 (as well as other architecture development methods) with RUP, is discussed in R. Kazman, P. Kruchten, R. Nord, and J. Tomayko, “Integrating Software-Architecture-Centric Methods into the Rational Unified Process”, Technical Report CMU/SEI-2004-TR-011, July 2004.
There are now several excellent books on the topic of DevOps, such as L. Bass, I. Weber, and L. Zhu, DevOps: A Software Architect’s Perspective, Addison-Wesley, 2015. A set of architectural tactics for DevOps was described in H-M Chen, R. Kazman, S. Haziyev, V. Kropov, and D. Chtchourov, “Architectural Support for DevOps in a Neo-Metropolis BDaaS Platform”, IEEE 34th Symposium on Reliable Distributed Systems Workshop (SRDSW), Montreal, Canada, September 2015.
Considerable attention has been given to the problem of architecture knowledge representation and management. For a good overview of this area, see P. Kruchten, P. Lago, and H. Van Vliet, “Building Up and Reasoning About Architectural Knowledge”, in Quality of Software Architectures, Springer, 2006. For a perspective on tools for architecture knowledge management, see A. Tang, P. Avgeriou, A. Jansen, R. Capilla, and M. Ali Babar, “A Comparative Study of Architecture Knowledge Management Tools”, Journal of Systems and Software, 83(3):352–370, 2010.