A Technical History of the SEI

Software Architecture Analysis Method
The Challenge: Predicting Systems Development Problems in Advance
One of the recurring themes of the various defense challenge problems is that of predicting problems
before a system has been built. Maintenance and improvement costs represent more than half
the total cost of a system, and this percentage has been steadily growing since 1960 [Jones 2006].
The problem for DoD is to predict maintenance problems before the system is constructed and before
these problems occur.
A Solution: The Software Architecture Analysis Method
The Software Architecture Analysis Method grew out of an effort undertaken by members of the
Serpent user interface project after the UI project was officially ended. The members of the UI
project were active participants in the Interface Federation of Information Processing Working
Group on User Interface Engineering (IFIP WG 2.7/13.4). This group was composed of members
interested in user interface management systems (UIMSs), and the group had many discussions
that centered on the thesis “my system is better than your system.” From these discussions, the
SEI members of the working group gathered two principles that were instrumental in the SAAM
and that have been embodied in almost every software architecture evaluation method since the
SAAM:
Different developers have different business goals for their systems. An architecture evaluation
must evaluate an architecture against the business goals for the system. This means the
architecture evaluation method must either explicitly state what goals it is evaluating or elicit
the goals as part of the evaluation.
Evaluating for a property such as maintainability without a specific definition of what maintainability
means is pointless. Every system is modifiable for some set of modifications and
not modifiable for others.
The importance of understanding the business goals prior to evaluating an architecture can be
seen in the claims made for various UIMSs that led to the development of the SAAM. Examples
of these claims are:
“We have developed … user interface components that can be reconfigured with minimal effort.”
[Pittman 1990]
“Serpent … encourages the separation of software systems into user interface and ‘core’ application
portions, a separation which will decrease the cost of subsequent modifications to
the system.” [Bass 1989]
“This Nephew UIMS/Application interface is better [than] traditional UIMS/Application interfaces
from the modularity and code reusability point of views.” [Sleekly 1989]
Each of these systems, which nominally are supposed to serve the same purpose, has different
goals. Thus, comparing or evaluating architectures must be done in light of the system’s goals.
Whether these are the correct goals is outside of the scope of an architecture comparison or evaluation.
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 251
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.