Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).

Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.

Generalizing a Model of Software Architecture Design

from Five Industrial Approaches

Christine Hofmeister Philippe Kruchten Robert L. Nord

Lehigh University University of British Columbia Software Engineering Institute
Bethlehem, PA, USA Vancouver, B.C., Canada Pittsburgh, PA, USA
[email protected] [email protected] [email protected]

Henk Obbink Alexander Ran Pierre America

Philips Research Labs Nokia Philips Research Labs
Eindhoven, The Netherlands Burlington, MA, USA Eindhoven, The Netherlands
[email protected] [email protected] [email protected]

Abstract opers, methods with explicit support for product fami-

We compare five industrial software architecture lies vs. methods for one of a kind systems, etc.
design methods and we extract from their commonal- On the other hand, all software architecture design
ities a general software architecture design approach. methods must have much in common as they deal with
Using this general approach, we compare across the the same basic problem: maintaining intellectual con-
five methods the artifacts and activities they use or trol over the design of large software systems that: re-
recommend, and we pinpoint similarities and differ- quire involvement of and negotiation among multiple
ences. Once we get beyond the great variance in termi- stakeholders; are developed by large, often distributed
nology and description, we find that the 5 approaches teams over extended periods of time; and have to ad-
have a lot in common and match more or less the dress multiple possibly conflicting goals and concerns.
“ideal” pattern we introduced. It is thus of significant interest to understand the
commonalities that exist between different methods
1. Introduction and to develop a general model of architecture design.
Such a model would help us better understand the
Over the last 15 years a number of organizations strengths and weaknesses of different existing methods
and individual researchers have developed and docu- as well as provide a framework for developing new
mented techniques, processes, guidelines, and best methods better suited to specific application domains.
practices for software architecture design [4, 5, 6, 7, 8, With this goal in mind, we selected five different
12, 15]. Some of these were cast and published as ar- methods: Attribute-Driven Design (ADD) Method [4],
chitecture design methods or systems of concepts, developed at the SEI; Siemens’ 4 Views (S4V) method
processes and techniques for architecture design [16, [16], developed at Siemens Corporate Research; the
22, 26, 27]. Rational Unified Process 4 + 1 views (RUP 4+1) [21,
Since many of the design methods were developed 22] developed and commercialized by Rational Soft-
independently, their descriptions use different vocabu- ware, now IBM; Business Architecture Process and
lary and appear quite different from each other. Some Organization (BAPO) developed primarily at Philips
of the differences are essential. Architecture design Research [1, 26], and Architectural Separation of Con-
methods that were developed in different domains cerns (ASC) [27] developed at Nokia Research. We
naturally exhibit domain characteristics and emphasize also assembled a team of people who have made sig-
different goals. For example architectural design of nificant contributions to developing and documenting
information systems emphasizes data modeling, and at least one of the methods. Through extensive discus-
architecture design of telecommunication software is sions focused on how typical architecture design tasks
concerned with continuous operation, live upgrade and are accomplished by different methods, we have ar-
interoperability. Other essential differences may in- rived at a joint understanding of a general software
clude methods designed for large organization vs. architecture design model that underlies the five meth-
methods suitable for a team of a dozen software devel- ods. In this paper we document our understanding of

