How do you know if a software architecture for a system is suitable without having to build the system first? The answer is to conduct an evaluation of it. A formal software architecture evaluation should be a standard part of the architecture-based software development life cycle. Architecture evaluation is a cost-effective way of mitigating the substantial risks associated with this highly important artifact.

Architects and designers often need insight into the viability of their early design strategies (or portions of their designs) before conducting a comprehensive architecture evaluation of their software architecture. These early designs are often poorly documented and sketchy, lacking important details that will emerge later. Nevertheless, reviewing a design in its pre-release stages can uncover important inconsistencies or oversights whose early correction can be invaluable.

To provide this insight, the SEI developed Active Reviews for Intermediate Designs (ARID). ARID is a blend of a stakeholder-centric, scenario-based, architecture evaluation method and an active design review (ADR) of design specifications.

ADRs are an effective technique for insuring quality detailed designs in software. The method ensures reviewers' active participation by asking them to utilize the design in a series of exercises, while carefully avoiding yes/no questions that are easy for a reviewer to undermine with a carelessly considered answer. This tests actual, not feigned, understanding.

The major steps of ARID are

• The designer who has commissioned the review works with the ARID facilitator to identify the best reviewers. These are usually the software engineers who will be expected to use the design, as they are in the best position to judge its adequacy.
• The designer prepares a briefing explaining the design, which is reviewed by the ARID facilitator. The designer presents the overview to the reviewers and walks through examples of using the design. A scribe captures questions and answers.
• The reviewers brainstorm scenarios for using the design to solve problems they expect to face. After a facilitated prioritization, the resulting set of scenarios operationally defines what it means for the design to be usable: If it performs well under the adopted scenarios, then it must be agreed that the design has passed the review.
• The reviewers begin to jointly craft code (or pseudo-code) that uses the design's services to solve the problem posed by each high-priority scenario. The scribe records issues, problems, and places where the stakeholders get stuck.

A typical ARID exercise takes about a day and a half.

Additional Information

For consulting information about ARID, visit our consulting pages. Direct technical questions about ARID to us using the link in the For more information box at the bottom of this page.

Software Architecture Training and Publications

Training

Publications

Related Reading

Active Reviews for Intermediate Designs
Paul C. Clements

Evaluating Software Architectures: Methods and Case Studies
Paul Clements, Rick Kazman, & Mark Klein

Integrating Software-Architecture-Centric Methods into Extreme Programming (XP)
Robert L. Nord, James E. Tomayko, & Rob Wojcik