Attribute Driven Design in Software Architecture
Attribute Driven Design is a software architecture design process which originally came from the Carnegie Mellon University Software Engineering Institute, (SEI). It has evolved over the years; ADD 1.0 was published by Felix Bachmann and Len Bass in 2001, ADD 2.0 was published in 2006 and ADD 3.0 was published in 2016 in the excellent book by Humberto Cervantes and Rick Kazman; Designing Software Architectures: A Practical Approach.
Personally, I have used the process for a number of years now and I find it incredibly useful. It helps me to structure my thought process as I go about my work. It's focus on quality attributes / non-functional requirements (NFRs) reduces the chances of missing these considerations when deadlines are looming. The cross-referencing of the design inputs, especially the mapping between the quality attributes and use cases is very helpful. It’s like a mental checklist, prompting me to investigate avenues and to cross reference my thoughts and ideas against the design criteria.
The process defines a set of design inputs followed by a set of steps which facilitates an iterative approach to architecture design. The duration of each Design Iteration will vary depending on the project. Where appropriate, the design iterations can follow an agile sprint cycle, where the architect works on the design in the sprint ahead of the development team, or the iterations can be much longer, especially if the architect is working across multiple architecture design projects simultaneously while waiting for clarity on functional requirements.
I have no affiation with the SEI and therefore no authority to declare a new version however I have made some changes to ADD 3.0 to more closely reflect the way I use the process, i.e.
- added current state architecture to the design inputs
- altered the description of Step 6 to include; “peer review” and "record design decisions"
This is the process modelled using ArchiMate:
Step 0. Capture Design Inputs
The design objectives describe the business or technical rationale for the project and the scope of the design project. Links to functional requirement documents or any other artefacts which provide background information should be included. The project sponsors and other key stakeholders can also be listed.
A list of the architecturally significant use cases and requirements, both technical and functional, also known as Architecturally Significant Requirements (ASRs).
Quality Attribute Scenarios
A list of the quality attributes / non-functional requirements (NFRs) relevant to the design project and how they relate to the Use Cases.
A list of limitations or restrictions on the design, i.e. the design must cater for both on-premise and cloud based deployments
Other concerns or external drivers, i.e. the development team allocated to the project have limited experience with this area of the system.
Current State Architecture
If this design is related to existing system/s, provide a description or references to any documentation describing the current state architecture.
Design Input Prioritisation
As an optional activity, Design Inputs can also be prioritised based input from the project sponsor/s and the architectural significance. This is a useful exercise in larger projects where design activities span multiple design iterations.
Step 1. Review Design Inputs
All of the Design Inputs must be reviewed at the start of each Design Iteration.
Step 2. Establish the iteration goal based on the (prioritised) Design Inputs
The iteration goal is determined by a number of factors; the size and complexity of the project, the clarity of the requirements etc.
Step 3. Choose one or more elements / aspects of the system to refine
For small projects which can be covered by a single design iteration, all elements of the system are refined together. For larger projects, the first iteration is generally scoped to refining the system at a high level of abstraction, such as choosing a reference architecture, or choosing a major technology. Subsequent design iterations then focus on more specific areas of the system.
Step 4. Choose one or more design concepts which satisfy the Design Inputs
At least two options should always be explored. Listing the Pro's and Con's of each helps to highlight the most suitable option. Where appropriate, a Proof-Of-Concept (POC) should be developed to validate the design assumptions.
Step 5. Document the design for each concept; sketches / diagrams, data flows, interfaces etc
This will vary based on the elements being designed, simple diagrams or (photographs of) white board sketches are often sufficient to describe each concept at an early stage.
Step 6. Peer review, record design decisions and rationale
Discussion and validation of the design concepts with peers, once consensus has been reached on the best option/s, record the decision/s and the rationale for making the decision/s.
Step 7. Review iteration goal and coverage of Design Inputs
Review how well the Design Inputs have been satisfied, to determine if another Design Iteration is required.
Go to Step 1 if all Design Inputs have not been satisfied, otherwise proceed to the Design Outputs.
Step 8. Document the architecture and communicate to stakeholders
See the Documentation section below.
The following artefacts are produced during the process:
Architecture Design Documentation
The Design Inputs and the Design Iterations are captured in the Architecture Design Documentation, this can be a single document or for larger projects, the Design Inputs and each Design Iteration can be captured in separate linked documents.
The primary stakeholders in the creation of Architecture Design documents are architects, senior software engineers and project sponsors.
Development Specification Documentation
The primary stakeholders for Development Specification documents are the development team/s that will build the software. These documents only include the option/s chosen during the Architecture Design. Where appropriate, more details can be added i.e. additional sequence diagrams, to aid the understanding of the development team. The Development Specification Document must include a link back to the Architecture Design Document for reference.
Architecture Description Documentation
The Architecture Description documentation, including release documentation, architecture models etc, must be updated to reflect the changes made as a result of the design process.
There isn't a "one size fits all" when it comes to performing a software architecture design, here are some guidelines describing what you should aim for:
- Small Project
- the ADD process may not be required for very small projects
- capture inputs and decisions in the development team's task management system
- or create a short Development Specification document
- Medium Project
- capture inputs, iterations and decisions in a single Architecture Design document
- perform one or two design iterations
- Large Project
- capture inputs, iterations and decisions in multiple Architecture Design documents
- perform two or more design iterations