1
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
what seems to be fundamental about architecture de- 2.3. RUP’s 4+1 Views
sign.
This paper is organized as follows. We introduce The Rational Unified Process (RUP) is a software
the five contributing methods in Section 2. Then in development process developed and commercialized
Section 3 we present a general model of architecture by Rational Software, now IBM. RUP includes an ar-
design. Section 4describes the five contributing meth- chitectural design method, using the concept of 4+1
ods using terms and concepts of the general model, and views (RUP 4+1) [21, 22]; four views to describe the
discusses the commonalities and differences between design: logical view, process view, implementation
the contributing methods. Section 5 discusses related view and deployment view, using a use-case view to
work, and Section 6 concludes the paper. relate the design to the context and goals.
In RUP, architectural design is spread over several
2. Five Industrial Software Architecture iterations in an elaboration phase, iteratively populating
the 4 views, driven by architecturally significant use
Design Methods cases, nonfunctional requirements in the supplementary
specification, and risks. Each iteration results in an
2.1. Attribute-Driven Design executable architectural prototype, which is used to
The Attribute-Driven Design (ADD) method [4], validate the architectural design.
developed at the SEI, is an approach to defining soft-
ware architectures by basing the design process on the 2.4. Business Architecture Process and Organi-
architecture’s quality attribute requirements. It follows zation
a recursive decomposition process where, at each stage
in the decomposition, architectural tactics and patterns The BAPO/CAFCR approach [1, 24, 26, 33], de-
are chosen to satisfy a set of quality attribute scenarios. veloped primarily by Philips Research, aims at devel-
In ADD, the architects, for each module to decom- oping an architecture (the A in BAPO) for software-
pose, 1) choose the architectural drivers, 2) choose an intensive systems that fits optimally in the context of
architectural pattern that satisfies the drivers, 3) instan- business (B), process (P), and organization (O). For
tiate modules and allocate functionality from use cases, that purpose, the five CAFCR views are described:
and represent the results using multiple views, 4) de- Customer, Application, Functional, Conceptual, and
fine interfaces of the child modules, and 5) verify and Realization. These views bridge the gap between cus-
refine the use cases and quality scenarios, making them tomer needs, wishes, and objectives on the one hand
constraints for the child modules. and technological realization on the other hand.
In BAPO/CAFCR, the architect iteratively: 1) fills
in information in one of the CAFCR views, possibly in
2.2. Siemens’ 4 views
the form of one of the suggested artifacts; 2) analyzes a
The Siemens Four-Views (S4V) method [16, 32], particular quality attribute across the views to establish
developed at Siemens Corporate Research, is based on a link between the views and with the surrounding
best architecture practices for industrial systems. The business, processes and organization. The architecture
four views (conceptual, execution, module and code is complete when there is sufficient information to real-
architecture view), separate different engineering con- ize the system and the quality attribute analysis shows
cerns, thus reducing the complexity of the architecture no discrepancies.
design task.
These views are developed in the context of a re- 2.5. Architectural Separation of Concerns
curring Global Analysis activity. For Global Analysis,
the architect identifies the organizational, technologi- Architectural Separation of Concerns (ASC) or
cal, and product factors that influence the architecture: ARES System of Concepts [27], developed primarily
requirements, desired system qualities, organizational by Nokia, is a conceptual framework based on separa-
constraints, existing technology, etc. From these the tion of concerns to manage complexity of architecture
key architectural issues or challenges are identified; design. ASC relies on the fact that concerns related to
typically they arise from a set of factors that, taken different segments of the software transformation cycle
together, will be difficult to fulfill. Design strategies (typically including design, build, upgrade, load, and
are proposed to solve the issue, and they are applied to run time) are often separable. In addition to design of
one or more of the views. In addition to interleaving architectural structures for each segment, ASC pays
Global Analysis with the view design, the architect is special attention to design of texture – replicated mi-
expected to iterate among the design tasks of the four crostructure that addresses concerns that cannot be lo-
views. calized within the main structure.

2
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
In ASC, the architect analyses design inputs, such right ones (see Figure 1).
as preferred technology platforms, road maps, func- Because of the complexity of the design task, these
tional and quality requirements for the product family activities are not executed sequentially. Instead they
and the product, and using a palette of techniques, pro- are used repeatedly, at multiple levels of granularity,
duces and prioritizes ASR (architecturally significant until the architecture is complete and validated. Thus
requirements), groups ASR by segments of the soft- the second part of the general model is a characteriza-
ware transformation cycle that they address. Implemen- tion of its workflow.
tation (write-time) design addresses the ASR con- The key requirement of our model was that it be
cerned with the write-time segment. Design decisions general enough to fit our five architecture design meth-
make implementation technology choices, partition ods, and provide a useful framework for comparing
functional requirements between different architectural them. One strong influence on the activities in our
scopes of product portfolio, product family, or single model was Gero’s Function-Behavior-Structure
product, establish portability layers for multiplatform framework for engineering design [13, 14], which
products, allocate classes of functional requirements to Kruchten applies to software design in [23].
different subsystems, and develop description of the
API facilitating work division and outsourcing. Per- 3.1. Architectural Design Activities & Artifacts
formance (run-time) design deals with run-time ASR
addressing concurrency and protection, develops per- First we describe the main activities of the model,
formance models and makes decisions regarding task and their related artifacts.
and process partitions, scheduling policies, resource Architectural concerns: The IEEE 1471 standard
sharing and allocation. Finally, delivery/installation/ defines architectural concerns as “those interests which
upgrade design decisions address the ASR of the corre- pertain to the system’s development, its operation or
sponding segments. Typical decisions address parti- any other aspects that are critical or otherwise impor-
tions into separately loadable/executable units, installa- tant to one or more stakeholders. Concerns include
tion support, configuration data, upgrade/downgrade system considerations such as performance, reliability,
policies and mechanisms, management of shared com- security, distribution, and evolvability” [18]. Most ar-
ponents, external dependencies and compatibility re- chitectural concerns are expressed as requirements on
quirements. the system, but they can also include mandated design
decisions (e.g., use of existing standards). Regulatory
3. A General Model for Software Architec- requirements may also introduce architectural con-
cerns.
ture Design Context: According to IEEE 1471, “a system’s …
environment, or context, determines the setting and
The general model for software architecture design
circumstances of developmental, operational, political,
we developed first classifies the kinds of activities per-
and other influences upon that system” [18]. This in-
formed during design. Architectural analysis articulates
cludes things like business goals (e.g., buy vs. build),
architecturally significant requirements (ASRs) based
characteristics of the organization (e.g., skills of devel-
on the architectural concerns and context. Architectural
opers, development tools available), and the state of
synthesis results in candidate architectural solutions
technology. Note that sometimes the only distinction
that address these requirements. Architectural evalua-
between a concern and a context is whether it is spe-
tion ensures that the architectural decisions used are the
cifically desired for this system (a concern) or is in-

Figure 1: Architectural design activities

