Software Engineering Institute | Carnegie Mellon University

SEI Insights


SEI Architecture Technology User Network (SATURN) News and Updates

SATURN 2015: ADD 3.0: Rethinking Drivers and Decisions in the Design Process (Session Notes)

Posted on by in

Rick Kazman, University of Hawaii and Carnegie Mellon Software Engineering Institute, and Humberto Cervantes, Universidad Autónoma Metropolitana-Iztapalapa
Design is hard. Architects need insight into types of architectural drivers, guidance on selecting design concepts, and what drives certain design decisions to make good decisions by considering these consciously. Architects also need an approach to negotiate with management and stakeholders better to make these good decisions. In this tutorial session, Kazman and Cervantes presented an updated version of the 2006 Architecture-Driven Design Method 2.0 to address these concerns.

ADD 3.0 covers the four main phases of the life cycle:
Architectural Drivers > Design > Documentation > Evaluation.

The drivers are the requirements that shape the architecture, including functional requirements, quality attribute requirements, constraints, design objectives, type of system, and concerns, which include decisions that the architect will need to make but that aren't stated explicitly as requirements. Remember that constraints can be your friends. They are simply design decisions over which you have little or no control, and they can reduce the size of the decisions base. The architectural design maps the problem domain onto the solution domain. Documenting the decisions is important for communicating and analyzing them. There are many architecture design methods: RUP, ADD, ACDM, Microsoft, and more. Most cover the whole life cycle but contain little detail about how actually to do design. There's just a "do design now" step. A method such as ADD 3.0 will help you even if you don't follow it precisely. A method can be performed in a systematic and repeatable way and help you prioritize requirements. Without this, architecture design is a mystic activity performed by gurus, not a field aspiring to an engineering discipline. ADD 2.0 promoted an iterative approach to design and provided steps, but it had limitations: The only inputs were QA and functional requirements, each iteration decomposed only a single element that was chosen before the drivers, design concepts included only patterns and tactics, and it did not include initial documentation. The steps of ADD 3.0 are as follows:

  1. Review inputs: functional and QA requirements, constraints, design objectives, and concerns.
  2. Establish a goal for the iteration, which subproblem to address.
  3. Choose one or more elements of the system to decompose (design decisions).
  4. Choose one or more design concepts that satisfy the inputs (design decisions).
  5. Instantiate the elements, allocate responsibilities, and define interfaces (design decisions).
  6. Sketch views and record design decisions.
  7. Analyze the design and decisions with the iteration goal and design objectives in mind.

In these steps, the design is produced, but it's not necessarily BDUF because an iteration can be small. The approach relies on Design Concepts. Architects want to avoid reinventing the wheel, and it's faster to use proven solutions. The creativity comes in adapting and combining them. Design Concepts include

  • Reference architectures: blueprints for structuring an application, because many systems are similar to other systems that have been built before.
  • Deployment patterns: guidance on how to structure the system from a physical standpoint.
  • Tactics: design decisions that influence the control of a QA response.
  • Patterns: recurring solutions to recurring design problems. There are thousands, including more than 100 patterns just for security. Many books and websites document these and provide practical advice about applicability.
  • Reusable solutions: externally developed components, addressing recurring concerns and including frameworks like Swing, Sprint, and Hibernate.

The second half of the tutorial worked through three illustrations of iterations for a Network Management System "Marketecture" that provides network status, event lists, and performance data.

  1. Type of system: greenfield system in a mature domain. The illustration included 11 use cases, including Monitor Network Status and Detect Faults, 6 QA scenarios with priorities assigned, 10 constraints, including minimum number of users to support and the use of an existing database.
  2. The first iteration goal is to create an overall system structure.
  3. Because it's greenfield, the only element to decompose is the system itself.
  4. Choose among reference architecture alternatives: rich client application on the client side and services application on the server side. Choose deployment patterns: 3-tier (client, services, database). And document these reasoning for these decisions.
  5. Instantiations, responsibilities, and interfaces.
  6. The architect decided to use UML to sketch his views. The sketches instantiate the design concepts. Focus on key points, and just initial documentation.
  7. The architect used a design Kanban board to analyze the design and decisions. It lists each use case and determines whether it is not addressed, partially addressed, or addressed.

And that's the first iteration of three example iterations. In the second iteration, you now have a system structure, so next you should work toward supporting the primary functionality. Selections of reference architectures and patterns will change according to the iteration goal and elements involved. Note that an element's functionality will cross layers. The third illustration focuses on a specific quality attribute, the availability scenario. Addressing QAs usually involves multiple design concepts, and Humberto recommends starting with tactics. When do we finish design? "Never" and "when you run out of time" are not good answers. Ideally, you are done when you have reached your design goal by making decisions for the most important drivers and most important technical risks. "Architecture design transforms drivers into structures."

About the Author

Bill Pollak

Contact Bill Pollak
Visit the SEI Digital Library for other publications by Bill
View other blog posts by Bill Pollak



We welcome comments with a wide range of opinions and views. To keep the conversation focused on topic, we reserve the right to moderate comments.

Add a Comment


Type the characters you see in the picture above.