3
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
stead a general characteristic or goal of the organiza- with design fragments [2]. Knowledge of the evalua-
tion or a stakeholder (context). For example, a business tion process itself (e.g., workflow, methods and
goal of the architecture is a concern, whereas a busi- techniques) [25] can also be an important input.
ness goal of the enterprise is context. ƒ Knowledge necessary to produce the system (tech-
Architecturally-Significant Requirements: An nologies, components, project management). In
ASR is “a requirement upon a software system which many cases analysis knowledge is not sufficient to
influences its architecture” [25]. Not all of the system’s evaluate the architecture. One example is when a
requirements will be relevant to the architecture. Con- partial implementation is needed upon which to do
versely, not all ASRs will have originally been ex- experimentation. In general the design must be
pressed as requirements: they may arise from other evaluated using realization knowledge, in order to
architectural concerns or from the system context. ensure that the system can be built.
Architectural analysis: Architectural analysis
serves to define the problems the architecture must 3.2. Workflow
solve. This activity examines architectural concerns
and context in order to come up with a set of ASRs. In all five of the architectural methods on which
Candidate architectural solutions: Candidate ar- our model is based, the three main activities in Figure 1
chitectural solutions may present alternative solutions, (architectural analysis, architectural synthesis, and ar-
and/or may be partial solutions (i.e., fragments of an chitectural evaluation) do not proceed sequentially, but
architecture). They reflect design decisions about the rather proceed in small leaps and bounds as architects
structure of software. The architectural solutions in- move constantly from one to another, “growing” the
clude information about the design rationale, that is, architecture progressively over time. This is primarily
commentary on why decisions where made, what deci- because it is not possible to analyze, resolve, find solu-
sions were considered and rejected, and traceability of tions and evaluate the architecture for all architectural
decisions to requirements. concerns simultaneously: the range and number of in-
Architectural synthesis: Architectural synthesis terrelated issues is just too overwhelming for the hu-
is the core of architecture design. This activity pro- man mind, and moreover the inputs (goals, constraints,
poses architecture solutions to a set of ASRs, thus it etc) are usually ill-defined and only get better under-
moves from the problem to the solution space. stood or discovered as the architecture starts to emerge.
Validated architecture: The validated architec- To drive this apparently haphazard process, archi-
ture consists of those candidate architectural solutions tects maintain, implicitly or explicitly, a backlog of
that are consistent with the ASRs. These solutions must smaller needs, issues, problems they need to tackle and
also be mutually consistent. Only one of a set of alter- ideas they might want to use. The backlog drives the
native solutions can be present in the validated archi- workflow, helping the architect determine what to do
tecture. The validated architecture, like the candidate next. It is not an externally visible, persistent artifact;
architectural solutions, includes information about the on small projects it may only be a list in the architect’s
design rationale. notebook, while for larger projects it might be an elec-
Architectural evaluation: Architectural evalua- tronic, shared spreadsheet. See Figure 2.
tion ensures that the architectural design decisions The backlog is fed by: a) selecting some architec-
made are the right ones. The candidate architectural tural concern and/or ASR from architectural analysis,
solutions are measured against the ASRs. Although b) negative feedback in the form of issues or problems
multiple iterations are expected, the eventual result of arising from architectural evaluation, and to a lesser
architectural evaluation is the validated architecture. extent, c) ideas from the architect’s experience, discus-
Intermediate results would be the validation or invali- sions, readings, etc. A backlog item can be thought of
dation of candidate architectural solutions. as a statement of the form:
In addition to the above-described artifacts used in ƒ “We need to make a decision about X.”
the design activities, there are some less explicit inputs ƒ or “We should look at Y in order to address Z.”
that are critical to the design process: The backlog is constantly prioritized, bringing to
ƒ Design knowledge comes from the architect, from the front the items that seem most urgent. The tactics
organizational memory, or from the architecture for prioritization will vary, mostly based on external
community. It can take the form of styles, patterns, forces. These forces include risks to mitigate, upcom-
frameworks, reference architectures, ADLs, product- ing milestones, team pressure to start work on a part of
line technologies, etc. the system, or simply perception of greater difficulty.
ƒ Analysis knowledge is needed to define the problem Very often it is simply the need to relieve pressure
and evaluate the solution. Some work exists in from a stakeholder that drives an item to the top of the
analysis patterns [11] and analytic models associated backlog.

4
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5). Pittsburgh, PA, November 6-9,
2005. Named one of the five best papers of the conference.
Table 1 – Comparing methods: Activities

Activity ADD S4V RUP 4+1 BAPO/CAFCR ASC

Architectural Step 2a: Choose the architec- Global Analysis involves 1) identifying Build or extract a BAPO analysis identifies Concept definition, identification
analysis tural drivers. influencing factors; 2) analyzing them subset of the use case those elements of the and refinement of ASR, partition of
Quality attribute models help to identify their importance to the ar- model as key drivers BAPO context that are ASR by software segments: runtime,
elicit and structure the re- chitecture, flexibility, and change- for architectural de- relevant for the architec- development, load, etc. Thus analy-
quirements. ability; 3) identifying key issues or sign tural fit and determine the sis results in a collection of semi
problems that arise from a set of factors scope of the architecture separable problems.
Architectural Steps 2b: Choose an architec- The fourth part of Global Analysis, Gradually build during Elaborate the five CAFCR Address the ASR, segment by seg-
synthesis tural pattern that satisfies the identifying solution strategies, is the the elaboration phase views, adding or refining ment in an iterative process, resolv-
architectural drivers; 2c: In- beginning of arch. synthesis. Then architecture organized artifacts suitable for the ing conflicts between the ASR
stantiate modules and allocate strategies are instantiated as design along 4 different particular system within the same segment and inte-
functionality from the use decisions that determine the number views; in parallel grating solutions from different
cases using multiple views; 2d: and type of design elements for one of implement an architec- segments.
Define interfaces of the child the software architecture views. Design tural prototype.
modules. decisions can be captured in a table.
Architectural Step 2e: Verify and refine use S4V splits evaluation into global Build an executable Evaluation of the CAFCR Architectural decisions are evaluated
evaluation cases and quality scenarios and evaluation (done by the architect as the prototype architecture views in the BAPO con- with respect to ASR that they ad-
make them constraints for the design progresses ) and architecture to assess whether text and quality attribute dress. Typical procedure of evalua-
child modules. Note: this step evaluation, led by a team of external architectural objec- analysis across the tion may include model-based analy-
bridges evaluation and analy- reviewers, and done at major check- tives have been met, CAFCR views sis (LQN, Petri nets, Q nets) simula-
sis, preparing for the next points (e.g. to validate arch. concepts and risks retired tion, prototyping, and discussion of
iteration of ADD. and after design is complete). (elaboration phase). change / use scenarios

Table 2: Comparing methods: Artifacts

Artifact ADD S4V RUP 4+1 BAPO/CAFCR ASC

Architectural Functional require- Influencing factors are organizational, Vision document, Supplemen- These concerns are expressed Each product family has lists of
concerns ments, system quality technological, and product factors. Prod- tary specification (for non func- in the Customer and Applica- typical concerns that need to be
attribute requirements, uct factors, describing required charac- tional requirements); the Risk tion views. The overriding addressed by products in the
design constraints. teristics of the product, are always archi- List identifies, among others, meta-concern is bridging the domain. Stakeholders contrib-
tectural concerns, so are technological technical issues: elements that gap between customer needs, ute product specific concerns
factors (state of technology including are novel, unknown, or just wishes, and objectives and during product conception
standards) that could affect the product. perceived as challenging. technological realization. phase.
Context Business quality goals Organizational factors (see above) are Business case and Vision docu- Business goals and con- Preferred technology platforms
(e.g., time to market, usually context, not concerns. ment straints (including the scope Technology/product road maps
cost and benefit), of the market to be ad- Product family functional and
architecture qualities dressed), process goals and quality requirements
(e.g., conceptual integ- constraints, organizational System / hardware architecture
rity, buildability) goals and constraints Implementation constraints

5
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5). Pittsburgh, PA, November 6-9, 2005.
Named one of the five best papers of the conference.
Artifact ADD S4V RUP 4+1 BAPO/CAFCR ASC
Architec- Architectural drivers are the Issue cards describe issues or ASR are identified out of Those elements of the BAPO context A specific process is used to
turally combination of functional, problems that arise from sets of the requirements docu- that are relevant for the architectural fit identify ASR based on stake-
significant quality attribute, and busi- factors that, taken together, pose ments (Vision, use case and determine the scope of the architec- holder concerns, domain and
requirements ness requirements that significant architectural chal- model, supplementary ture. Traditional types of requirements product family specific check-
(ASR) “shape” the architecture. To lenges. These issues and their specification), and the risk are represented in the Customer and lists, and patterns for analysis.
identify them, locate the influencing factors are equiva- list. Some of the ASR are Application views, which can be influ- ASR are partitioned by seg-
quality attribute scenarios lent to the architecturally signifi- expressed in the form of enced by the architect in order to obtain ments of software transforma-
that reflect the highest cant requirements. scenarios (use case in- a better BAPO fit. tion cycle to establish semi-
priority business goals and stances) that are allocated separable solution domains.
have the most impact on the as objectives in the upcom- ASR that are in the same seg-
decomposition. ing iteration; this forms a ment are prioritized and ana-
requirements view (+1). lyzed for potential conflicts.
Candidate A collection of views, Part of the four views (concep- Design decisions are in- Consistent and partially complete A collection of patterns, frame-
architectural patterns, and architectural tual, module, execution, and crementally captured in CAFCR views (Customer, Application, works, and reference architec-
solutions tactics. The architecture code arch. views). These repre- four views (logical, proc- Functional, Conceptual, and Realiza- tures constitute the source for
also has associated with it sent design decisions taken in ess, implementation, de- tion), filled with various artifacts (mod- alternative decisions. An often
refined scenarios that show accordance with strategies that ployment), supplemented els, scenarios, interfaces, etc.) used practice is to analyze
mapping from requirements solve one or more issues. Issue with a use-case view and alternatives along with any
to decisions and also aid the Cards capture the issues, their with complementary texts, proposed solutions.
next iteration of design. influencing factors, and solution and plus an architectural
strategies. Factors are listed and prototype.
characterized in Factor Tables.
Validated Architecture describes a The description of the four Baseline a complete, ex- Consistent and complete CAFCR Concepts, structure and texture
architecture system as containers for views, the Issue Cards, and the ecutable architectural views. Consistent in the sense that these for each significant segment of
functionality and interac- Factor Tables represent the prototype at the end of the artifacts are mutually corresponding software transformation cycle
tions among the containers, validated architecture. elaboration phase. This and quality attribute analysis shows no (development / load/ runtime)
typically expressed in three prototype is complete discrepancies (for example, all quality
views: module decomposi- enough to be tested, and to requirements from the Application view
tion., concurrency, and validate that major archi- are satisfied by the Conceptual and
deployment. The architec- tectural objectives (func- Realization views). Complete in the
ture is validated for satis- tional and non functional, sense that artifacts have been suffi-
faction of require- such as performance) have ciently elaborated to enable realization.
ments/constraints with been met, and major tech-
respect to the decomposi- nical risks mitigated.
tion.
Backlog Information to be processed Supported in part by Issue In larger projects, an Issue Worry List contains: Artifacts to be The initial backlog is a result of
in subsequent steps includ- Cards, which help the architect List is maintained, which completed; Quality attributes to be the analysis. As the design
ing: identify important issues to contains elements of the analyzed; Quality requirements to be progresses ASR are partitioned
requirements to be ana- address and drive the bigger backlog. Architectural satisfied; BAPO analysis to be done; into solvable problems and
lyzed, decisions to be iterations through the activities. objectives are allocated to BAPO issues to be improved. Design some are left on the backlog to
merged, patterns to be Issue Cards are intended to be upcoming iterations, and knowledge comes from the architect (or be addressed later while some
instantiated, requirements permanent artifacts. S4V also captured in the form of organizational memory or community are being addressed earlier.
to be verified and refined. recommends the capture of iteration objectives in the best practice) and is recorded as an Thus entries in the backlog
certain inputs to the backlog: iteration plan. influencing factor. A large amount of represent finer and finer
Issue Cards can capture strate- general architectural knowledge is grained problems or issues.
gies (ideas) that don’t work. documented in the Gaudì website [24].

6
 Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
working to identify and understand this commonality
as well as the important differences. The rows of the
table are based on the activities and artifacts identified
Architectural
Assets
in the general model of the previous section.
Architecture
This comparison has been an iterative process of
producing a common model of design activities and
Ideas artifacts, seeing how well they relate to the methods,
Architectural
Synthesis and adjusting the models. We take a broad view of
architectural design activities and see that the methods
Context, Constraints Backlog address interrelated activities centered on analysis, syn-
Architectural thesis, and evaluation.
Architectural Evaluation The steps of ADD follow the sequence of analysis,
Analysis synthesis, and evaluation activities. Subsequent itera-
tions of the activities follow the decomposition of the
Architecturally Evaluation results
architecture – the order of which will vary (e.g., depth-
Significant
Requirements first, breadth-first) based on the business context, do-
main knowledge, or technology.
Figure 2: Backlog Global Analysis from S4V plays a large role in
analysis and in driving iterations through the activities.
Once a backlog item (or a small set of backlog Thus it spans architectural analysis, architectural syn-
items) is picked by the architects, they will proceed to thesis, the backlog, and describes how architectural
incrementally do architectural synthesis, making some concerns, context, ASRs, and some backlog items
design decisions and integrating them with the existing should be recorded. The Global Analysis artifacts, de-
set of design decisions. Thus it serves to set the objec- sign decision table, and tables that record the relation-
tives for a particular iteration of architectural synthesis. ships among views support traceability from require-
Less frequently, backlog items will drive architectural ments to the code (at the file and module level).
analysis or architectural evaluation. Once resolved, an
item is removed from the backlog, and the architects 4.2. Commonalities
proceed to the next one. If they encounter some diffi-
culty or some input is missing, the item is returned to Elements the methods have in common include:
the backlog. ƒ an emphasis on quality attribute requirements and the
Thus the backlog is constantly changing. The cycle need to aid the architect in focusing on the important
of adding to the backlog, reprioritizing, resolving an requirements that impact the architecture during
item, and removing an item is happening at various analysis,
periods: from a few hours, to a few days, or more. ƒ design elements organized into multiple views dur-
This backlog is similar to what some Agile meth- ing synthesis,
ods use, in particular Scrum [29]. It guides the work- ƒ and an iterative fine-grained evaluation activity (per-
flow through the three kinds of activities and provides formed internally after each synthesis result by the
the objectives for each iteration through the synthesis architect) as distinct from course-grained evaluation
activity. In addition to using some kind of backlog, the (architectural reviews performed at key stages in the
architect should also make sure that each iteration of software development life-cycle).
each activity is preceded by the setting of objectives for
that step. 4.3. Variations
There are also important variations between the meth-
4. Method Comparison using the General ods:
Model ƒ Intent – ADD was developed as a design approach
based on making a series of design decisions (aided
The five architectural methods have been devel- by the application of architectural tactics). Other
oped independently but there are many commonalities view-based approaches were initially centered on de-
among them. sign artifacts, with their dependencies suggesting a
sequencing of activities. 4+1 embedded in RUP pro-
4.1. Side-by-side comparison vides full process support. BAPO/CAFCR has been
See Tables 1 & 2 for a comparison of activities and especially developed to support the development of
artifacts By putting the methods side by side, we are product families.

7
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
ƒ Emphasis – RUP puts a strong emphasis on incre- comparisons based on applying the methods to a par-
mentally building an evolutionary prototype, forcing ticular example application, or comparing the methods
the designers to a more experimental style of archi- by classifying the artifacts or activities.
tectural design. BAPO/CAFCR is putting a strong The first group compares the artifacts for an ex-
emphasis on the scoping of the architecture and once ample application. Bahill et al. [3] first provide a
the scope of the architecture using a BAPO analysis “benchmark” application to be used for comparing
has been established, the focus is on ensuring the design methods. Then they provide a qualitative analy-
consistency and the completeness of the CAFCR sis of the results of applying eleven design methods to
views. ADD puts its emphasis on constructing the the benchmark application. Sharble & Cohen [30] use
architecture by applying architectural tactics (design complexity metrics to compare the class diagrams that
options for the architect that are influential in the result from applying two different OO development
control of a quality attribute response). methods on a brewery application.
ƒ Driving forces – ADD is quality attribute scenario The next group also compares artifacts, but by
focused; experience suggests that a handful of these classifying them according to what they can model.
shape the architecture and all other requirements are Wieringa [35] does this for a number of structured and
then mapped to this structure. This fact is also recog- OO specification methods, and Hong et al. [17] do this
nized in ASC, which ties architecture design to archi- as part of their comparison of six OO analysis and de-
tecturally significant requirements. ASR are broader sign methods.
than quality attributes and may include key func- The third kind of comparison examines the activi-
tional requirements. RUP is mostly driven by risk ties undertaken when designing particular applications.
mitigation. Kim & Lerch [20] measure the cognitive activities of
ƒ Architectural Scope – ASC recognizes a hierarchy designers when using an OO design method versus a
of architectural scopes like product portfolio, product functional decomposition approach. Each participant in
family, a single product, and a product release. Each this study designed two variants of a Towers of Hanoi
architecture design project uses enclosing scope as application.
the context of the design. The approach we take in this paper falls into the
ƒ Process Scope – ADD provides a step for choosing fourth category, characterizing and classifying activi-
the architectural drivers but its scope is such that it ties then comparing them across methods. Song & Os-
depends on more analysis types of activities from terweil [31] use process modeling techniques to model
other methods, such as global analysis from S4V. the activities and, to a lesser extent, the artifacts of the
However, S4V does not recommend or advocate methodologies. Although this approach is similar to
specific evaluation techniques. Thus ADD and S4V ours, the approaches differ in the development of the
complement each other in these respects. comparison model. They decompose the activities of
ƒ Description – Although four specific views are rec- each methodology, then classify and compare them.
ommended, the view-related aspects of S4V are lim- Thus the classification and comparison is begun with
ited to the second part of arch synthesis. Thus other the low-level elements. In contrast we create a general
views could be substituted or added while still using model where only one level of decomposition is done,
all the other parts of S4V. The views used for archi- resulting in the three activities of architectural analysis,
tecture design in ASC are tied to architectural struc- synthesis, and evaluation and the corresponding arti-
tures that are important for the specific system, facts. We then determine which elements of each
which in turn, are determined by the ASR. Thus ASC methodology map to these activities and artifacts, and
offers a process to determine which views should be compare to what extent each methodology covers the
used for architecture design of a specific system. various aspects of the activities and artifacts.
The views used in ADD are determined by the ASR, Hong et al. [17] also compare activities by first
though typically there is one for each of the three characterizing and classifying them. They repeatedly
kinds of viewtypes: module, component & connec- decompose the activities of each method, then create a
tor, and allocation [6]. “super-methodology” that is a union of all the finest
granularity of the subactivities. Each method is com-
5. Related Work pared to the super-methodology. Fichman & Kemerer
[10] take a similar approach, comparing methods using
We have found four main approaches to compar- the eleven analysis activities and ten design activities
ing design methods. Some researchers compare the that are the superset of the activities supported by
methods by comparing their results or artifacts. Others methods. Both of these approaches decompose the ac-
compare the activities done when following the meth- tivities to very specific tasks that are tightly related to
ods. Each of these approaches breaks down further into the artifacts produced by the method (e.g. Identify

8
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
classes, Identify inheritance relationships). We did not tectural evaluation are present in all of the investigated
want our general model to be restricted by the kinds of methods. The major variation can be observed in the
artifacts our five methods produce (e.g. specific views different details with respect to guidance and process
used by the method), so we did not decompose activi- focus across the various methods. Here the concept of
ties to the low level. backlog is crucial to relate the various activities.
Dobrica & Niemela’s approach to comparing For our general model many of the concepts we
methods is perhaps closest to ours [9]. However, rather use are already part of the IEEE 1471 [18] vocabulary:
than comparing architectural design methods, they are views, architectural concerns, context, stakeholders,
comparing methods for software architecture evalua- etc. Our more process-oriented model introduces the
tion. Thus the eight methods have a much narrower following concepts: backlog, analysis, synthesis and
scope, and in addition a number of them are variants of evaluation.
each other. Like us they compare activities and work- An important part of our model is the inclusion of
flow at a fairly coarse granularity, but they add a few analysis and evaluation activities as part of architecture
other dimensions for comparison, such as scope of design. While architecture evaluation has been the fo-
method, stakeholders involved, etc. cus of much prior work, the emphasis is typically on
In [23] Kruchten shows that if software engineers identifying candidate architectures or evaluating the
were to use the term “design” analogously to the way completed architecture. There has been far less work
other engineers use it, design would include “some on incremental or ongoing evaluation, and on architec-
requirements activities and all coding and testing ac- tural analysis. Our model reveals these to be important
tivities.” In a similar spirit, our use of the term “archi- research topics.
tecture design” encompasses analysis and evaluation Our model also introduces the concept of a back-
activities. Architectural synthesis, the activity that goes log as the driving force behind the workflow. The
from the problem space to the solution space is what backlog is a much richer workflow concept than simply
others might equate with the term “architecture de- noting that iteration is expected.
sign.” In [11] Fowler discusses the importance of We hope that our increased understanding of the
analysis, or understanding the problem, in moving from commonalities and differences of the various ap-
the problem space to the solution space. Roshandel et proaches will contribute to future methods that com-
al. [28] reinforce our conviction that evaluation is an bine the strong points of the existing ones and provide
integral part of architecture design. They demonstrate specific support for software architecture design in a
that the kinds of automated evaluation possible depend large variety of different contexts. As an example, two
on the architectural view described (where each of the of the authors looked at ways of combining ADD and
two views studied is represented in a different ADL). RUP 4+1 by modeling ADD as a RUP activity, and
Finally we note that our general model and the found that they complement each other well [19]. ADD
methods it is derived from are for the architecture de- fills a need within the RUP: it provides a step-by-step
sign of new systems, not for evolving or reconstructing approach for defining a candidate architecture. The
the architecture of existing systems. While parts of the RUP fills a need in the ADD by placing it in a life-
model may be relevant for architecture evolution, when cycle context; the RUP provides guidance on how to
comparing our model to the Symphony architecture proceed from the candidate architecture to an executa-
reconstruction process [34] we see that the activities ble architecture, detailed design and implementation.
and artifacts are not related at all. In both cases the
activities can be categorized into 1) understand the
problem, 2) solve it, and 3) evaluate the solution, but References
the same can be said of nearly any problem-solving
activity. [1] P. America, H. Obbink, and E. Rommes, "Multi-View
Variation Modeling for Scenario Analysis," in Proceedings of
Fifth International Workshop on Product Family Engineering
6. Conclusion (PFE-5), Sienna, Italy, 2003, Springer-Verlag, pp. 44-65.
In this paper we have analyzed a number of indus- [2] F. Bachmann, L. Bass, and M. Klein, Illuminating the
trially validated architectural design methods. Using a Fundamental Contributors to Software Architecture Quality,
CMU/SEI-2002-TR-025, Software Engineering Institute,
general model for architectural design activity, we have
Carnegie Mellon University, 2002.
identified the common and variable ingredients of these
methods. Despite the different vocabulary used for the [3] A.T. Bahill, M. Alford, K. Bharathan, J.R. Clymer, D.L.
Dean, J. Duke, G. Hill, E.V. LaBudde, E.J. Taipale, and A.W.
individual methods they have a lot in common at the Wymore, "The design-methods comparison project," IEEE
conceptual level. The basic architecting activities, like Transactions on Systems, Man and Cybernetics, vol. 28, no.
architectural analysis, architectural synthesis and archi- 1, 1998, pp. 80-103.

9
Proceedings of the 5th Working IEEE/IFIP Conference on Software Architecture (WICSA5).
Pittsburgh, PA, November 6-9, 2005. Named one of the five best papers of the conference.
[4] L. Bass, P. Clements, and R. Kazman, Software Archi- [21] P. Kruchten, "The 4+1 View Model of Architecture,"
tecture in Practice, 2nd ed., Reading, MA: Addison-Wesley, IEEE Software, vol. 12, no. 6, 1995, pp. 45-50.
2003. [22] P. Kruchten, The Rational Unified Process: An Intro-
[5] J. Bosch, Design and Use of Software Architecture: duction, 3 ed., Boston: Addison-Wesley, 2003.
Adopting and Evolving a Product-Line Approach, Boston: [23] P. Kruchten, "Casting Software Design in the Function-
Addison-Wesley, 2000. Behavior-Structure (FBS) Framework," IEEE Software, vol.
[6] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, 22, no. 2, 2005, pp. 52-58.
R. Little, R. Nord, and J. Stafford, Documenting Software [24] G. Muller, The Gaudi Project website, at
Architectures: Views and Beyond, Boston: Addison-Wesley, http://www.extra.research.philips.com/natlab/sysarch/index.h
2002. tml, 2005.
[7] P. Clements and L. Northrop, Software Product Lines: [25] H. Obbink, P. Kruchten, W. Kozaczynski, R. Hilliard,
Practice and Patterns, Boston: Addison-Wesley, 2002. A. Ran, H. Postema, D. Lutz, R. Kazman, W. Tracz, and E.
[8] D.M. Dikel, D. Kane, and J.R. Wilson, Software Archi- Kahane, Report on Software Architecture Review and As-
tecture: Organizational Principles and Patterns, Upper Sad- sessment (SARA), Version 1.0, February 2002.
dle River, NJ: Prentice-Hall, 2001. [26] H. Obbink, J.K. Müller, P. America, R. van Ommering,
[9] L. Dobrica and E. Niemela, "A survey on software ar- G. Muller, W. van der Sterren, and J.G. Wijnstra, COPA: A
chitecture analysis methods," IEEE Transactions on Software Component-Oriented Platform Architecting Method for
Engineering, vol. 28, no. 7, 2002, pp. 638-653. Families of Software-Intensive Electronic Products. Tutorial
[10] R.G. Fichman and C.F. Kemerer, "Object-oriented and for the First Software Product Line Conference, Denver,
conventional analysis and design methodologies," IEEE Colorado, August 2000. 2000,
Computer, vol. 25, no. 10, 1992, pp. 22-39. [27] A. Ran, "ARES Conceptual Framework for Software
[11] M. Fowler, Analysis Patterns: Reusable Object Models, Architecture," in M. Jazayeri, A. Ran, and F. van der Linden,
Addison Wesley, 1997. ed., Software Architecture for Product Families Principles
and Practice, Boston: Addison-Wesley, 2000, pp. 1-29.
[12] J. Garland and R. Anthony, Large-Scale Software Archi-
tecture: A Practical Guide using UML, New York: John [28] R. Roshandel, B. Schmerl, N. Medvidovic, D. Garlan,
Wiley & Sons, Inc., 2002. and D. Zhang, "Understanding Tradeoffs among Different
Architectural Modeling Approaches," in Proceedings of 4th
[13] J.S. Gero, "Design prototypes: A knowledge representa- Working IEEE/IFIP Conference on Software Architecture
tion scheme for design," AI Magazine, vol. 11, no. 4, 1990, (WICSA-04), Oslo, Norway, 2004, pp. 47-56.
pp. 26-36.
[29] K. Schwaber and M. Beedle, Agile Software Develop-
[14] J.S. Gero and U. Kannengiesser, "The situated function– ment with SCRUM, Upper Saddle River: Prentice-Hall, 2002.
behaviour–structure framework," Design Studies, vol. 25, no.
4, 2004, pp. 373-391. [30] R.C. Sharble and S.S. Cohen, "The object-oriented
brewery: a comparison of two object-oriented development
[15] H. Gomaa, Designing Concurrent, Distributed and methods," ACM SIGSOFT Software Engineering Notes, vol.
Real-time Applications with UML, Boston: Addison-Wesley, 18, no. 2, 1993, pp. 60-73.
2000.
[31] X. Song and L.J. Osterweil, "Experience with an ap-
[16] C. Hofmeister, R. Nord, and D. Soni, Applied Software proach to comparing software design methodologies," IEEE
Architecture, Boston: Addison-Wesley, 2000. Transactions on Software Engineering, vol. 20, no. 5, 1994,
[17] S. Hong, G. van den Goor, and S. Brinkkemper, "A pp. 364-384.
formal approach to the comparison of object-oriented analy- [32] D. Soni, R. Nord, and C. Hofmeister, "Software Archi-
sis anddesign methodologies," in Proceedings of Twenty- tecture in Industrial Applications," in Proceedings of 17th
Sixth Hawaii International Conference on System Sciences, International Conference on Software Engineering, 1995,
Wailea, HI, USA, 1993, pp. iv 689-698. ACM Press, pp. 196-207.
[18] IEEE, IEEE 1471:2000--Recommended practice for [33] F. van der Linden, J. Bosch, E. Kamsteries, K. Känsälä,
architectural description of software intensive systems., Los and H. Obbink, "Software Product Family Evaluation," in
Alamitos, CA: IEEE, 2000. Proceedings of Software Product Lines, Third International
[19] R. Kazman, P. Kruchten, R. Nord, and J. Tomayko, Conference, SPLC 2004, Boston, MA, 2004, Springer-
Integrating Software Architecture-Centric Methods into the Verlag, pp. 110-129.
Rational Unified Process, Technical report CMU/SEI-2004- [34] A. van Deursen, C. Hofmeister, R. Koschke, L. Moonen,
TR-011, Software Engineering Institute, 2004. and C. Riva, "Symphony: View-Driven Software Architec-
[20] J. Kim and F.J. Lerch, " Towards a model of cognitive ture Reconstruction," in Proceedings of 4th Working
process in logical design: comparing object-oriented and IEEE/IFIP Conference on Software Architecture (WICSA-
traditional functional decomposition software methodolo- 04), Oslo, Norway, 2004, IEEE, pp. 122-134.
gies," in Proceedings of SIGCHI conference on human fac- [35] R. Wieringa, "A Survey of Structured and Object-
tors in computing systems, Monterey, California, United Oriented Software Specification Methods and Techniques,"
States, 1992, ACM Press, pp. 489-498. ACM Computing Surveys, vol. 30, no. 4, 1998, pp. 459-527.

10