Tabla de contenido

INTRODUCTION .................................................................................................................... 5
APPLYING THE PROCESS................................................................................................... 6
THE PROCESS IN BRIEF ..................................................................................................... 6
SCOPE...................................................................................................................................... 12
SUMMARY .............................................................................................................................. 13
Chapter 2. Architecture, Architect, Architecting ....................................................................... 13
ARCHITECTURE .................................................................................................................... 13
ARCHITECT ............................................................................................................................ 26
ARCHITECTING ..................................................................................................................... 34
THE BENEFITS OF ARCHITECTING ................................................................................ 42
SUMMARY ............................................................................................................................... 49
Chapter 3. Method Fundamentals .............................................................................................. 49
KEY CONCEPTS ..................................................................................................................... 50
METHOD CONTENT ............................................................................................................. 53
PROCESS ................................................................................................................................. 58
SUMMARY ............................................................................................................................... 67
Chapter 4. Documenting a Software Architecture .................................................................... 68
THE END GAME .................................................................................................................... 69
KEY CONCEPTS ..................................................................................................................... 71
VIEWPOINTS AND VIEWS ................................................................................................. 72
MODELS .................................................................................................................................. 80
CHARACTERISTICS OF AN ARCHITECTURE DESCRIPTION FRA MEWORK ........ 84
AN ARCHITECTURE DESCRIPTION FRAMEWORK ..................................................... 89
THE SOFTWARE ARCHITECTURE DOCUMENT ........................................................... 95
SUMMARY ............................................................................................................................... 97
Chapter 5. Reusable Architecture Assets ................................................................................... 97
SOURCES OF ARCHITECTURE .......................................................................................... 97
AN ARCHITECTURE ASSET METAMODEL .................................................................... 98
ASSET TYPES ....................................................................................................................... 102
ATTRIBUTES OF AN ARCHITECTURE ASSET ............................................................ 112
OTHER REUSE CONSIDERATIONS ................................................................................ 115
 SUMMARY ............................................................................................................................. 116
Chapter 6. Introduction to the Case Study ............................................................................... 116
APPLYING THE PROCESS ................................................................................................ 117
SCOPE OF THE CASE STUDY ........................................................................................... 120
APPLICATION OVERVIEW ............................................................................................... 125
THE YOURTOUR VISION .................................................................................................. 128
SUMMARY ............................................................................................................................. 133
Chapter 7. Defining the Requirements ..................................................................................... 133
RELATING REQUIREMENTS TO ARCHITECTURE .................................................... 137
FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS ...................................... 139
TECHNIQUES FOR DOCUMENTING REQUIREMENTS ............................................. 141
APPLYING THE PROCESS ................................................................................................ 141
UNDERSTANDING THE TASK DESCRIPTIONS .......................................................... 143
DEFINE REQUIREMENTS: ACTIVITY OVERVIEW ..................................................... 143
PURPOSE .............................................................................................................................. 145
ROLES .................................................................................................................................... 145
STEPS..................................................................................................................................... 146
SUMMARY ............................................................................................................................. 188
Chapter 8. Creating the Logical Architecture .......................................................................... 189
MOVING FROM REQUIREMENTS TO SOLUTION ...................................................... 193
HOW MUCH LOGICAL ARCHITECTURE? ..................................................................... 195
APPLYING THE PROCESS ................................................................................................ 198
CREATE LOGICAL ARCHITECTURE: ACTIVITY OVERVIEW .................................. 199
PURPOSE .............................................................................................................................. 202
ROLES .................................................................................................................................... 202
STEP ....................................................................................................................................... 203
SUMMARY ............................................................................................................................. 272
Chapter 9. Creating the Physical Architecture ........................................................................ 272
MOVING FROM LOGICAL TO PHYSICAL ARCHITECTURE ...................................... 274
APPLYING THE PROCESS ................................................................................................ 276
CREATING THE PHYSICAL ARCHITECTURE: ACTIVITY OVERVIEW .................. 277
TASK: SURVEY ARCHITECTURE ASSETS .................................................................... 281
TASK: DEFINE ARCHITECTURE OVERVIEW .............................................................. 283
 TASK: DOCUMENT ARCHITECTURE DECISIONS ...................................................... 285
TASK: OUTLINE FUNCTIONAL ELEMENTS ................................................................ 285
CONTAINERS ....................................................................................................................... 294
EJB INTERFACES ................................................................................................................ 294
SESSION, ENTITY, AND MESSAGE-DRIVEN EJBS ..................................................... 294
TASK: OUTLINE DEPLOYMENT ELEMENTS ............................................................... 299
TASK: VERIFY ARCHITECTURE ..................................................................................... 303
TASK: BUILD ARCHITECTURE PROOF-OF-CONCEPT ............................................. 304
TASK: DETAIL FUNCTIONAL ELEMENTS ................................................................... 305
TASK: DETAIL DEPLOYMENT ELEMENTS .................................................................. 307
TASK: VALIDATE ARCHITECTURE ............................................................................... 311
TASK: UPDATE SOFTWARE ARCHITECTURE DOCUMENT .................................... 312
TASK: REVIEW ARCHITECTURE WITH STAKEHOLDERS ...................................... 313
SUMMARY ............................................................................................................................. 313
Chapter 10. Beyond the Basics ................................................................................................. 314
THE ARCHITECT AND THE PROJECT TEAM .............................................................. 314
THE ARCHITECT AND EXTERNAL INFLUENCES ...................................................... 325
ARCHITECTING COMPLEX SYSTEMS ........................................................................... 330
SUMMARY ............................................................................................................................. 342
IN CONCLUSION: A NOTE FROM THE AUTHORS ..................................................... 343
Appendix A. Software Architecture Metamodel ......................................................................... 343
DEFINITION OF METAMODEL TERMS .............................................................................. 345
Appendix B. Viewpoint Catalog ................................................................................................ 348
STAKEHOLDER SUMMARY .............................................................................................. 350
BASIC VIEWPOINTS .......................................................................................................... 350
CROSS-CUTTING VIEWPOINTS ...................................................................................... 353
VIEW CORRESPONDENCE ............................................................................................... 355
Appendix C. Method Summary ................................................................................................. 357
ROLES .................................................................................................................................... 357
WORK PRODUCTS .............................................................................................................. 360
ACTIVITIES .......................................................................................................................... 362
TASKS .................................................................................................................................... 363
PHASES ................................................................................................................................. 367
Appendix D. Architectural Requirement Checklist ................................................................. 370
FUNCTIONAL REQUIREMENTS ...................................................................................... 371
USABILITY REQUIREMENTS .......................................................................................... 371
RELIABILITY REQUIREMENTS ...................................................................................... 372
PERFORMANCE REQUIREMENTS.................................................................................. 372
SUPPORTABILITY REQUIREMENTS ............................................................................. 372
CONSTRAINTS ..................................................................................................................... 373
Glossary ...................................................................................................................................... 375
References .................................................................................................................................. 383
INTRODUCTION
Bjarne Stroustrup, the inventor of the C++ programming language, once
said, “Our civilization runs on software.” Software does indeed touch
many aspects of our everyday lives and is found in something as simple as
a birthday card that sings “Happy Birthday” when opened through to the
ubiquitous cell phone and, of course, in very complex systems such as
airplanes and nuclear power stations. In fact, many of the innovations
that we take for granted today, and organizations such as eBay or
Amazon, simply wouldn’t exist if it weren’t for software. Even traditional
organizations, such as those in the finance, retail, and public sectors,
depend heavily on software. In this day and age, it’s difficult to find an
organization that isn’t in the software business in some way.

This is where the process of architecting comes in. If this increasing

reliance on software is to be sustained, the software needs to provide the
required capability, be of sufficient quality, be available when promised,
and get delivered at an acceptable price. All these characteristics are
directly influenced by the architecture of the software, and it follows that
if we do a good job of architecting it, we’re more likely to meet our
desired objectives.

The purpose of this book is to guide you through the tasks and associated
best practices that are applied in architecting a software system. In
meeting this objective, the book will address some basic questions, such
as these:

• What is an architecture?
• What is the role of the architect on a software development project?
• What is the relationship of the architect to the other project roles?
• What is the architect’s role with respect to requirements?
• How is an architecture described?
• When and how does the architect produce an initial architecture?
• How does the architect refine the architecture?
• When does the architect consider reuse?
• How is an architecture validated?
APPLYING THE PROCESS
In answering such questions, we present a series of best practices that are
manifest in the roles, tasks, and work products described throughout this
book.

A practice is an approach to solving one or several commonly occurring

problems. Practices are intended as “chunks” of process for adoption,
enablement, and configuration. (RUP 2008)

These practices can be incorporated within any process you might use,
including those characterized as a waterfall process, an
iterative development process (such as the Rational Unified Process), or an
agile process (such as Scrum). As such, we don’t associate the practices
with any process in particular, although we do present the practices in a
sequence that allows us to demonstrate the relationships among them
and their relevance at different points in the project lifecycle. You are
encouraged to pick and choose those practices that will add the most
value to your projects and, of course, your architectures.

THE PROCESS IN BRIEF

Getting straight to the point, we thought it would be worthwhile to
provide a brief tour of the key process elements described in this book to
whet your appetite. Here, we focus on a single pass through the tasks
described in detail in this book (which we will refer to as an iteration)
although, of course, we may execute each of the tasks many times on a
project.

A high-level overview of the macro activities that comprise the process is

shown in Figure 1.1, aligned with software engineering disciplines.
Figure 1.1. Activity Overview
[A discipline is a] primary categorization mechanism for organizing tasks
that define a major “area of concern: and/or cooperation of work effort.
(OpenUP 2008)

As you can see, the architecting activities sit between requirements and
development. The iteration starts with the definition of the software
requirements in the Define Requirements activity. Although this activity
is primarily the responsibility of the business analyst, the architect will
participate in some of the detailed tasks that comprise this activity. The
architect subsequently creates a first-cut architecture in the Create
Logical Architecture activity. The resulting architecture is independent
of any technology considerations and is referred to as the logical
architecture. Consider this a stepping stone in getting from the
requirements to a physical architecture, which is technology-specific and
forms the basis of implementation (coding). The logical architecture is
input to any detailed design that is performed in the Create Logical
Detailed Design activity. This activity results in the addition of any
remaining detail that may be required at a logical level but is not
considered to be architectural. For an explanation of the difference
between architecture and detailed design, see the sidebar “Concept:
Architecture versus Design.”

Based on the requirements, logical architecture, and logical detailed

design, the architect then refines the architecture in the Create Physical
Architecture activity, which takes technology into account, resulting in
the physical architecture. This is input to any detailed design that is
performed in the Create Physical Detailed Design activity, which forms
the basis of implementation. Although the detailed design and
implementation activities are not the responsibility of the architect, they
provide guidance to the team as needed.

Concept: Architecture versus Design

All architecture is design, but not all design is architecture. Architecture represents
the significant design decisions that shape a system, where significant is measured
by cost of change. (Booch 2009)

Put another way, architecture can be considered to be strategic design,

whereas detailed design is considered to be tactical design.

The arrows linking the activities aren’t intended to show a hard-and-fast

sequence—just a likely sequence. Based on the architecting performed,
you may find that clarification of the requirements is needed and may
revisit the requirements as a result, for example.

So let’s now look a little deeper into a few of these activities so that you
can better appreciate the role of the architect within the iteration. The
detailed tasks that comprise the Define Requirements activity are
shown in Figure 1.2. The iteration starts with the Collect Stakeholder
Requests task, which, as its name suggests, focuses on understanding the
needs of the various stakeholders. The requests provide the architect an
initial indication of the scope of the system to be architected. After a
vocabulary of terms is developed in the Capture Common
Vocabulary task, the Define System Context task is of particular interest
to the architect, because it defines the external elements that must
interact with the system, such as end users and other systems. Based on
this context, the Outline Functional Requirements and Outline Non-
Functional Requirements tasks identify the functional and non-
functional requirements, respectively. The architect is interested not only
in the key functional requirements, but also in the system qualities (such
as performance) and solution constraints that comprise the non-
functional requirements, which are often more challenging to address
than the functional requirements.
Figure 1.2. Tasks in the Define Requirements Activity
The architect is involved, to some extent, throughout the Define
Requirements activities to ensure that the requirements are specified in
a manner that can be realistically achieved with available technology,
within the required schedule, and within budget. This often requires a
degree of negotiation with stakeholders in which the architect actively
participates. As far as requirements tasks are concerned, the architect is
particularly involved in the Prioritize Requirements task, in which the
architect ensures that the priorities are influenced by those requirements
and risks that will allow the architecture to stabilize as soon as possible.

The prioritized requirements drive the content of the remainder of the

iteration, in the sense that only the highest-priority requirements are
considered, because the extent to which you address these requirements
determines whether you have a viable system. (Lower-priority
requirements are considered in subsequent iterations.) The high-priority
requirements are detailed in the Detail Functional
Requirements and Detail Non-Functional Requirements tasks. Then
the architect formally documents a summary of the architecturally
significant requirements in the Update Software Architecture
Document task. The requirements-related tasks conclude with a review
of the requirements in the Review Requirements with
Stakeholders task. As for activities, the arrows linking the tasks aren’t
intended to show a hard-and-fast sequence (just a likely sequence), and
tasks may be revisited as required.

The tasks that comprise the Create Logical Architecture activity are
shown in Figure 1.3. Throughout this activity, the architect considers the
use of existing assets in the Survey Architecture Assets task. Even early
in the project, you may, as an architect, select an asset such as a reference
architecture that has a significant influence on your architecture. As each
task is performed, the architect captures those decisions in
the Document Architecture Decisions task.
Figure 1.3. Tasks in the Create Logical Architecture Activity

Based on the highest-priority requirements, the architect outlines the

candidate solution in the Define Architecture Overview task. The
architecture overview provides the “big picture” outline of the
architecture. Then the Outline Functional Elements and Outline
Deployment Elements tasks are performed concurrently, subsequently
refining this outline in terms of components, their interactions and
relationships, and their deployment on nodes. The Verify
Architecture task ensures that the various functional and deployment
elements that make up the architecture are consistent with one another
and, in particular, ensures that any concerns that cut across these
elements (for example, a quality such as performance that influences both
functional and deployment elements) have been addressed appropriately.
We acknowledge that functional and deployment elements do not
necessarily dominate every architecture (for example, concurrency
elements may dominate a real-time, embedded system), so in Chapter 4,
“Documenting a Software Architecture,” we introduce an extensible
architecture description framework for accommodating such concerns.

The architect also focuses on proving certain aspects of the architecture

in the Build Architecture Proof-of-Concept task. The objective is to
synthesize at least one solution (which may simply be conceptual rather
than physical) that satisfies the architecturally significant requirements
to determine whether such a solution, as envisaged by the architect,
exists. In particular, the proof-of-concept provides a vehicle for mitigating
certain architecture-related risks and often takes the form of executable
software that allows system functionality and qualities to be assessed.

Next, the architectural elements are detailed in the Detail Functional

Elements and Detail Deployment Elements tasks. The Validate
Architecture task ensures that the architectural elements will satisfy the
requirements as stated (both functional and non-functional), as well as
project considerations such as resource, budget, and schedule constraints.
Then the architect documents a summary of the platform-independent
architecture in the Update Software Architecture Document task. The
resulting architecture description is used to communicate the
architecture to the relevant stakeholders, including designers,
programmers, testers, project manager, maintainers, and support
personnel. Finally, the Review Architecture with Stakeholders task
allows agreement on the architecture to be established.

As indicated in Figure 1.1, the set of architecture-related work products

subsequently feeds into the Create Logical Detailed Design activity,
which adds detail to the identified architecture elements, before moving
on to the Create Physical Architecture activity.
The Create Physical Architecture activity contains exactly the same
tasks as those in the Create Logical Architecture activity but takes
technology considerations into account. Therefore, the tasks adopt
additional best practices that acknowledge this difference. The set of
architecture-related work products that is output from the Create
Physical Architecture activity feeds into the Create Physical Detailed
Design activity, which adds the relevant level of detail to the identified
architecture elements and which can be used as the basis of
implementation. The implementation ultimately results in an executable
release of software that is then tested to ensure that it meets the
requirements associated with the current iteration. Feedback on the
architecture from the architecture review and testing activities helps
guide the priorities for, and content of, the next iteration.

So there you have it—a complete iteration in terms of those tasks that
most influence the architecture! Much more detail exists behind each of
these tasks, which we briefly outline in this chapter. We elaborate on
these tasks and the architecture principles on which they are based in the
remainder of this book.

SCOPE
This book focuses on software-intensive systems. Thus, the
terms architecture, architect, and architecting, when unqualified, are
synonymous with the terms software architecture, software architect,
and software architecting, respectively. Although this book focuses on
software-intensive systems, several additional considerations are
discussed later in this book. It is important to remember, for example,
that a software-intensive system still needs hardware to execute and that
certain qualities, such as reliability or performance, are achieved only
through a combination of software and hardware. Therefore, this aspect
of the total solution cannot be ignored and will be considered in
subsequent discussions.

You should also be conscious that software-intensive systems support an

even broader picture in which you may consider systems that comprise
people and information to be first-class citizens, as well as software and
hardware. An even broader perspective is consideration of an enterprise
architecture that provides, among other things, a landscape of business
processes and existing IT systems, as well as a view of business change
initiatives that include transition planning and governance. Enterprise
architecture and systems engineering are outside the scope of this book,
although we do acknowledge such perspectives and the influences they
have in terms of guiding and constraining our work as software
architects.

SUMMARY
This chapter focused on setting the scene for the remainder of the book.
Before diving into the details, we need to establish some core concepts,
which we use extensively in the remaining chapters. These concepts are
the role of the architect, the characteristics of the architecting tasks that
they perform, and the architecture that results. All these concepts are
described in Chapter 2.

Chapter 2. Architecture, Architect,

Architecting

This chapter provides an overview of three of the core concepts related to

the subject of this book and concludes with a discussion of the benefits of
architecting. These concepts, as shown in Figure 2.1, are the role of
the architect, the characteristics of the architecting tasks they perform,
and the architecture that results.
Figure 2.1. Core Concepts Used in This Book

ARCHITECTURE
There is no shortage of definitions when it comes to architecture. Even
some websites maintain collections of definitions (SEI 2009). The
definition used in this book is that taken from IEEE 1471-2000, IEEE
Recommended Practice for Architectural Description of Software-
Intensive Systems (IEEE 1471 2000). This definition follows, with key
characteristics highlighted:

[Architecture is] The fundamental organization of a system embodied in

its components, their relationships to each other, and to the environment,
and the principles guiding its design and evolution. (IEEE 1471 2000)

This standard also defines the following terms related to this definition:

[A system is] a collection of components organized to accomplish a

specific function or set of functions. The term system encompasses
individual applications, systems in the traditional sense, subsystems,
systems of systems, product lines, product families, whole enterprises,
and other aggregations of interest. A system exists to fulfill one or
more missions in its environment. (IEEE 1471 2000)
The environment, or context, determines the setting and circumstances of
developmental, operational, political, and other influences upon that
system. (IEEE 1471 2000)
A mission is a use or operation for which a system is intended by one or
more stakeholders to meet some set of objectives. (IEEE 1471 2000)
[A system stakeholder is] an individual, team, or organization (or classes
thereof) with interests in, or concerns relative to, a system. (IEEE 1471
2000)

As you can see, the term component is used in this definition. Most
definitions of architecture do not define the term component, however,
and IEEE 1471 is no exception, choosing to leave it deliberately vague
because the term is intended to cover the many interpretations in the
industry. A component may be logical or physical, technology-
independent or technology-specific, large-grained or small-grained. For
the purposes of this book, we use the definition of component from the
Unified Modeling Language (UML) 2.2 specification:
A component represents a modular part of a system that encapsulates its
contents and whose manifestation is replaceable within its environment.
A component defines its behavior in terms of provided and required
interfaces. As such, a component serves as a type whose conformance is
defined by these provided and required interfaces (encompassing both
their static as well as dynamic semantics). One component may therefore
be substituted by another only if the two are type conformant. (UML 2.2
2009)

It is worth considering some other definitions of architecture so that you

can observe similarities among those definitions. Consider the following
definitions, in which some of the key characteristics are highlighted:

An architecture is the set of significant decisions about the organization of

a software system, the selection of structural elements and their
interfaces by which the system is composed, together with
their behavior as specified in the collaborations among those elements,
the composition of these elements into progressively larger subsystems,
and the architectural style that guides this organization—these elements
and their interfaces, their collaborations, and their composition.
(Kruchten 2000)
The software architecture of a program or computing system is
the structure or structures of the system, which comprise
software elements, the externally visible properties of those elements,
and the relationships among them. (Bass 2003)
The software architecture of a system or a collection of systems consists
of all the important design decisions about the software structures and
the interactions between those structures that comprise the systems. The
design decisions support a desired set of qualities that the system should
support to be successful. The design decisions provide a conceptual basis
for system development, support, and maintenance. (McGovern 2004)

You can see that although the definitions are somewhat different, they
have a large degree of commonality. Most definitions indicate that an
architecture is concerned with both structure and behavior, is concerned
with significant elements only, may conform to an architectural style, is
influenced by its stakeholders and its environment, and embodies
decisions based on rationale. All these themes and others are discussed in
the following sections.

An Architecture Defines Structure

If you were to ask someone to describe architecture to you, nine times out
of ten, that person would make some reference to something related to
structure, quite often in relation to a building or some other civil-
engineering structure, such as a bridge. Although other characteristics of
these items exist, such as behavior, fitness for purpose, and even
aesthetics, the structural characteristic is the most familiar and the most
often mentioned.

It should not surprise you, then, that if you ask someone to describe the
architecture of a software system that he or she is working on, you’ll
probably be shown a diagram that shows the structural aspects of the
system, whether these aspects are architectural layers, components, or
distribution nodes. Structure is indeed an essential characteristic of an
architecture.

The structural aspects of an architecture manifest themselves in many

ways, and most definitions of architecture are deliberately vague as a
result. A structural element could be a subsystem, a process, a library, a
database, a computational node, a legacy system, an off-the-shelf product,
and so on.

Many definitions of architecture also acknowledge not only the structural

elements themselves, but also the composition of structural elements,
their relationships (and any connectors needed to support these
relationships), their interfaces, and their partitioning. Again, each of these
elements can be provided in a variety of ways. A connector, for example,
could be a socket, be synchronous or asynchronous, be associated with a
particular protocol, and so on.

Figure 2.2 shows an example of some structural elements. This figure

shows a UML component diagram containing some structural elements in
an order processing system. You see three components, named Order
Entry, Customer Management, and Account Management. The Order
Entry component is shown as depending on the Customer Management
component and also on the Account Management component, indicated
by a UML dependency.
Figure 2.2. UML Component Diagram Showing Structural Elements

An Architecture Defines Behavior

As well as defining structural elements, an architecture defines the

interactions among these structural elements. These interactions provide
the desired system behavior.

Figure 2.3 is a UML sequence diagram showing several interactions that,

together, allow the system to support the creation of an order in an order
processing system. The figure shows five interactions. First, a Sales Clerk
actor creates an order by using an instance of the Order Entry component.
The Order Entry instance gets customer details by using an instance of
the Customer Management component. Then the Order Entry instance
uses an instance of the Account Management component to create the
order, populate the order with order items, and place the order.
Figure 2.3. UML Sequence Diagram Showing Behavioral Elements
It should be noted that Figure 2.3 is consistent with Figure 2.2 in that you
can derive the dependencies shown in Figure 2.2 from the interactions
defined in Figure 2.3. An instance of Order Entry, for example, depends on
an instance of Customer Management during its execution, as shown by
the interactions in Figure 2.3. This dependency is reflected in a
dependency relationship between the corresponding Order Entry and
Customer Management components, as shown in Figure 2.2.

An Architecture Focuses on Significant Elements

Although an architecture defines structure and behavior, it is not

concerned with defining all the structure and all the behavior. It is
concerned only with those elements that are deemed to be significant.
Significant elements are those that have a long and lasting effect, such as
the major structural elements, those elements associated with essential
behavior, and those elements that address significant qualities such as
reliability and scalability. In general, the architecture is not concerned
with the fine-grained details of these elements. Architectural significance
can also be phrased as economical significance, because the primary
drivers for considering certain elements over others are the cost of
creation and the cost of change.

Because an architecture focuses on significant elements only, it provides a

particular focus of the system under consideration—the focus that is
most relevant to the architect. In this sense, an architecture is an
abstraction of the system that helps an architect manage complexity.

It is also worth noting that the set of significant elements is not static and
may change over time. As a consequence of requirements being refined,
risks identified, executable software built, and lessons learned, the set of
significant elements may change. The relative stability of the architecture
in the face of change, however, is to some extent the sign of a good
architecture, the sign of a well-executed architecting process, and the sign
of a good architect. Continual revision of the architecture due to relatively
minor changes is not a good sign. If the architecture is relatively stable,
however, the converse is true.

An Architecture Balances Stakeholder Needs

An architecture is created ultimately to address a set of system

stakeholder needs, but often, meeting all the expressed needs is not
possible. A stakeholder may ask for some functionality within a specified
time frame, for example, but the two needs—functionality and time
frame—are mutually exclusive. Either the scope can be reduced to meet
the schedule, or all the functionality can be provided within an extended
time frame. Similarly, different stakeholders may express conflicting
needs, and again, an appropriate balance must be achieved. Making trade-
offs, therefore, is an essential aspect of the architecting process, and
negotiation is an essential characteristic of the architect.

Just to give you an idea of the task at hand, consider the following needs
of a set of stakeholders:

• The needs of the end user are associated with intuitive and correct
behavior, performance, reliability, usability, availability, and security.
• The needs of the system administrator are associated with intuitive
behavior, administration, and tools to aid monitoring.
• The needs of the marketer are associated with competitive features,
time to market, positioning with other products, and cost.
• The needs of the customer are associated with cost, stability, and
schedule.
• The needs of the developer are associated with clear requirements and a
simple, consistent design approach.
• The needs of the project manager are associated with predictability in
the tracking of the project, schedule, productive use of resources, and
budget.
• The needs of the maintainer are associated with a comprehensible,
consistent, and documented design approach, as well as the ease with
which modifications can be made.

Another challenge for the architect, as you can see from this list, is that
the stakeholders are not concerned only that the system provide the
required functionality. Many of the concerns that are listed are non-
functional in nature (in that they do not contribute to the functionality of
the system). Such concerns represent system qualities or constraints.
Non-functional requirements are quite often the most significant
requirements as far as an architect is concerned; they are discussed in
detail in Chapter 7, “Defining the Requirements.”

An Architecture Embodies Decisions Based on Rationale

An important aspect of an architecture is not just the end result—the

architecture itself—but also the rationale that explains why it is the way it
is. Thus, as described in Chapter 4, “Documenting a Software
Architecture,” important considerations are the documenting of the
decisions that led to this architecture and the rationale for these
decisions.

This information is relevant to many stakeholders, especially those who

must maintain the system. This information is often valuable to the
architects themselves when they need to revisit the rationale behind the
decisions that were made, so that they don’t end up having to retrace
their steps unnecessarily. This information is used when the architecture
is reviewed and the architect needs to justify the decisions that have been
made, for example.

Also, some of these decisions may have been imposed on the architect
and, in this sense, represent constraints on the solution. A companywide
policy to use particular technologies and products may exist, for example,
and this policy needs to be accommodated in the solution.
An Architecture May Conform to an Architectural Style

Most architectures are derived from systems that have a similar set of
concerns. This similarity can be described as an architectural style, a term
borrowed from the styles used in building architectures. You can think of
an architectural style as being a particular kind of pattern, albeit an often
complex and composite pattern (several patterns applied together).

Every well-structured software-intensive system is full of patterns.

(Booch 2009)

An architectural style represents a codification of experience, and it is

good practice for architects to look for opportunities to reuse such
experience. Examples of architectural styles include a distributed style, a
pipes-and-filters style, a data-centered style, a rule-based style, service-
oriented architecture, and so on. Architectural styles are discussed
further in Chapter 5, “Reusable Architecture Assets.” A given system may
exhibit more than one architectural style.

[An architectural style] defines a family of systems in terms of a pattern of

structural organization. More specifically, an architectural style defines a
vocabulary of components and connector types, and a set of constraints
on how they can be combined. (Shaw 1996)

The application of an architectural style (and reusable assets in general)

makes the life of an architect somewhat easier because such assets are
already proved, thereby reducing risk and, of course, effort. A style is
normally documented in terms of the rationale for using it (so there is
less thinking to be done) and in terms of its key structures and behaviors
(so there is less architecture documentation to be produced because you
can simply refer to the style instead). Architecture assets are discussed in
detail in Chapter 5, “Reusable Architecture Assets.”

An Architecture Is Influenced by Its Environment

A system resides in an environment, and this environment influences the

architecture. This is sometimes referred to as architecture in context. In
essence, the environment determines the boundaries within which the
system must operate, which then influence the architecture. The
environmental factors that influence the architecture include the
business mission that the architecture will support, the system
stakeholders, internal technical constraints (such as the requirement to
conform to organizational standards), and external technical constraints
(such as the need to use a specified technology, interface to an external
system, or conform to external regulatory standards).

Conversely, as eloquently described in Software Architecture in Practice,

2nd ed. (Bass 2003), the architecture may also influence its environment.
The creation of an architecture may contribute reusable assets to the
owning organization, for example, thereby making such assets available
to the next development effort. Another example is the selection of a
software package that is used within the architecture, such as a customer
relationship management (CRM) system, which subsequently requires
users to change the processes they follow to accommodate the way that
the package works.

An Architecture Influences Development Team Structure

An architecture defines coherent groupings of related elements that

address a given set of concerns. An architecture for an order processing
system, for example, may have defined groupings of elements for order
entry, account management, customer management, fulfillment,
integrations with external systems, persistence, and security.

Each of these groupings may require different skill sets. Therefore, it

makes perfect sense to align the software development team structures
with the architecture after it has been defined. Often, however, the
architecture is influenced by the initial team structure and not vice versa.
This pitfall is best avoided, because the result typically is a less-than-ideal
architecture. Conway’s Law states, “If you have four groups working on a
compiler, you’ll get a four-pass compiler.” In practice, architects often
unintentionally create architectures that reflect the organization creating
the architecture.

Although organizing work in line with the architecture can be beneficial,

this somewhat idealized view is not always practical. For purely
pragmatic reasons, the current team structure and the skills available
(both in the current team and the maintenance teams) represent a very
real constraint on what is possible, and the architect must take this
constraint into account. The geographic distribution of the team is
another constraint that needs to be accommodated:

The architectural partitioning should reflect the geographic partitioning,

and vice versa. Architectural responsibilities should be assigned so
decisions can be made (geographically) locally. (Coplien 2005)

An Architecture Is Present in Every System

It is also worth noting that every system has an architecture, even if this
architecture is not formally documented or if the system is extremely
simple and, say, consists of a single element. Documenting the
architecture usually has considerable value; this topic is discussed in
detail in Chapter 4, “Documenting a Software Architecture.”

Ultimately, every software-intensive system has an architecture, be it

intentional or accidental. Every such architecture serves to hold back the
forces upon that system in a manner that is functional, economical and
elegant. (Booch 2009)

If an architecture is not documented, it is difficult (if not impossible) to

assess the architecture and prove that it meets the stated requirements in
terms of development-time qualities such as flexibility, accommodation of
best practices, and so on. A lack of documentation can also make it
extremely difficult to maintain the system over time.

An Architecture Has a Particular Scope

Many kinds of architecture exist, the best known being the architecture
associated with buildings and other civil-engineering structures. Even in
the field of software engineering, you often come across different forms of
architecture. In addition to the concept of software architecture, for
example, you may encounter concepts such as enterprise
architecture, system architecture, information architecture, hardware
architecture, application architecture, infrastructure architecture, and data
architecture. You also hear other terms mentioned. Each of these terms
defines a specific scope of the architecting activities.
Unfortunately, the industry has come to no agreement on the meanings of
all these terms or their relationships to one another, resulting in different
meanings for the same term (homonyms) and two or more terms that
mean the same thing (synonyms). You can infer the scope of some of
these terms, as used in this book, from Figure 2.4, in which we focus on
the architecture of software-intensive systems. As you consider this figure
and the discussion that follows it, you will almost certainly find elements
that you disagree with or that you use differently within your
organization. Consider this example to be an acknowledgment of (and one
interpretation of) several possible scopes of architecting activities.

Figure 2.4. Different Architecting Scopes

Inspiration for the elements shown in Figure 2.4 came from various
sources. IEEE Std 12207-1995, the IEEE Standard for Information
Technology—Software Life Cycle Processes, defines a system as follows:

[A system is] an integrated composite that consists of one or more of the

processes, hardware, software, facilities and people, that provides a
capability to satisfy a stated need or objective. (IEEE 12207 1995)

A configuration of the Rational Unified Process for Systems Engineering

(RUP SE), also known as Model-Driven Systems Development (MDSD),
contains a similar definition:

[A system is] a set of resources that provide services that are used by an
enterprise to carry out a business purpose or mission. System
components typically consist of hardware, software, data, and workers.
(Cantor 2003)

The various elements shown in Figure 2.4 are

• Software.This element is the main focus of this book and considers

items such as components, relationships between components, and
interactions between components.
• Hardware.This element considers items such as CPUs, memory, hard
disks, peripheral devices such as printers, and the elements used to
connect these elements.
• Information.This element considers the information used within the
system.
• Workers.This element considers the people-related aspects of a system,
such as business processes, organizational structures, roles and
responsibilities, and core competencies of the organization.
• System.As described in the preceding definitions, a system comprises
software, hardware, information, and workers.
• Enterprise.This element is similar to a system in that it, too, considers
elements such as hardware, software, information, and workers. An
enterprise, however may span multiple systems and place constraints on
the systems that are part of the enterprise. An enterprise also has a
stronger link to the business than a system does, in that an enterprise
focuses on the attainment of the business objectives and is concerned
with items such as business strategy, business agility, and organizational
efficiency. Further, an enterprise may cross company boundaries.

Because we focus on software-intensive systems in this book, it is worth

making some additional observations. In particular, we should note that a
software-intensive system is a system. Therefore, you should understand
the relationship between the software and those elements with which it
must coexist:

• Software and workers.Although workers are not considered to be part

of the systems considered by this book, a relationship exists in terms of
the functionality that the system must provide to support any people who
interact with the system. Ensuring that this functionality is provided is, in
this book, the responsibility of the application architect.
• Software and hardware.A particular aspect of the environment that
must always be considered in software-intensive systems is the hardware
on which the software executes. The resulting system, therefore, is a
combination of software and hardware, and this combination allows
properties such as reliability and performance to be achieved. Software
cannot achieve these properties in isolation from the hardware on which
it executes. Ensuring the appropriate consideration of hardware is, in this
book, the responsibility of the infrastructure architect.
• Software and information.Software elements may produce and
consume persistent information during their execution. Ensuring the
appropriate consideration of information is, in this book, the
responsibility of the data architect.

For each specific type of architecture, a corresponding type of architect

exists (software architect, hardware architect, and so on), as well as a
corresponding type of architecting (software architecting, hardware
architecting, and so on).

Now that you’ve gotten through these definitions, you may have many
unanswered questions. What is the difference between an enterprise
architecture and a system architecture? Is an enterprise a system? Is an
information architecture the same as the data architecture found in some
data-intensive software applications? Unfortunately, no set of agreed-on
answers to these questions exists. For now, be aware that these different
terms exist but that the industry has no consistent definition of these
terms and how they relate to one another. We recommend, therefore, that
you select the terms that are relevant to your organization and define
them appropriately. Then you will achieve some consistency, at least, and
reduce the potential for miscommunication.

ARCHITECT
Now that we have defined what we mean by architecture, we can turn our
attention to the role that is responsible for the creation of the
architecture: the architect. The role of the architect is arguably the most
challenging in any software development project. The architect is the
technical lead on the project and, from a technical perspective, ultimately
carries responsibility for the technical success or failure of the project.
[An architect is] the person, team, or organization responsible for systems
architecture. (IEEE 1471 2000)

As the technical lead on the project, the architect must have skills that are
typically broad rather than deep (although architects should have deep
skills in particular areas).

The Architect Is a Technical Leader

First and foremost, the architect is a technical leader, which means that in
addition to having technical skills, the architect exhibits leadership
qualities. Leadership can be characterized in terms of both position in the
organization and the qualities that the architect exhibits.

In terms of position in the organization, the architect (or lead architect, if

the architect role is fulfilled by a team) is the technical lead on the project
and should have the authority to make technical decisions. The project
manager, on the other hand, is more concerned with managing the project
plan in terms of resources, schedule, and cost. Using the film industry as
an analogy, the project manager is the producer (making sure that things
get done), whereas the architect is the director (making sure that things
get done correctly). As a result of their positions, the architect and project
manager represent the public persona of the project and, as a team, are
the main contact points as far as people outside the project are
concerned. The architect in particular should be an advocate of the
investment made in creating an architecture and the value it brings to the
organization.

The architect should also be involved in determining how the team is

populated, because the architecture will imply the need for certain skills.
Dependencies among elements of the architecture influence the
sequencing of tasks and, therefore, when these skills are required, so the
architect should contribute actively to planning activities. On a related
note, because the success of the architect is closely linked to the quality of
the team, participation in interviewing new team members is also highly
appropriate.

In terms of the qualities that the architect exhibits, leadership can also be
characterized in terms of interactions with other team members.
Specifically, the architect should lead by example and show confidence in
setting direction. Successful architects are people-oriented, and all
architects take time to mentor and train members of their team. This
practice benefits the team members in question, the project, and
ultimately the organization itself, because some of its most valuable
assets (people) become better skilled.

Also, architects need to be very focused on the delivery of tangible results

and must act as the driving force for the project from a technical
perspective. Architects must be able to make decisions (often under
pressure) and make sure that those decisions are communicated, that
they are understood, and that they ultimately stick.

The Architect Role May Be Fulfilled by a Team

There is a difference between a role and a person. One person may fulfill
many roles (Mary is a developer and a tester), and a role may be fulfilled
by many people (Mary and John fulfill the role of tester). Given the
requirement for a very broad set of skills in an architect, it is often the
case that the architect role is fulfilled by more than one person. This
practice allows the skills to be spread across several people, each bringing
his or her own experiences to bear. In particular, the skills required to
understand both the business domain and various aspects of technology
are often best spread across several people. The resulting team needs to
be balanced, however.

Throughout this book, the term architect refers to the role, which may be
fulfilled by either an individual or a team.

[A team is] a small number of people with complementary skills who are
committed to a common purpose, performance goals, and approach for
which they hold themselves mutually accountable. (Katzenbach 1993)

If the architect role is to be fulfilled by a team, it is important to have one

individual who is considered to be the lead architect, who is responsible
for owning the vision, and who can act as a single point of coordination
across the architecture team. Without this point of coordination, there is a
danger that members of the architecture team will not produce a cohesive
architecture or that decisions will not be made.
For a team that is new to the concept of architecture, it has been
suggested that to achieve this common purpose, goals, and approach, the
team should create and publish a team charter (Kruchten 1999).

Good architects know their strengths and weaknesses. Whether or not the
architect role is fulfilled by a team, an architect is supported by several
trusted advisors. Such architects acknowledge where they are weak and
compensate for these weaknesses by obtaining the necessary skills or by
working with other people to fill the gaps in their knowledge. The best
architectures usually are created by a team rather than an individual,
simply because there is greater breadth and depth of knowledge when
more than one person is involved.

One pitfall with the concept of an architecture team, especially on large

projects, is that it may be perceived as an ivory tower whose output is
intellectual rather than useful. This misconception can be minimized from
the outset by ensuring that all the stakeholders are actively consulted,
that the architecture and its value are communicated, and that any
organizational politics in play are considered.

The Architect Understands the Software Development Process

Most architects have been developers at some point and should have a
good appreciation of the need to define and endorse best practices used
on the project. More specifically, the architect should have an
appreciation of the software development process, because this process
ensures that all the members of the team work in a coordinated manner.

This coordination is achieved by defining the roles involved, the tasks

undertaken, the work products created, and the handoff points among the
different roles. Because architects are involved with many of the team
members on a daily basis, it is important for them to understand the team
members’ roles and responsibilities, as well as what they are producing
and using. In essence, team members look to the architect for guidance on
how to fulfill their responsibilities, and the architect must be able to
respond in a manner that is consistent with the development process
being followed by the team.
The Architect Has Knowledge of the Business Domain

As well as having a grasp of software development, it is also highly

desirable (some would say essential) for architects to have an
understanding of the business domain so that they can act as
intermediaries between stakeholders and users, who understand the
business, and the members of the development team, who may be more
familiar with technology.

[A domain is] an area of knowledge or activity characterized by a set of

concepts and terminology understood by practitioners in that area. (UML
User Guide 1999)

Knowledge of the business domain also allows the architect to better

understand and contribute to the requirements on the system, as well as
to be in a position to ensure that likely requirements are captured. Also, a
particular domain often is associated with a particular set of architectural
patterns (and other assets) that can be applied in the solution, and
knowing this mapping can greatly assist the architect.

Therefore, a good architect has a good balance of software development

knowledge and business domain knowledge. When architects understand
software development but not the business domain, a solution may be
developed that does not fit the problem, but instead reflects the comfort
zone of things that the architect is familiar with.

Familiarity with the business domain also allows architects to anticipate

likely changes in their architecture. Given that the architecture is heavily
influenced by the environment in which it will be deployed, which
includes the business domain, an appreciation of the business domain
allows the architect to make better-informed decisions in terms of likely
areas of change and the areas of stability. If the architect is aware that
new regulatory standards will need to be adhered to at some point in the
future, this requirement should be accommodated in the architecture, for
example.
The Architect Has Technology Knowledge

Certain aspects of architecting clearly require knowledge of technology,

so an architect should have a certain level of technology skills. An
architect does not need to be a technology expert as such, however, and
needs to be concerned only with the significant elements of a technology,
not the detail. The architect may understand the key frameworks
available in a platform such as Java EE or .NET, but not necessarily the
detail of every application programming interface (API) that is available
to access these platforms. Because technology changes fairly frequently, it
is essential that the architect keep abreast of these changes.

The Architect Has Design Skills

Although architecting is not confined solely to design (as you have seen,
the architect is also involved in requirements tasks), design clearly is the
core aspect of architecting. The architecture embodies key design
decisions, so the architect should possess strong design skills. Such
decisions could represent key structural design decisions, the selection of
particular patterns, the specification of guidelines, and so on. To ensure
the architectural integrity of the system, these elements are typically
applied across the board and can have farreaching effects in terms of the
success of the system. Therefore, such elements need to be identified by
someone who has the appropriate skills.

One does not acquire design prowess overnight; instead, such skill is the
result of years of experience. Even expert designers look back on their
early work and shudder at how bad it was. As with every other skill, one
must practice design in order to obtain proficiency. (Coplien 2005)

The Architect Has Programming Skills

The developers on the project represent one of the most important

groups that the architect must interact with. After all, their work products
ultimately deliver the working executable software. The communication
between the architect and the developers can be effective only if the
architect is appreciative of the developers’ work. Therefore, architects
should have a certain level of programming skills, even if they do not
necessarily write code on the project, and those skills need to be kept up
to date with the technologies being used.

The Architect should be organizationally engaged with Developers and

should write code. If the architect implements, the development
organization perceives buy-in from the guiding architects, and that
perception can directly avail itself of architectural expertise. The
architects also learn by seeing the first-hand results of their decisions and
designs, thus giving them feedback on the development process. (Coplien
2005)

Most successful software architects have, at some stage, been hard-core

programmers. To some extent, this experience is how they learned
certain aspects of their trade. Even as technologies evolve and new
programming languages are introduced, good architects can abstract out
the concepts in any programming language and apply this knowledge to
learning a new programming language to the depth required. Without
this knowledge, the architect will be unable to make decisions with
respect to the architecturally significant elements of the implementation,
such as the organization of the source code and the adoption of
programming standards, and a communication barrier will exist between
the architect and the developers.

The Architect Is a Good Communicator

Of all of the soft skills associated with the architect, communication is the
most important. Effective communication involves several dimensions,
and the architect needs to be proficient in all of them. Specifically, the
architect should have effective verbal, written, and presentation skills.
Also, the communication should be two-way. The architect should be a
good listener and a good observer also.

Being able to communicate effectively is a skill that is fundamental to the

success of the project for many reasons. Clearly, communication with
stakeholders is particularly important to understand their needs and also
to communicate the architecture in a way that gains (and maintains)
agreement with all stakeholders. Communication with the project team is
particularly important, because the architect is not responsible simply for
conveying information to the team, but also for motivating the team.
Specifically, the architect is responsible for communicating (and
reinforcing the communication of) the vision for the system so that the
vision becomes shared, not something that only the architect understands
and believes in.

The Architect Makes Decisions

An architect who is unable to make decisions in an environment where

much is unknown, where insufficient time to explore all alternatives is
available, and where pressure to deliver exists is unlikely to survive.
Unfortunately, such environments are the norm rather than the
exception, and successful architects acknowledge the situation rather
than try to change it. Even though the architect may consult others when
making decisions and foster an environment in which others are included
in decision-making, it is still the architect’s responsibility to make the
appropriate decisions, which do not always prove to be right. Thus,
architects need to be thick-skinned, because they may need to correct
their decisions and backtrack.

An inability to make decisions will slowly undermine the project. The

project team will lose confidence in the architect, and the project manager
will be concerned because those waiting for the architecture cannot make
the required progress. The very real danger is that if the architect does
not make and document decisions about the architecture, team members
will start to make their own, possibly incorrect, decisions.

The Architect Is Aware of Organizational Politics

Successful architects are not only concerned with technology. They also
are politically astute and conscious of where the power in an organization
resides. They use this knowledge to ensure that the right people are
communicated with and that support for a project is aired in the right
circles. Ignoring organizational politics is, quite simply, naïve.

Politics involves a great deal of ambiguity, which makes many technical

people nervous. It forces them to play on “someone else’s court,” as it
were, a place where they feel they are at a disadvantage because their
technical prowess doesn’t count for much. (Marasco 2004)
The reality is that many forces at work in organizations lie outside the
project delivering the system, and these forces need to be accounted for.

Human beings tend not to all think alike; in order to resolve differences of
opinion, a political process is unavoidable. So, rather than condemn it, it is
better to understand politics as an effective means of dealing with the
inevitable need to resolve differences of opinion. (Marasco 2004)

The Architect Is a Negotiator

Given the many dimensions of architecting, the architect interacts with

many stakeholders. Some of these interactions require negotiation skills.
A particular focus for the architect is minimizing risk as early as possible
in the project, because minimizing risk has a direct correspondence to the
time it takes to stabilize the architecture. Because risks are associated
with requirements (and changes in requirements), one way to remove a
risk is to refine the requirements so that the risk is no longer present—
hence, the need to push back on such requirements so that stakeholders
and architect can reach a mutually agreeable position. This situation
requires the architect to be an effective negotiator who is able to
articulate the consequences of different trade-offs.

ARCHITECTING
Having described what an architecture is, and having defined the
characteristics of the architect role, now we can look at some of the
themes, or characteristics, that underlie the process of architecting. We
will not go into the detail of each task, because this detail is covered
throughout the remainder of this book. Also, those characteristics of
architecting that can be described in terms of benefits are described later
in this chapter.

[Software architecting represents] the activities of defining, documenting,

maintaining, improving, and certifying proper implementation of an
architecture. (IEEE 1471 2000)

The scope of architecting is fairly broad. Figure 2.5 shows a metamodel

that defines various aspects of the process of software architecting. This
metamodel is derived from that given in the IEEE 1471 standard and can
be considered to be a road map through the various aspects of
architecting that an architect is concerned with. Additional elements of
the metamodel will be considered throughout this book. We elaborate on
the Architectural Description element, for example, in Chapter 4,
“Documenting a Software Architecture,” where we consider how an
architecture is documented. We provide a complete description of the
metamodel used in this book in Appendix A, “Software Architecture
Metamodel.”
Figure 2.5. A Metamodel of Architecting-Related Terms

The relationships in this metamodel that are taken directly from the IEEE
1471 standard, in words, are

• A system has an architecture.

• A system fulfills one or more missions.
• A system has one or more stakeholders.
• A system inhabits an environment.
• An environment influences a system.
• An architecture is described by an architectural description.
• An architectural description identifies one or more stakeholders.
• An architectural description identifies one or more concerns.
• An architectural description provides rationale.
• A stakeholder has one or more concerns.
• A concern is important to one or more stakeholders.

A side benefit of the IEEE 1471 standard is that it not only applies to
documenting a software architecture, but also can be thought of as being
a reasoning framework for concepts that architects need to be concerned
with in their work. Additional relationships in the figure that are not part
of the IEEE 1471 standard are

• A development project is staffed by a team.

• A development project follows a development process.
• A development project develops a system.
• The development process includes architecting.
• The team includes an architect.
• The architect performs architecting
• The architect creates an architecture.
• The architect is a kind of stakeholder.
• Architecting results in an architecture.
• Rationale justifies one or more architecture decisions.
• An architecture decision addresses one or more concerns.

Architecting Is a Science

Architecting is a recognized discipline, albeit one that is still emerging.

With this recognition comes an emphasis on techniques, processes, and
assets that focus on improving the maturity of the process of architecting.
One way to advance this maturity is to draw on an existing body of
knowledge. In general terms, architects look for proven solutions when
developing an architecture rather than reinventing the wheel, thereby
avoiding unnecessary creativity. Codified experience in terms of reference
architectures, architectural and design patterns, and other reusable assets
also has a part to play.

There is still some way to go, however, before the process of software
architecting is anywhere near as mature as, for example, the processes in
civil engineering. This maturity can be considered in many dimensions,
including the use of standards and an understanding of best practices,
techniques, and processes.

Architecting Is an Art

Although architecting can be seen as a science, there is always a need to

provide some level of creativity, particularly true when dealing with novel
and unprecedented systems. In such cases, no codified experience may be
available to draw on. Just as painters look for inspiration when faced with
a blank canvas, architects may on occasion see their work as being more
like an art than a science. For the most part, however, the artistic side of
architecting is minimal. Even in the most novel of systems, it normally is
possible to copy solutions from elsewhere and then adapt them to the
system under consideration.

As the process of software architecting becomes more mainstream, it is

likely that it will no longer be seen as some mysterious set of practices
that only the chosen few are able to comprehend, but as a broadly
accessible set of well-defined and proven practices that have some
scientific basis and are widely accepted.

Architecting Spans Many Disciplines

The architect is involved in many aspects of the software development

process beyond architecting:

• The architect assists in the requirements discipline, for example,

ensuring that those requirements of particular interest to the architect
are captured.
• The architect is involved in prioritizing requirements.
• The architect participates in implementation, defining the
implementation structures that will be used to organize the source code
as well as executable work products.
• The architect participates in the test discipline, ensuring that the
architecture is both testable and tested.
• The architect is responsible for certain elements of the development
environment, in terms of defining certain project standards and
guidelines.
• The architect assists in defining the configuration management strategy,
because the configuration management structures (which support
version control) often reflect the architecture that has been defined.
• The architect and project manager work closely together, and the
architect has input in the project planning activities.

All these elements are described further later in this book.

Architecting Is an Ongoing Activity

Experience shows that architecting is not something that’s performed

once, early in a project. Rather, architecting is applied over the life of the
project; the architecture is grown through the delivery of a series of
incremental and iterative deliveries of executable software. At each
delivery, the architecture becomes more complete and stable, which
raises the obvious question of what the focus of the architect is through
the life of the project.

Successful software architecting efforts are results-driven. Thus, the focus

of the architect changes over time as the desired results change over time.
This profile is indicated in Figure 2.6, which is attributed to Bran Selic.
Figure 2.6. Project Emphasis over Time
Figure 2.6 shows that early in the project, the architect focuses on
discovery. The emphasis is on understanding the scope of the system and
identifying the critical features and any associated risks. These elements
clearly have an impact on the architecture. Then the emphasis changes to
invention; the architect’s primary concern is developing a stable
architecture that can provide the foundation for full-scale
implementation. Finally, the emphasis changes to implementation when
the majority of discovery and invention has taken place.

It should be noted that the concerns of discovery, invention, and

implementation are not strictly sequential. Some implementation occurs
early in the project as architectural prototypes are constructed, and some
discovery occurs late in the project as lessons are learned and different
strategies for implementing certain elements of the architecture are put
in place. This changing emphasis of architecting over time is discussed in
more detail in Chapter 3, “Method Fundamentals.”

The process of architecting is not complete until the system is delivered;

therefore, the architect must be involved until the end of the project. An
organization often has a strong desire to remove the architect from a
project when the architecture has stabilized so as to use this precious
resource on other projects. However, architectural decisions may still
need to be made late in the project. In practice, a middle ground is often
found: After the major decisions that affect the architecture have been
made, the architect becomes a part-time member of the team. The
architect should not disengage completely, however. A much more
flexible situation exists when the role of the architect is fulfilled by a
team, because some of the members may be used on other projects,
whereas those who remain continue to ensure the architectural integrity
of the system.

Architecting Is Driven by Many Stakeholders

An architecture fulfills the needs of a number of stakeholders. The

process of architecting, therefore, must accommodate all these
stakeholders to ensure that their concerns—specifically, those that are
likely to have an impact on the architecture—are captured, clarified,
reconciled, and managed. It is also necessary to involve the relevant
stakeholders in any reviews of the solution to these concerns.

Involving all the stakeholders is critical to ensuring a successful outcome

in terms of the resulting architecture. The stakeholders influence many
aspects of the process, as discussed further in this book, including the
manner in which the requirements are gathered, the form in which the
architecture is documented, and the way in which the architecture is
assessed.

Architecting Often Involves Making Trade-Offs

Given the many factors that influence an architecture, it is clear that the
process of architecting involves making trade-offs. Quite often, the trade-
off is between conflicting requirements, and the stakeholders may need to
be consulted to assist in making the correct trade-off. An example of a
trade-off is between cost and performance; throwing more processing
power at the problem will improve performance, but at a cost. This may
be a conflict in requirements and, assuming that the architect has been
diligent in his or her work by exploring all options, is a matter that needs
to be resolved with the stakeholders whose needs are in conflict.

Other trade-offs occur in the solution space. The use of one technology
over another, one third-party component over another, or even the use of
one set of patterns over another are all trade-offs concerned with the
solution rather than the requirements. Making trade-offs is not something
that the architect can or should avoid. The architect is expected to
consider alternatives, and making trade-offs among them is an essential
aspect of the process of architecting.
Figure 2.7 provides a simple classification of some of the forces at work in
architecting a solution. In addition to the function provided by the system,
you must be concerned with nonfunctional requirements that include
run-time qualities (such as performance and usability), non-run-time
qualities (such as maintainability and portability), business constraints
(such as regulatory and resource constraints), and technical constraints
(such as mandated technology standards and mandated solution
components).
Figure 2.7. Making Trade-Offs Addresses Opposing Forces

Architecting Acknowledges Experience

Architects rarely work from a blank sheet of paper. As noted earlier, they
actively seek experience that may be codified in architectural patterns,
design patterns, off-the-shelf components, and so on. In other words, the
architect seeks out reusable assets. Only the most ignorant architect does
not consider what has gone before.

A reusable asset is a solution to a recurring problem. A reusable asset is

an asset that has been developed with reuse in mind. (RAS 2004)

Although it is true that elements of an architecture are reusable in the

context of the current system, architects may also look upon their
architecture, or elements of it, as reusable assets that can be used outside
the current system. The subject of reuse is discussed later in this chapter
and in Chapter 5, “Reusable Architecture Assets.”
Architecting Is Both Top-Down and Bottom-Up

Many architectures are often considered in a top-down manner, where

stakeholder needs are captured and requirements developed before the
architecture is defined, architectural elements are designed, and these
elements are implemented. Architectures rarely are driven totally from
the top down, however. The primary reason is that most systems do not
start from a blank sheet of paper. Some heritage usually exists, in the
form of existing solution elements that need to be accommodated and
that influence the architecture. Such elements range from complete
applications that are to be reengineered to mandated design or
implementation elements that constraint the architecture. An example
might be a constraint that the design will use a relational database or
interface to an existing system.

An architecture may also be driven from the bottom up as a result of

lessons being learned from any executable software that has been
created, such as an architecture proof of concept, where these lessons
result in the architecture being refined accordingly.

Successful architects acknowledge that both approaches to architecting

are necessary and that their architectures are created both top-down and
bottom-up, which could be referred to as the “meet-in-the-middle”
approach to architecting.

THE BENEFITS OF ARCHITECTING

In general terms, architecting is a key factor in reducing cost, improving
quality, supporting timely delivery against schedule, supporting delivery
against requirements, and reducing risk. In this section, we focus on more
specific benefits that contribute to meeting these objectives.

Also, because architects sometimes have to justify their existence, this

section provides some useful ammunition for treating architecting as a
critical part of the software development process.

Architecting Addresses System Qualities

The functionality of the system is supported by the architecture through

the interactions that occur among the various elements that comprise the
architecture. One of the key characteristics of architecting, however, is
that it is the vehicle through which system qualities are achieved.
Qualities such as performance, security, and maintainability cannot be
achieved in the absence of a unifying architectural vision; these qualities
are not confined to a single architectural element but permeate the entire
architecture.

To address performance requirements, for example, it may be necessary

to consider the time for each component of the architecture to execute
and also the time spent in intercomponent communication. Similarly, to
address security requirements, it may be necessary to consider the nature
of the communication among components and introduce specific security-
aware components where necessary. All these concerns are architectural
and, in these examples, concern themselves with the individual
components and the connections among them.

A related benefit of architecting is that it is possible to assess such

qualities early in the project life cycle. Architectural proofs of concept are
often created to specifically ensure that such qualities are addressed.
Demonstrating that such qualities are met through an actual
implementation (in this case, an architectural proof of concept) is
important because no matter how good an architecture looks on paper,
executable software is the only true measure of whether the architecture
has addressed such qualities.

Architecting Drives Consensus

The process of architecting drives consensus among the various

stakeholders because it provides a vehicle for enabling debate about the
system solution. To support such debate, the process of architecting
needs to ensure that the architecture is clearly communicated and
proved.

An architecture that is communicated effectively allows decisions and

trade-offs to be debated, facilitates reviews, and allows agreement to be
reached. Conversely, an architecture that is poorly communicated does
not allow such debate to occur. Without such input, the resulting
architecture is likely to be of lower quality. Clearly, an important aspect of
communicating the architecture effectively is documenting it
appropriately. This topic is a primary concern for the architect and is the
subject of Chapter 4, “Documenting a Software Architecture.”

On a related note, the architecture can drive consensus between

architects (and their vision) and new or existing team members as part of
training. Again, the architecture must be communicated effectively for
this benefit to be achieved. Development teams with a good vision of what
they are implementing have a better chance of implementing the product
as desired.

Driving consensus is also achieved by validating that the architecture

meets the stated requirements. As mentioned in the preceding section,
the creation of an executable proof of concept is an excellent way of
demonstrating that the architecture meets certain run-time qualities.

Architecting Supports the Planning Process

The process of architecting supports several disciplines. Clearly, it

supports the detailed design and implementation activities, because the
architecture is a direct input to these activities. In terms of the benefits
that the process of architecting brings, however, arguably the major
benefits are those related to the support provided to project planning and
project management activities in general—specifically scheduling, work
allocation, cost analysis, risk management, and skills development. The
process of architecting can support all these concerns, which is one of the
main reasons why the architect and the project manager should have
such a close relationship.

Much of this support is derived from the fact that the architecture
identifies the significant components in the system and the relationships
among them. Consider the UML component diagram in Figure 2.8, which
has been kept deliberately simple for the purposes of this discussion. This
figure shows four components with dependencies among them.
Figure 2.8. UML Component Diagram Showing Architecturally Significant Elements
For the purposes of this discussion, consider a simple case in which each
component is always implemented in its entirety (that is, we do not create
partial implementations of each element, and no separation of interface
from implementation exists). In terms of scheduling, the dependencies
imply an order in which each of these elements should be considered.
From an implementation perspective, for example, the dependencies tell
you that the Error Log component must be implemented before anything
else, because all the other components use this component. Next, the
Customer Management and Fulfillment components can be implemented
in parallel because they do not depend on each other. Finally, when these
two components have been implemented, the Account Management
component can be implemented. From this information, you can derive
the Gantt chart (one of the conventional planning techniques used by a
project manager) shown in Figure 2.9. The duration of each of the tasks
shown does require some thought but can be derived partially from the
complexity of each of the architectural elements.
Figure 2.9. Gantt Chart Based on Dependencies among Architecturally Significant
Elements
The architect can also assist in the cost estimation for the project. The
costs associated with a project come from many areas. Clearly, the
duration of the tasks and the resources allocated to the task allow the cost
of labor to be determined. The architecture can also help determine costs
related to the use of third-party components to be used in the delivered
system. Another cost is derived from the use of particular tools that are
required to support the creation of the architectural elements.
Architecting also involves prioritizing risks and identifying appropriate
risk mitigation strategies, both of which are provided as input to the
project manager.

Finally, the architecture identifies discrete components of the solution

that can provide input in terms of the skills required on the project. If
appropriately skilled resources are not available within the project or
within the organization, the architecture clearly helps identify areas in
which skills acquisition is required. This acquisition may be achieved by
developing existing personnel, outsourcing, or hiring new personnel.

Architecting Drives Architectural Integrity

One of the primary objectives of the process of architecting is making sure

that the architecture provides a solid framework for the work undertaken
by the designers and implementers. Clearly, this objective is more than
simply conveying an architectural vision. To ensure the integrity of the
resulting architecture, the architect must clearly define the architecture
itself, which identifies the architecturally significant elements, such as the
components of the system, their interfaces, and their interactions.

The architect must also define the appropriate practices, standards, and
guidelines that will guide the designers and implementers in their work.
Another objective of architecting is eliminating unnecessary creativity on
the part of the designers and implementers, and this objective is achieved
by imposing the necessary constraints on what designers and
implementers can do, because deviation from the constraints may cause
breakage of the architecture. Still another aspect of architecting that helps
ensure architectural integrity is the adoption of appropriate review and
assessment activities that confirm adherence to architectural standards
and guidelines by designers and implementers.
We discuss architecture assessment further in Chapter 8, “Creating the
Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.”

Architecting Helps Manage Complexity

Systems today are more complex than ever, and this complexity needs to
be managed. As mentioned earlier in this chapter, because an architecture
focuses on only those elements that are significant, it provides an
abstraction of the system and therefore provides a means of managing
complexity. Also, the process of architecting considers the recursive
decomposition of components, which is clearly a good way of taking a
large problem and breaking it down into a series of smaller problems.

Finally, another aspect of managing complexity is using techniques that

allow abstractions of the architecture to be communicated. You might
choose to group components into subsystems or to separate interfaces
from implementation, for example. The adoption of industry standards
that allow abstractions to be expressed, such as UML, is commonplace in
the industry today for documenting the architecture of software-intensive
systems.

Architecting Provides a Basis for Reuse

The process of architecting can support both the production and

consumption of reusable assets. Reusable assets are beneficial to an
organization because they can reduce the overall cost of a system and also
improve its quality, given that a reusable asset has already been proved
(because it has already been used).

In terms of asset consumption, the creation of an architecture supports

the identification of possible reuse opportunities. The identification of the
architecturally significant components and their associated interfaces and
qualities supports the selection of off-the-shelf components, existing
systems, packaged applications, and so on that may be used to implement
these components.

In terms of asset production, the architecture may contain elements that

are, by their very nature, applicable outside the current system. The
architecture may contain an error logging mechanism that could be
reused in several other contexts. Such reuse generally is opportunistic,
whereas a strategic reuse initiative considers candidate assets ahead of
time. We touch on this topic in Chapter 10, “Beyond the Basics.”

Architecting Reduces Maintenance Costs

The process of architecting can help reduce maintenance costs in several

ways. First and foremost, the process of architecting should always
ensure that the maintainer of the system is a key stakeholder and that the
maintainer’s needs are addressed as a primary concern, not as an
afterthought. The result should be an architecture that is appropriately
documented to ease the maintainability of the system; the architect also
ensures that appropriate mechanisms for maintaining the system are
incorporated and considers the adaptability and extensibility of the
system when creating the architecture. In addition, the architect
considers the skills available to maintain the system, which may be
different from those of the team members who created the system.

The architect should consider the areas of the system that are most likely
to require change and then isolate them. This process can be fairly
straightforward if the change affects a single component or a small
number of components. Some changes, however, such as those relating to
system qualities such as performance or reliability, cannot be isolated in
this way. For this reason, the architect must consider any likely future
requirements when architecting the current system. Scaling up a system
to support thousands of users rather than the tens of users for which the
system was originally designed may not be possible without changing the
architecture in fundamental ways, for example.

The issue of maintainability is a primary concern only for those systems

that will evolve over time, not for systems whose purpose is to provide a
tactical solution and whose life is limited.

Architecting Supports Impact Analysis

An important benefit of architecting is that it allows architects to reason

about the impact of making a change before it is undertaken. An
architecture identifies the major components and their interactions, the
dependencies among components, and traceability from these
components to the requirements that they realize.
Given this information, a change to a requirement can be analyzed in
terms of the impact on the components that collaborate to realize this
requirement. Similarly, the impact of changing a component can be
analyzed in terms of the other components that depend upon it. Such
analyses can greatly assist in determining the cost of a change, the impact
that a change has on the system, and the risk associated with making the
change.

SUMMARY
This chapter defined and explained the core concepts used throughout
this book: architecture, architect, and architecting. The benefits of taking
an architecturecentric approach to the software development process
were also discussed. Many issues remain unresolved, however, such as
what the architect actually does on a software development project, what
the architect produces, and how the role of the architect relates to other
project roles.

Having defined these core concepts, we turn our attention to the

application of these concepts within the overall software development
process in Chapter 3, “Method Fundamentals.”

Chapter 3. Method Fundamentals

Having discussed some core concepts, we now turn our attention to some
of the details that underpin the process of architecting, such as work
products, tasks, and roles. To provide this summary, we consider various
architecture related best practices that have developed in the software
industry and draw on elements of various approaches, including the
Rational Unified Process, IBM Unified Method Framework, OpenUP,
eXtreme Programming (XP), Scrum, Feature-Driven Development (FDD),
and Lean. We also consider relevant standardization initiatives, such as
the Software and Systems Process Engineering Metamodel Specification
(SPEM).

The purpose of this chapter is to provide an overview of the key method

elements on which this book is based. Therefore, this chapter sets the
scene for the remaining chapters, in which we elaborate on these
concepts. A summary of the method elements described in this book is
also given in Appendix C, “Method Summary.”

KEY CONCEPTS
For subsequent discussion in this chapter to make sense, it is important
for us to establish some basic concepts present in a method. The Software
and Systems Process Engineering Metamodel Specification (SPEM) Object
Management Group (OMG) standard (SPEM 2007) can help, because it
provides definitions of such concepts, and we use them in this book. The
SPEM standard is influenced by and supports several existing software
development methods, including OpenUP (OpenUP 2008), the Rational
Unified Process (RUP 2008), IBM Unified Method Framework, Fujitsu
DMR Macroscope, and Unisys QuadCycle.

The SPEM standard defines various concepts in a significant amount of

detail. For the purposes of this book, however, we adopted a simple
subset and made some simplifying assumptions. The relevant terms used
in this book are shown in Figure 3.1, which uses, where defined,
relationships and icons from the SPEM standard.
Figure 3.1. Key Method Concepts and Their Relationships
In essence, an effective software development method should describe
who does what, how, and when. This book does exactly that in terms of
the following key concepts:

• Roles: The who

• Work products: The what
• Tasks: The how
• Phases, iterations, and activities: The when

In addition, a method includes guidance in the form of templates,

examples, and techniques. With reference to Figure 3.1, a software
development project typically moves through several phases, each of
which is divided into several iterations (although, as you will see, not all
processes are organized by phases and iterations). Within each iteration,
we consider various activities and the tasks they reference, which are
executed to achieve a particular result. Tasks are performed by
appropriate roles, and relevant work products are used and produced.

Also, as shown in Figure 3.1, a method can be considered to

comprise method content and process. Method content describes the life-
cycle-independent elements, such as roles, tasks, and work products.
Then a process takes these elements and defines a sequence in which they
are applied, depending on the nature of the project being considered, and
considers concepts such as phases, iterations, and activities. An example
of the separation of method content and process is provided by OpenUP, a
visualization of which is provided in Figure 3.2. In this figure, the vertical
axis represents the method content, grouped by discipline, and the
horizontal access describes the process.

[A discipline is a] primary categorization mechanism for organizing tasks

that define a major “area of concern” and/or cooperation of work effort.
(OpenUP 2008)
Figure 3.2. Method Content and Process Dimensions of OpenUP
A discipline is a collection of activities that are related to a major area of
concern within the overall project. As shown in Figure 3.2, OpenUP is
organized around five disciplines, which are described in Table 3.1.

Table 3.1. OpenUP Discipline Summary

As the “humps” in Figure 3.2 demonstrate, the relative emphasis of the

disciplines changes over the life of the project. In early iterations, for
example, more time is spent on requirements, and in later iterations,
more time is spent on development.
The definitions of roles, tasks, and work products usually are considered
to be highly reusable because, unlike the process-related elements, they
do not tend to vary greatly among different types of life cycles and
projects. A software development project that is developing a system
from a blank sheet of paper will perform a task such as Identify
Functional Requirements by using much the same steps as a project
that is changing an existing system, but the emphasis on this task will be
very different through the life cycle.

METHOD CONTENT
As we mention in the preceding section of this chapter, method content
refers to the roles, work products, and tasks that comprise the method
being followed.

Role

A role defines the responsibilities of an individual or a set of individuals

working together as a team within the context of a software development
organization. A role is responsible for one or more work products and
performs a set of tasks. The Business Analyst role, for example, is
responsible for the Functional Requirements work product and
performs the Identify Functional Requirements task. In this book,
when a role performs a task, the role is considered to be either primary or
secondary, as discussed in the sidebar “Concept: Primary and Secondary
Roles.”

It is important to emphasize that roles are not individuals. Individuals

may play multiple roles (wear multiple hats), and multiple individuals
may play a single role. The Project Manager is responsible for
performing the mapping of individuals to roles when planning and
staffing the project, although the Project Manager of course consults
others when doing this. The architect related roles used in this book are
shown in Figure 3.3 (although not all projects require these specialized
roles, and a single role of architect may be sufficient).

Figure 3.3. Roles Related to Software Architecture

The Lead Architect has overall responsibility for the major technical
decisions that define the architecture of the system. This role also is
responsible for providing rationale for these decisions; balancing the
concerns of the various stakeholders; managing technical risks and
issues; and ensuring that decisions are effectively communicated,
validated, and adhered to.

The Application Architect focuses on those elements of a system that

automate business processes and meet business needs. This role focuses
primarily on satisfying the functionality required by the business, but it is
also concerned with how the application-related elements meet the non-
functional requirements of the system (qualities and constraints).

The Infrastructure Architect concentrates on those elements of the

system that are independent of business functionality, such as a
persistence mechanism, hardware, and middleware. Such elements
support the execution of the application-related elements. This role
focuses on elements that have a significant bearing on the qualities
exhibited by the system and, therefore, the extent to which certain non-
functional requirements are addressed.

The Data Architect focuses on the data elements of a system, especially

data that is made persistent in an appropriate mechanism, such as a
database, a file system, a content management system, or some other
storage mechanism. This role defines appropriate data-related properties,
such as structure, source, location, integrity, availability, performance,
and age.

Concept: Primary and Secondary Roles

The primary role for a given task is considered to be responsible for the task and is
never optional. A secondary role is considered to contribute to the task but is not
responsible for it and may be considered optional.

A more complete characterization of roles is given by the RACI classification,

wherein each role may be Responsible for the task, Accountable for the
task, Consulted (the role player’s opinion is sought), and Informed (the role player
is kept informed of progress on the task and its content). Our simplified
characterization treats a primary role as the role that is both responsible and
accountable and a secondary role as the role that is consulted and informed.

Work Product

A work product is a piece of information or physical entity that is

produced and/or used during the execution of the process. Examples of
work products include models, plans, code, executables, documents,
databases, and so on. A work product is the responsibility of a single role,
although multiple roles may collaborate to produce a work product. Roles
use work products as input to tasks, and roles produce or modify work
products as an output from tasks that perform. The architect participates
in various tasks that produce and use work products, as described later in
this chapter and in the case study–related chapters (Chapters
6 through 9).

The SPEM defines three types of work products: artifact, deliverable, and
outcome. An artifact is a tangible work product, such as a document,
model, source code, executable, or project plan. A deliverable is also a
tangible work product that represents content packaged for delivery.
Deliverables are used to represent a work product that is of value
(material or otherwise) to a stakeholder. An outcome represents a result
or state as the result of task execution. Unlike artifacts and deliverables,
outcomes do not represent potentially reusable assets.

The approach described in this book focuses primarily on artifacts. In

addition to artifacts, the architect is responsible for the Software
Architecture Document deliverable. The work products for which the
architect is specifically responsible are shown in Figure 3.4, which also
shows the different architect roles. Any given method may add or remove
some of the work products summarized in this figure.

Figure 3.4. Work Products Owned by Architecture-Related Roles

This figure may give two misleading impressions. The first is that all the
work products are documents (because the SPEM icon for a work product
looks like a document!). This is not the case, however. The Functional
Model and Deployment Model, for example, may be represented as
Unified Modeling Language (UML) models in an appropriate modeling
tool, and the Architecture Decisions work product may be captured in a
project wiki. The second is that the level of ceremony associated with the
creation of each work product is very much dependent on context (such
as the complexity of the system, the point in the life cycle, and the like).
The Architecture Overview work product could be one page, for
example, and the Architecture Decisions work product may comprise
three items in a spreadsheet.

Although not shown in Figure 3.4, there are also work products that the
architect contributes to but does not own, such as the Prioritized
Requirement List. Another example is the RAID Log work product,
which the architect contributes to but which is owned by the Project
Manager. As you would expect, a correlation exists between the role that
is responsible for a task and the ownership of any work products that are
output. The Business Analyst is responsible for the Collect Stakeholder
Requests task and is the owner of the Stakeholder Requests work
product, for example.

Activity

An activity represents a grouping of tasks. The architect performs tasks

within the activities shown in Figure 3.5, which we elaborate on
in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating
the Physical Architecture.”

Figure 3.5. Architecture-Related Activities

Task

A task is a unit of work that provides a meaningful result in the context of

the project. It has a clear purpose, which usually involves creating or
updating work products. All tasks are performed by appropriate roles.

Tasks may be repeated several times, especially when an iterative

development approach is taken (iterations are discussed later in this
chapter). The architecture-related tasks, which are described in detail
in Chapter 8, “Creating the Logical Architecture,” and Chapter 9, “Creating
the Physical Architecture,” are shown in Figure 3.6, together with the
primary roles involved. You should remember, however, that this set of
tasks represents only the core architecting tasks and that an architect
typically is involved in other tasks, too, such as development of a
technology strategy and skills development. As you will see, the architect
also assists other roles, such as overseeing the development process,
identifying stakeholders, defining and prioritizing requirements,
estimating, and planning.

Figure 3.6. Architecture-Related Tasks

PROCESS
We now turn our attention to the application of the method content in
terms of a sequence in which they are applied. As you will see, many of
the differences among various methods used in the software industry
primarily involve the process being followed rather than the roles, work
products, activities, and tasks performed.

In this section, we consider three types of process, which are

characterized as waterfall, iterative, and agile. As we do so, we not only
examine the key characteristics of each approach, but also highlight those
practices that are of most relevance to the software architect and also
explore some of myths that seem to pervade such discussions.
Waterfall Processes

A traditional waterfall development process is shown in Figure 3.7, using

discipline names taken from OpenUP. In this approach, each discipline is
deemed to be complete when all the appropriate work products for that
discipline have been created and signed off on. The requirements
discipline, for example, may be considered to be complete when all the
requirements have been identified, defined in detail, and reviewed. Then
the output from requirements flows into the architecture discipline. This
process continues until the system has been designed in detail and coded
(in the development discipline), tested, and made available to its end
users. Changes in the work products (shown by the backward-pointing
arrows) typically are handled through a formal change process.
Figure 3.7. A Waterfall Process

This approach is widely used, especially in those projects that represent

minor enhancements of an existing system or in the development of a
system that involves a relatively small amount of risk.
On greenfield projects (in which the architect starts from a blank sheet of
paper), however, or projects that are changing extensively, this approach
can be problematic for several reasons:

• Project progress cannot be measured accurately, because it is based

on the creation of work products rather than the achievement of results.
Completing the requirements for a time machine without doing any
architecture, development, or testing, for example, won’t give you an
accurate indication of how long the project will take, because you can’t
really determine whether a feasible solution exists!
• User feedback cannot be obtained until late in the project, when the
system is available to use, delaying ultimate convergence on the real
requirements.
• Resolution of certain risks is deferred until late in the project, after
the system has been built, integrated, and tested. Such activities often
identify flaws in the design and even the stated requirements, which is
why certain classes of project that follow a waterfall approach are prone
to schedule slippage.

An alternative approach is to use an iterative development process, which

we discuss in the next section.

Iterative Processes
[An iteration is a] short and set duration division of a project. Iterations
allow you to demonstrate incremental value and obtain early and
continuous feedback. (OpenUP 2008)

Within an iteration, a pass is made through each of the disciplines,

including requirements, architecture, development, and test.
An iteration is a distinct, time-boxed sequence of activities that results in
a release (internal or external) of an executable product. As the project
progresses, releases provide incremental improvements in capability
until the final system is complete. An iterative development process is
similar to growing software, in which the end product matures over time.
Each iteration results in better understanding of the requirements, a
more robust architecture, a more experienced development organization,
and a more complete implementation. The notion of growing an
architecture through a series of iterations and executables appears to be a
common practice in organizations that we would consider to be
productive and successful in architecting their software systems.

Figure 3.8 illustrates how the focus of a project shifts across successive
iterations. In this figure, you see that each discipline is addressed during
every iteration, and the size of the boxes within each of the disciplines
illustrates the relative time spent performing the activities (and tasks)
within that discipline. In this simple example, you see that iteration 1
focuses on requirements definition, but some architecting is performed
(focusing on the highest-priority requirements to be considered in the
iteration), together with some development and testing. In this example,
iteration 2 focuses on stabilizing the architecture, which is why you see
the emphasis on the architecting activities. Iteration 3 focuses on
completing the solution based on a relatively stable set of requirements
and architecture, which is why you see an emphasis on development and
testing.

Figure 3.8. An Iterative Process

Following are some important characteristics of iterations in projects that

are successful in following an iterative process:

• The iteration has clear evaluation criteria.

• The iteration has a planned capability that is demonstrable.
• The iteration is concluded by a minor milestone, where the result of the
iteration is assessed relative to the objective success criteria for that
particular iteration.
• During the iteration, work products are updated (work products evolve
with the system).
• During the iteration, the system is integrated and tested.

An iterative development approach is particularly appealing to the

architect because it specifically acknowledges that adjustments to the
architecture will need to be made as the project progresses. The number
of architectural changes should reduce over time, of course. The point is
that such changes are not afterthoughts but are considered to be essential
aspects of the project life cycle.

An iterative development process involves more than a stream of

iterations, however. It also must have an overall framework in which the
iterations are performed, which represents the strategic plan for the
project and drives the goals and objectives of each iteration. Such a
framework is provided by phases.

[A phase is] a specialized type of activity that represents a significant

period in a project normally ending with a decision checkpoint, major
milestones, or a set of deliverables. Phases typically have well-defined
objectives and provide the basis for how the project work will be
structured. (OpenUP 2008)

Phases provide well-defined business milestones that ensure that the

iterations make forward progress and converge on a solution, rather than
just iterating indefinitely. Iterations are time-boxed (of a fixed duration),
whereas phases are goal-based. A phase is not time-boxed, because the
completion of a phase is assessed based on the state of the project. Some
organizations fail to acknowledge this important principle, as discussed in
the sidebar “Pitfall: Declaring Victory Too Soon.”

Pitfall: Declaring Victory Too Soon

A very common mistake is for the Project Manager to declare victory by stating
that a phase has been completed when it really hasn’t, simply because the date on
which the phase should have been completed has been reached. This scenario is
the software equivalent of false accounting, and Project Managers who cook the
books in this manner often become unstuck as their misguided decisions come
back to haunt them.

It usually is far better for a Project Manager to bite the bullet and convey the
news that the phase has not been completed as planned, rather than delude
themselves, and everyone else, that everything is on track—a situation that
normally results in additional and unnecessary pressure being placed on the
project.

Phases and iterations together provide the foundation for an iterative

development process. The objectives of each phase are achieved by
executing one or more iterations within the phase. Each phase concludes
with a major milestone and an assessment to determine whether the
objectives of the phase have been met. A satisfactory assessment allows
the project to move to the next phase.

OpenUP defines four sequential phases, which we use in this book:

Inception, Elaboration, Construction, and Transition (see Figure 3.9).

Figure 3.9. Project Phases

A phase-based approach supports the convergence of several elements as

the project progresses. Risks reduce over the project life cycle, for
example, and cost and schedule estimates become more accurate. The
architecture also stabilizes over time, as indicated in Figure 3.10. As it
happens, most phase-based software development processes have a
phase that focuses on stabilizing the architecture. In this book, this phase
is the Elaboration phase, which clearly is a particular focus for the
architect.
Figure 3.10. Architecture Stability over Time
Figure 3.10 also characterizes the Inception and Elaboration phases as
engineering, whereas the Construction and Transition phases are treated
as production. This distinction is discussed in detail in Software Project
Management: A Unified Framework (Royce 1998). Moving from
Elaboration to Construction (that is, engineering to production) is
particularly interesting because this move represents a significant
milestone as far as the business is concerned. The production stage
generally is more predictable than the engineering stage, because there is
usually a good understanding of both the problem and the solution.
Therefore, a much higher level of fidelity exists in cost and schedule
estimates, and funding decisions can be made with greater confidence.

This is not to say that all the requirements have been defined by the end
of elaboration or that requirements never change, but the majority of
requirements are expected to have been defined, and any changes are
expected to have minimal impact on the architecture. Should this not be
the case (when a significant requirement is added, for example), a case
exists for reviewing the project and its timeline and adjusting accordingly.
This may require essentially resetting the project and possibly revisiting
the elaboration (and even inception) phase.

As indicated in Figure 3.11, a direct relationship exists between the

emphasis on architecture in each of the phases and the number of
resources typically dedicated to architecture (which, of course, will vary
depending on the nature of the system under development). This graph is
derived from information in Software Project Management:A Unified
Framework (Royce 1998).
Figure 3.11. Percentage of Resources Focused on Architecture over Time

Clearly, moving from one phase to another is a significant moment in the

project life cycle, so it is important to understand the criteria under which
the transition from one phase to the next is made. A detailed summary of
the primary objectives of each of the phases and their milestone
evaluation criteria is provided in Appendix C, “Method Summary.”
Following is an overview of each of the phases:

• The Inception phase is where the business case for the project is
established and where concurrence among all stakeholders on the
objectives for the project is established. Inception is where the focus is on
ensuring that the project is both valuable and feasible.
• The Elaboration phase is where the architecture is established to
provide a stable foundation for the activities performed during the
Construction phase. This phase, therefore, is of particular relevance to the
architect and certainly is where the architect expends the most effort.
• The Construction phase is where the remaining requirements are
clarified and where development of the system is completed on the
baselined architecture established during the Elaboration phase. Between
the Elaboration and Construction phases, the focus shifts from
understanding the problem and identifying key elements of the solution
to developing a deployable product.
• The Transition phase ensures that the software is available to, and
accepted by, its end users. This phase is where the system is deployed in
the users’ environment for evaluation and testing. The focus is on
finetuning the product and on addressing configuration, installation, and
usability issues. By the end of the Transition phase, the project should be
in a position to be closed out.
Iterative Development and Waterfall Development

Compared with a waterfall development process, an iterative

development process is results-driven (in that it focuses on the results to
be achieved within a given iteration) rather than work-product-driven
and lends itself to providing more accurate measures of project progress.
An iterative approach allows early user feedback through the execution of
incremental releases of the system, and such feedback accelerates
convergence on the real requirements. Also, an iterative approach
ensures that integration and testing occur within each iteration and that
an executable release is produced. Risks are attacked head on and early in
the project, thereby supporting the business in making decisions before
substantial investment in the project is made. As Royce puts it:

Establish an iterative life-cycle process that confronts risk early. With

today’s sophisticated software systems, it is not possible to define the
entire problem, design the entire solution, build the software, then test
the end product in sequence. Instead, an iterative process that refines the
problem understanding, an effective solution, and an effective plan over
several iterations encourages a balanced treatment of all stakeholder
objectives. Major risks must be addressed early to increase predictability
and avoid expensive downstream scrap and rework. (Royce 1998)

Agile Processes

Interest in agile processes has increased in recent years, expressed in

methods such as eXtreme Programming (XP), Scrum, Lean, and Feature-
Driven Development. Although some differences exist with respect to
each specific agile method and the practices they advocate, all are based
on the same fundamental principles. One articulation of such principles is
the Agile Manifesto (Agile Manifesto 2009) which states the following
values:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
It is the authors’ view that these principles are complementary to those
found in an iterative development approach. Also, as you can see from the
Agile Manifesto, the main distinction is the emphasis placed on principles
that guide the execution of the process, rather than new or different
method content. An example comes from Scrum:

Scrum is a management and control process that cuts through complexity

to focus on building software to meet business needs. Scrum is
superimposed on top of and wraps existing engineering practices,
development methodologies and standards. (Schwaber 2002)

Scrum also exemplifies the emphasis on process. It focuses on the content

of an iteration (referring to an iteration as a Sprint), the prioritized
requirements to be considered in the iteration (the Sprint Backlog), and a
short daily status meeting (a Scrum).

Agile principles are also relevant to architects, and it is surprising how

often the principles are misrepresented. A common perception is that
agile processes do not advocate up-front design and that somehow the
architecture simply emerges from the code. The principle of working
software over comprehensive documentation, however, does not mean
that no documentation exists (including architecture-related
documentation); it simply means that just enough documentation exists
for the purposes of the current iteration.

There seems to be a fear in the agile community that if we use terms such
as “model” or “document” that suddenly the “evil bureaucrats” will dig
their claws into our projects and force us to write detailed, big
requirements specifications or to take a big-design-up-front approach . . .
the strange thing is that agilists are, in fact, modeling on a regular basis,
even though they’re not directly talking about it. (Ambler 2008)

SUMMARY
This chapter provided a brief overview of the method fundamentals used
in this book, using the Software and Systems Process Engineering
Metamodel Specification (SPEM) standard as a framework for explaining
these concepts. The chapter emphasized the distinction between method
content and the processes that enact this content, and considered
different types of processes, including waterfall, iterative, and agile. The
chapter discussed the relevance of these concepts to the architect and to
the process of architecting. The method used in this book borrows from
all these types of processes.

The next two chapters—Chapter 4, “Documenting a Software

Architecture,” and Chapter 5, “Reusable Architecture Assets”—focus on
specific aspects of the method that warrant a more detailed discussion
and that pervade the project life cycle.

Chapter 4. Documenting a Software

Architecture

The primary purpose of documenting a software architecture is to allow

the architecture to be communicated. This communication is essential in
ensuring that all stakeholders understand the architecture and can
provide their input accordingly. This communication is critical in
ensuring that certain stakeholders are comfortable with the proposed
solution, for example, and that the project team has a consistent view of
the system to be built. Accommodating all the concerns of all the
stakeholders is often challenging, however. Therefore, we dedicate this
chapter to exploring various aspects of describing a software
architecture. Documenting a software architecture is beneficial for the
following reasons:

• A documented architecture contributes to effective communication

between different stakeholders, such as communication between those
developing the system and those maintaining the system, even if the
individuals involved never meet physically.
• A documented architecture provides the context for deriving other work
products, such as detailed design work products or even training
materials.
• A documented architecture can convey alternative architectural
solutions and the pros and cons of each.
• A documented architecture can help with the planning of the transition
from an existing architecture to a new architecture.
• A documented architecture can help with planning in general by
identifying the elements that comprise the architecture and the
dependencies among them. This information can help in planning an
appropriate sequence for implementing the architecture and also
understand the impact of making a change in the architecture.
• A documented architecture can remind the architect of the rationale
behind certain decisions that have been made.
• A documented architecture can help identify reuse opportunities in
terms of both the creation and use of reusable assets.
• A documented architecture can help with the assessment of the
architecture and can, for example, help determine if the implementation
is in accordance with the specification provided.

Some simple concepts that can be applied when documenting a software

architecture are particularly useful to architects who have little
experience in documenting architectures. We start this chapter by
discussing these concepts. Then we discuss several architecture
description frameworks (ADF) and close by describing the architecture
description framework used in this book.

THE END GAME

Before jumping into the elements that comprise a documented software
architecture, we present a very simple example of what we’re aiming for,
as shown in Figure 4.1.
Figure 4.1. Elements Involved in Documenting a Software Architecture
When documenting a software architecture, you should follow some
simple steps:

• Identify the stakeholder groups. In documenting a software

architecture, the first thing to understand is the target audience. One of
the first items that the Lead Architect will consider is the target audience
in terms of stakeholders of the architecture. Stakeholders can be
organized in groups that share related concerns. The two groups of
stakeholders shown in the figure are Developers and Users.
• Select the viewpoints. After identifying the stakeholder groups, you
need to identify the corresponding viewpoints that will allow the
stakeholders’ concerns to be expressed. Viewpoints are fundamental to
documenting a software architecture and are discussed in detail in
“Viewpoints and Views” later in this chapter. A viewpoint, for example,
defines the work products needed so that the architecture can be
communicated to the identified stakeholders in an appropriate manner.
In the example in Figure 4.1, the selection of a functional viewpoint
requires the architect to create a Functional Model to describe the
functionality (logic) of the system in terms of, for example, components,
relationships among components, and their interactions. The selection of
a deployment viewpoint requires the architect to create a Deployment
Model to describe the deployment of the system in terms of, for example,
nodes and the connections among them. For simplicity, other viewpoints
and their corresponding work products, such as the Architecture
Decisions and Architecture Proof-of-Concept work products, are not
shown in the figure.
• Create the work products. The architect (or architecture team)
populates the work products accordingly. You may add elements to any
models that you decided to create, as well as any diagrams that allow you
to express these elements visually. In Figure 4.1, we show two diagrams
in the Functional Model and one in the Deployment Model. In general
terms, every work product can be considered to be a model of the system
under development; we discuss this topic in the next section.
• Package the architecture description. Rather than communicating the
architecture using all the work products that have been created, the
architect typically packages elements in a form that is more easily
consumed by the stakeholders. (Not all stakeholders may not have access
to any modeling tools used to create certain work products, for example.)
In our example in Figure 4.1, the architect creates a Software
Architecture Document deliverable. This deliverable is organized by the
different views of the architecture, with each view representing the
application of a particular viewpoint for a given system. The extent of
architecture documentation required is discussed in the sidebar “Best
Practice: Documentation Is Minimal but Sufficient.”

The concepts of viewpoint, view, and model are discussed in detail in the
next section.

Best Practice: Documentation Is Minimal but Sufficient

One of the agile principles is “Working software over comprehensive

documentation” (Agile Manifesto), and this principle reminds you that the creation
of any work products should be minimal but sufficient. When documenting a
software architecture, you determine what you mean by sufficient by considering
the needs of the identified stakeholders.

Given that stakeholders of the architecture may be team members or maintainers,

you also need to pay appropriate attention to the upkeep of any work products
you create and ensure, where appropriate, that they are kept up to date and
consistent with one another.

KEY CONCEPTS
The key architecture description concepts are viewpoint, view, and model.
These concepts are defined in IEEE 1471-2000, IEEE Recommended
Practice for Architectural Description of Software-Intensive
Systems. Figure 4.2 shows a subset of the elements defined in this
standard. This figure expands on the discussion in Chapter 2,
“Architecture, Architect, Architecting,” by specifically identifying those
elements that are related to an architectural description.

Figure 4.2. A Metamodel of Elements Related to an Architectural Description

All the relationships shown in this figure come from the IEEE 1471
standard. Those relationships not described in Chapter 2 are provided in
the following list; we expand on these relationships later in this chapter.

• An architectural description is organized by one or more views.

• A view consists of one or more models.
• A model participates in one or more views.
• A model participates in one or more architectural descriptions.
• A view conforms to a viewpoint.
• An architectural description selects one or more viewpoints.
• A viewpoint establishes methods for one or more models.
• A viewpoint is used to cover one or more concerns.

As you can see, the concepts of viewpoint, view, and model are
fundamental to describing a software architecture, and all of them are
described in more detail in the following sections.

VIEWPOINTS AND VIEWS

It would be nice to think that you could communicate the architecture of a
system by using a single diagram that satisfies the needs of all
stakeholders. Although this approach may be an effective means of
informally communicating some aspects of the architecture to interested
parties, taking such a narrow approach—an informal technical
description intended to cover all facets of the architecture—usually leads
to confusion, because such diagrams tend to be overly complex. Such
diagrams also tend to mix different aspects of the architecture. An
innocent-looking box in such a diagram, for example, may mix functional
responsibilities with deployment concerns, and an arrow between boxes
may mix control flow with a simple dependency between elements.
Another common flaw is emphasizing one aspect of the architecture to
the detriment of others. The diagram may emphasize the functional
partitioning of the architecture into components, their relationships, and
interactions to the detriment of concerns regarding the deployment of the
system, for example.

The solution to such failings is to describe a software architecture by

applying several viewpoints concurrently, with each viewpoint
addressing a particular set of concerns.

[An architectural viewpoint is] a specification of the conventions for

constructing and using a view. A pattern or template from which to
develop individual views by establishing the purposes and audience for a
view and the techniques for its creation and analysis. (IEEE 1471 2000)
[An architectural view is] a representation of a whole system from the
perspective of a related set of concerns. (IEEE 1471 2000)

A viewpoint has several characteristics that are worth noting:

• A viewpoint has an identified audience.A primary concern of a

viewpoint is that it addresses the needs of a particular audience, where
the audience represents one or more stakeholders in the system. A
functional viewpoint can address the needs of a developer (who must
undertake detailed design activities and implement code), a tester (who
must test the system), and so on.
• A viewpoint serves one or more purposes.Although a viewpoint
supports a set of stakeholders who have similar concerns, those concerns
may not be identical. A developer may use a functional viewpoint to
understand context for designing the internals of a specific design
element before implementing that element in a given programming
language, whereas a tester may use the same functional viewpoint to
understand the key components of the system for the purposes of
determining whether the system meets certain requirements.
• A viewpoint is a pattern or template for a view.In simple terms, a
view conforms to a viewpoint. The viewpoint defines the rules by which
the view is created and used. In object-oriented terminology, a viewpoint
represents a class (of view), and a view is a particular instance of a
viewpoint. Therefore, when documenting the architecture of a particular
system, you select the appropriate set of viewpoints and, as a result,
create the views that are specific to the architecture of the system under
development. Because a viewpoint can be considered to be a template, it
is no surprise that some organizations invest in the creation of
a viewpoint catalog from which viewpoints can be selected for any given
project.
• A viewpoint defines techniques.Finally, a viewpoint defines the
conventions by which a view is created, depicted, and analyzed. A
viewpoint defines the language in which a view that conforms to the
viewpoint is defined, perhaps including notations and specific techniques
for deriving the content of the view. A deployment viewpoint may state
that a deployment view contains a Deployment Model; that
the Deployment Model will be created with the Unified Modeling
Language (UML); that the Deployment Model will be created by applying
certain techniques and conventions; and that the Deployment
Model should be applied in certain situations (with corresponding
benefits accrued and pitfalls to be avoided). As a consequence, you can
see that a viewpoint has a bearing on the manner in which the work
products that comprise the view are created.

Basic Viewpoints

We’ve already mentioned two viewpoints that architects often encounter

in practice: a functional viewpoint, which is concerned with elements that
support the functionality of the system (such as components, their
relationships, and their behavior), and a deployment viewpoint, which is
concerned with elements that support the distribution of the system
(such as nodes, devices, and the connections among them).

The rationale for considering viewpoints can be extended further, as

shown in Figure 4.3, in which viewpoints appear to be on the fringes of an
architecture description: a requirements viewpoint and a validation
viewpoint. The purpose of the requirements viewpoint is to provide an
indication of the system requirements that have shaped the architecture;
it includes functional requirements, qualities, and constraints. The
purpose of the validation viewpoint is to provide an indication of whether
the system will provide the required functionality, exhibit the required
qualities, and accommodate the defined constraints.

Figure 4.3. Basic Viewpoints

Cross-Cutting Viewpoints

In their book Software Systems Architecture: Working with Stakeholders

Using Viewpoints and Perspectives (Rozanski 2005), Nick Rozanski and
Eoin Woods give special significance to the term perspective to represent
the collection of elements that address a cross-cutting concern:

An architectural perspective is a collection of activities, tactics, and

guidelines that are used to ensure that a system exhibits a particular set
of related quality properties that require consideration across a number
of the system’s architectural views. (Rozanski 2005)

A perspective is really a special kind of viewpoint that focuses on the

qualities the system must exhibit. To address the security requirements in
a system, for example, you may need to specify security requirements,
introduce security-related functional elements and deployment elements
in the solution, and subsequently validate the security implemented in the
architecture. This situation is shown in Figure 4.4, in which we introduce
both a performance viewpoint and a security viewpoint. The
corresponding views created by applying these viewpoints are
considered to cut across the requirements, functional, deployment, and
validation views in that they may share the same elements. More
specifically, given the examples shown in Figure 4.4, you can consider the
following intersections among the views implied by these viewpoints:

• The performance view identifies the performance-related requirements

in the requirements view and how those requirements are realized.
• The performance view identifies the elements in the functional view
that contribute to meeting the performance requirements, which may
result in the need to couple elements tightly when a lot of communication
occurs, for example.
• The performance view identifies the elements in the deployment view
that contribute to meeting the performance requirements. This view
would consider the location of communicating elements, the specification
of the hardware supporting the system, and the distribution of the system
as a whole (taking into account elements such as network latency, for
example).
• The performance view identifies the elements in the validation view
that support the validation of the performance requirements. This view
would consider how well the architecture meets the required
performance characteristics, the rationale for any trade-offs made, and
the outstanding risks and issues.
• The security view identifies the security-related requirements in the
requirements view and how those requirements are realized. Security
requirements may be functional in nature, such as how users authenticate
themselves to the system, or they may be constraints that are placed on
the system, such as what strength of encryption must be used to encrypt
data in the system.
• The security view identifies the elements in the functional view that
contribute to meeting the security requirements, such as components that
handle authentication, authorization, auditing, and nonrepudiation. This
view may also show which components and data elements need to be
protected.
• The security view identifies the elements in the deployment view that
contribute to meeting the security requirements. The view may identify
the need for specialized hardware or software (such as firewalls).
• The security view identifies the elements in the validation view that
support the validation of the security requirements. This view would
consider how well the architecture meets the required security
characteristics, the rationale for any trade-offs made, and the outstanding
risks and issues.

Figure 4.4. Basic Viewpoints and Cross-Cutting Viewpoints

Consideration of cross-cutting viewpoints can be extended further,

beyond a consideration of qualities. You may decide to introduce an
infrastructure viewpoint that focuses on elements that underpin the
system under development but that are independent of the business
domain (such as an error log or persistency mechanism). Again, the
corresponding view would cut across the basic views. You may have
infrastructure-related requirements (such as a constraint to use a
particular relational database), infrastructure-related functional elements
(such as an error-logging mechanism), infrastructure-related deployment
elements (such as hardware nodes used to host the error-logging
mechanism), and infrastructure-related validation elements (such as an
assessment of how well the error-logging mechanism addresses the
stated requirements).

In practice, the authors have found that focusing on both basic and cross-
cutting views provides us a simple mental model for considering certain
aspects of our architecture and can ensure that appropriate emphasis is
placed on key architectural characteristics throughout the project life
cycle.
Views and Diagrams

A common misconception among architects is the assumption that a view

is a diagram or that a diagram is a view, largely due to the similarity of
these terms in IT circles. Although a view may be entirely represented by
a single diagram, more often a view is represented in many diagrams.

Consider a Boeing 747 jumbo jet, which consists of more than 6 million
parts that weigh hundreds of thousands of pounds, contains wiring that
runs more than 160 miles, has a cockpit that contains hundreds of control
items, and can carry hundreds of passengers thousands of miles nonstop.
Boeing produced more than 75,000 engineering drawings when the first
747 was designed in the 1960s. If each diagram were a view, the result
would be not only an explosion of views (because many diagrams would
be involved), but also an unmanageable number of diagrams. Therefore,
different diagrams often target the same set of concerns and should be
considered as a group. Each group of diagrams is considered to be a view,
given our definitions. In essence, a view is a window onto the whole
architecture from a particular vantage point.

The relationship between views and diagrams is indicated in Figure 4.5,

which shows two views: a functional view and a deployment view. In this
example, the functional view, which is relevant to the concerns of
stakeholder group A, is concerned with the components and their
interactions, and consists of two diagrams. The deployment view, which is
relevant to the concerns of stakeholder group B, is concerned with the
deployment topology in terms of nodes and connections among nodes,
and consists of a single diagram.
Figure 4.5. An Example of Views and Diagrams
Benefits of Viewpoints and Views

In addition to the general benefits of documenting a software

architecture, you can achieve some specific benefits by taking an
approach based on viewpoints and views:

• To manage the complexity of the system.A view represents a

simplification of reality. This simplification is achieved by focusing on a
particular aspect of the system under consideration. A physical view of an
airplane may focus on its aerodynamic properties, whereas a view of a
software system’s deployment focuses on the operational environment in
which the system will execute.
• To focus on a specific aspect of the system.Most complex systems
have several related but different views. An airplane has an external
structure manifested in its wings, fuselage, and undercarriage; electrical
circuitry; hydraulic systems; and so on. Similarly, a software system
has functional characteristics, deployment characteristics, and so on.
Views provide a clear separation of these various concerns. This
separation allows you to consider a subset of the overall system without
getting bogged down in the complexity of the system as a whole.
• To communicate with stakeholders.To communicate a system to its
various stakeholders effectively, you often have to represent different
aspects of the same system in different views to address the needs of each
stakeholder. A view that considers the external structure of an airplane
may be used to communicate with an aerodynamics engineer. Similarly, a
view of the deployment of a software system may be used to
communicate with designers and systems administrators.

MODELS
Model is the term used in the IEEE 1471 standard to represent a work
product that participates in a view. Models contain the specific elements
that are present within a view. A good example of a model is a mockup of
an airplane that is placed in a wind tunnel to get a better understanding of
its aerodynamic properties. As you will see, in terms of purpose, there is
no difference between this example and the creation of models that
represent different aspects of a software system, in that a model
represents an abstraction of the system under consideration.

Models provide the specific description, or content, of an architecture. For

example, a structural view might consist of a set of models of the system
structure. The elements of such models might include identifiable system
components and their interfaces, and interconnections among those
components. (IEEE 1471 2000)

The models described in this book include a Functional Model,

a Deployment Model, and a Data Model. In addition, in a general sense,
even work products that are represented in documents or spreadsheets
(for example) can be considered to be models, because they conform to
the definition of a model given in the preceding paragraph.

Figure 4.6 shows the relationship among views, diagrams, and models. As
you can see from this figure, models may be shared across views.
Specifically, although the functional view presents elements in
the Functional Model and the deployment view presents elements in
the Deployment Model, you can also see that the deployment view
presents elements in the Functional Model because we want to show the
deployment of components (from the Functional Model) to nodes (from
the Deployment Model).

Figure 4.6. An Example of Views, Diagrams, and Models

Levels of Realization

Although different models are used to capture different aspects of the

system, a given model may itself go through a series of refinements,
particularly models that represent aspects of the solution, such as
the Functional Model work product. The discrete levels of realization
that a model moves through during its life can provide stepping stones in
getting from an initial model whose content is very conceptual to a model
whose content is detailed enough to be used as the basis of
implementation.

It is possible to consider the content of the Functional Model work

product in both a logical (or technology-independent) manner and a
physical (or technology-specific) manner, for example. These two aspects
of the same model represent different levels of realization of the model.

The same thinking can be applied to other models. The Data Model, for
example, can be considered in terms of a logical data model (that
identifies entities and their relationships) or in terms of a physical data
model (that also acknowledges implementation concerns, such as index
tables and stored procedures that improve the performance of data
access). This thinking is reflected in Figure 4.7. If appropriate, the
architect may also choose to retain the logical models and create separate
physical models. This topic is discussed further in Chapter 8, “Creating the
Logical Architecture.”
Figure 4.7. Views, Models, and Levels of Realization

Note that a level of realization is not the same as a level of abstraction. A

level of abstraction is concerned with a particular amount of detail, where
the higher the level of abstraction, the less detail. When considering levels
of realization, however, you are not simply adding or removing detail; you
are fundamentally making choices that result in different elements being
considered.

A component representing an Order Manager in the logical Functional

Model may be realized, in a Java EE environment, as an Enterprise
JavaBean (EJB) and provide Java EE-specific interfaces in the
physical Functional Model, for example. Therefore, when moving from
the logical architecture to the physical architecture, the architect may
need to consult technical specialists who are deeply familiar with any
technologies being considered, because a one-to-one, one-to-many, or
many-to-one mapping may exist between logical elements and physical
elements, depending on the technologies (and patterns) being used. We
discuss this topic further in Chapter 8, “Creating the Logical Architecture.”

Finally, we should note that the distinction

between logical and physical elements is not black and white. Is a Load
Balancer component logical, for example? The answer, of course, is “It
depends.” The component certainly is not technology specific, because
we’ve not stated what technology will be used to provide the load
balancing. It’s not technology independent either, because it assumes that
we have chosen an environment that requires load balancing! In
summary, just remember that the terms logical and physical are not clear-
cut.

Benefits of Models

In addition to the general benefits of documenting an architecture,

creating models has some specific benefits:

• Detecting errors and omissions early in the life cycle.It is a lot

cheaper to create a scale model of an airplane and place it in a wind
tunnel than to construct an actual airplane and fly it to understand its
aerodynamic properties. Similarly, it is a lot cheaper to create a model of
the design of a software system and test this model than to construct the
actual software system to validate the design.
• Examining the relative merits of different options.Creating several
models of an airplane, all satisfying the same requirements, allows the
relative merits of each solution to be debated without having to move to
actual full-scale production of several aircraft. Similarly, several designs
of a software system, captured in appropriate models, can be used to
discuss the relative merits of the proposed software solutions.
• Understanding the impact of change.If a model contains elements
that are derived from elements of other models (such as solution
elements that are derived from requirements), documenting the
relationships among elements in the various models may be possible.
These relationships are often called traceability relationships, because
they show how elements in one model trace to elements in another. Then
the architect can use these to understand the impact of making a change.
The impact of changing a requirement can be assessed in terms of the
impact on solution elements, for example. Conversely, the impact of
changing a solution element (such as rewriting a computational
algorithm) can be determined in terms of its coverage by looking at the
requirements that this solution element wholly or partially satisfies.
• Assisting with project planning.The elements of a model can assist
with project planning in terms of schedule and resource. Having a model
of the solution that shows which elements are dependent on others can
provide an indication of the sequence in which these elements can be
implemented, the skills required, and the effort required.
CHARACTERISTICS OF AN ARCHITECTURE
DESCRIPTION FRAMEWORK
In simple terms, an architecture description framework represents a set
of viewpoints (and, therefore, views, models, other work products,
techniques, and so on) that can be used together to describe an
architecture. Rather than starting from scratch, an architect typically
selects viewpoints from a viewpoint catalog and, if necessary, tailors them
to his or her needs. The choice of viewpoints is often specified by some
organizational standard (a requirements viewpoint and a functional
viewpoint may be mandatory, for example), as well as the nature of the
system under consideration (a system that executes on a single node may
not use a deployment viewpoint, for example).

The purpose of this section is to set the scene for the architecture
description framework used in this book by examining specific
characteristics that are exemplified in certain architecture description
frameworks in use today and to put some meat on the bones of the earlier
discussion. This section is not intended to be a comprehensive discussion
of all architecture description frameworks that you may encounter—
simply those that help demonstrate a particular characteristic. The
characteristics emphasized in this section are

• Multiple views and the use of a scenarios view, taken from Philippe
Kruchten’s “The “4+1” View Model of Software Architecture” (Kruchten
1995)
• Levels of realization, taken from the Zachman Framework, created by
John Zachman (Zachman 1987)
• Cross-cutting concerns, taken from Software Systems Architecture:
Working with Stakeholders Using Viewpoints and Perspectives (Rozanski
2005)

As you will see, each architecture description framework we discuss

focuses on ensuring that the many aspects of the architecture are clearly
separated but have well-defined relationships and, thus, are consistent.
Several of the architecture description frameworks also include elements
of process guidance. Additional considerations for documenting a
software architecture effectively are given in Documenting Software
Architectures: Views and Beyond (Clements 2003).
In the following descriptions, it is important to remember that a one-to-
one correspondence exists between a view and a viewpoint (if you
consider a view to be an instance of a viewpoint) for any given project,
although different architecture description frameworks prefer to use one
term instead of the other in their descriptions.

The 4 + 1 View Model of Software Architecture

A commonly used architecture description framework is “The “4+1” View

Model of Software Architecture,” as defined by Philippe Kruchten
(Kruchten 1995). This architecture description framework defines five
views and is shown in Figure 4.8.
Figure 4.8. The “4+1” View Model of Software Architecture

The author describes the various viewpoints as follows:

• The logical view is the object model of the design (when an object-
oriented design method is used).
• The process view captures the concurrency and synchronization aspects
of the design.
• The development view describes the static organization of the software
in its development environment.
• The physical view describes the mapping(s) of the software to the
hardware and reflects its distributed aspect.
• The description of an architecture is illustrated by a few selected use
cases or scenarios that become a fifth view (the scenarios view).

An interesting characteristic of this architecture description framework is

the use of a scenarios view. The scenarios typically are selected based on
the architecturally significant requirements that the scenarios will
exercise, which allows the architect to validate whether these
requirements have been addressed.

Zachman Framework

The Zachman Framework, created by John Zachman and discussed in “A

Framework for Information Systems Architecture” (Zachman 1987),
targets enterprise architecture rather than software architecture. This
architecture description framework, which exhibits some characteristics
that are worth mentioning specifically, is shown in Figure 4.9. In
particular, this framework not only defines several viewpoints (the
columns), but also explicitly defines several levels of realization (the
rows). The Zachman Framework uses the term perspective to represent a
level of realization (as described in this book) and the term abstraction to
represent a view.
Figure 4.9. The Zachman Framework

The viewpoints (the columns) are

• Data (the what).This column describes the entities in the enterprise,

such as business entities and relational tables.
• Function (the how).This column describes the functions in the
enterprise, such as business processes and software application
functionality.
• Network (the where).This column describes locations in the
enterprise, such as major business geographical locations and system
nodes.
• People (the who).This column describes the people in the enterprise.
• Time (the when).This column describes the impact of time on the
enterprise, such as scheduling of capabilities.
• Motivation (the why).This column describes the motivations of the
enterprise, such as goals and objectives.

The levels of realization (the rows) are

• Scope.This row defines a contextual perspective.

• Business model.This row defines a conceptual perspective.
• System model.This row defines a logical perspective.
• Technology model.This row defines a physical perspective.
• Detailed representations.This row defines modules that can be
implemented.
• Functioning enterprise.This row defines the operational system.

Rozanski and Woods

In Software Systems Architecture:Working with Stakeholders Using

Viewpoints and Perspectives (Rozanski 2005), Nick Rozanski and Eoin
Woods emphasize a set of cross-cutting viewpoints (referred to
as perspectives) in addition to several basic viewpoints, as shown
in Figure 4.10.
Figure 4.10. The Rozanski and Woods Framework
The authors describe their various viewpoints in the form of a catalog.
The basic viewpoints, as described in their work, are

• Functional.Describes the system’s functional elements and their

responsibilities, interfaces, and primary interactions.
• Information.Describes the way that the architecture stores,
manipulates, manages, and distributes information.
• Concurrency.Describes the concurrency structure of the system, and
maps functionality elements to concurrency units to identify clearly the
parts of the system that can execute concurrently and how this execution
is coordinated and controlled.
• Development.Describes the architecture that supports the software
development process.
• Deployment.Describes the environment in which the system will be
deployed, including capturing the dependencies of the system on its
runtime environment.
• Operational.Describes how the system will be operated, administered,
and supported when it is running in its production environment.

The perspectives described (although not all are shown in Figure 4.10)
are
• Security.The ability of the system to control, monitor, and audit reliably
who can perform what actions on what resources, and to detect and
recover from failures in security mechanisms.
• Performance (and scalability).The ability of the system to execute
predictably within its mandated performance profile and to handle
increased processing volumes.
• Availability (and resilience).The ability of the system to be fully or
partly operational as and when required, and to handle effectively failures
that could affect system availability.
• Evolution.The ability of the system to be flexible in the face of the
inevitable change that all systems experience after deployment, balanced
against the costs of providing such flexibility.
• Accessibility.The ability of the system to be used by people with
disabilities.
• Development resource.The ability of the system to be designed, built,
deployed, and operated within known constraints around people, budget,
time, and materials.
• Internationalization.The ability of the system to be independent of any
particular language, country, or cultural group.
• Location.The ability of the system to overcome problems brought about
by the absolute locations of its elements and the distances between them.
• Regulation.The ability of the system to conform to local and
international laws, quasilegal regulations, company policies, and other
rules and standards.
• Usability.The ease with which people who interact with the system can
work effectively.

AN ARCHITECTURE DESCRIPTION FRAMEWORK

The architecture description framework used in this book builds on
several of the architecture description frameworks discussed in this
chapter. This architecture description framework can be reused for the
architectures of different systems, and each architect using this
framework should select the appropriate viewpoints, depending on the
nature of the system under consideration. In addition, the framework
should be considered to be extensible, in that viewpoints may be added as
necessary.
Viewpoints

Figure 4.11 shows a summary of the viewpoints (and, therefore, views)

used in this book.
Figure 4.11. The Architecture Description Framework

Table 4.1 provides a summary of the stakeholders of the architecture and

identifies those who are potentially interested in each viewpoint. The
table also indicates the scope of each stakeholder; internal stakeholders
are members of the current development team, and external stakeholders
are not members of that team.

Table 4.1. Stakeholder Summary

Table 4.2 summarizes the viewpoints. For a more complete description of
each of these viewpoints, turn to Appendix B, “Viewpoint Catalog.”

Table 4.2. Viewpoint Summary

It is important to ensure that the correct viewpoints are applied in any
given situation. The architecture description framework presented here is
only an example that demonstrates the principles inherent in such a
framework.

Therefore, for any given system, you may remove or add views as
required. If you are building a system that always executes on a single
node, for example, you can ignore the deployment view (which considers
distribution). Conversely, you may choose to add views if you require a
particular emphasis that is not an inherent consideration of the
architecture description you selected, such as adding an evolution view if
system evolution is a primary concern of the architecture.

Work Products

In the “Models” section earlier in this chapter, we state that a view refers
to elements contained in one or more models (work products) and that a
model may participate in one or more views. Figure 4.12 shows the
following work products, which are used in the architecture description
framework that we use in this book:

• The requirements view refers to elements contained in the Business

Entity Model, Business Process Model, Business Rules, Change
Request, Enterprise Architecture Principles, Existing IT
Environment, Functional Requirements, Glossary, Non-Functional
Requirements, Prioritized Requirements List, Stakeholder
Requests, System Context, and Vision work products.
• The functional view refers to elements contained in the Architecture
Decisions, Architecture Overview, Data Model, and Functional
Model work products.
• The deployment view refers to elements contained in the Architecture
Decisions, Architecture Overview, and Deployment Model work
products.
• The validation view refers to elements contained in the Architecture
Assessment, Architecture Proof of Concept, Issue List, RAID Log,
and Review Record work products.

Figure 4.12. Viewpoints and Work Products

A cross-cutting view potentially references elements in all these work
products.

Levels of Realization

This architecture description framework used in this book also

incorporates different levels of realization and is represented in Figure
4.13. The important item to note is that the framework is used to describe
both the logical architecture and the physical architecture. The logical
architecture is discussed in detail in Chapter 8, “Creating the Logical
Architecture,” and the physical architecture is discussed in Chapter 9,
“Creating the Physical Architecture.”
Figure 4.13. Levels of Realization
View Correspondence

Although you may think of views as being independent, this is not

necessarily the case. You may want to enforce a rule that says that all
components described in a functional view are deployed to nodes in a
deployment view, for example. The term view correspondence is used to
describe such relationships.

THE SOFTWARE ARCHITECTURE DOCUMENT

The Software Architecture Document provides a comprehensive
architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. (RUP 2008)

As we mention in Chapter 3, “Method Fundamentals,” the Software and

Systems Process Engineering Metamodel Specification (SPEM) defines
three types of work products: artifact, outcome, and deliverable.
A deliverable is a work product that is provided to an internal or external
third party. The Software Architecture Document is an example of a
deliverable and is the primary vehicle for documenting and
communicating the software architecture. Rather than reinventing
content defined in other work products, the Software Architecture
Document makes reference to these work products, as discussed
in Chapter 3.

As one would expect, the Software Architecture Document deliverable

conforms to the chosen architecture description framework. An outline
for a Software Architecture Document, which conforms to the
architecture description framework on which we elaborate in this
chapter, is as follows:

• Front matter (title page, change history, table of contents, list of figures,
references)
• Objectives of the Software Architecture Document
• Overview of the Architecture
• Architecture Decisions
• Requirements View
• Functional View
• Deployment View
• Validation View
• Application View
• Infrastructure View
• Systems Management View
• Availability View
• Performance View
• Security View
• Appendices

SUMMARY
This chapter discussed many of the fundamental concepts in documenting
a software architecture, including views and viewpoints and their
relationships with the underlying work products. We also presented an
architecture description framework that builds on proven practices when
documenting a software architecture.

This architecture description framework is exemplified in the case study–

related chapters (Chapters 6 through 9). First, we touch on another
foundational concept of architecting a software-intensive system: the
reuse of existing assets. This topic is the subject of Chapter 5, “Reusable
Architecture Assets.”

Chapter 5. Reusable Architecture Assets

The life of a software architect is a long and rapid succession of

suboptimal design decisions taken partly in the dark. (Kruchten 1999)

The purpose of this chapter is to shed some light on the darkness by

discussing a key characteristic of successful software architectures: the
use of reusable assets. Reusable assets provide a valuable vehicle for
capitalizing on the work of other successful architects, from fine-grained
design patterns to large-grained off-the-shelf packaged applications.

However, consideration of reusable assets can itself be a mine field. You

have many types of assets to consider, and it is not always clear what each
of them means and the value it provides. What is the difference between
an architectural style and a reference architecture? How does a
mechanism differ from a framework? The purpose of this chapter is to
discuss the different types of reusable assets available to the architect,
their characteristics, and their use.

SOURCES OF ARCHITECTURE
Inspiration for deriving an architecture comes from many places and
varies depending on many factors, including the novelty of the system, the
method being followed, and the skills of the architect. This was succinctly
described in “Mommy, Where Do Software Architectures Come From?”
(Kruchten 1995-2), where the author suggests three main sources of
architecture: theft, method, and intuition, as shown in Figure 5.1.

Figure 5.1. Sources of Architecture, Taken from Kruchten.

In terms of theft, most elements of a software architecture are derived

from a previous system of the same kind, another system with overall
similar characteristics, or an architecture found in technical literature—in
other words, the use of existing assets. Method refers to a systematic way
by which an architecture is derived from the system’s requirements.
Finally, intuition reflects the experience of the software architect who
recognizes some pattern or finds other inspiration for an architectural
element.

The relative widths of the arrows shown in Figure 5.1 also provide an
indication of the relative emphasis of the three sources, depending on the
novelty of the system. A classical system may comprise 80 percent theft,
19 percent method, and 1 percent intuition, and an unprecedented
system may comprise 30 percent theft, 50 percent method, and 20
percent intuition. In both cases, the reuse of existing assets is significant.
Put another way, a good architect does not reinvent the wheel.

AN ARCHITECTURE ASSET METAMODEL

Not surprisingly, successful architects tend to be those who are conscious
of the assets available. Consideration of reusable assets can significantly
help architects in their work because it reduces the number of things that
architects need to be concerned with; they do not need to reinvent the
wheel. From a project perspective, the reuse of assets within the project
can have a significant bearing on the project schedule, cost, and quality of
the delivered system.

In a general sense, reusable assets can be applied in all the software

engineering disciplines. A reusable asset could represent a reusable
requirement (a requirement that occurs over and over within different
systems), a reusable solution element (such as an architectural pattern or
reusable code), a reusable test, a reusable method, and so on. In this book,
we focus on those reusable assets that are of most relevance to the
software architect in defining an architecture. Keep in mind that the
assets discussed here are based on the authors’ experiences of working
with clients. The industry has no agreed-on definition for several of these
assets, so we offer definitions based on our experiences.

Understanding the characteristics of each type of asset and the

relationships among assets can help you understand their applicability
when trying to find an asset for a particular situation. To help you build
this understanding, Figure 5.2 shows a partial asset metamodel, which we
use to describe the different types of assets and their relationships. From
this figure you can see that to a large extent, architecture assets can be
divided into development-time assets (such as design patterns) and run-
time assets (such as packaged applications). For more details, see the
sidebar “Concept: Development-Time and Run-Time Assets.”

Figure 5.2 tells you that

• An architecture may be based on a reference architecture.

• An architecture has any number of associated development-time assets.
• An architecture has any number of associated run-time assets.
• A reference architecture is a kind of architecture.
• A reference architecture may be used as the basis of any number of
architectures.
• A development-time asset may be used in any number of architectures.
• A development-time asset may use any number of other development-
time assets.
• A development-time asset may influence any number of run-time assets.
• A run-time asset may be used in any number of architectures.
• A run-time asset may use any number of other run-time assets.
• A run-time asset may influence any number of development-time assets.

Figure 5.2. An Architecture Asset Metamodel

Development-Time Assets

A metamodel of development-time assets is shown in Figure 5.3.

Figure 5.3. Metamodel of Development-Time Assets

Figure 5.3 tells you that

• A development method, architectural style, architectural mechanism,

pattern, reference model, and architecture decision are all kinds of
development-time assets.
• A development method is associated with any number of viewpoint
catalogs.
• A viewpoint catalog is associated with any number of development
methods.
• An architectural pattern, design pattern, and idiom are all kinds of
patterns.

Run-Time Assets

A metamodel of run-time assets is shown in Figure 5.4.

Figure 5.4. Metamodel of Run-Time Assets

Concept: Development-Time and Run-Time Assets

The asset metamodel described in this chapter characterizes the majority of assets
as being either development-time assets or run-time assets. In general terms, this
characterization is based on the level of articulation. A development-time asset has
no concrete run-time implementation, whereas a run-time asset does.

Almost all assets, however, exhibit their influence at both development-time and
run-time. A design pattern may not have a concrete implementation, but run-time
elements and interactions may conform to the pattern. Similarly, a packaged
application has a concrete implementation, but you also need to consider this
element in any architecture models at development time.

Figure 5.4 tells you that

• An existing application, application framework, and component library

are all kinds of run-time assets.
• A packaged application is a kind of existing application.
• A component library contains any number of components.
• A component may be contained in any number of component libraries.

ASSET TYPES
This section contains a detailed description of each of the assets in the
meta-model described in the preceding section, in the sequence in which
they were introduced.

Reference Architecture

One asset in particular can have a major bearing on the architecture: a

reference architecture. The idea of a reference architecture is that it
provides an initial starting point upon which to build a new system. This
type of asset is relatively large-grained in comparison with some other
reusable assets.

A reference architecture is associated with a particular domain of interest

and typically includes many different architectural patterns, applied in
different areas of its structure. In 1999 IBM published a series of technical
reference architectures that described the architectures of systems across
different business domains (such as e-business, Life Sciences, and
Wireless).

Because a reference architecture is an architecture, it is no surprise to

find that a reference architecture is described in exactly the same manner
as any other architecture. It may be described in a Software
Architecture Document that refers to several other architecture work
products, such as architecture models that describe different aspects of
the architecture. On occasion, reference architectures also may include
concrete implementation elements. Reference architectures are most
successful when they are exemplified with concrete reference
implementations.

Development Method

As we discuss extensively in this book, a development

method codifies best practices and associated guidance, techniques, and
standards, and also typically contains reusable elements associated with
the creation of work products, such as templates and examples. As such,
the development method is itself a reusable asset at the disposal of the
architect. As with other assets, it also makes sense to apply appropriate
standards to maximize the reuse potential. Also, from the perspective of a
development method, consideration of the Software and Systems Process
Engineering Metamodel Specification (SPEM) Object Management Group
(OMG) standard (SPEM 2007) (discussed in Chapter 3, “Method
Fundamentals”) is warranted.

The development method is just one part of a complete development

environment, all aspects of which are potentially reusable assets at the
disposal of the architect. The development method, for example, is
augmented by appropriate tools that automate aspects of the method,
such as modeling tools, compilers, and debuggers.

Viewpoint Catalog

In this chapter we describe those reusable assets that are of most

relevance to the software architect, so we should explicitly mention a
particular standard associated with the development method: the
viewpoint catalog. As discussed in Chapter 4, “Documenting a Software
Architecture,” architects typically describe their architecture by using a
set of viewpoints that have been selected from a viewpoint catalog and
tailored to their needs. Each viewpoint addresses a related set of
stakeholder concerns.

Architectural Style

The concept of an architectural style was introduced by Mary Shaw and

David Garlan in their seminal work Software Architecture: Perspectives on
an Emerging Discipline (Shaw 1996).

[An architectural style] defines a family of systems in terms of a pattern of

structural organization. More specifically, an architectural style defines a
vocabulary of components and connector types, and a set of constraints
on how they can be combined. (Shaw 1996)

An architectural style applies to the system as a whole and, therefore, has

a major impact on the architecture. Also, a given system may exhibit more
than one architectural style. As touched on in Chapter 2, “Architecture,
Architect, Architecting,” service-oriented architecture (SOA) can be
considered to be an architectural style. Some examples of other
architectural styles, as described in Software Architecture: Perspectives on
an Emerging Discipline (Shaw 1996) and Software Systems Architecture:
Working with Stakeholders Using Viewpoints and Perspectives (Rozanski
2005), are

• Client-server.This widely used style supports the physical (distributed)

separation of client-side processing (on a user workstation) and server-
side processing (on a remote server that may, for example, access a
database).
• Event-based.This style is similar to the Observer pattern (described in
the “Pattern” section later in this chapter) in that it promotes a publish–
subscribe way of working in which one or more observers subscribe to a
particular event occurring in the system and a subject publishes a
notification when the event occurs. Rather than being confined to
specific instances within the architecture, however, this style is applied
strategically across large areas of the architecture.
• Pipes-and-filters.This style comprises a series of filters that provide
data transformation and pipes that connect the filters. Examples of a
pipes-and-filters style include compilers, signal processing, and even
elements of a Straight Through Processing (STP) solution used in
financial markets, in which the trade process for capital markets and
payments transactions is conducted electronically. This concept is also
used in the energy sector for electricity, oil, and gas trading.

Architectural Mechanism

Architects frequently characterize solution elements as mechanisms, as in

“the mechanism for achieving X” or “this element is underpinned by
mechanism Y.” Examples of mechanisms include a persistency
mechanism, an error-logging mechanism, a communication mechanism,
and a shopping cart. Like an architectural style, a mechanism may
comprise one or more patterns.

Architectural mechanisms represent common concrete solutions to

frequently encountered problems. They may be patterns of structure,
patterns of behavior, or both. (SPEM 2007)
Of all of the terms introduced in this chapter, an architectural mechanism
is possibly the least well defined, because it is simply an overarching term
for the many different (and more precise) types of architectural elements
you may encounter.

Pattern

The term pattern is used to represent many types of reusable elements

that may be conceived and, therefore, represents a very general type of
asset.

[A pattern is] a common solution to a common problem in a given context.

(UML User Guide 1999)

Because a pattern is such a general concept, it can be applied throughout

the development life cycle in many areas, resulting in requirements
patterns, architectural patterns, design patterns, programming patterns
(referred to as idioms), testing patterns, project management patterns,
process patterns, organizational patterns, and so on.

Given the importance of patterns to the architect, it is not surprising that

some emphasis has been placed on identifying patterns and on
techniques for documenting patterns. Applying lessons learned from civil
engineering, the patterns movement has risen rapidly over the past ten
years. Many publications and websites are dedicated to various types of
patterns, including platform-independent design patterns (Fowler 1997),
architectural patterns (Buschmann 1996), and design patterns (Gamma
1995). The inspiration for these publications stems from the influential
works of building architect Christopher Alexander (Alexander
1964, Alexander 1977, and Alexander 1979). There are even sources
of antipatterns (Brown 1998).

[An antipattern is] a commonly occurring pattern or solution that

generates decidedly negative consequences. An antipattern may be a
pattern in the wrong context. (Brown 1998)

Architects are particularly interested in those patterns that influence

their work directly, as well as those that influence detailed design and
implementation. These patterns generally include the following:
• Architectural patterns.These patterns are large-grained, an example of
which is the Layers pattern as defined in Pattern-Oriented Software
Architecture: A System of Patterns (Buschmann 1996). This pattern
structures applications into groups, where each group represents a
particular level of abstraction. One of the most familiar examples of
layering is the OSI 7-layer model, defined by the International
Standardization Organization (ISO), where each layer builds upon the
capabilities in lower layers.
• Design patterns.These patterns are finer-grained, an example of which
is the Observer pattern as defined in Design Patterns: Elements of
Reusable Object-Oriented Software (Gamma 1995). This pattern, also
known as Publish-Subscribe, allows an object to subscribe to events that
occur in a target object and to be notified when such events occur. The
architect often identifies the design patterns to be used in a project
because such decisions constrain the designers in their work, ultimately
resulting in a level of consistency and, therefore, architectural integrity.
• Idioms (programming patterns).These patterns are reusable
programming expressions defined in a particular programming language.
Architects typically are not involved in the identification of idioms,
although they may want to influence certain areas, such as the manner in
which programming exceptions are raised and handled.

Patterns are of interest to architects in terms of reusing existing

experience; they are also valuable mechanisms for defining elements of
the solution that should be applied consistently and represent an
opportunity for architects to share their knowledge with the project in a
codified form. Although many templates exist for describing patterns (or
antipatterns), they have much commonality. Most pattern descriptions
include

• The name of the pattern

• The context within which the pattern is used
• The specific problem(s) that the pattern solves
• The solution provided by this pattern
• The patterns that are related to this pattern

The pattern solution can be represented visually, in terms of both

structure and behavior. Figure 5.5 is a Unified Modeling Language (UML)
class diagram showing the participants in the Observer pattern, which is
derived from Design Patterns: Elements of Reusable Object-Oriented
Software (Gamma 1995). One of the primary goals of this pattern is to
remove the need for the subject to have any knowledge of the elements
observing it. In this pattern, this goal is achieved by introducing a
superclass (Subject) that maintains a list of observers.

Figure 5.5. Structural Elements in the Observer Pattern

As well as showing the structure of a pattern, you may show its

behavior. Figure 5.6 is a UML sequence diagram showing how the
structural elements within the Observer pattern collaborate. This
diagram shows the behavior when the subject is updated. This update
results in a notification message being sent to the observers, informing
them that the subject has changed.

Figure 5.6. Behavior in the Observer Pattern

The point here is not simply to demonstrate the Observer pattern, but to
show how architectural experience can be captured and communicated.
Architects typically reuse patterns identified from external sources, as
well as defining their own patterns to be used in the project, to ensure
some level of architectural consistency. Also, of course it is more efficient
to capture a pattern once and note where it has been applied than to
describe every use of the pattern in detail.

Describing a pattern in a UML modeling tool also opens opportunities to

apply the pattern automatically to existing model elements. Then you may
be able to identify those model elements that satisfy particular roles
within a pattern and subsequently update the model (automatically) by
applying the pattern in the relevant places. In our Observer pattern
example, any elements identified as observers would have
a notification operation added to them. The application of a pattern in a
modeling tool could be more extensive, resulting in the creation of
attributes, operations, relationships, and even new modeling elements.
This capability supports a model-driven development approach to
software development.

Patterns (in the broadest sense) can also be applied

when transforming an input to an output. You may want to generate code
from a UML model, for example. The rules that govern the transformation
could be specified as a pattern. Similarly, you can use the same
philosophy when transforming from one model to another model. The
concept of model transformation is one of the cornerstones of the Model
Driven Architecture (MDA) initiative from the OMG (MDA 2009).
Patterns can also be combined to form a pattern language, which defines
a collection of patterns and the rules to combine them. Pattern languages
are often used to describe a family of systems. IBM Patterns for e-
Business (IBM 2009), for example, define a set of architectural patterns
that describe various web-based applications. One aspect of this offering
is a pattern-selection process that supports the identification of an
application pattern and, based on that pattern, the selection of an
appropriate run-time pattern. The linkage between the application
pattern and the runtime pattern is part of the pattern language that has
been implemented.

Reference Model

A reference model is an abstract representation of entities, their

relationships, and behavior in a given domain of interest, which typically
forms the conceptual basis for the development of more concrete
elements. Examples include a business model, an information model, and
a glossary of terms.

An example of a reference model is a business model that defines the

business entities and business processes that you would expect to find in
a financial organization. Because such entities and processes influence the
IT systems that support them, it is clearly of benefit to architects to
consider such reference models in their work. The business entities
typically represent crisp abstractions that influence elements in the
different layers of the architecture in terms of their identification and
naming. IBM’s Insurance Application Architecture (IAA) is a concrete
example of a reference model. This model provides more than 200
business processes and 700 individual business activities representing
best practices used throughout the insurance industry.

Architecture Decision
[Architecture decisions are] conscious design decisions concerning a
software system as a whole, or one or more of its core components. These
decisions determine the non-functional characteristics and quality factors
of the system. (Zimmermann 2008)
Architects make decisions throughout the project life cycle, and the
decision rationale may come from experience, method, or some other
asset. Nevertheless, thinking of an architecture decision as a first-class
reusable asset can help ensure that you don’t reinvent the wheel by
retracing steps already taken by other architects. Architectural decisions
often are more informative than the final architectural solution, because
they typically discuss alternatives considered and the rationale for
choosing the option selected.

Consideration of architecture decisions as reusable assets is an emerging

field. As such, method and tool support for such assets is relatively
immature compared with other assets discussed in this chapter.

Existing Application

A highly reusable asset is, of course, any existing application. Such

applications are often referred to as legacy applications. The
term legacy can come across as being rather negative, and it is not
uncommon for inexperienced architects to look upon legacy applications
as things to be avoided rather than the valuable assets that they truly are.

A cynic is a man who knows the price of everything but the value of
nothing.
—Oscar Wilde

The level of reuse clearly is very high when you incorporate existing
applications into your architecture, and the effort in this area is focused
on integration rather than custom development. This integration is
sometimes referred to as legacy integration or enterprise application
integration (EAI).

Packaged Application

A packaged application is a large-grained commercial-off-the-shelf (COTS)

product that provides a significant amount of capability (and reuse), such
as a customer relationship management (CRM) or enterprise resource
planning (ERP) application. Examples of packaged applications include
Siebel and SAP. Packaged applications may be deployed as part of a
solution or treated as a hosted service (see the sidebar “Concept:
Software as a Service”).

Clearly, if the packaged application represents a substantial part of our

system, the amount of custom development required is greatly reduced,
with the effort moving to configuration of, and integration with, the
packaged application. In addition, many of the significant decisions that
you would make as an architect have already been made and are manifest
in the chosen packaged applications being used.

Concept: Software as a Service

Software as a Service (SaaS) is an approach to software deployment in which an

application is made available as a hosted service over the Internet. The main
advantage of this approach is that a consumer of the services doesn’t need to
worry about application installation, operations, and support. The main
disadvantage of this approach is that control of the application is relinquished in
terms of, for example, product upgrades that may destabilize the architecture.

One of the areas to focus on when applying a packaged application is a

fit/gap analysis of how close the packaged application is in terms of
satisfying the requirements. In some cases, when adopting a packaged
application, it is easier to accommodate any constraints imposed by the
application than to try to change the application itself. In this sense, the
use of a packaged application can have a bottom-up influence on the
architecture, because the chosen technology is influencing the
architecture, rather than the top-down influence of requirements on the
architecture.

The selection of such a significant asset may also have a bearing on the
approach you take to developing the system under consideration.
Selecting a packaged application may result in the application of different
software development practices than if you were integrating a legacy
system or building custom code. Quite often, architects take a hybrid
approach, because many software development projects apply many
types of reusable assets concurrently.

Application Framework

An application framework (sometimes referred to simply as framework)

represents the partial implementation of a specific area of an application.
Application frameworks can vary widely in scope. Some represent
complete platforms, such as Java EE and .NET; others focus on a particular
area (possibly within the scope of a platform), such as data access or the
user interface. Hibernate, for example, is a framework that maps an object
model to a relational database in a Java environment. Java Server Faces
and ASP.NET are frameworks that support the creation of user interfaces.

One of the key characteristics of an application framework (just like a

pattern) is that it clearly defines the boundaries of what is fixed in the
framework (in terms of both structure and behavior) and what is
intended to be varied by any application using the framework. Not
surprisingly, an application framework is frequently based on one or
more patterns and is often documented in a similar manner.

The term application framework should not be confused with architecture

description framework (discussed in Chapter 4, “Documenting a Software
Architecture”), which is a standard for describing a software architecture
based on a set of viewpoints.

Component Library/Component

In the most general sense, several asset types considered here

represent components of a solution, including existing applications and
packaged applications. In the context of reusable assets, however, we use
the term component to represent something that has a complete
implementation but is finer-grained than a complete application.

Even so, such components can vary widely in granularity. A component

may represent a significant element in the architecture, such as a message
broker. It also could represent a service in SOA or a technology-specific
component such as an Enterprise JavaBean. A widely understood form of
reuse is with respect to even finer-grained elements, such as a user
interface widget representing a table.

Components also may be provided in the form of a component library,

class library, or procedure library. An example of a component library is
the Java class library.

ATTRIBUTES OF AN ARCHITECTURE ASSET

As you will see, assets can be qualified with several attributes. As an
example, Figure 5.7 shows a subset of the architecture assets discussed
earlier in this chapter characterized by two attributes: granularity and
articulation (the level of implementation). Consumers use these attributes
when trying to locate an asset for any given situation.
Figure 5.7. Using Attributes to Characterize Asset Types

As shown in this figure, assets can be considered in terms of their

granularity (size) and their level of articulation (implementation).
Granularity is related to both the number of elements that comprise the
asset and the asset’s impact on the overall architecture. Articulation is
concerned with the extent to which the asset can be considered to be
complete and may be one of the following:

• Specification.Such assets have no implementation and are represented

in an abstract form, such as a model or document. Such assets include
various types of pattern, architectural styles, and reference models.
• Partial Implementation.Such assets are considered to be partial
implementations but require additional elements before they can be
instantiated. Such assets include application frameworks and packaged
applications.
• Complete Implementation.Such assets are considered to be complete
implementations and can be instantiated as is, without modification. Such
assets include components and existing applications.

This is all well and good, but granularity and articulation are just two
attributes that may be of interest. If the purpose of assigning attributes to
particular types of assets is to help a potential consumer locate the asset,
you may want to consider many more attributes. A basic set of attributes
that are relevant to any asset includes

• Articulation.The extent to which the asset provides a concrete

implementation
• Author.The person who originally created the asset
• Concerns addressed.The concerns that the asset is aimed at addressing
• Contained artifacts.The physical files that comprise the asset
• Granularity.An indication of the size of the asset in relation to other
assets
• Name.The name of the asset
• Prerequisites.The conditions that must apply before the asset can be
used
• Related assets.Any assets that are related to this asset and the nature
of these relationships
• State.The current state of the asset in terms of any asset life cycle (such
as submitted or approved)
• Type.The asset type (such as a reference architecture or design pattern)
• Use instructions.The instructions for using the asset
• Variability.The extent to which the asset may be varied (such as none,
limited, or extensive)
• Version.The asset version number

Attributes that result from the use of the asset include

• Feedback.Any feedback comments associated with the asset

• Rating.An indication of the rating associated with the asset
• Usage count.An indication of the number of times the asset has been
requested

Attributes related to the context within which the asset is applied include

• Business domain.The domain to which the asset applies (such as

telecoms or financial services)
• Development discipline.The discipline to which the asset applies (such
as requirements or architecture)
• Development method.The method to which the asset applies (such as
Scrum)
• Development phase.The development phase to which the asset applies
(such as Inception)
• Development scope.The scope of the asset from a development
perspective (such as software engineering or enterprise architecture)
• Technical domain.The technical (rather than business) domain to
which the asset applies (such embedded systems)

In addition, a variety of non-functional properties may be associated with

the asset: cost, performance, scalability, and the like.

OTHER REUSE CONSIDERATIONS

The past few years have seen renewed focus on reusable assets as a
means of improving project performance and decreasing time to value.
The seemingly widespread acceptance of SOA, for example, has led to
renewed focus on how the associated reusable assets (services, in this
case) are identified, specified, realized, deployed, managed, supported,
maintained, upgraded, and (ultimately) retired. In more general terms,
there are considerations related to a strategic approach to reuse.
Unfortunately, a detailed discussion of such topics warrants a book of its
own, although we do discuss a system-of-systems approach to the
identification of large-scale reusable assets in Chapter 10, “Beyond the
Basics.”

Underpinning any reuse initiative is a means of describing reusable

assets, which is where the Reusable Asset Specification (RAS) comes in
(RAS 2004). This OMG standard fundamentally defines two aspects of a
reuse strategy. The first aspect is a standard for describing a reusable
asset. The second aspect is a standard that defines an interface to a RAS-
compliant repository (referred to as a RAS repository service). Any
organization that wants to be consistent in its handling of reusable assets
would do well to look at the RAS and reuse repositories that implement
this standard.

Achieving successful asset reuse involves more than just resolving the
purely technical challenges, of course. Specifically, we’ve not gone into
any detail regarding the roles that may exist in an organization in support
of a strategic reuse initiative, the tasks that are performed (especially
around the creation, use, and maintenance of assets), and any specific
work products that specifically support a reuse initiative (such as an asset
catalog). There are also broader implications at an organizational level,
such as the embedding of a reuse culture and assessing what level of
reuse culture is practical or beneficial to the organization.

SUMMARY
Many types of reusable assets are at the disposal of software architects,
and the use of such assets can improve project performance dramatically
when the assets are applied correctly. This chapter provided an overview
of commonly encountered assets available to architects in their work, as
well as a discussion of asset attributes.

We consider the application of reusable assets in the case study–related

chapters (Chapters 6 through 9).

Chapter 6. Introduction to the Case Study

The purpose of this chapter is to introduce the case study used as an

example in Chapters 7 through 9. The detailed requirements and the
corresponding solution, with an emphasis on the architectural elements,
are progressively introduced and discussed in these chapters. This
chapter sets the context and describes the high-level requirements for the
solution. It contains information commonly found in work products, such
as a business case, a vision document, or a business model. This
information is input to several tasks undertaken during the definition of
the detailed requirements, as you will see in Chapter 7, “Defining the
Requirements.”

APPLYING THE PROCESS

Before discussing the case study, we should first make some general
comments regarding the application of the elements described in this
chapter and in Chapters 7 through 9. As we mention at the very start of
this book, what you have in your hands is an articulation of a series of
practices that you can apply in many ways and on many types of projects.
This section (and the equivalent section in Chapters 7 through 9)
provides guidance on their application.

A practice is an approach to solving one or several commonly occurring

problems. Practices are intended as “chunks” of process for adoption,
enablement, and configuration. (RUP 2008)

Given the discussion in Chapter 3, “Method Fundamentals,” we could

more correctly say that a practice is a chunk of method, because a method
has two dimensions: method content and process, both of which are
configurable. We said in Chapter 3 that method content describes the life
cycle–independent elements, such as roles, tasks, and work products.
A process then takes these elements and defines a sequence in which they
are applied and considers concepts such as iterations.

We discuss each of these dimensions in Chapters 7 through 9. We can

make some general statements, however, regarding the application of the
various method elements described in these chapters (roles, tasks, work
products, iterations, and the like). In particular, the content in these
chapters represents our attempt to strike a balance between an extremely
simple project that executes in weeks or months and a very large and
complex project that executes in years. The various elements described in
this book, therefore, need to be right-sized for your development project.
Put another way, you need to consider the level of ceremony that needs to
be applied. For the purposes of exemplification, the case study applies all
the elements described in this book—no more and no less.

The first elements that need to be right-sized are those that comprise
the method content: the roles, tasks, and work products. The obvious
question that must be asked is “How much of each of these items do we
need?” The answer, of course, is “It depends.” A general comment is
that all elements should be considered and then right-sized. Examples of
right-sizing for two fictitious projects, small and large, are given in Table
6.1. In these examples, we consider the selection of viewpoints, which is
discussed further in the sidebar “Best Practice: Select the Relevant Set of
Viewpoints.”

Table 6.1. Examples of Right-Sizing

Similarly, the process elements within the method—phases, iterations,

and the like—also need to be right-sized. Some of the items you need to
consider include

• The definition of any phases in the process and any milestones

associated with them.
• The emphasis applied to each of the architecting tasks within an
iteration, based on where the iteration is in the overall life cycle and the
phase within which the iteration occurs.
• The number of times a given task is performed within an iteration. It
may make perfect sense to apply a task more than once.
• The sequencing of tasks within an iteration. (The sequencing suggested
in this book is just that—a suggestion.)

The reason for such flexibility is that most elements of a project are rarely
made concrete at the start. The scope and requirements often evolve (and
are even discovered) as the project progresses, for example. The
architecture in turn also evolves over time. The involvement of different
roles in the project therefore varies over time, in line with the emphasis
on the associated tasks. We discuss this topic further in Chapters
7 through 9.

Additionally, depending on the duration of the project, the expectations

and influences of key stakeholders can fluctuate during the project life
cycle as factors such as budget cycles, organizational change, new
business priorities, and corporate initiatives are established and this may
influence the right-sizing performed.

Best Practice: Select the Relevant Set of Viewpoints

In this book, as discussed in Chapter 4, “Documenting a Software Architecture,” we

select viewpoints based on the nature of the system being built. Given a basic
description standard, we may choose to add or remove viewpoints accordingly.
Additional viewpoints we could have included are

• A data (or information) viewpoint that places a specific focus on the persistent
data in the system. Such concerns are considered to be part of the functional
viewpoint in this book.
• A user experience viewpoint that places an emphasis on capturing the
interactions that the user has with the system through one or more user interfaces.
User experience modeling is introduced in Building Web Applications with
UML, 2nd ed. (Conallen 2003).
• A concurrency viewpoint that considers concurrency and synchronization
elements, such as executable processes and threads in the system. Concurrency is
one of the viewpoints in “The ‘4+1’ View Model of Software Architecture”
(Kruchten 1995).
• A development viewpoint that describes the static organization of the software in
its development environment. This viewpoint is also one of the viewpoints in “The
‘4+1’ View Model of Software Architecture” (Kruchten 1995).

SCOPE OF THE CASE STUDY

If this book were to acknowledge all possible business challenges,
business domains, architectural styles, available technologies, and so on,
it would be a very large book indeed. Instead, as we discuss in Chapter 1,
“Introduction,” this book focuses on those architecture-related tasks that
are often encountered and that may be applied across many types of
organizations, business domains, systems, and projects.

Although the process described in this book can be applied to many types
of initiatives, we have confined ourselves to a single case study, which
allows us to exemplify the key tasks in which the architect is involved. An
“at a glance” characterization of this case study is provided in Table 6.2.
Although this set of characteristics could never fit all projects perfectly,
we do believe that the tasks described in this book can be adjusted
appropriately for any given situation, including the extent to which each
task is applied. We discuss additional considerations in dealing with
complex systems in Chapter 10, “Beyond the Basics.” Table 6.2 uses the
terms brownfield and greenfield, which are discussed in the sidebar
“Concept: Brownfield and Greenfield Development.”

Table 6.2. Characteristics of the Case Study

Concept: Brownfield and Greenfield Development

In their book Eating the IT Elephant: Moving from Greenfield Development to

Brownfield (Hopkins 2008), the authors use the terms brownfield
development and greenfield development through analogy with the construction
industry. In software engineering, brownfield sites present a level of constraint on
architects’ work and recognizes that architects are not starting from a blank sheet
of paper.

Brownfield sites are those in which redevelopment or reuse of the site is

complicated by existing contaminants. Greenfield sites are clean, previously
undeveloped land. (Hopkins 2008)

The Project Team

Throughout the case study–related chapters, we refer to the roles that

comprise the project team. These roles are shown in Figure 6.1, and
definitions of the roles follow. Note that the various architecture roles
may be fulfilled by a single individual or, on occasion, by an architecture
team. The tasks described in this book make no assumptions about the
size of the team involved, although each chapter contains a section on
how to apply the tasks that we describe.
Figure 6.1. The Project Team

• The Project Manager is responsible for leading the project team that
will deliver the solution by applying a range of project management
principles, tools, and techniques. The Project Manager has overall
responsibility for managing scope, cost, schedule, and contractual
deliverables, as well as for the management of issues, risks, and change.
• The Business Analyst is responsible for identifying and documenting
requirements and for analyzing these requirements from a business
perspective. The person in this role defines current and future
operational scenarios (processes, models, use cases, plans, and solutions),
and works with the stakeholders and the architects to ensure proper
translation of business requirements into IT solution requirements.
• The Developer is responsible for performing detailed design tasks,
defining the organization of the implementation, implementing the
detailed design elements, unit-testing the implementation, integrating his
work with that of other developers, and ultimately producing an
executable system.
• The Tester is responsible for finding and documenting defects in
software quality, generally advising about perceived software quality, and
validating that the system functions as designed and as required.
Complementing the unit testing performed in the development discipline,
the Tester focuses on the integrated units provided by the developers
and the system as a whole.
• The Lead Architect has overall responsibility for the major technical
decisions that define the architecture of the system. The person in this
role also is responsible for providing rationale for these decisions,
balancing the concerns of the various stakeholders, managing technical
risks and issues, and ensuring that decisions are effectively
communicated, validated, and adhered to.
• The Application Architect focuses on those elements of a system that
automate business processes and meet business needs. The person in this
role focuses primarily on satisfying the functionality required by the
business but also is concerned with how the application-related elements
meet the non-functional requirements of the system (qualities and
constraints).
• The Infrastructure Architect concentrates on those elements of the
system that are independent of business functionality, such as a
persistence mechanism, hardware, and middleware. Such elements
support the execution of the application-related elements. The person in
this role focuses on elements that have a significant bearing on the
qualities exhibited by the system and, therefore, the extent to which
certain non-functional requirements are addressed.
• The Data Architect focuses on the data elements of a system, especially
data that is made persistent in an appropriate mechanism, such as a
database, a file system, a content management system, or some other
storage mechanism. The person in this role defines appropriate data-
related properties, such as structure, source, location, integrity,
availability, performance, and age.

External Influences

Most development projects do not start from a completely blank sheet of

paper. Here, we consider some of the business and technical inputs to the
case study; we discuss external influences on the project in more detail
in Chapter 10, “Beyond the Basics.” For the purposes of the case study, we
assume that we have several inputs that are from outside the project
itself. The availability of such inputs is discussed in the sidebar “Best
Practice: Understand the Broader Context.”

From a business perspective, the primary input is the identification of,

and rationale for, any aspect of the business that can be supported by IT
and, therefore, any applications that should be commissioned. The input
from the business does not stop there, however, and the following work
products may be provided as input:

• Business Entity Model.This work product (or a similar work product,

such as a Domain Model) defines the key concepts in the business domain
under consideration.
• Business Process Model.This work product defines the activities
performed by the business and the roles that perform each activity.
• Business Rules.This work product defines any business-related policies
or conditions that must be satisfied by the system under development.

From a more technical perspective, you also may have access to the
following work products or similar ones. Such work products help guide
and constrain the creation of any applications produced in the
organization but are not specific to any particular application.

• Enterprise Architecture Principles.This work product contains rules,

standards, and guidelines that influence the way in which the architecture
of any applications will be created. This work product may contain an
approved vendor list or a policy such as “buy versus build,” for example.
This work product is defined at enterprise level (and is part of
an enterprise architecture, as discussed in Chapter 10,“Beyond the
Basics”) and applies to all applications that may be created.
• Existing IT Environment.This work product represents the collection
of existing elements that comprise the current IT landscape and that may
be used by, or constrain, the system under development. This work
product lists both hardware and software assets that are either available
or that constrain the architect’s work. A hardware asset may be an
existing network or node available in the organization. A software asset
may be an existing application that you might use as part of your overall
solution. Determining the content of the existing IT environment is
discussed in the sidebar “Best Practice: Survey the Existing IT
Environment.”
Best Practice: Understand the Broader Context

The case study assumes that both business and technical inputs are readily
available. In some situations, however, this is not the case. If these inputs are not
available, the project team (and the architect in particular) needs to determine
how to proceed without these inputs or whether to produce these items within the
project itself.

Best Practice: Survey the Existing IT Environment

Most of today’s initiatives involve some element of brownfield thinking. Therefore,

it is essential to understand the IT environment within which a system will exist.

IT architects and business analysts rarely do as thorough a job of surveying a site

as building architects do. Unfortunately, in IT, relatively little time is spent on the
equivalent of a site survey. (Hopkins 2008)

APPLICATION OVERVIEW
YourTour is a company that connects tour organizers with prospective
customers. The YourTour offering is unique in that it not only allows
multiple locations to be defined for a tour, but also provides flexibility in
terms of the accommodations and transportation required by each
participant in the tour. Suppose that the tour organizer wants to define a
wildlife-watching tour that takes in four locations. The YourTour
application not only allows the tour organizer to define the itinerary in
terms of the locations to be visited (and the associated dates), but also
allows each tour participant flexibility in terms of both accommodations
and transportation based on availability (choosing a four-star hotel over a
two-star hotel or traveling by train rather than by air, for example).
Another example is a sightseeing tour that takes in several locations in
the same country or continent.

In simple terms, the YourTour offering sits somewhere between a

packaged tour—which typically is defined as a single location, with fixed
accommodation and transportation arrangements—and a do-it-yourself
tour, which can be quite painful to organize on an individual basis, let
alone for a group.

Before discussing the high-level requirements for the YourTour

application, we should note why we chose this particular example as a
case study. As well as being conceptually simple, in that it does not
require specific domain expertise to understand, this example exemplifies
many of the challenges that architects typically face on a real project, such
as the following:
• Core functional requirements.The YourTour application must address
all the core functional requirements, such as the ability to process
payments when bookings are made.
• Development-time qualities.The application needs to address
development-time qualities, such as extensibility and portability.
• Run-time qualities.The application needs to address certain run-time
qualities, such as performance and usability.
• System constraints.The development of the application needs to
conform to specified constraints, such as cost, schedule, and the use of
particular technologies.
• Reusable assets.Most applications are not built from scratch but are
derived from an existing system or make significant use of existing assets.
Throughout the development of the application, the architect should
consider reusable assets such as architectural styles and patterns.
• Application integration.YourTour already uses IT to maintain
customer details, and there is some legacy integration to be considered in
terms of an existing customer relationship management (CRM) system.
You can consider such a system to represent a reusable asset, albeit a
very large-grained asset. In addition, it is anticipated that the YourTour
application will need to interact with a third-party payment engine to
handle monetary transactions and a third-party reservation system for
determining the availability of (and making) accommodation and
transportation reservations.
• Physical distribution.The YourTour application will be physically
distributed among a central office, branch offices (where customers can
purchase tours in store), and devices that allow Internet access (such as
web browsers and personal digital assistants [PDAs]). Again, physical
distribution is simply another complexity that the architect must face in
deriving a suitable solution to the defined requirements.

Although this list of considerations is not exhaustive, it does give some

sense of the breadth of complexity that the architect must address. As you
will see in subsequent chapters, it is precisely this sort of complexity that
a development process can help address in a systematic fashion.

The profitability of the YourTour application essentially depends on the

volume of bookings (because YourTour receives a fee for each booking
made) and the cost of running the application. Both of these factors can
be greatly influenced by a well-architected, well-designed, and well-
implemented tour booking system. If the application is easy to access and
use, is reliable, and performs well, it is likely to attract both tour
organizers and customers, and the result will be a corresponding increase
in the number of bookings. Similarly, if the system is easy to install,
administer, and maintain, its cost of operation will be lower.

Figure 6.2 shows an extract from a Business Entity Model that is

relevant to the YourTour application. This extract includes the key
concepts that are supported by the YourTour application.

Figure 6.2. Extract from the Business Entity Model

A tour comprises several tour locations and is defined by a tour

organizer. A tour location represents a base from which the surrounding
area will be explored. The YourTour application is concerned only with
arranging transportation between tour locations, however, not with
transportation arrangements within a tour location, such as a private-hire
bus that transports a group between sites that are visited from the same
base. Such transportation needs to be arranged by the tour organizer,
along with items such as a tour guide and meals. A tour participant is a
person who is booked on a tour.
Not surprisingly, a tour booking represents the heart of the YourTour
application. It represents the relationship between the tour participants
and the tour itself. In addition, a distinction exists between a tour
participant and the person who actually books the tour: the customer.
Although a tour participant and customer may actually be the same
person, the customer represents the person who pays for the tour,
whereas a tour participant is an actual attendee of the tour. This situation
is analogous to the head of a family booking the members of the family
and (optionally) herself on a tour. In this example, each family member is
considered to be a tour participant, but the family head who is paying for
the tour is considered to be the customer. Indirectly, a tour booking also
includes any reservations (accommodation or transportation) associated
with each participant.

THE YOURTOUR VISION

Another input that may be provided to the YourTour development team
and that is specific to the YourTour application is a Vision. The content of
this work product may be found in a project charter, if one exists.
The Vision work product may contain a problem statement, a list of
stakeholders, a list of features, any qualities that the system must exhibit,
and any constraints on the system. We look at these items in the following
sections.

Problem Statement

The YourTour application must address the following needs of its

stakeholders and users:

• Tour organizers want to reach the largest possible number of potential

customers to ensure that tours are run at capacity.
• Customers require access to a large and diverse catalog of tours, and
want control of the amount of money they pay based on the preferred
accommodation and transportation options of each tour participant. The
tour catalog represents the sum of all tours being offered by all tour
organizers.
• The YourTour application owner wants to provide an environment in
which tour organizers and customers can conduct their business, and
wants to make a profit by charging a fee for any bookings made.
• The YourTour application must provide a secure environment in which
tour operators can advertise their tours, customers can book them, and
an administrator can support this solution effectively.

Stakeholders
A stakeholder is an individual, team, or organization (or classes thereof)
with interests in, or concerns relative to, a system. (IEEE 1471 2000)

The key stakeholders of the YourTour application are briefly described

in Table 6.3. The various stakeholders in the development team (such as
the Project Manager or Tester) are represented by the Application
Provider stakeholder and are not treated separately. The Tour Organizer,
Customer, System Administrator, and Business Administrator are also
users of the system. Providers of accommodation and transportation are
not included in this list because they are accessed only indirectly through
interactions between the YourTour system and an external third-party
reservation system.

Table 6.3. Stakeholder Summary

Functionality

The functional features of the YourTour application should address the

needs and concerns of its stakeholders. We define the detailed
requirements associated with these features in Chapter 7, “Defining the
Requirements.” For now, we are simply putting a stake in the ground
regarding the high-level features of the YourTour system.

As we mention earlier in this chapter, you may have access to a Business

Process Model that defines the anticipated business behavior expected
and in which the YourTour application will participate. This model helps
you identify the features required of the YourTour application. An extract
from such a model is shown in Figure 6.3, which shows the process of
identifying a tour, registering tour participants, selecting the reservations
for each tour participant, and finally booking the tour. In terms of the
stakeholders listed in Table 6.3, in the preceding section, all these tasks
are performed by a customer.
Figure 6.3. Extract from the Business Process Model
Here is a list of features envisioned for the YourTour application:

• Specifying tours.The tour organizer is able to describe all aspects of the

tour, including the various locations that will be visited, together with the
tour pricing (excluding accommodation and transportation costs, which
depend on the selection made by the customer).
• Browsing tours.A customer is able to browse a structured catalog of
available tours and view tour descriptions (including location and price
information). The application will indicate which tours have spaces
remaining and also will present any promotions that may apply.
• Booking tours.A customer is able to book a tour. When a customer
makes a booking and pays for the tour, the tour organizer receives the
payment from the customer. The tour organizer pays a fee to YourTour
for every booking made.
• Managing user accounts.The application supports various types of
users, such as tour organizers, customers, or system administrators, each
of which has an account. User accounts can be created and subsequently
changed if the information is incorrect or changes. The system
administrator has access to all user accounts and, as such, is able to
browse user accounts, update user accounts, and archive or delete user
account information.
• Managing bookings.A tour organizer may cancel a tour (if the tour
guide becomes unavailable, for example) or cancel a booking (if the
customer has a poor credit history, for example), a customer may cancel a
booking (and may incur a penalty as a result), and a system administrator
may archive bookings.
• Maintaining system security.The application will support system
security, in particular providing user authentication of trusted identities
and ensuring that users perform only the operations for which they have
authorization.
• Providing access to external services.The application will provide the
customer links to tour-related external services, such as travel insurance
companies. This capability represents a revenue stream for YourTour
through both advertising and click-through capability.

Qualities

As well as functional features, the application must support certain

qualities and constraints. One important quality that the system must
address is availability; backup and maintenance operations should not
require the system to be offline. Another quality is performance;
specifically, the system should process a tour-booking confirmation (that
involves making reservations and processing the associated payment) in
less than 10 seconds. Scalability is also a concern, and the system should
support 5,000 concurrent users.

Constraints

In addition to a Business Entity Model and a Business Process Model,

you may be provided Business Rules with which the application must
conform. A business rule describes the policies that govern how a business
is run. An example is “An individual who is under 18 years of age may not
book a tour.” You also may have access to an Existing IT
Environment work product that represents the current IT landscape.
This work product may contain elements that you reuse or are
constrained by. An Enterprise Architecture Principles work product
may be provided; this work product contains rules and guidelines that
influence the way in which the architecture will be created, such as an
approved vendor list.
In terms of constraints, then, the YourTour company has decided that the
YourTour application will interface with an external payment engine (it
has already been decided that the YourTour company will not build this
engine part of the overall solution) as well as an external reservation
system. The company also has decided that the implementation of the
YourTour application will use an existing legacy application to store
customer information.

The company has determined that the application should be available to

end users over the Internet through web browsers and other mobile
devices, such as PDAs. It should also be available through a web browser
to sales clerks based in one of the YourTour branch offices, working over
the company local area network (LAN) behind a firewall. It is anticipated
that the system administrator will also work over the LAN, using a web-
browser interface to the system.

SUMMARY
As we mention in the introduction to this chapter, the information
presented here is commonly found in work products such as a Business
Entity Model, Business Process Model, Business Rules, Existing IT
Environment, Enterprise Architecture Principles, and Vision. The
content of the Vision in particular represents a first approximation of
what the YourTour application should provide and is used as a major
input to the project go/no-go decision. If the project goes ahead, this
information often becomes the basis for the development of more
detailed requirements, as described in Chapter 7, “Defining the
Requirements.”

Chapter 7. Defining the Requirements

This chapter discusses the requirements discipline, with a particular

focus on the role of the architect. As discussed in Chapter 2, “Architecture,
Architect, Architecting,” the architect is involved only peripherally in the
requirements discipline, because the Business Analyst is primarily
responsible for executing the requirements-related tasks. We have a
whole chapter dedicated to it, however. Why is that? The section
“Relating Requirements to Architecture” in this chapter answers this very
question.

In this chapter, and for the purpose of this book, we assume that several
work products are provided as input to, and are output from, the Define
Requirements activity, as shown in Figure 7.1. The Define
Requirements activity (introduced in Chapter 1, “Introduction”)
comprises the tasks described in detail in this chapter.
Figure 7.1. Input and Output Work Products of the Define Requirements Activity
The input work products, which we discuss briefly in Chapter 6,
“Introduction to the Case Study,” are as follows:

• Business Entity Model.This work product defines the key concepts in

the business domain under consideration.
• Business Process Model.This work product defines the activities
performed by the business and the roles that perform each activity.
• Business Rules.This work product defines any policies or conditions
that must be satisfied by the system under development.
• Change Request.This work product describes the request for a change
to the system. Changes may be significant and may dramatically impact
the focus of the iteration.
• Enterprise Architecture Principles.This work product contains rules
and guidelines, defined at the enterprise-level, that inform and guide the
way in which architectures will be created.
• Existing IT Environment.This work product represents the collection
of existing elements that comprise the current IT landscape and that may
be used by, or constrain, the system under development.
• RAID Log.This is a project management work product that captures
the risks, assumptions, issues and dependencies for the project. This work
product is an input when we prioritize the requirements for the current
iteration, since outstanding risks and issues are factors that we take into
consideration.
• Vision.This work product defines the stakeholders’ view of the system
to be developed, and is specified in terms of the stakeholders’ key needs
and features. It outlines the envisioned core requirements and may be as
simple as a problem statement. This work product provides an initial
indication of the scope of the system, which is refined as we move
forward.

The following requirements-related work products are output:

• Change Request.This work product may be output as a result of

changes resulting from a review of the requirements. Such changes are
typically accommodated in the next iteration.
• Functional Requirements.This work product captures the functional
requirements of the system under development.
• Glossary.This work product provides a list of common terms, their
meanings, and alternatives used by the business.
• Non-Functional Requirements.This work product captures the non-
functional requirements of the system under development. Non-
functional requirements represent system qualities (such as reliability)
and constraints.
• Prioritized Requirements List.This work product captures the priority
associated with each requirement.
• RAID Log.As described in the preceding list, this project management
work product captures the risks, assumptions, issues, and dependencies
for the project.
• Review Record.This work product defines, in the context of this
activity, the result of a requirements review.
• Software Architecture Document.This work product provides a
comprehensive architectural overview of the system, using several
architectural views to depict different aspects of the system.
• Stakeholder Requests.This work product contains requests that a
stakeholder may have for the system to be developed. It also may contain
references to any standards to which the system must conform (such as
regulatory compliance standards or organizational standards). The
difference between a request and a requirement is discussed later in the
section “Task: Collect Stakeholder Requests.”
• System Context.This work product represents the entire system as a
single entity or process, and identifies the interfaces between the system
and external entities.

The System Context, Functional Requirements, and Non-Functional

Requirements work products represent the requirements of the system
and serve as a contract between the customer, the users, and the system
developers. They allow customers and users to validate that the system
will become what they expected and enable developers to build what is
required.

RELATING REQUIREMENTS TO ARCHITECTURE

The emphasis given to requirements in this book is driven by the close
relationship between requirements and architecture that occurs in
practice. Although architects are involved only peripherally in the
requirements discipline, they are involved. Therefore, it is important to
understand the contribution of the architect and where that contribution
occurs. The requirements discipline is related to the resulting
architecture in several ways:
• Requirements influence the architecture.The most obvious
relationship is that the requirements influence the architecture of the
solution, because solution elements are selected that satisfy the stated
requirements (therefore, it is essential to understand the work products
that you, as the architect, will be receiving). Architects focus on
architecturally significant requirements when deriving the architecture,
and architectural significance is discussed in the sidebar “Concept:
Architectural Significance.”
• Well-defined requirements result in higher-quality
architectures.Because the requirements drive the definition of the
architecture, it follows that a well-defined set of requirements will result
in a better architectural solution than a set of poorly defined
requirements. Having architects participate in certain aspects of
requirements elicitation and definition can, given their experience, often
result in better-quality requirements.
• Architectural decisions influence the requirements.When defining
the architecture, the architect must often make trade-offs between
requirements, such as balancing performance and cost. As a result,
feedback goes from the architect to the Business Analyst so that the
requirements can be adjusted as necessary. The selection of a particular
architectural element may also constrain the requirements that can be
fulfilled. The selection of a Commercial-Off-The-Shelf (COTS) product,
such as a customer relationship management (CRM) packaged
application, may impose certain constraints on the requirements in terms
of the terminology used, the functionality provided, and any qualities
achieved. In such circumstances, the requirements are often refined to
accommodate the chosen architectural element. Any changes in
requirements must be renegotiated with the various stakeholders, of
course, and this renegotiation may require a formal change process to be
in place.
• The architecture defines requirements on subsystems.Another
notso-obvious relationship between requirements and architecture
occurs when the architecture is decomposed into its constituent parts. In
essence, the specification of any of the parts within the architecture forms
the requirements for that part. This is particularly relevant in developing
large-scale systems in which the parts are developed within separate
projects, which may be outsourced to a third party. Such considerations
are discussed further in Chapter 10, “Beyond the Basics.”
Concept: Architectural Significance

The phrase architecturally significant is often used to characterize the subset of

elements relevant to the architecture, whether these elements are architecturally
significant requirements, architecturally significant design elements, and so on.
But what is architectural significance? We touched on this topic in Chapter 2,
“Architecture, Architect, Architecting,” but we can be more specific here. An
element is considered to be architecturally significant if:

• The element is associated with some critical functionality of the system, without
which you do not have a viable system.
• The element is associated with some critical quality of the system, such as
performance, without which you do not have a viable system.
• The element is associated with a critical constraint on the solution, such as the
need to integrate with a specific external system.
• The element incurs a particular technical risk.
• The element presents a particular architectural challenge.

FUNCTIONAL AND NON-FUNCTIONAL

REQUIREMENTS
Before proceeding, we should clarify some terms that are used somewhat
inconsistently in the industry to discuss requirements—specifically, the
terms functional requirement and non-functional requirement. The
term functional requirement is fairly straightforward:

Functional requirements describe the behaviors (functions or services) of

the [IT] system that support user goals, tasks or activities. (Malan 2001)

In an order processing system, for example, allowing a customer to order

goods is clearly a functional requirement.

The term non-functional requirement is not so straightforward, because

its name describes what it is not rather than what it is. In other words,
you know that a non-functional requirement is not a functional
requirement! A simple definition is

Non-functional requirements include constraints and qualities. (Malan

2001)
This definition introduces two more terms used throughout this chapter
(and the book in general): constraint and quality.

A constraint is a restriction on the degree of freedom we have in

providing a solution. (Leffingwell 2000)
[System] qualities are properties or characteristics of the system that its
stakeholders care about and hence will affect their degree of satisfaction
with the system. (Malan 2001)

As discussed in Chapter 2, “Architecture, Architect, Architecting,” you can

think about constraints in terms of both business constraints (such as
regulatory and resource constraints) and technical constraints (such as
mandated technology standards and mandated solution elements). You
can think of qualities in terms of run-time qualities (such as performance
and usability) and nonrun-time qualities (such as maintainability and
portability). Qualities and constraints are of particular interest to the
architect because they often represent the most challenging aspects of
their work, as you will see later in the section “Task: Outline Non-
Functional Requirements.” Note that some texts use the term quality
attribute in addition to quality as explained in the sidebar “Concept:
Quality and Quality Attributes.”

Concept: Quality and Quality Attributes

In discussions of software quality, two terms are often used

interchangeably: quality and quality attribute. The difference between the two is
summarized in the following quotation:

Software quality is the degree to which software possesses a desired combination

of attributes. (IEEE 1061 1992)

Performance, scalability, and maintainability are all examples of quality attributes.

In this book, however, we tend to use the term quality, which seems to be more
commonly used in day-to-day conversation.

Functional requirements and non-functional requirements usually are

independent, and as a result, it is possible to build a system that is
functionally correct but that fails to meet the qualities and constraints
defined by the non-functional requirements. Because non-functional
requirements are often critical to the success of the system, and often
extremely challenging for the architect, you should (as this book suggests)
consider them early in a project.

TECHNIQUES FOR DOCUMENTING REQUIREMENTS

In documenting all the functional and non-functional requirements, you
need to consider what techniques you should use. Although you could
describe all your requirements in text, you may choose to use a technique
that also has an element of visual modeling to help communicate the
requirements. An example of such a technique is use case–driven
development, which is used in this book. This technique is used primarily
to define functional requirements, with the provisos that:

• Non-functional requirements may be associated with particular aspects

of the use case. A particular step in a use case may need to be performed
in a particular amount of time, for example.
• Some functional requirements are not necessarily best captured in use
cases and are referred to in this book as system-wide functional
requirements (in the sense that they are not associated with a particular
use case). A requirement to provide a secure system, for example, is a
functional requirement that pervades the entire system and is not tied to
a particular use case.

In this book, the Functional Requirements work product contains all

functional requirements (both those that are captured in use cases and
those that are system-wide). In keeping with an approach that advocates
the use of models and model-driven development, we refer to the
collection of use cases as a use-case model. Good overviews of use-case
modeling appear in Use Case Modeling (Bittner 2003) and Writing
Effective Use Cases (Cockburn 2000).

The Non-Functional Requirements work product contains all non-

functional requirements. This work product is of particular interest to
architects because it contains many of the challenging requirements that
architects must address in their work.

APPLYING THE PROCESS

As discussed in Chapter 6, “Introduction to the Case Study,” we consider
various practices that you can refine and apply as you see fit within your
own process. In this section, we make more specific observations
regarding the requirements tasks and, in particular, the typical
application within the life cycle of a project. Specifically, the requirements
tasks vary throughout the development life cycle, as shown in Figure 7.2.

Figure 7.2. Requirements and Iterative Development

Requirements definition is not something that happens once, at the

beginning of the project, because normally it is not possible to fully
understand and document all the requirements of the system up front.
Rather, requirements are refined throughout the life cycle of the project,
which emphasizes the need for effective requirements management (and
change management). Requirements management represents a systematic
approach to eliciting, organizing, and documenting the requirements of
the system in such a way that all stakeholders (including the developers)
understand them. It is also an approach to establishing and maintaining
agreement between the customer and the project team on the system’s
changing requirements.

The greatest emphasis on requirements activities occurs late in the

Inception phase, where the scope of the system is being established, and
early in the Elaboration phase, where the architecturally significant
requirements are detailed to drive the project toward the development of
a stable architecture. Some requirements tasks are performed in the
Construction phase, as the remaining requirements are detailed, and even
into the Transition phase, as requirements are refined based on feedback
received when transitioning the system to the end user.

Requirements, therefore, are refined as the project progresses. It certainly

is not our intention to give the impression that major changes to
requirements occur throughout the project! But there may be occasions
when exactly this happens, such as the following:

• A poor requirements management process is in place, accommodating

stakeholder requests without any discussion of their effect on the project.
• A requirement becomes better understood when examined in detail.
• An unforeseen change of circumstances occurs that requires the
requirements to be revisited. Your company may have merged with
another organization, for example, and now you have a new set of
stakeholder needs to satisfy. In this situation, it may make sense to put
the project on hold and revisit earlier phases to validate decisions and
assumptions that have been made thus far.

UNDERSTANDING THE TASK DESCRIPTIONS

Each of the tasks described in this book starts with a table that provides
an overview of the task. The tables should be read as follows:

• The Purpose section provides a brief summary of the purpose of the

task.
• The Roles section lists both primary and secondary roles involved in the
execution of the task.
• The Inputs section lists the work products that are produced by the
task. In an iterative process, in which work products are refined from
iteration to iteration, all output work products from the task are implicitly
considered to be input to the task.
• The Outputs section lists the work products that are output from the
task.
• The Steps section lists the steps that are performed to execute the task.
• The Role of the Architect section summarizes the involvement of the
architect in the task.

DEFINE REQUIREMENTS: ACTIVITY OVERVIEW

The tasks that comprise the Define Requirements activity (introduced
in Chapter 1, “Introduction”) are shown in Figure 7.3.
Figure 7.3. Overview of the Define Requirements Activity
The tasks can be summarized as follows:

• The purpose of the Collect Stakeholder Requests task is to gather the

requests that the various stakeholders place on the system.
• The purpose of the Capture Common Vocabulary task is to ensure that
common business and technical terms used by stakeholders are
understood and documented.
• The purpose of the Define System Context task is to ensure that the
boundary of the system under development is understood and that the
users and external systems that interact with the system are identified.
• The purpose of the Outline Functional Requirements task is to outline
the set of functional requirements.
• The purpose of the Outline Non-Functional Requirements task is to
outline the set of non-functional requirements. Such requirements may
represent qualities or constraints.
• The purpose of the Prioritize Requirements task is to prioritize the
requirements so that iterations are planned based on the highest-priority
requirements.
• The purpose of the Detail Functional Requirements task is to define
the functional requirements to the extent that they can be used to drive
the definition of the system from a functional perspective.
• The purpose of the Detail Non-Functional Requirements task is to
define the non-functional requirements to the extent that they can be
used to drive the definition of the system in terms of the qualities
exhibited and the constraints accommodated.
• The purpose of the Update Software Architecture Document task is to
document the architecturally significant requirements in the Software
Architecture Document.
• The purpose of the Review Requirements with Stakeholders task is
to obtain stakeholder agreement that the requirements, at their current
level of elaboration, satisfy their requests.

We look at each of these tasks in subsequent sections where the role of

the architect is highlighted.

Task: Collect Stakeholder Requests

PURPOSE
The purpose of this task is to gather the requests that the various stakeholders
place on the system.

ROLES
Application Architect (secondary), Business Analyst, Infrastructure Architect
(secondary), Stakeholder
STEPS
• Identify stakeholders.
• Collect stakeholder requests.
• Prioritize stakeholder requests.
ROLE OF THE ARCHITECT
• Ensure that the more technical roles, such as System Administrator, are
considered.
• Ensure that the more technical requirements, such as qualities and constraints,
are captured.
• Articulate the implications of a requirement on the solution, in terms of cost, time
to market, and the like.
• Assist with the prioritization of requests by explaining the impact of prioritizing
a request one way or another.

When gathering Stakeholder Requests, it is extremely important to

remember that a request is not a requirement. Often, requests from
different stakeholders are ambiguous, conflicting, or incomplete. Rather
than treating requests as requirements, first clarify and consolidate the
various requests, and subsequently provide input into the final statement
of the requirements as documented in the System Context, Functional
Requirements, and Non-Functional Requirements work products, as
discussed later in this chapter.

Step: Identify Stakeholders

The first step in this task is to determine the stakeholders that will
participate in the request-gathering activities. The complete set of
stakeholders is normally provided in a work product, such as
a Vision document, that is input to this activity. A Business Process
Model may also provide inspiration for stakeholders, because such a
model will contain a description of the business activities that the system
will support and, therefore, the associated business roles that may
represent stakeholders that you should consider.

It is important to ensure that stakeholders are identified appropriately,

because different stakeholders will have different concerns, and you
should have an appropriate focus and use appropriate techniques when
eliciting their requests. In the case of the YourTour system, the
stakeholders have indeed been identified, as discussed in Chapter 6,
“Introduction to the Case Study.” As a reminder, they are

• Application Owner
• Application Provider
• Business Administrator
• Customer
• Maintainer
• Supplier
• Support Personnel
• System Administrator
• Tour Organizer

To ensure that no stakeholders are inadvertently forgotten, it is often

useful to maintain a checklist of stakeholders as discussed in the sidebar
“Checklist: Maintain a Checklist of Stakeholders.”

Checklist: Maintain a Checklist of Stakeholders

It is all too easy to overlook a stakeholder when you are in the throes of
requirements elicitation. Therefore, there is value in maintaining and applying a
checklist of stakeholders that should be considered for any software development
effort.

Certain stakeholders are of particular significance to the architect, because their

needs often directly drive aspects of the architecture. Therefore, it is important to
ensure that these stakeholders are considered from the outset. Such stakeholders
include systems administrators (who support the installation, configuration, and
operation of the system) and support personnel (who are responsible for
providing front-line support of the system).

Step: Collect Stakeholder Requests

The main aspect of this activity is to gather the potential requirements,

which are referred to as requests because they are not yet agreed-upon
requirements, as discussed in the sidebar “Pitfall: Treating Requests As
Requirements.” You can use several techniques to achieve this goal,
including conducting workshops, brainstorming sessions, and interviews,
as well as using questionnaires. Another source of requests in an iterative
development process is the set of Change Requests that have been
raised. These potential requirements may be input to the start of an
iteration or even the start of the project (if the project represents an
evolution of an existing system). You should use consistent terms, as
defined in the Glossary, to capture the requests themselves.

This task is typically performed relatively well when it comes to the

functionality of the system. When it comes to capturing requirements that
represent the elements that are often of most interest to the architect—
namely, those requests that are non-functional in nature (those that
represent system qualities or constraints)—a less-than-adequate result is
often achieved. Successful projects involve the architect in gathering
stakeholder requests so that such items are considered from the outset.

A simple and effective technique is to maintain a checklist of such

potential requirements and ensure that these areas are discussed when
gathering stakeholder requests. A checklist is provided in Appendix D,
“Architectural Requirement Checklist.” This checklist can form the basis
of a questionnaire that you can use when collecting requests. It also can
form the basis of a discussion of likely future changes in the system.
Specifically, the content of the questionnaire will feed directly into the
creation of the Functional Requirements and Non-Functional
Requirements work products, as discussed in this chapter. Such an
approach could be called architecture-driven requirements elicitation.

Various pitfalls that can ensue when using such a questionnaire, and
when gathering requests in general, and a summary of these pitfalls is
provided in the following “Pitfall” sidebars.

Pitfall: Treating Requests as Requirements

A request is not a requirement; it is an expression of what a stakeholder

would like to have in the system. It does not become a requirement until explicit
agreement has been reached with the relevant parties and any conflicts with
existing requirements have been resolved.

When you apply agile practices and a customer representative is deemed to be

part of the team, a request may well be a requirement, and any drawn-out
negotiation is circumvented. Understanding the difference between requests and
requirements is still important even in these circumstances, however, because an
individual may state conflicting or ambiguous requests that need reconciliation
with existing requirements before they can be accommodated.

Pitfall: The Shopping-Cart Mentality

When collecting stakeholder requests, it is important to avoid the shopping-cart

mentality of the stakeholders. In the absence of any other criteria, a request-
gathering exercise quickly degrades into a fruitless conversation in which the
stakeholder decides that everything on offer is absolutely needed. Accommodating
such requests isn’t free, however, and this isn’t a shopping cart. It is very easy to
fall into the trap of presenting your stakeholders the equivalent of a shopping list
from which they pick and choose. The trick is to ensure that the stakeholders
understand the cost of their purchases by being able to position the effect of
selecting a particular requirement in stakeholder-friendly terms such as cost,
schedule, and quality. Supplementing the question “Does the system need to be
secure?” with the statement “A highly secure system is likely to double the cost of
the overall system” is almost guaranteed to get a different response from the one
you would get if the question were not qualified, for example. In both cases, of
course, you would need to define what you mean by secure, but you get the point.

Pitfall: The Questionnaire Is Technical

A questionnaire given to a stakeholder may be treated as a technical document

whose content lies outside the stakeholder’s area of concern. The reason for this
perception is that many stakeholders are more comfortable, and more familiar,
with business-related concepts. A typical stakeholder will understand the concept
of booking a tour, for example, but will be less comfortable talking about
availability. Consequently, stakeholders sometimes see such a questionnaire as an
impediment to the project’s progress rather than as a technique for eliciting some
crucial requirements of the system being built. The trick, again, is to ensure that
the stakeholders understand the value of spending time answering the questions
posed in the questionnaire. Often, it is easier to show this value by giving examples
of problems that arise in the absence of a questionnaire!

Pitfall: Requests Are Too General

Another pitfall is that requests are too general. A request may state that the
response time of any transaction is less than three seconds, for example. More
likely, however, the response time for specific transactions must conform to this
particular request, while other transactions take significantly longer. If you don’t
make requests as specific as possible, and these requests ultimately become
requirements, elements of the system are likely to be overengineered, as these
elements will be designed based on requirements that may not apply.
Pitfall: Requests Are Not Measurable

All requests should be measurable. An example of a request that cannot be

measured is “The system will have a state-of-the-art user interface.” This
statement is ambiguous because the definition of “state-of-the-art” is subjective
and simply cannot be measured. You must ensure that all the stated requests are
both unambiguous and measurable as far as possible, although some elaboration
of each request is permissible as requests are elaborated through the
requirements process.

Pitfall: Talking with the Wrong People

Another pitfall sometimes occurs when all the questions are being posed to all the
stakeholders. Many types of stakeholders have input to the request gathering
process, and you need to ask the right questions of the right people. The ability to
license elements of the system, for example, is a request that will be specified by
product management (and may be a request captured within your organization).
The usability of the system, however, may be specified by an end user (and may be
a request captured outside your organization).

Step: Prioritize Stakeholder Requests

As discussed in the preceding section, each individual stakeholder assigns

his or her own priorities to each request. However, different stakeholders
may make the same requests but give them different priorities. In this
step, you reconcile the various request priorities, which ultimately
influence the priorities of the resulting requirements that you review
with the stakeholders in the Review Requirements with
Stakeholders task (discussed later in this chapter).

Architects have a role to play in this reconciliation because they are often
in the best position to articulate the impact of prioritizing a request one
way or another in terms of factors, such as cost and time, to implement.

Task: Capture Common Vocabulary

PURPOSE
The purpose of this task is to ensure that common business and technical terms
used by stakeholders are understood and documented.

ROLES
Application Architect (secondary), Business Analyst, Infrastructure Architect
(secondary), Stakeholder

STEP
• Identify common terms.
ROLE OF THE ARCHITECT
• Assist with the definition of any technical terms used.

A project should consistently use a common vocabulary that is, where

relevant, aligned with the terminology of the problem domain. It is
especially important that the requirements work products use this
vocabulary consistently to prevent misunderstandings among the project
members. The vocabulary terms are documented in the Glossary. Each
term should have a clear and concise definition, and all interested parties
should agree on these definitions.

This particular task may be performed several times within an iteration

and across iterations. As requirements are defined, you may define and
refine the terms used. As requirements are detailed, you may, again, add
them to the Glossary.

A consistent terminology is particularly relevant to the architect for

several reasons. To communicate effectively with stakeholders and the
development team, the architect must use terms consistently and
unambiguously. Also, these terms often influence the names of
requirements and solution elements, so defining these terms
appropriately is important. Given the relatively simple task of creating
a Glossary, it is surprising how many organizations fail to create such a
simple and obvious work product. This failure is likely to lead to delays in
the overall project due to the ambiguity and miscommunication that
ensue—and that could have been prevented from the outset.
Step: Identify Common Terms

The terms themselves are often derived from the work products that are
input to a project, such as a Business Entity Model, Business Process
Model, Enterprise Architecture Principles, and Vision, or are simply
terms that are frequently used to describe the system and what it does,
and that may have been documented in the Stakeholder Requests work
product. When discussing the YourTour system, for example, you may use
terms such as tour, tour organizer, customer, and tour booking.

Terms are often documented simply with a name and description. Table
7.1 defines several terms from the Glossary of the YourTour system. The
architect often assists with the definition of any technical terms used. In
particular, some technical terms may be defined in industry standards
and, therefore, should be referenced rather than redefined. The architect
should be careful to reconcile synonyms and homonyms, however, as
defined in the sidebar “Best Practice: Reconcile Synonyms and
Homonyms.”

Table 7.1. YourTour Glossary Terms

Best Practice: Reconcile Synonyms and Homonyms

It’s very easy, especially on large projects, for different people to use different
terms to mean the same thing (synonyms) and for the same term to mean different
things (homonyms). In constructing the Glossary, it is important to ensure that
the preferred terms are used in all cases (although you may note the alternative
names for the terms), because the terms in the Glossary influence the naming of
elements in many other work products. A late change in the name of a term can
result in much rework, assuming that it is beneficial for terms to be consistent.
Having said that, it may be desirable for the same term to be used based on
common use in the industry. The term service, for example, can be applied in a
technical context in relation to a service-oriented architecture (SOA), where it
represents a software capability that is exposed via one or more interfaces. The
term service may also be used in a business context in relation to business service
management (BSM), where it typically represents an alignment of technology in
providing a service to the business.

Task: Define System Context

PURPOSE
The purpose of this task is to ensure that the boundary of the system under
development is understood and that the users and external systems that interact
with the system are identified.

ROLES
Business Analyst, Lead Architect (secondary), Stakeholder (Secondary)

STEPS
• Identify actors.
• Identify actor locations.
• Identify data flows.
ROLE OF THE ARCHITECT
• Ensure that external systems, with which the system under development must
integrate, are considered.
• Ensure that the locations of any actors are defined appropriately.
• Ensure that the flow of data between the system and external actors is
considered.

Two critical aspects of the system definition are its scope and, therefore,
its boundaries. In this task, you identify the actors, their locations, and the
flow of data between the actors and the system, and document them all in
the System Context work product.
Step: Identify Actors

When defining the system, one of the first things you identify is the
system context in terms of system actors and their interfaces to the
system. An actor is someone or something outside the system that
interacts with the system. An actor can be a person, an external system, or
an external device (such as a printer). Inspiration for such actors may
come from the roles defined in the Business Process Model work
product, mandated elements defined in the Enterprise Architecture
Principles work product, existing elements defined in the Existing IT
Environment work product, the requests defined in the Stakeholder
Requests work product, or the list of stakeholders described in
the Vision work product.

The actors identified for the YourTour system are shown in Figure 7.4. In
this figure, the Customer, Sales Clerk, Tour Organizer, System
Administrator, and Business Administrator actors represent people (or,
more correctly, the roles undertaken by people using the system),
whereas the CRM System, Payment Engine, and Reservation System
actors represent external systems. As for stakeholders, it is useful to
maintain a checklist of actors to ensure none is forgotten, as discussed in
the sidebar “Checklist: Maintain a Checklist of Actors.”
Figure 7.4. System Context of the YourTour System
Checklist: Maintain a Checklist of Actors

Just as we recommend that you maintain a checklist of stakeholders, you can

maintain a checklist of actors. As a technique, use-case modeling encourages the
description of business-related functionality and the business users, who are
represented as actors. Often, however, other actors interact with the system. Aside
from external systems and devices, it is also important to consider actors that
ensure the smooth operation of the system, such as a System Administrator that
performs systems management functions or a Support Operator that runs
diagnostics when required. Often, it is useful to maintain and use a list of such
actors to ensure that they are not overlooked. Addressing this pitfall may also
result in the identification of additional stakeholders.

Table 7.2 provides a description of each actor in Figure 7.4.

Table 7.2. Actor Definitions

A system context diagram, such as that shown in Figure 7.4, is particularly

useful not only for understanding the external environment within which
the system must operate, but also for describing the anticipated interface
between the system and its environment without getting bogged down in
the details of the internals of the system in terms of its implementation.

Interactions between the actors and the system are often of interest to
architects because they are concerned with any technologies required to
support the interface and any qualities that must be achieved when using
the interface (such as performance), and they also need to acknowledge
any constraints that may be imposed (such as the format of data passed
across the interface). Quite often, the architect has several choices to
make in realizing such interfaces and has to make appropriate trade-offs.
Therefore, the architect ensures that actors representing external
systems are considered, because such systems may result in the
identification of particular integration concerns.
Step: Identify Actor Locations

In addition to identifying the actors, it is important to acknowledge where

the actors are physically located. The location of actors subsequently
affects the architecture of your system, because you must acknowledge
any constraints incurred as a result of the locations specified. The
network latency inherent in a distributed environment, for example, can
mean that communication between elements is orders of magnitude
slower than communication between elements in a nondistributed
environment. Table 7.3 describes the locations identified for the
YourTour system and the actors associated with these locations.

Table 7.3. Location Definitions

Step: Identify Data Flows

You can be more precise about the nature of the interface between the
system and its external actors and provide details of the information
passed across this interface. An example is shown in Table 7.4. The
architect may get involved in this exercise to ensure appropriate
consideration of the flow of data between the system and external actors.
The descriptions of the data items typically make reference to items
described in the Business Entity Model, if this work product has been
provided as input. Subsequently, identified data items may be used when
describing the flows of events in each of the use cases, for example.

Table 7.4. Data Flows

Task: Outline Functional Requirements

PURPOSE
The purpose of this task is to outline the set of functional requirements.

ROLES
Application Architect (secondary), Business Analyst, Stakeholder (secondary)

STEPS
• Identify functional requirements.
• Outline functional requirements.
ROLE OF THE ARCHITECT
• Ensure that the requirements of the more technical actors, such as a System
Administrator, are considered.

In this task, you identify and outline the system’s functional

requirements. Each functional requirement is subsequently considered
and detailed based on its priority, as defined in the Prioritize
Requirements activity, which is discussed later in this chapter.

Note that the identification of actors (performed in the Define System

Context task), functional requirements, and non-functional requirements
is not performed in a strict sequence. As you identify functional
requirements, you may identify new actors, and vice versa. Also, you may
identify requirements that are best captured in the Non-Functional
Requirements work product, which is discussed later in this chapter.

Step: Identify Functional Requirements

In this step, you consider each actor and their functional requirements of
the system. In this book, we employ use cases for documenting functional
requirements. In this step, however, we also consider system-wide
functional requirements that aren’t readily captured in use cases.

A use case is a description of a complete flow of events that results in

something of value to an actor. The best way to find use cases is to
consider what each actor defined in the System Context work product
requires of the system, based on the Stakeholder Requests that have
been gathered, because the system exists only to service the requests of
the actors that interact with it. You also may refer to the Business
Process Model and Vision work products (and not rely only on the
stakeholder requests) to ensure that you are addressing the functionality
required. The Enterprise Architecture Principles work product may
also influence the functional requirements. The principle “Industry
regulations will be conformed to” may require the system to provide an
audit trail of its execution, supported by use cases that allow the relevant
system actors to access this audit trail, for example.

Each use case is identified by providing it a name and brief description.

The name of the use case should indicate what is achieved through the
interactions between the actors and the use case and, by convention, is a
verb followed by a noun (such as Browse Tours). The brief description of
a use case should reflect its goal and purpose, should refer to the actors
involved, and should use the terms defined in the Glossary.

A name, a brief description, the identification of related actors, and the

identification of the main flow and key alternative flows through the use
case (but not the detail behind each flow) usually are all that you need for
the use case at this point in the process. We expand on this information
when we flesh out the details of the use case in the Detail Functional
Requirements task, later in this chapter.

Figure 7.5 shows the initial set of use cases identified for the YourTour
system. The architect is often involved in this exercise to ensure that the
requirements associated with the more technical actors, such as the
System Administrator, are acknowledged.
Figure 7.5. Actors and Use Cases in the Use-Case Model
In addition to these use cases, you may identify functional requirements
that are considered to be system-wide and that are not expressed in use
cases. In the case of the YourTour application, we have identified a need
for both online help and security. Requirements should be negotiated
with stakeholders to ensure that a mutually acceptable statement of the
requirement is agreed to, as discussed in the sidebar “Pitfall:
Requirements Are Non-Negotiable.” You can also benefit from
understanding those requirements that may change, as discussed in the
sidebar “Concept: Change Cases.”

Pitfall: Requirements Are Non-Negotiable

Every requirement comes at a cost, and this cost is not always appreciated by the
stakeholder. The architect is often in a good position to articulate this cost in terms
of resource, time, skills, and the like. Conversely, the stakeholder is in the best
position to articulate the value of the requirement in terms of the solution being
provided. The architect and stakeholder need to bring their two perspectives
together so that a mutually acceptable requirement is agreed to and
communicated.

In a software project, you can change almost anything at any time: plans, people,
funding, milestones, requirements, designs, tests. Requirements—probably the
most misused word in our industry—rarely describe anything that is truly
required. Nearly everything is negotiable. (Royce 2005)

Concept: Change Cases

Be prepared for change long before it happens by implementing change cases in

your design. (Ambler 2000)

A change case represents a potential change in the system requirements and can
give the architect insight into those aspects of the architecture that should be
easily modified or extended. There is a trade-off to be made when addressing
change cases, however, because by definition, a change case is not a requirement;
it is a potential requirement. Although not explicitly included in the process
described in this book, formally documenting change cases can prove a valuable
exercise.

Whether the architecture should address a given change case is one of the trade-
offs that the architect needs to make, because it may involve additional effort or
have an impact on certain system qualities. Given two seemingly equal
architectural options, where one option addresses a change case and the other
does not, choosing the option that addresses the change case is clearly the thing to
do. Understanding the likelihood that a change case will become a requirement can
also help architects in their decision-making.

Step: Outline Functional Requirements

In this step, you provide an outline of the functional requirements. Table

7.5 describes the functional requirements that have been identified for
the YourTour system and indicates whether the functional requirement is
expressed as a use case or is a system-wide functional requirement.

Table 7.5. Functional Requirement Descriptions

These descriptions give you a hint that some refactoring of the use-case
model is in order. Specifically, different categories of user are identified: a
Tour Organizer, a Customer, and a Sales Clerk. Therefore, you may refine
the initial use case model. Figure 7.6 shows several refinements that have
been made, including generalized actors and associated use cases, and
also management use cases that have been identified. Such refactoring is
typically performed by a Business Analyst and can provide hints to the
architect of common behavior in the system, although you always need to
ensure a clear separation of requirements and solution. Any refactoring
may be reflected back in the System Context work product if it enhances
the communication of this work product.
Figure 7.6. Refactored Actors and Use Cases
As you can see, we added the generalized actors of User, Registered User,
and Tour Booker, as well as several use cases. This refactoring allows you
to identify common behavior and also allows you to communicate the
intent of the use-case model more easily, because it provides some level
of abstraction. The definitions of the additional actors are shown in Table
7.6; all other actor definitions remain unchanged. The additional use
cases are considered to be self-explanatory and are not detailed here.

Table 7.6. Refined Actor Definitions

Although they are not spelled out in the use-case diagram in Figure 7.6 or
in the associated descriptions, certain prerequisites exist for the
execution of some of the use cases. A Tour Organizer cannot specify a
tour, for example, and a Tour Booker cannot book a tour unless he or she
is logged into the system. Also, some rather obvious rules must be obeyed.
A Tour Booker cannot book a tour that is full, for example. Such rules are
used in the relevant use-case descriptions (a use-case description is
associated with a particular use case), and references are made to the
relevant items in the Business Rules work product. These considerations
are discussed later in this chapter, in the Detail Functional
Requirements activity.

Task: Outline Non-Functional Requirements

PURPOSE
The purpose of this task is to outline the set of non-functional requirements. Such
requirements represent qualities or constraints.

ROLES
Application Architect (secondary), Business Analyst, Infrastructure Architect
(secondary), Stakeholder (secondary)

STEPS
• Identify non-functional requirements.
• Outline non-functional requirements.
ROLE OF THE ARCHITECT
• Ensure that the appropriate non-functional requirements have been considered.
• Ensure that non-functional requirements are expressed in an appropriate
manner.

The identification of non-functional requirements is of particular interest

to the architect, because such requirements often present the most
challenging requirements to be accommodated in the resulting
architecture. As for functional requirements, we do not describe the non-
functional requirements in detail at this point. Instead, we concentrate on
defining their intent and purpose, and possibly outlining their content.
Each of the non-functional requirements is subsequently detailed based
on its priority, as defined in the Prioritize Requirements task, which is
discussed later in this chapter.

It is worth noting that the Outline Functional

Requirements and Outline Non-Functional Requirements activities
are not performed in strict sequence and typically are performed
concurrently. While identifying use cases, for example, you may
encounter non-functional requirements that are associated with a
particular aspect of the use case, in which case the requirement may be
defined in the Non-Functional Requirements work product and referred to
from the use case. Conversely, while identifying non-functional
requirements, you may encounter requirements that apply only to a
particular use case, in which case the requirement is associated with the
use case in question and not the system as a whole.

Step: Identify Non-Functional Requirements

Based primarily on the requests that have been specified in

the Stakeholder Requests work product, you can derive the non-
functional requirements. This activity is much easier to undertake if you
use a questionnaire, such as that discussed in the Collect Stakeholder
Requests task, because the requests are already classified in a manner
that aligns well with the content of the Non-Functional Requirements work
product. This work product typically is organized with the same
classification, using the usability, reliability, performance, and
supportability non-functional categories of the FURPS classification
described in Appendix D, “Architectural Requirement Checklist.” As for
stakeholders and actors, it useful to maintain a checklist of non-functional
requirements, as described in the sidebar “Best Practice: Maintain a
Systematic List of Non-Functional Requirements.”

In identifying the non-functional requirements, you may refer to

the Business Rules work product that contains explicit constraints on your
solution. Business rules are described in the sidebar “Concept: Business
Rules.” In addition, you may refer to the Vision, because it may contain
features that are actually non-functional in nature, such as system
availability. The System Context work product is also used as input
because it defines the nature of any integration with external actors,
which may imply non-functional requirements of the system, such as a
constraint on the nature of the interface to a particular external system.
The Enterprise Architecture Principles work product may contain
defined technology standards. The architect typically gets involved in this
task to ensure that all relevant non-functional requirements are
identified.

Non-functional requirements that represent qualities associated with the

YourTour system include accessibility, availability, scalability, and
testability. Non-functional requirements that represent constraints
associated with the YourTour system include schedule, integration,
platform support, standards compliance, and third-party components.

Best Practice: Maintain a Systematic List of Non-Functional Requirements

Unlike functional requirements, a more finite set of non-functional requirements

can be considered for any given system (in particular, those non-functional
requirements representing qualities). Whichever framework you use to classify
the non-functional requirements, it is good practice to maintain and apply an
appropriate checklist of non-functional requirements to ensure that nothing has
been overlooked.

Concept: Business Rules

A business rule is a statement that defines or constrains some aspect of the

business. It is intended to assert business structure or to control or influence the
behavior of the business. (Business Rules Group 2000)
Business rules describe the operations, policies, and constraints that an
organization puts in place to achieve its goals. Rules help the organization achieve
its business goals by acting as a communication mechanism between the
organization and interested third parties and by allowing the organization to meet
its legal and other statutory obligations. They also allow the organization to
operate more efficiently, because rules can be automated and analyzed to look for
time and cost savings and the like.

Business rules fall into several categories:

• Rules that provide the conditions that govern business behavior (legislative,
regulatory, cultural, and business)
• Rules that provide the criteria for when an action is successfully or
unsuccessfully completed
• Rules that stipulate what other actions can or cannot be performed as a result of
successful or unsuccessful completion
• Rules that specify the response to some external event that impinges on the
enterprise
• Rules that govern relationships among various business entities

Step: Outline Non-Functional Requirements

In Table 7.7, we show a few entries from the Non-Functional

Requirements work product of the YourTour system. The categories and
requirements shown in this table come from the FURPS classification
described in Appendix D, “Architectural Requirement Checklist.” As you
would expect, non-functional requirements are documented by using
terms defined in the Glossary, and the architect typically gets involved to
ensure that the non-functional requirements that have been identified are
described in an appropriate manner. Specifically, the non-functional
requirements must be measurable to prove or disprove that such
requirements have been met. In addition, you may choose to explicitly
state what is not required to avoid any ambiguity, as discussed in the
sidebar “Best Practice: State What Is Not Required if This Aids
Understanding.”

Table 7.7. An Extract from the Non-Functional Requirements Work

Product of the YourTour System
Best Practice: State What Is Not Required if This Aids Understanding

Sometimes, it is useful to state what is not required of the system to prevent

assumptions from being made or to prevent a lack of clarity about the
requirements. A good example is “The YourTour system will not implement
handling of payments and reservations (of accommodations and transportation)
directly; it will interface with the MyPay payment engine and the MyReservation
reservation system, respectively.”

Task: Prioritize Requirements

PURPOSE
The purpose of this task is to prioritize the requirements so that iterations are
planned based on the highest-priority requirements.

ROLES
Business Analyst, Lead Architect, Project Manager (secondary), Stakeholder
(secondary)

STEP
• Prioritize requirements.
ROLE OF THE ARCHITECT
• Assist with the prioritization of requirements.

As mentioned in Chapter 3, “Method Fundamentals,” one of the premises

of architecting software systems successfully is using an iterative
development life cycle, which helps architects focus on the results they
are trying to achieve at any given time without getting bogged down in
whether a particular work product is complete. In other words, architects
are results-driven and not document-driven. More specifically (as also
discussed in Chapter 3), architects move from focusing on understanding
the scope and associated risks in the system, to focusing on removing risk
and stabilizing the architecture, to focusing on completing the system in
an incremental fashion.

Prioritizing requirements helps you determine which things to focus on

within the current iteration based on your goals and focus. Because your
focus changes through the project life cycle, the priority associated with a
particular requirement will also change. Therefore, requirements are not
prioritized only once. You examine the relative priorities within each
iteration and, where necessary, adjust those priorities based on the
current project status (including new requirements, new change requests,
discovery of new risks, and mitigation of existing risks).
Prioritizing the requirements is based on several factors. One of these
factors, associated with an iterative development approach, is ensuring
that risks are confronted early. For this reason, the RAID Log, which
includes the known and open risks to the project and current issues on
the project that need to be addressed, is considered to be an essential
work product that is input to this task. Another factor is the key needs of
the stakeholders and the corresponding features of the system, as
documented in the Vision document, which is also an input to this
activity. In addition, the Stakeholder Requests work product is input,
because it contains an indication of the stakeholder priorities based on
the originating requests that were made. The Glossary is input because it
provides clarification of any terms used. The Functional
Requirements and Non-Functional Requirements work products are input,
of course.

The priority given to a particular requirement is captured in

the Prioritized Requirements List work product that is output from this
task.

Step: Prioritize Requirements

You can perform an initial prioritization of the requirements by looking

across all requirements, functional and non-functional, resulting in an
indication of those high-priority requirements that you should attempt to
address in the current iteration. Consideration of these high-priority
requirements can entail a significant amount of effort, however, especially
if you consider that each requirement may have an element of detailed
design and testing associated with it.

Therefore, you need to be smart about how you address the high-priority
requirements. The fact that requirements are not always truly
independent can help you in this regard. If you address the Book Tour use
case, for example, you know that it will also address the integration with
third-party components. To minimize the effort involved in addressing
high-priority requirements, it is beneficial to consider the alignment of
use cases and other requirements when prioritizing, which you can show
in a simple table.

Table 7.8 shows an example from the YourTour system. The rows
represent use cases, and the columns represent all other requirements
(systemwide functional requirements from Table 7.5 and non-functional
requirements from Table 7.7). Coverage of a specific non-functional
requirement or systemwide requirement by a use case is indicated with
a Y in the relevant cell. You cannot determine the schedule of the system
by considering a single use case (all use cases must be considered),
however, and so schedule is not included in this table.

Table 7.8. Alignment of Use Cases and Other Requirements

This table helps inform our decisions regarding the relative priority of
each of the use cases. Table 7.9 shows the priority assigned to each use
case, together with the rationale for its priority. The priorities are based
on the information gleaned from Table 7.8 and other characteristics
mentioned in the rationale. Each requirement is shown as being high,
medium, or low priority. Any risks that form part of the rationale are
taken from the RAID Log. Both the prioritized list and the rationale for
the priority are captured in the Prioritized Requirements List. The list
may also contain requirements that do not align with any use case in
particular, such as a requirement for the system to start up in a given
amount of time, in which case you just add them to the list with the
associated rationale for their priority. You should also ensure that the use
cases really are prioritized against one another, as discussed in the
sidebar “Pitfall: All Requirements Are Equal.”

Table 7.9. Prioritized Use Cases

Pitfall: All Requirements Are Equal

A common pitfall is for all requirements to be given the same priority. Without
exception, projects that suffer from this pitfall classify all requirements as high
priority. If all requirements have the same priority, providing priorities against
requirements is a waste of time, because this information cannot be used to
identify those requirements that are more important than others. The
requirements need to be prioritized to indicate to the architect (or anyone else)
the most important requirements of the system.

Task: Detail Functional Requirements

PURPOSE
The purpose of this task is to complete the functional requirements to the extent
that they can be used to drive the definition of the system from a functional
perspective.

ROLES
Application Architect (secondary), Business Analyst, Stakeholder (secondary)

STEPS
• Detail use cases (for each use case considered in the current iteration).
• Detail use-case data items.
• Detail system-wide functional requirements.
• Detail functional requirement scenarios.
ROLE OF THE ARCHITECT
• Ensure that all the alternative flows are considered.
• Assist with the definition of use-case data items.
• Assist with the detailing of system-wide functional requirements.
• Assist with the detailing of specific scenarios.

At this point, you have an initial specification of what the system is

required to do, what its scope is, and a list of prioritized requirements.
Now you turn your attention to refining this initial system definition to
gain a deeper understanding of the requirements. Only the highest-
priority requirements are considered in the current iteration.

As you detail the various requirements, it is important to note that the

addition of such detail may require you to revisit some of the tasks
already performed. You may find that a use case needs to be split into two
or more use cases or that the detail contained within a use-case
description makes the use case architecturally significant and, therefore,
higher priority. Such refinements may be accommodated in either the
current iteration or the next iteration.

Step: Detail Use Cases

This step is performed for each use case being considered in the current
iteration. In this step, you start with the Functional Requirements work
product that contains the use-case model and that in turn contains each of
the use cases and, therefore, the associated use-case descriptions. You
gradually make the use case description more detailed until all the
stakeholders are happy that it unambiguously expresses their
requirements. You specify the following information when you detail a
use case, elements of which will have been defined in the Outline
Functional Requirements task:

• Name.The name initially defined in the Outline Functional

Requirements task.
• Brief Description.The goal and purpose of the use case (initially
defined in the Outline Functional Requirements task).
• Primary Actors.The names of the initiating actors. You may have more
than one primary actor if two or more actors are able to initiate the same
use case.
• Secondary Actors.The names of any other actors involved in the use
case.
• Main Flow of Events.A description of the primary path through the use
case when it executes, expressed in terms of interactions between the
actors and the system. These interactions may have been outlined when
the use case was initially defined in the Outline Functional
Requirements task.
• Alternative Flows of Events.A description of alternative paths through
the use case when it executes, also expressed in terms of interactions
between the actors and the system. The key alternative flows (and
associated interactions) may also have been outlined when the use case
was initially defined in the Outline Functional Requirements task.
• Special Requirements.A textual description of requirements that are
not considered in the use case flows of events but that need to be taken
care of during the detailed design or implementation. Such requirements
typically represent non-functional requirements associated with the use
case, such as system qualities (performance, for example) or constraints
on the solution, and items in this section may reference the Non-
Functional Requirements work product. Special requirements are
discussed later in this section.
• Preconditions.The required state of the system to execute the use case.
• Postconditions.A list of possible states that the system must be in
immediately after the use case has finished.

When describing a use case, it is important to consider the context of the

use case. The context of the use case is described by the relationships that
the use case has with actors and other use cases. If it adds value, this
context can be expressed in a local use-case diagram that contains only
the use case, its actors, and other use cases that the use case may have
relationships with (such as use cases that this use case includes or
extends). Figure 7.7 shows the context of the Book Tour use case.

Figure 7.7. The Context of the Book Tour Use Case

The use-case description should also refer to the Glossary to ensure that
consistent terms are used. You may also refer to the Stakeholder
Requests to get a better understanding of the intent, if required.

Some of the items in the use-case description warrant further

explanation. We start with the various flows of events. A use case may
have several potential flows through it, as shown symbolically in Figure
7.8. A use case always has a main flow (sometimes referred to as the basic
flow or happy day path) and may have several alternative flows that arise
due to exceptional conditions, for example.

Figure 7.8. The Flows of Events of a Use Case

The following information should be included in the detailed description

of each flow of events:

• How and when the use case starts

• When the use case interacts with the actors and what information is
exchanged
• How and when the use case uses information stored in the system or
stores information in the system
• When business rules (referenced from the Business Rules work product)
are applied
• How and when the use case ends

As an example, Table 7.10 contains the description of the main flow of

events for the Book Tour use case.

Table 7.10. Main Flow of Events of the Book Tour Use Case
As well as detailing the main flow of events, you may detail alternative
flows. Table 7.11 describes three of the alternative flows of events for the
Book Tour use case. The architect may be involved in helping identify the
alternative flows, because the stimulus for the flow being executed may
be technical in nature.

Table 7.11. Alternative Flows of Events of the Book Tour Use Case

The special requirements associated with a use case also warrant further
explanation. Architects sometimes come across requirements that are
associated with a use case but that are not associated with any flow of
events in particular. Such requirements often represent qualities or
constraints that are specific to the use case as a whole and are described
in the special requirements section of the use-case description. The Book
Tour use case of the YourTour system, for example, specifies the following
special requirement: “Booking a tour must take less than 10 seconds,
from the time the request is submitted, to the confirmation of the booking
being presented to the user.”

Because you also have a Non-Functional Requirements work product, it

does raise the question of where special requirements that are use case–
specific and non-functional in nature should physically reside in terms of
any documentation that constitutes the Non-Functional
Requirements work product. On the one hand, it is clearly of value to see
the requirement in context in the use-case description. On the other hand,
it is also of value, especially for the architect, to see all non-functional
requirements in one place, whether or not these requirements are
associated with a use case.

In a perfect world, you would have appropriate development tools that

allow use case–specific non-functional requirements to be seen with the
use-case description and in a list of all non-functional requirements. In
practice, such requirements are often included with the use case, with
references to these requirements from a separate document, spreadsheet,
or tool that provides a summary of all non-functional requirements.

Other items in the use-case description worth describing are the

preconditions and postconditions. In detailing a use case, sometimes you
need to define that the system be in a particular state before the use case
can start. A common example is the “user is logged in” state. The Book
Tour use case specifies the preconditions shown in Table 7.12.

Table 7.12. Preconditions of the Book Tour Use Case

It also may be necessary to describe what must be true after the use case
completes. The Book Tour use case has the postcondition shown in Table
7.13.

Table 7.13. Postconditions of the Book Tour Use Case

Step: Detail Use-Case Data Items

In the Define System Context task, you identified the data that flows
between the external actors and the system, and the data items involved
in the interactions. Then you used the data items in describing various
aspects of the requirements. The purpose of this step is to elaborate on
the data items you identified. You will consider these data items further
when you think about the solution to the requirements, as discussed
in Chapter 8, “Creating the Logical Architecture.”

Again, we can use the Book Tour use case as an example. Simply looking
at the main flow of events, you can see that this use case makes use of
Tour Participants, Tour Participant Options, Tour, Tour Location,
Payment Details, and Tour Booking data items, which were originally
identified in the Define System Context task. You can also see that the
use case may infer additional data items or attributes of these items.

The step “The Tour Booker receives a unique reference as confirmation of

the Tour Booking” in the use-case flow tells you two things, for example:

• There probably is a Booking Confirmation data item.

• A Tour Booking has a unique reference.

If you apply this scrutiny across all use cases, you can see that the
definition of the various data items is refined as a result. Any new data
items that are identified are added to the System Context work product
as required.
Step: Detail System-Wide Functional Requirements

For those functional requirements that are not easily expressed in use
cases, you generally embellish the textual description of the requirement
that has been outlined. You could refine a requirement such as “The
system shall provide online help” with a more detailed description of the
form in which this online help will be provided. You might add “Online
help will be accessible at any point in time, and it will be possible for the
help contents to be downloaded as a PDF file.” The architect may assist
with this step because any system-wide capabilities may have a
significant impact on the architecture.

Step: Detail Functional Requirement Scenarios

The functional requirements discussed so far are general enough to cover

all possible scenarios. It may also be beneficial to define several concrete
scenarios to exemplify and clarify a given functional requirement. This
approach can also ensure that specific values that the system must
address are made explicit, which can provide valuable information to
developers and testers.

A specific scenario associated with booking a tour may include a

statement such as “John Smith is an existing customer. He would like to
book his three sons, Tom, Dick and Harry, on the Around Africa tour.”

Even these simple statements can make explicit items that might
otherwise go unnoticed. The concept of an existing customer, for example,
implies that customer information is retained by the system. Also, this
particular scenario does not involve the customer participating in the
tour; therefore, it must be possible for a customer to book a tour on behalf
of others.

Task: Detail Non-Functional Requirements

PURPOSE
The purpose of this task is to complete the non-functional requirements to the
extent that they can be used to drive the definition of the system in terms of the
qualities exhibited and the constraints accommodated.
ROLES
Application Architect (secondary), Business Analyst, Infrastructure Architect
(secondary), Stakeholder (secondary)

STEPS
• Detail non-functional requirements (for each non-functional requirement
considered in the current iteration).
• Detail non-functional requirement scenarios.
ROLE OF THE ARCHITECT
• Ensure that all non-functional requirements are described in an appropriate
manner.
• Assist with the detailing of specific scenarios.

In this task, you detail those non-functional requirements associated with

the high-priority items in the current iteration. As for functional
requirements, you may encounter non-functional requirements that have
not been stated or characteristics that warrant a fundamental change in
the non-functional requirement. Again, such refinements may be
accommodated in either the current iteration or the next iteration.

Step: Detail Non-Functional Requirements

The purpose of this step is to augment the relevant non-functional

requirements with any additional detail required. Imagine that you had a
requirement that simply stated, “The system will be scaleable.” You
cannot address this requirement unless you understand what it means in
terms of numbers of users, volumes of data, and so on. Supporting a
solution that scales to 100,000 concurrent users is likely to result in a
different solution from one that must scale to 100 concurrent users, for
example. The architectural solution to the requirement is potentially
different depending on the details of the requirement. Another example is
“The system will interface with the ABC external system.” You need to
augment the requirement with information regarding the precise nature
of the interface so that our system communicates with the ABC system in
an appropriate manner.

A simple way to supplement the description of each non-functional

requirement is to apply the elements of the SMART acronym. This
acronym has many variations, but for the purposes of this discussion,
assume that the items are specific, measurable, achievable, realistic,
and time-based. Simply thinking about each element of this acronym and
applying it to your definition of each non-functional requirement can take
you some way toward providing the detail required. In particular, if a
requirement cannot be measured, it cannot be validated. If a requirement
cannot be validated, it cannot be realized in the solution, because there is
no way to determine whether the requirement has been satisfied.
Providing a sufficient description often requires effort to achieve. As
stated succinctly in Principles of Software Engineering Management (Gilb
1988):

[Quality] attributes can always be made measurable. This frequently

seems difficult, but there is always a way of achieving it. (Gilb 1988)

Each description of a non-functional requirement should also refer to

the Glossary to ensure that consistent terms are used. You may also refer
to the Stakeholder Requests to get a better understanding of the intent,
if required.

Step: Detail Non-Functional Requirement Scenarios

The detailing of scenarios associated with non-functional requirements

focuses primarily on qualities. A technique for detailing such scenarios is
presented in Software Architecture in Practice, 2nd ed. (Bass 2003), where
each quality is qualified with one or more quality attribute scenarios,
which may be identified in a Quality Attribute Workshop (QAW) (Barbacci
2003). Each scenario consists of six parts:

• Stimulus.The stimulus defines the condition that must be handled by

the system.
• Source of the stimulus.The source defines the role, system, or system
element that causes the scenario to start.
• Artifact stimulated.The artifact represents the target of the stimulus
and represents either the system or a part of the system.
• Environment.The environment defines the conditions under which the
stimulus occurs.
• Response.The response represents the response of the system to the
stimulus under the conditions expressed in the environment.
• Response Measure.The response measure is a definition of how the
outcome is handled.

We can exemplify this template by considering a scalability scenario:

• Stimulus.The initiation of a tour booking.

• Source of the stimulus.The end user who is causing a booking with the
YourTour system to be initiated.
• Artifact stimulated.The YourTour system.
• Environment.5,000 concurrent users are currently logged in to the
system.
• Response.The booking request is rejected because a threshold has been
reached (assuming that a limit of 5,000 concurrent users is defined).
• Response Measure.The end user who initiates the tour booking is
notified that currently it is not possible to book a tour and told what
action he or she should take.

Describing scalability scenarios in this manner is much more explicit and

measurable than simply stating “The system must scale to support 5,000
concurrent users,” because it describes the conditions under which the
scenario occurs (the source, stimulus, and environment), what the
scenario applies to (the artifact), and the desired outcome (the response
and response measure).

Task: Update Software Architecture Document

PURPOSE
The purpose of this task is to document the architecturally significant
requirements in the Software Architecture Document.

ROLE
Lead Architect

STEP
• Update software architecture document.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

The requirements view of the Software Architecture Document is used

to document the architecturally significant requirements. As discussed
in Chapter 4, “Documenting a Software Architecture,” several cross-
cutting views allow you to also consider a particular focus on the
architecture, and this focus allows you to describe the requirements for a
specific set of concerns. A checklist of requirements associated with each
of the cross-cutting views is given in Appendix B, “Viewpoint Catalog.”

Step: Update Software Architecture Document

In this step, you update the requirements view, and any cross-cutting
views, of the Software Architecture Document. This requirements view
contains the architecturally significant functional and non-functional
requirements. You should always bear in mind that the purpose of
the Software Architecture Document is to allow the architecture to be
communicated. From the perspective of requirements, you are trying to
communicate the requirements that have a major bearing on the
architecture and that provide rationale for why the architecture is the
way it is. This information is particularly valuable when, for example, you
have to defend your architecture in an architecture review.

Task: Review Requirements with Stakeholders

PURPOSE
The purpose of this task is to obtain stakeholder agreement that the requirements,
at their current level of elaboration, satisfy their requests.
ROLES
Application Architect (secondary), Business Analyst, Data Architect (secondary),
Infrastructure Architect (secondary), Lead Architect, Stakeholder

STEPS
• Baseline work products.
• Assemble work products.
• Review work products.
ROLE OF THE ARCHITECT
• Participate in the review.
• Respond to any questions of a technical nature.

The purpose of reviewing the requirements with the stakeholders is to

ensure that the requirements, at their current level of elaboration, satisfy
their requests. Before performing the review of the various requirements,
you baseline work products so that you have a clear record of what was
reviewed and can refer to these work products if necessary (to clarify a
review comment against one of these work products, for example).

Step: Baseline Work Products

Baselining is one aspect of configuration management (which also

includes version control of work products), and the approach to
configuration management is a project concern that should be addressed
very early in the project. In this step, the various requirements work
products are baselined, which simply means that the correct versions of
the work products that will be input to the review are clearly identifiable.

Although a configuration management approach can be very simple

(when, for example, files are manually renamed to include a version
number and a spreadsheet is used to describe a baseline of work
products), you may find that even for small teams, using appropriate
tooling to support the configuration management approach is a far more
effective and less error-prone approach.

Step: Assemble Work Products

In this step, you assemble the requirements work products that have
been created or updated (and baselined) during the iteration in a form
that stakeholders can review. Work products may be defined in various
forms (such as a modeling tool or as stand-alone documents in a shared
work area) and must be assembled into one or more deliverables. The
work products assembled potentially include all work products that are
input into, or output from, the Define Requirements activity.

Step: Review Work Products

In this step, you review the requirements work products and document
any problems discovered in the work products in Change
Requests. Document any issues that arise in the RAID Log. When the
review is complete, you briefly capture the results of the review, including
any action items, in a Review Record.

This review serves as a quality gate for the iteration that ensures that the
requirements work products are mature enough to support subsequent
tasks. It is important that people outside the development team (such as
users and customers) approve the requirements work products at this
stage, although all stakeholders are involved to some extent in many of
the tasks discussed in this chapter, of course. They should verify that the
work products capture the detailed requirements accurately. It is also
important that the members of the development team be involved to
make sure that they understand what needs to be built, as well as to
identify areas where more information is needed.

SUMMARY
In this chapter, we described the process for documenting the
requirements of the system, resulting in the following key work
products: Glossary, Stakeholder Requests, System Context, Functional
Requirements, Non-Functional Requirements, and Prioritized
Requirements List. We also updated the Software Architecture
Document with the architecturally significant requirements. These work
products drive the development activities in Chapter 8, “Creating the
Logical Architecture,” and Chapter 9, “Creating the Physical Architecture.”

Chapter 8. Creating the Logical Architecture

In this chapter we describe the tasks that produce the logical architecture
that realizes the requirements defined in Chapter 7, “Defining the
Requirements.” The sidebar “Concept: Logical Architecture versus
Physical Architecture” describes the meaning of a logical architecture and
how it differs from a physical architecture. Figure 8.1 shows the work
products that are inputs to and outputs from the Create Logical
Architecture activity, which contains the tasks that we discuss in this
chapter.

Figure 8.1. Input and Output Work Products of the Create Logical Architecture
Activity
Concept: Logical Architecture versus Physical Architecture

A logical architecture represents an initial stepping stone in getting from the

requirements to the solution—a first step that considers the architecture in a
largely technology independent manner. A physical architecture, on the other
hand, is more specific—and takes technology into account. The logical architecture
may contain an Account component, for example, whereas the physical
architecture may use the Java Platform Enterprise Edition (Java EE) and
implement this logical component as an Account EJB (Enterprise JavaBean).

The input work products (discussed in Chapter 7, “Defining the

Requirements”) are

• Business Entity Model.This work product defines the key concepts in

the business domain under consideration.
• Business Rules.This work product defines any policies or conditions
that must be satisfied by the system under development.
• Enterprise Architecture Principles.This work product contains rules
and guidelines, defined at enterprise level, that inform and guide the way
in which architectures will be created.
• Existing IT Environment.This work product represents the collection
of existing elements that comprise the current IT landscape and that may
be used by, or constrain, the system under development.
• Functional Requirements.This work product captures the functional
requirements of the system under development.
• Glossary.This work product provides a list of common terms, their
meanings, and alternatives used by the business.
• Non-Functional Requirements.This work product captures the non-
functional requirements of the system under development.
• Prioritized Requirements List.This work product captures the priority
associated with each requirement.
• RAID Log.This project management work product captures
the risks, assumptions, issues, and dependencies for the project.
• System Context.This work product represents the entire system as a
single entity or process and identifies the interfaces between the system
and external entities.

The following work products are output from the Create Logical
Architecture tasks:
• Architecture Assessment.This work product records the results of an
assessment of the requirements and architecture performed at various
stages during the project life cycle. An assessment identifies issues and
risks associated with the architecture or its requirements and describes
the actions and mitigation strategies to address them.
• Architecture Decisions.This work product records the significant
decisions made in shaping the overall architecture. It describes the
rationale used in making the decision, the options considered, and the
implications of the decision.
• Architecture Overview.This work product provides an overview of the
key elements of the architecture, such as the major structural elements,
important behavior, and significant decisions.
• Architecture Proof-of-Concept.This work product is used to prove and
validate key parts of the architecture to reduce project risk. It may take
the form of a model of a solution using a notation such as Unified
Modeling Language (UML), a simulation of a solution, or an executable
prototype.
• Change Request.This work product describes the request for a change
in the system. Changes may be significant and may dramatically affect the
focus of the iteration.
• Data Model.This work product describes the representation of the data
used by the system.
• Deployment Model.This work product shows the configuration of
nodes, the communication links between them, and the components that
are deployed on them.
• Functional Model.This work product describes the software
components, including their responsibilities and relationships, and the
collaborations of components in delivering the required functionality.
• RAID Log.As described in the preceding list, this project management
work product captures the risks, assumptions, issues, and dependencies
for the project.
• Review Record.This work product defines, in the context of this
activity, the result of an architecture review.
• Software Architecture Document.This work product provides a
comprehensive architectural overview of the system, using several
architectural views to depict different aspects of the system.
MOVING FROM REQUIREMENTS TO SOLUTION
This chapter is the first time we consider the transition from
requirements to solution. Figure 8.2 is a subset of the work products that
architects consider when making this transition and helps us
demonstrate some simple but important concepts.

Figure 8.2. Key Work Products in Moving from Requirements to Solution

In this figure, you see two of the key requirements work products:
the Functional Requirements and Non-Functional Requirements. You
also see two of the key solution work products: the Functional
Model and the Deployment Model. Some important and fairly obvious
concepts are represented by the arrows (which indicate various
influences) in this figure:

• Functional requirements influence the Functional Model. A use case

that allows an order to be placed requires appropriate functional
elements in the solution that provide this capability, for example.
• Functional requirements influence the Deployment Model. The
interaction between an actor representing a human being and the system
may require the presence of a user workstation in the solution, for
example.
• Non-functional requirements influence the Functional Model. A
particular third-party package that provides some of the functionality
required may be mandated as a constraint, for example.
• Non-functional requirements influence the Deployment Model. An
availability requirement may introduce additional nodes that support
system failover should a system element fail, for example.

Although each of these individual statements is straightforward to

understand, considering all of them simultaneously—and at the same
time ensuring that the Functional Model, the Deployment Model, and
other work products remain consistent—is not. We take a divide-and-
conquer approach in this book by considering each item in turn while at
the same time ensuring consistency across the architecture models.

Different approaches to deriving an architectural solution exist, but their

consideration of all elements sketched in Figure 8.2 is variable. Some
approaches focus on functional requirements, to the exclusion of their
non-functional counterparts. Others focus on the functional solution
elements without considering the equally important deployment
environment. This book places equal emphasis on functional
requirements, non-functional requirements, functional elements, and
deployment elements, because the authors believe that any imbalance
will result in a suboptimal architecture.

Several approaches to deriving an architectural solution exist, and several

are worthy of note. The commonality among several approaches is
discussed in “Generalizing a Model of Software Architecture Design from
Five Industrial Approaches” (Hofmeister 2005), which considers five
approaches. Three are listed here:

• Attribute-Driven Design (ADD) Method, developed at the Carnegie

Mellon Software Engineering Institute. In this approach, quality
attributes (such as availability) are used to drive the derivation of the
architecture and design, at successive levels of decomposition, through
the use of architectural tactics and patterns that satisfy quality attribute
scenarios. For more information, see Software Architecture in Practice,
2nd ed. (Bass 2003). Tactics are discussed in the sidebar “Concept:
Tactics.”
• Siemens’ 4 Views (S4V) method, developed at Siemens Corporate
Research. This approach starts with a global analysis of the factors that
influence the architecture, such as functional requirements, desired
system qualities, organizational constraints, and technical constraints.
The key architectural challenges are identified, and strategies are derived
for addressing these challenges iteratively across four views: conceptual,
execution, module, and code architecture. For more information,
see Applied Software Architecture (Hofmeister 2000).
• The Rational Unified Process (RUP), developed at Rational Software,
now IBM Rational. This approach is driven by the architecturally
significant use cases, non-functional requirements, and risks. Each
iteration considers the key architectural elements of the solution before
realizing the requirements using these solution elements. The solution is
validated in executable software. For an overview of RUP, see The
Rational Unified Process: An Introduction, 2nd ed. (Kruchten 2000).

This book acknowledges the commonality in these approaches, as well as

those practices that we see successful software architects following. Such
practices are discussed in this chapter and in subsequent chapters.

Concept: Tactics

The concept of a tactic is a key ingredient of the Attribute-Driven Design (ADD)

method described in detail in Software Architecture in Practice, 2nd ed. (Bass
2003). Tactics are design decisions that decide how a functional requirement will
be met or how a quality attribute will be resolved. A tactic that addresses
availability might be to introduce redundancy into the system, for example.

This book doesn’t provide a comprehensive catalog of tactics, because this

approach would result in a mammoth publication that covered many kinds of
reusable assets (reference architectures, architectural patterns, design patterns,
and so on), all of which are built around one or more tactics. Instead, we focus on
the method framework, which considers the application of reusable assets in
general (including tactics). As well as the many books on different kinds of
patterns, both Software Architecture in Practice, 2nd ed. (Bass 2003) and Software
Systems Architecture: Working with Stakeholders Using Viewpoints and
Perspectives (Rozanski 2005) provide an excellent grounding in those tactics that
are at the disposal of the architect for addressing specific challenges such as
availability, performance, and usability.

HOW MUCH LOGICAL ARCHITECTURE?

One way to think of a logical architecture is as a rough-and-ready means
of getting, as quickly as possible, from the requirements to a physical (and
technology specific) architecture that can be implemented in code. In this
approach, the logical architecture essentially is throwaway. Alternatively,
you may treat the logical architecture as a strategic asset in its own right
that, as a consequence, is actively maintained. In this approach, the logical
architecture may provide an excellent abstraction of the system that you
can refer to should you want to reengineer your system in a new
technology. In many projects, the approach taken lies somewhere
between these two extremes, where some, but not all, of a logical
architecture is created and maintained. Such considerations are discussed
in this section.

Minimizing Logical Architecture

If the logical architecture is simply a means of getting to a physical

architecture as quickly as possible, you need to produce just enough
logical architecture to demonstrate that you understand the current set of
requirements and that those requirements have been allocated
appropriately to parts of the solution.

In extreme cases, no logical architecture may be required at all. This is

possible in certain situations—when the requirements for the system are
similar to those of an existing system, for example. In this case, it may be
possible to derive major elements of your architecture by looking at the
existing system. Another example is the inclusion of a packaged
application or integration with an existing system; much of what is
required is already provided, thereby minimizing the need for a logical
architecture.

Another factor is the complexity of the system. You may choose to

develop the logical Deployment Model, for example, only if you
anticipate that the system will be highly distributed and that considering
deployment at a logical level will help you rationalize about the
deployment elements at a physical level.

Logical Architecture as an Investment

As well as providing a valuable stepping stone for getting from

requirements to a physical architecture, the logical architecture is
sometimes maintained to provide a good starting point when a
technology change is anticipated. Rather than having to reinvent the
wheel as a result of a technology change, you can use the original logical
architecture (assuming that the system requirements have not changed)
because, in general terms, the logical architecture is technology
independent.

The flip side of minimizing the emphasis on the logical architecture, then,
is considering the logical architecture to be an investment that is immune
to technology change. Therefore, it may make sense, from an investment
perspective, to maintain the logical architecture in anticipation of a
technology change that can support any reengineering of the system in
the future.

When deciding whether to regard a logical architecture as something that

should be maintained moving forward, consider the following questions:

• Is the system large and complex, and is its development likely to

run over a long period?Long-duration projects are more likely to have a
return on investment from investing in a logical architecture.
• Is the system likely to evolve over several releases and potentially
need to accommodate changes in technology over its lifetime?When
making technology changes, often it is useful to refer to a technology-
independent representation of the architecture.
• Will the skills be available to both develop and maintain the logical
architecture?An organization whose staff consists primarily of
developers or programmers may not have people who have the necessary
mindset to think architecturally. If the logical architecture cannot be
developed or maintained because the skills are not available, the initial
investment costs (of training or hiring) will be harder to justify, and
building such an architecture simply may not be possible.

The Importance of Traceability

Whatever approach you take, it is important to understand how work

products are derived from one another, because this knowledge can help
you perform an impact analysis of changing a requirement or an
architecture element. The sidebar “Concept: Traceability” describes what
is meant by traceability and why it is important.

As the architect on the project, you need to consider the extent to which
you want to describe the traceability through the development process
and whether this traceability is explicit (such as adding specific modeling
elements that support traceability, for example requirements realizations,
described later in this chapter) or implicit (such as naming code elements
based on the architecture elements that they implement).

Concept: Traceability

Traceability is the mechanism by which the elements in one work product are
linked to elements in the same or another work product. In terms of a
development life cycle, traceability allows the architect to follow the linkage from,
for example, requirements to logical architecture to physical architecture to code.
Traceability allows you to perform impact analysis of changing a requirement or
the potential impact of optimizing a programming algorithm in terms of its impact
on the system as a whole. Both of these scenarios are supported by considering
how you (explicitly or implicitly) describe traceability in the work products you
create.

APPLYING THE PROCESS

Tasks that support the architecture discipline vary throughout the
development life cycle, as shown in Figure 8.3.

Figure 8.3. Logical Architecture and Iterative Development

The logical architecture tasks are most visible during the Elaboration
phase, where you focus on baselining the software architecture. During
this phase, you concentrate on analyzing those requirements that are
considered to be architecturally significant (that is, those that have most
influence on the architecture). During the Construction phase, you
analyze any remaining requirements, but this work is not as extensive as
that performed during the Elaboration phase, as most of the major system
elements have already been discovered and major technical decisions
made. The time you spend on logical architecture, therefore, tapers off
throughout the Construction phase, as the number of requirements that
you have yet to analyze decreases and the emphasis shifts to
development. You may need to perform some minimal logical
architecture tasks even into the Transition phase as changes to the
requirements are introduced based on feedback received when
transitioning the system to the user, though this situation is unlikely.

CREATE LOGICAL ARCHITECTURE: ACTIVITY

OVERVIEW
Figure 8.4 shows the tasks that comprise the Create Logical
Architecture activity (introduced in Chapter 1, “Introduction”).

Figure 8.4. Overview of the Create Logical Architecture Activity

The tasks can be summarized as follows:

• The purpose of the Survey Architecture Assets task is to identify

reusable architecture assets that can be applied to the system under
development.
• The purpose of the Define Architecture Overview task is to identify
and describe the major elements of the system under development.
• The purpose of the Document Architecture Decisions task is to
capture the key decisions made in shaping the architecture and the
rationale behind them.
• The purpose of the Outline Functional Elements task is to identify the
major functional elements (subsystems and components) of the system
under development.
• The purpose of the Outline Deployment Elements task is to identify
the locations across which the system under development will be
deployed and the nodes within each location.
• The purpose of the Verify Architecture task is to verify that the
architecture work products are consistent and to ensure that any
concerns that cut across the architecture work products (a quality such as
performance, for example) have been addressed consistently.
• The purpose of the Build Architecture Proof-of-Concept task is to
synthesize at least one solution (which may simply be conceptual) that
satisfies the architecturally significant requirements to determine
whether a solution, as envisaged by the architect, if possible.
• The purpose of the Detail Functional Elements task is to refine the
functional elements to the point that they can be handed off to detailed
design.
• The purpose of the Detail Deployment Elements task is to refine the
deployment elements to the point that they can be handed off to detailed
design.
• The purpose of the Validate Architecture task is to validate that the
system as a whole is going to support the various stakeholder requests.
• The purpose of the Update Software Architecture Document is to
document the architecturally significant elements in the Software
Architecture Document.
• The purpose of the Review Architecture with Stakeholders task is to
obtain stakeholder agreement that the architecture, at its current level of
elaboration, addresses the defined requirements.

As we did for the requirements definition activity described in Chapter 7,

“Defining the Requirements,” the activity of creating a logical
architecture includes both outline and detail tasks. The sidebar “Concept:
Outline Tasks versus Detail Tasks” describes why we advocate this
approach for deriving an architecture.

Concept: Outline Tasks versus Detail Tasks

The tasks that focus on functional elements and deployment elements are divided
into those that outline the elements and those that detail the elements. In practice,
the distinction is somewhat arbitrary, and the tasks are often performed together.
Understanding the difference in terms of the content of this book is worthwhile,
however.

In essence, the outline tasks focus on those elements that are most significant to
the architecture and that would be the responsibility of the Lead Architect on the
project. These tasks are where major decisions regarding the solution to non-
functional requirements are made, for example.

The detail tasks focus on those elements that, although important, are less
significant for understanding the overall architecture of the system. Detail tasks
usually are the responsibility of the architect with the relevant focus, such as
the Application Architect, Infrastructure Architect, or Data Architect.

Table 8.1 summarizes the elements in the outline and detail tasks
described in this chapter.

Table 8.1. Elements Considered in the Outline and Detail Tasks

Task: Survey Architecture Assets

PURPOSE
The purpose of this task is to identify reusable architecture assets that can be
applied to the system under development.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect
STEP
• Survey architecture assets.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

As discussed in Chapter 5, “Reusable Architecture Assets,” a key source of

inspiration for the architect is to consider available reusable assets.

One thing expert designers know not to do is to solve every problem from
first principles. Rather, they reuse solutions that have worked for them in
the past. When they find a good solution, they use it again and again. Such
experience is part of what makes them experts. (Gamma 1995)

This task is typically performed several times in the course of an iteration,

because the reuse of architecture assets is always at the forefront of an
architect’s mind, as we discuss in some detail in Chapter 5, “Reusable
Architecture Assets.” You may execute this task following the creation of
the Architecture Overview, Functional Model, or Deployment
Model work products, for example, because these work products may
have identified elements that can be satisfied by an existing asset.

Step: Survey Architecture Assets

An important consideration when you start to work on software

architecture is reviewing what work in this area has been done before
and what you could reuse within your system. Chapter 5, “Reusable
Architecture Assets,” discusses various types of architecture assets and
how these reusable elements can be categorized based on many
attributes, such as their granularity and level of implementation. These
attributes can provide an indication of an asset’s applicability at different
stages of architectural definition.

The extent of asset reuse is dependent on the context within which the
architect is working. In early iterations, architects may select assets that
have far-reaching effects on the architecture. A case in point is the
selection of a reference architecture that defines a broad range of system
elements. Architects also may choose to base their architecture on a
packaged application or to reengineer a legacy system. Again, this
selection has a significant bearing on the architecture. The other end of
the spectrum is selecting a particular set of patterns that may be applied
only to the Functional Model or Deployment Model. Such elements are
typically considered in conjunction with the Outline Functional
Elements and Outline Deployment Elements tasks.

Other assets that may be of relevance are so-called industry vertical

models such as the Insurance Application Architecture (IAA) from IBM
(IAA 2009), which offers a suite of models (including data and process
models) developed to help insurance companies apply information
technology effectively and consistently. These models clearly have an
influence on the models you create.

The mandatory use of assets wherever possible may have been stated at
the enterprise architecture level, in which case the Enterprise
Architecture Principles work product will contain one or more
principles indicating this fact. Table 8.2 shows an example of such a
principle using attributes suggested by The Open Group Architecture
Framework (TOGAF 2009).

Table 8.2. Example Enterprise Architecture Principle

Given the brownfield nature of many development efforts, the existing IT

environment (as documented in the Existing IT Environment work
product) provides an inventory of installed applications, data, and
computing and network infrastructure—some or all of which may feature
in the architecture of your system. (The system may already be using a
particular database package, for example.) Therefore, you review
the Existing IT Environment work product in this task to decide
whether any of the elements described there are potential candidates for
reuse in the new system.

The result of surveying architecture assets and deciding which assets to

use is a particular form of architecture decision and as such is captured in
the Architecture Decisions work product, which is discussed in
the Document Architecture Decisions task later in this chapter.

Task: Define Architecture Overview

PURPOSE
The purpose of this task is to identify and describe the major elements of the
system under development.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect

STEP
• Define architecture overview.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

The Architecture Overview provides a high-level description of the

system under development. The Architecture Overview is not meant to
be a full specification for the architecture from which a system could be
built; it is intended more for information purposes to obtain early
consensus and understanding with the system stakeholders and the
development team.
Very often, something equivalent to an Architecture Overview was
developed during earlier phases of the project (when the initial vision
was described, for example, or when requests for information were being
sent out to vendors). In this case, at the very least you should refer to
these diagrams to ensure continuity and traceability back to the initial
vision.

Step: Define Architecture Overview

The Architecture Overview may touch on several architectural views

but tends to focus on the functional view and deployment view in
conveying the major building blocks of the solution. Other views may be
provided, such as systems management and security, if particular
concerns need to be addressed and clarified at this stage. It also conveys
early working assumptions about the solution and is often treated as an
informal sketch of the system to be. Subsequent tasks (discussed later in
this chapter) result in the creation of the more rigorous and more precise
work products, such as the Functional Model and Deployment Model.

The Architecture Overview usually is structural in nature and tends to

show boxes and lines, with the lines indicating dependencies rather than
interactions among the various elements. If certain interactions are
fundamental to the architecture of the system, these interactions should
be shown, of course. Therefore, several diagrams may actually comprise
the Architecture Overview, with different diagrams representing
different views and stakeholder concerns.

Although we do not recommend a formal notation for describing

the Architecture Overview, we do recommend that whatever notation is
used, it be explained (with a key) and applied consistently so that, for
example, a line with an open-ended arrow means the same thing
wherever it is used. This practice not only aids understanding, but also
enables stakeholders to quickly grasp the key ideas that are being
described by the overview.

The Architecture Overview typically includes a number of notational

“styles” and often contains boxes indicating groupings of functionality as
“components” or “subsystems” and lines separating these boxes that
indicate “layers” or “tiers.” Subsystems, components, layers, and tiers are
all terms that are used when describing architectures and can sometimes
have different meanings. The sidebars “Concept: Subsystem and
Component” and “Concept: Tiers and Layers” describe the meanings of
these terms used in this book.

Where required, the Architecture Overview should reflect any

principles as captured in the Enterprise Architecture Principles work
product. Typical principles that may apply are

• Reuse.This principle implies that existing components must be reused

where applicable.
• Buy rather than build.This principle is discussed in Table 8.2 earlier in
this chapter.
• Single point of view.This principle implies combining multiple data
sources to make it appear as though the relevant data has a single source.
• Separation of concerns.This principle implies that components should
responsible for a cohesive set of business-focused tasks.

Finally, although this task represents a less formal approach to defining a

candidate architecture than the tasks that follow, it acknowledges all
significant requirements, both functional and non-functional. In terms of
non-functional requirements in particular, it represents an initial
consideration in addressing some of the qualities required of the system.
It also accommodates any constraints specified in the requirements, such
as constraints imposed by any existing environment (as in the need to
deploy the system in an existing network), constraints imposed through
the use of external systems (such as integration with a legacy system),
and constraints imposed on the use of defined commercial off-the-shelf
(COTS) software.

Figure 8.5 shows the Architecture Overview for the YourTour system.
This overview has been derived by reviewing the System Context to
understand what the boundary of the YourTour system is, the Functional
Requirements to understand what the major functional areas of the
system need to be, and the Non-Functional Requirements to
understand what qualities need to be addressed and what constraints
need to be complied with. Terms used in these work products should all
be collected in the Glossary.
Figure 8.5. Architecture Overview for YourTour
Concept: Subsystem and Component

A subsystem is a set of related components. In business systems, components

usually are grouped because they collectively support a major business area such
as customer relationship management or account processing. Subsystems may
also be nested, and this topic is discussed in more detail in Chapter 10, “Beyond
the Basics,” where we discuss systems of systems.

[A component is] a modular part of a system that encapsulates its contents and
whose manifestation is replaceable within its environment. A component defines its
behavior in terms of provided and required interfaces. As such, a component serves
as a type, whose conformance is defined by these provided and required interfaces
(encompassing both their static as well as dynamic semantics). (UML 2.0 2003)

We used the following approach when coming up with the Architecture

Overview in Figure 8.5:

• The Presentation Integration subsystem decouples the user interface

devices (web browser on a computer, mobile device, and so on) from the
business functions and performs a translation from generic business
services to user interface–specific protocols.
• We believe that the effective management of content is important for
providing users access to information that enhances their overall
experience of YourTour, such as travel insurance offerings. This content
has suggested the inclusion of a dedicated Content Management
subsystem to create, edit, manage, search, and publish the various kinds
of digital content (that is, images, audio files, video files, electronic
documents, and web content) that will be used by YourTour.
• To facilitate effective decoupling of user interactions from YourTour
business functions, we provide a separate process-control subsystem
(Tour Process Control) that is responsible for controlling the execution of
any business processing logic and that allows the business process to be
changed independently of both the user interface and business services
(which are in the Tour Services subsystem).
• Security is important, as the system is dealing with personal payment
details such as credit card information and other personal details.
Therefore, a dedicated Security Services subsystem is required for dealing
with user authentication and authorization.
• We want to be able to decouple the YourTour application from the
intricacies of the legacy systems, so we added a dedicated Application
Integration subsystem for dealing with these interactions.
• Finally, we drew point-to-point connections between the subsystems we
identified based on known (dictated by any patterns we have adopted) or
obvious interactions. This initial set of point-to-point connections will be
refined as the architecture evolves.
Concept: Tiers and Layers

In addition to the concepts of subsystem and component, two concepts related to

the structural decomposition of a system are tier and layer. On occasion, these
concepts are shown in an Architecture Overview. A tier is used in multitier
architectures where each tier represents a related grouping of processing logic. As
an example, typical three-tier architectures are often divided into presentation
logic, business logic, and integration logic. A tier represents a physical separation
of concerns but to some extent is also a logical partitioning, because the tiers can
be physically distributed in different ways:

• In a single system distribution, the presentation, business, and integration tiers

all reside on the same physical machine.
• In a thin-client distribution, the presentation tier is on the client, but the business
and integration tiers reside on the server.
• In a thick-client distribution, the presentation and business tiers reside on the
client, but the integration tier resides on the server.

Layers are sometimes confused with tiers, but they are not the same thing.
Whereas tiers are abstractions of physical elements, layers are much more general,
and the concept of layering a system conforms to the Layers architectural pattern,
as described in Pattern-Oriented Software Architecture: A System of
Patterns (Buschmann 1996) and elsewhere. In brief, the Layers pattern places
components within layers according to their generality, with the more general-
purpose components (that is, the most reusable components) in lower layers. In
simple terms, the components in any given layer may use the services of
components in the same layer or in lower layers. Layering is said to be strict if
components can communicate only with components in the same layer or the layer
immediately below it and non-strict if components can communicate with
components in the same layer or any lower layer. Either way, a component should
never communicate with components in higher layers, as this situation makes the
component less reusable. Also, it is difficult to switch the component with another
that provides the same interface, for example. Figure 8.6 shows one example of a
layering approach derived from a layering given in Software Reuse: Architecture,
Process and Organization for Business Success (Jacobson 1997).

Figure 8.6. Example of Layers

The responsibility of each layer is as follows:

• The Application-Specific layer contains elements that are specific to the

application in question. The figure implies many applications.
• The Business-Specific layer contains elements that are specific to a business or
application domain (such as financial systems) but that are reusable across
applications.
• The Business-Independent layer contains elements that are independent of the
business or application domain (such as a user interface framework, message bus,
operating system, or database).

Task: Document Architecture Decisions

PURPOSE
The purpose of this task is to capture the key decisions made in shaping the
architecture and the rationale behind them.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect

STEPS
• Capture issue or problem.
• Assess options.
• Select preferred option.
• Document decision.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

To truly understand the architecture of an IT system, it’s very important

to understand the decisions that have shaped the architecture and the
rationale for those decisions. Some decisions are captured explicitly in the
various work products (such as the fact that a component is deployed on
a particular node). Usually, however, several implicit decisions have been
made, and these decisions have had equally significant impact on the
overall shape of the system but are known only to the person who made
the decision. The purpose of capturing architecture decisions, therefore,
is to make explicit what’s in the mind of the architect and to ensure that:

• Decisions have been documented so that stakeholders can understand

why the architecture is the way it is.
• Decisions are realistic and based on a real business need rather than
being purely technology-driven.
• The rationale used in arriving at the decision is evident and can be
reviewed and critiqued by others (including internal and external
auditors, if required).
• The options that are being considered represent a valid and reasonable
set.
• The architect does not have to reinvent the wheel by covering old
ground to justify a long-forgotten decision.
Formally capturing architecture decisions normally is confined to those
key decisions that have shaped the architecture, so a spectrum of
formality is considered. Even in the simplest architectures, however,
several key decisions usually have shaped the architecture, and these
decisions are not obvious to those who must understand or maintain the
system. Explicitly documenting such decisions, therefore, is a valuable
exercise.

Some decisions are time-sensitive and may have a life span that is less
than that of the project within which they are set. A decision may be made
that is short-term and tactical to move the project forward but that needs
to be revisited before the system goes live. In this case, a note must be
made against the decision that it needs to be reviewed by a given date.
Conversely, some decisions are fundamental and may actually outlive the
project that generated them, as they are applicable to other system
development projects within the enterprise. Such decisions are elevated
to the status of architecture principles that are adopted at the enterprise
architecture level.

For a more detailed discussion of architectural decisions, as well as a

template for documenting architecture decisions, refer to the paper
“Architecture Decisions: Demystifying Architecture” (Tyree 2005).

Step: Capture Issue or Problem

An architectural decision usually is made because an issue or problem has

been identified that needs to be addressed. Issues usually are captured in
the RAID Log work product or may have been communicated by
stakeholders or project members verbally or via e-mail. Similarly, certain
concerns are formally expressed as risks, also in the RAID Log.

As a first step in documenting an architecture decision, it is helpful to

capture, clearly and unambiguously, the issue or problem that needs to be
considered. This documentation may be a simple sentence stating the
issue, or it may need to be a longer statement to describe a lot of history
or context. It is worthwhile to give some thought to this step so that there
is no doubt about what is being addressed.
Step: Assess Options

In this step, you decide what options you have to address the issue or risk.
This step may involve looking at patterns (to see how similar problems
have been solved), researching products and packages from vendors (if
the problem could be addressed by procuring a product or package), or
brainstorming alternative approaches (if the problem involves a new or
challenging area).

Step: Select Preferred Option

In this step, you assess each option and decide which one to adopt. You
may need to consider several questions when deciding which option to
select:

• Do any functional requirements, qualities, or constraints suggest one

option over another? Is cost or the project schedule an important factor,
for example?
• Do you need to adhere to any principles, policies, or guidelines, such as
enterprise-wide policies?
• Are some options more risky to adopt than others? Do they use new or
unproven technology, for example, and if so, how willing is the project or
organization to take risks?
• Are the options tactical or strategic? Might some options produce
tactical short-term gains whereas others are longer-term and strategically
significant? You may be able to support a short-term improvement in the
performance of a system by adding more resources to existing machines
(that is, adopt vertical scalability) by adding processors, but in the long
term, it may be better to add machines (that is, adopt horizontal
scalability).
• Is there actually more than one option that could apply? Sometimes,
your decision may not be a case of simply selecting one option. Both
short-term (tactical) and long-term (strategic) options may be applicable.
• Do some decisions have dependencies, either on other decisions or on
the result of some prototyping work being performed to validate the
decision? If such dependencies exist, you should note the situation.
Step: Document Decision

When the decision has been made, the initial problem statement, the
options considered, the decision, and the rationale that led to the decision
are all captured in the Architecture Decisions work product. Table
8.3 shows an example from the Architecture Decisions work product
from the YourTour system.

Table 8.3. Example of a Documented Architecture Decision

Task: Outline Functional Elements

PURPOSE
The purpose of this task is to identify the major functional elements (subsystems
and components) of the system under development.

ROLES
Application Architect, Data Architect (secondary), Infrastructure Architect
(secondary)

STEPS
• Identify subsystems.
• Identify components.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

This task focuses on identifying the functional elements (subsystems and

components) of the architecture and ensuring that the resulting set of
subsystems and components conforms to solid architecture principles. In
this book, we use the term component to represent a main building block
of the system. We should point out that components, as defined in this
book, are not just technical software elements (such as Enterprise
JavaBeans), but also are used in a more general sense to represent the
architectural elements that make up the system. See the sidebar “Concept:
Subsystem and Component” earlier in this chapter for the definitions we
are using.

When this task is complete, several well-structured, logical subsystems

and components will have been defined, together with their relationships
and responsibilities. The subsystems and components may be defined in a
modeling tool (such as a tool that supports the creation of UML models)
or may simply be drawings in a document. When naming functional
elements, we use any relevant terms defined in the Glossary.

Step: Identify Subsystems

The initial set of subsystems can be derived from the Architecture

Overview work product. Figure 8.7 is an example of a UML component
diagram showing the logical subsystems and their dependencies for the
YourTour system—the highest-level view of the YourTour architecture.
Each of these subsystems contains one or more components that
collaborate to support the functionality required by the system.
Figure 8.7. YourTour Logical Subsystems

We derived the content of Figure 8.7 by simply transposing the informal

notation of the Architecture Overview into UML. As a technique for
identifying subsystems, this technique is as good as any. Had we not had
an Architecture Overview at the level of detail we developed for
YourTour, we would have had to apply some of the following techniques
for identifying subsystems:

• Review the Functional Requirements work product, and look for

requirements that are either already grouped or that could be.
Requirements that deal with all aspects of customer management might
suggest a customer relationship management subsystem, for example.
• Review the Enterprise Architecture Principles, Non-Functional
Requirements, and Existing IT Environment work products to see
whether any constraints suggest particular technologies (application
servers, message brokers, systems management support, transaction
handlers, and so on). At this level of the architecture, these technologies
can be identified as separate subsystems.
• Review the Business Entity Model, and look for groupings of related
business entities that might be managed by a group of related
components. Grouping the entities that deal with tours suggests a Tour
Services subsystem, for example.

Step: Identify Components

When describing the logical architecture, we identify the components,

their responsibilities, and the collaborations among them—all driven by
the stated requirements (logical architecture components are described
in the sidebar “Concept: Characterizing Logical Architecture
Components”). This approach was made popular through the CRC
(Classes-Responsibilities-Collaborations) technique devised by Rebecca
Wirfs-Brock (Wirfs-Brock 1990). Based on that technique, we consider
the following for each component:

• What the component knows (the data it owns or manages)

• What the component does (the behavior it exhibits)
• What the component asks other components to do on its behalf (that is,
the components it needs to collaborate with to perform some function)

Identification of components is based on an analysis of the Business

Entity Model, Functional Requirements, Non-Functional
Requirements, Business Rules, Existing IT Environment,
and Architecture Decisions work products. Each of these work products
is considered in the following discussion, which describes how they were
used to develop the Functional Model for the YourTour system. Although
we discuss these work products in a particular sequence, in practice we
would tend to consider them and any associated techniques together. In
addition, we would consider any Architecture Proof-of-Concept that
had been created.

Concept: Characterizing Logical Architecture Components

A logical architecture encompasses different aspects of the system, as reflected in

the different types of components. In many situations, considering three types of
components (Jacobson 1992) can help you “divide and conquer” your work during
the development of a logical architecture:

• Boundary (or presentation) components.These components support the

boundary between the system and items outside the system with which the system
interacts, such as end users or external systems. Boundary components typically
invoke Control components.
• Control (or execution) components.These components support the control
logic of the system as well as the business rules and other logic required to satisfy
the functional requirements. Control components typically invoke Boundary
components, Entity components, and other Control components.
• Entity (or data) components.These components support the representation of
persistent information. Entity components typically invoke other Entity
components.

When representing these different types of components in UML, you may also
choose to use a UML profile that includes stereotypes for each. The notation used
is shown in Table 8.4.

Table 8.4. Component Types Used in the Logical Architecture

Business Entity Model

A Business Entity Model can be used to identify components by

clustering related entities and then assigning a managing component for
each cluster. Figure 8.8 shows a subset of elements from the Business
Entity Model of the YourTour case study—those that manage tour-
related information. The entities Tour, Tour Category, and Tour Location
are grouped in the figure and assigned to the Tour Manager component
that manages these entities. You can say, therefore, that one of the
responsibilities of Tour Manager is to manage the data related to a tour.
Other responsibilities may be assigned to Tour Manager as the architect
does further analysis of the requirements and determines what additional
processing the Tour Manager component must support to contribute to
meeting the functional requirements. The Tour Manager component
resides in the Tour Services subsystem.
Figure 8.8. Identifying Components from a Business Entity Model
Functional Requirements

Analysis of the architecturally significant Functional Requirements is

one of the most robust ways of identifying components. Assuming that
use cases are your primary means of capturing functional requirements,
you can analyze them to identify components, focusing on the highest-
priority use cases first. The prioritized requirements are determined from
the Prioritized Requirements List, as discussed in Chapter 7, “Defining
the Requirements.” This discussion uses the Book Tour use case as an
example. The context of the Book Tour use case is shown in Figure
8.9 (which is reproduced from Figure 7.7 in Chapter 7).
Figure 8.9. The Context of the Book Tour Use Case
Table 8.5 (which is reproduced from Table 7.10 in Chapter 7) shows the
main flow of events of the Book Tour use case. When analyzing use cases
in this manner, you may consider only a subset of the flows of events,
depending on the objectives of the current iteration. This example
considers only the main flow of events in the Book Tour use case.

Table 8.5. Main Flow of Events of the Book Tour Use Case
When identifying logical components (and their responsibilities) by using
the functional requirements, you proceed as follows:

1. Define an interface (boundary) component that will handle

requests from, and send responses to, the primary actor of the use
case. For the use case Book Tour, you would define a Tour Booker
interface component.
2. Where an external system needs to be invoked to get or send data,
create a boundary component that deals with the interface to that
system. For the Book Tour use case, you would define a Reservation
System boundary component for dealing with the external
reservation system and a Payment Engine boundary component for
dealing with the payment system.
3. Define a controller component with the same name as the use case
that will handle overall control of that use case. For the Book Tour
use case, you would create a Book Tour controller component that
is responsible for execution of the Book Tour use case.
4. For each step in the use case that requires an actor to system
interaction, assign a responsibility to the controller component to
manage that interaction. For the Book Tour use case, you would
assign responsibilities for obtaining a list of valid tours and
selecting the appropriate tour, adding participants to a tour, adding
travel options for each participant, and obtaining payment details
(which results in accommodation and transportation reservations
being placed).
5. Some steps imply use of data, often indicated by the nouns in the
use case (Tour, Tour Booking, and so on). For such data elements,
create an entity component that is responsible for managing related
data. The Book Tour use case needs a Tour Manager entity
component to manage tour data and a Tour Booking Manager entity
component to manage tour booking data.
6. Repeat steps 1 through 5 for each use-case flow of events being
considered in the current iteration. As you do, you may identify new
components or add responsibilities to an existing component.

The result of applying these steps to the Book Tour use case is shown
in Figure 8.10. The dependencies among elements are also derived from
the use-case flow of events.
Figure 8.10. Components Derived from the Book Tour Use Case
These components are related to the subsystems identified earlier in this
chapter, as follows:

• The Tour Booker Boundary component resides in the Presentation

Integration subsystem.
• The Payment Engine Boundary and Reservation System Boundary
components reside in the Application Integration subsystem.
• The Book Tour Controller component resides in the Tour Process
Control subsystem.
• The Tour Manager and Tour Booking Manager components reside in the
Tour Services subsystem.

Components usually are allocated to subsystems because they

are functionally related and therefore create a cohesive subsystem (the
reason for grouping Tour Manager and Tour Booking Manager) or
because they are technically related and create a subsystem that is likely
to be deployed to the same run-time platform (the reason for allocating
controller, system interfaces, and user interface components together).

You can derive additional responsibilities on components by explicitly

modeling the interactions between components to realize the flows of
events in each use case. The result is the assignment of responsibilities to
the components that respond to a particular message. Figure 8.11 is a
sequence diagram for the main flow of the Book Tour use case, showing
how the components collaborate to satisfy the use-case description
in Table 8.5 earlier in this chapter.

Figure 8.11. UML Sequence Diagram for the Book Tour Use Case (Main Flow)

It is also good practice to ensure components can be traced back to the

requirements from which they are originated. The sidebar “Best Practice:
Trace Solution Elements to Requirements” shows one way of doing this
using the UML.

We should emphasize that this approach will result in a first cut at

identifying components and their responsibilities. Components may need
to be refactored several times to ensure that they are well architected.
Although there is no definitive measure of what makes a well-architected
component, adhering to the principles of high cohesion and loose
coupling, and also ensuring that components are defined at the correct
level of granularity (as discussed in the sidebar “Concept: Component
Quality Metrics”) are both ways of ensuring that components are well
architected.

Non-Functional Requirements

Consideration of functional requirements in such a rigorous manner is

only half the picture, so it’s surprising how many development methods
stop there. This often results in systems that are functionally correct but
that fail to provide the required qualities. Another source that helps shape
architects’ understanding of the required components and their
associated characteristics is the system’s non-functional requirements, as
captured in the Non-Functional Requirements work product. In this
section, we consider both the desired qualities that the system must
exhibit (such as performance and availability) and any constraints (such
as mandated technologies, the use of third-party components, and the use
of existing legacy systems) that the system must accommodate.

Such considerations may result in the identification of new components.

The YourTour system has a testability requirement—“The system will
allow the content of any transactions to be logged in order to allow all
transactions and their payload to be validated”—that results in a
transaction logging component being identified and added to the Tour
Services subsystem. Similarly, the YourTour system has an integration
constraint—“The YourTour system will make use of YourTour’s existing
customer relationship management (CRM) system for storing customer
information.” This constraint results in a component being added to
manage the interface with the CRM system that is added to the
Application Integration subsystem. Figure 8.13 shows the components
identified as a result of these examples.

Best Practice: Trace Solution Elements to Requirements

When considering the requirements and how they are satisfied in the solution,
often it is beneficial to trace the solution explicitly back to the requirements they
address. This traceability can help you determine the impact of changing the
requirement. Figure 8.12 shows the concept of a requirement realization that
shows this traceability. A requirement realization is a stereotyped UML
collaboration that simply indicates which solution elements collaborate to satisfy a
particular requirement. In Figure 8.12 the solution elements that realize the Book
Tour use case are those contained in the Participants UML component diagram
and which interact as shown in the Main Flow of Events UML sequence diagram.
References to these diagrams are shown as UML notes in Figure 8.12. By
convention, the requirement realization has the same name as the requirement it
realizes.

Figure 8.12. Requirement Realization for the Book Tour Use Case

The concept of a requirement realization can also be applied to the realization of

non-functional requirements, as described in the following section. In addition, a
requirement realization may refer to diagrams that show deployment elements
(rather than functional elements) and how they, too, realize functional and non-
functional requirements.

Tracing from the solution back to the requirements (functional and non-
functional) can be time-consuming to set up and maintain. On relatively small
projects, it may be possible to develop a simple form of traceability using a
spreadsheet. The traceability defined with this approach can be difficult to
maintain, however. A better solution, which is certainly applicable for large or
complex projects, is to use appropriate development tools that provide explicit
support for tracing between solution elements and the requirements they realize
and for maintaining this information.

Concept: Component Quality Metrics

The software quality metrics of coupling and cohesion, as applied to computer

programs, were first proposed by W. P. Stevens (Stevens 1974) as a way of
reducing the maintenance and modification costs of software.

Cohesion is a measure of how well the responsibilities that are attributed to the
component are related to one another. High cohesion (a component with a set of
closely related responsibilities) is considered to be good; low cohesion (a
component with a set of poor or unrelated responsibilities) is considered to be
bad. High cohesion is good because it makes the architecture easier to understand.
Maintenance is also likely to be easier, as changes will be localized to a single
component rather than being spread throughout the system. Also, components are
more reusable if they exhibit high cohesion because it is more likely that a
functionally related set of responsibilities will be used as a whole than if a random
set of responsibilities were provided by a component.

Coupling is related to cohesion; it is an indication of the strength of the

associations between components. Strongly coupled components have tightly
bound associations, and the components are highly dependent on one another.
Weakly coupled components, however, have very loose (or even non-existent)
associations. Weak (or loose) coupling is better than strong (or tight) coupling
because it is easier to switch one component for another or to update a component
without affecting others. Weakly coupled components are likely to be more
reusable than strongly coupled components because, by definition, they can be
extracted from one system and inserted into another more easily.

Granularity is anaother quality metric, is a measure of the size or amount of

functionality assigned to a component. The architect needs to understand the
context within which a component exists before making an assessment of the
granularity of the component. At one extreme, the system as a whole may be
represented as a single component and, in the context of the business processes
that it supports, may be wholly appropriate. At the other extreme, the system may
consist of many fine-grained components, and again, this may be appropriate in a
given context. An interesting discussion of the different levels of granularity in
which components may exist is given in Business Component Factory (Herzum
2000). This book discusses not only simple utility components, but also
components that are designed to support a distributed environment as well as all-
encompassing business components whose elements span the different tiers of a
distributed environment.

Consideration of non-functional requirements may not only result in the

identification of new components, but also lead you to refine components
by indicating that certain qualities may be addressed by a particular
component (or, more likely, a group of components), and you may refine
the component specification accordingly. Specifically, you may derive the
non-functional requirements that apply to a particular component. To do
so, you look at each non-functional requirement in turn and, based on the
components that have been identified, allocate requirements across them.
An example is given in Table 8.6.

Table 8.6. Assigning Non-Functional Requirements to Components

If you are using UML to capture this additional information, it is
appropriate to create a UML profile that allows this additional
information to be captured. A UML profile is an extension mechanism that
allows, among other things, additional properties to be allocated to
standard UML modeling elements (based on the application of UML
stereotypes).

When allocating non-functional requirements to components, take care

that each component is capable of supporting the stated requirements,
especially when the component may depend on an external service to
fulfill its responsibility. In Table 8.6, the three-second requirement for
processing the payment is dependent on the ability of the Payment
Engine (an external system over which you may not have control) to
complete its processing within that time. The architect needs to
understand what organizational or even commercial agreements are in
place to manage and monitor this situation.
Figure 8.13. Components Derived from the YourTour Non-Functional Requirements

Architecting a solution to meet potentially conflicting non-functional

requirements involves resolving opposing forces, as discussed in Chapter
2, “Architecture, Architect, Architecting.” Often, two or more solutions
exist, each with their pros and cons in terms of cost, feasibility, and so on.
When considering which option to take, it is helpful to use
the Architecture Decisions work product to capture all the options and
the rationale behind the chosen approach.
Business Rules

Consideration of business rules, as captured in the Business Rules work

product, may also result in components being identified. In the YourTour
system, several rules relate to the management of tours and how they are
booked. It is reasonable to assume that these rules may change over time,
and so you may choose to separate the rules into a rules component,
which you place inside the Tour Services subsystem. Then all components
inside that subsystem use the rules component to access the current
rules, as shown in Figure 8.14.

Figure 8.14. YourTour Business Rules Component

For a discussion of the placement and representation of business rules,

see the sidebar “Concept: Placement and Representation of Business
Rules.”

Concept: Placement and Representation of Business Rules

Placement of business rules can be facilitated by considering the following

questions:

• Is the business rule likely to change frequently? The answer dictates how
much flexibility needs to be provided for updating the business rule. A business
rule that is likely to change frequently is best assigned to a component that is
dedicated to implementing that business rule.
• Does the business rule apply in many scenarios, or is it specific to a
particular use? The answer dictates which component, or set of components, the
rule gets assigned to. A business rule that needs to be reused in many scenarios is
best assigned to a separate component that is invoked accordingly. A business rule
that is used in only one scenario is best placed with the component that requires
this business rule to execute.
• Does the user of the application need to have visibility of the business
rules? If so, you may need to allow aspects of the business rule to be made visible
in the user interface. In a loan application, for example, the basis on which a loan is
given may be provided to the end user (the requester must be over 18 years of age,
for example). Similarly, a system administrator may require the ability to change
business rules, which requires an interface to access the business-rule definitions
to allow such changes to be performed.
• Where does the data used by the business rule reside? The answer dictates
where the components that handle the business rule need to be located in relation
to the data that the rules need as input. This consideration is particularly
important in a distributed system, where network latency has a major impact on
the performance of the system.
• Is the business rule likely to have an impact on system
performance? Sometimes business rules have a hidden or unexpected impact on
system performance, and you should consider this impact when placing rules. A
rule to determine a person’s creditworthiness, for example, might review that
person’s credit history for the past two years. A regulatory change may cause the
check to be done over ten years, and suddenly the performance of the system is
affected because the credit engine is doing five times as much work.
• What middleware components are available, or are being mandated, to
manage business rules? If a rules engine is being proposed as part of the system,
you can represent the engine as a separate component. (The specific rules engine
itself will be selected when the physical architecture is defined.) A rules engine
generally provides the ability to define, manage, and run business rules, and
almost certainly mandates where and how to place such rules.

Two of the key objectives in placing business rules on components should be to

keep the business logic in one place (to support ease of maintenance) and, as far as
possible, to prevent it from being duplicated in different parts of the system. It is
not always possible to achieve this ideal, given other system characteristics. In a
client–server environment, for example, business logic may be distributed
between the client (such as field-level validation of data) and the server (such as
business processing logic).

In terms of representing business rules, you have several options in the logical
architecture:

• Business rules may be specified as algorithms that calculate results or

manipulate or check data in some way. The rule Validate Credit Card Number
would apply the standard algorithms issued by credit card agencies to check
whether a credit card has the right form.
• Business rules may be specified as relationships between components, such as
“An order must have one or more line items.”
• Business rules may be specified as invariants or constraints on the data managed
by a component, such as “An order number has to be eight characters in length.”
• Business rules may be specified as preconditions and postconditions on an
operation signature, such as “An order amount must be less than $200.”

A discussion of principles that apply specifically to business rules is given

in Business Rules Applied (von Halle 2001). These principles are referred to as the
STEP principles (Separation, Trace, Externalize, and Position). The principles refer
to the separation of rules from other components, externalization of business
rules, traceability of rules to their origin, and positioning rules for change.

Architecture Decisions

Architecture decisions (as documented in the Architecture

Decisions work product) capture important decisions that have been
made and that may dictate key structural and relational aspects of the
architecture. Architecture decisions may identify a particular product or
package that needs to form part of the architecture and therefore
influences the components being identified. You may have decided to use
a particular security component provided by an external vendor, for
example. You should also acknowledge any reusable assets that may have
been selected, as discussed in the Survey Architecture Assets task.

Confusion can exist about where or how to represent existing

components in a logical architecture. Although it is important to capture
the fact that an existing (physical-level) element is to be used, it is equally
important not to confuse logical- and physical-level elements in the same
model. The recommended approach in this case is to abstract the
physical-level element for the purpose of representing it in a logical
manner while at the same time making a note that the actual
implementation of this component has already been decided.

Suppose that a decision has been made that the Acme Message Broker
will be used as the messaging bus. To represent this decision in a
logical Functional Model, you could abstract it to a component called
Message Bus and make a note that the implementation will be the Acme
Message Broker.
Along with all the other components exemplified thus far, the Message
Bus component is shown in Figure 8.15, together with the layers that
comprise the YourTour architecture, which are derived from the layering
given in Software Reuse: Architecture, Process and Organization for
Business Success (Jacobson 1997) and discussed in the earlier sidebar
“Concept: Tiers and Layers.” You can also show the subsystems that
contain these components in a similar diagram, if required.
Figure 8.15. YourTour Components Aligned with Layers

Task: Outline Deployment Elements

PURPOSE
The purpose of this task is to identify the locations across which the system under
development will be deployed and the nodes within each location.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect

STEPS
• Identify locations.
• Identify nodes.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

Any moderately complex IT system architecture consists of several

disparate computer platforms (end-user desktops, midrange servers,
mainframe computers, web and application servers, database servers,
and so on) that typically are distributed across one or more locations.
These locations may simply be different rooms or floors in the same
building or different buildings at a single site, or they may be
geographically distributed sites around the country or even the world.
The challenge, then, is to decide what computer platforms need to be used
and which locations they should be placed in. The purpose of this task is
to identify the locations across which the computer platforms will be
distributed and the computer platforms themselves on which the
components will be placed.

In this book we adopt the systems engineering philosophy of treating

software and hardware as peers as discussed in the sidebar “Concept:
Software Engineering and Systems Engineering.”

In this task, you are identifying logical locations and nodes. You could
refer to “a branch office” that might be refined later, when you consider
the physical architecture, into actual locations such as “the New York
branch office” or “the Tokyo branch office.”
An initial set of deployment elements may be derived from
the Architecture Overview. As for functional elements, deployment
elements are named, where appropriate, according to the terms defined
in the Glossary.

Concept: Software Engineering and Systems Engineering

As touched on in Chapter 2, “Architecture, Architect, Architecting,” the systems

engineering field considers a system to comprise software, hardware, information,
and workers. When deriving a solution, systems engineers make trade-offs
regarding the use of software, hardware, and people. If performance is key, a
decision may be made to implement certain system elements in hardware rather
than software or people. Another example is that to provide a usable system to
customers, a decision is made to provide a customer interface that is a human
being rather than an interface implemented in software or hardware. More
complex scenarios require certain system qualities to be achieved through a
combination of software, hardware, and people. Accordingly, this book refers to
elements other than software where appropriate.

It is interesting to note that systems engineering is specifically concerned with

treating software and hardware (as well as people) as peers, thus avoiding two
kinds of pitfalls: (1) Hardware is treated as a second-class citizen to the software
and is simply a vehicle for executing the software, and (2) Software is treated as a
second-class citizen with respect to the hardware and is simply a vehicle for
making the hardware function as desired.

This approach taken in the Outline Deployment Elements task is analogous to

the Outline Functional Elements task, in which you consider the architecture in a
technology-independent manner. At this stage, you don’t know whether a branch
office will be physically implemented as a store, as a country-specific website, as a
person with a phone, and so on. All you know, when considering the logical
architecture, is that a set of capabilities needs to be offered.

The field of systems engineering would take a very broad view of how such a
location could be implemented physically. The location could contain any
combination of software, hardware, people, and information. This book focuses on
software-intensive systems, however. As you will see in the examples, this book
assumes that a location is ultimately implemented as a physical geographic
location containing physical computing resources on which software is deployed.

In the field of systems engineering, in which a system comprises hardware and

people as well as software, it is well understood that some qualities, such as
scalability, are achieved through a combination of software and hardware.
Therefore, you should consider these two aspects together when addressing the
requirements. The Outline Functional Elements and Outline Deployment
Elements tasks are considered separately in practice, however, so that the
architect can focus on the practices that are specific to these two aspects of the
architecture. The danger is failing to consider software and hardware as two sides
of the same coin. The Verify Architecture task is introduced specifically to ensure
the alignment of functional and deployment elements and to ensure that, together,
they address all requirements in a consistent manner—both functional and non-
functional.

Step: Identify Locations

In this step, you review the relevant input work products to identify the
locations that the system under development is to be distributed across.
Identification of locations is based on an analysis of one or more of the
following work products:

• The Architecture Decisions work product may suggest the use of

additional reusable assets (beyond those identified in the Existing IT
Environment) that are to be used in a particular location. (A decision
may have been made to interface to a mainframe program located in a
particular city, for example.)
• The Enterprise Architecture Principles work product may contain
principles that can be adhered to only if particular locations are used or
created. A principle of business continuity may state that operations must
be maintained in spite of system interruptions or exceptional (disaster)
incidents, which certainly implies the use of a separate disaster-recovery
location.
• The Existing IT Environment work product may contain elements that
you choose to incorporate into your architecture; these elements may
suggest particular locations.
• The Non-Functional Requirements work product may identify
constraints that mandate a particular location for certain aspects of the
solution (“The call center must be located in our central office,” for
example). In addition, certain qualities that the system must exhibit, such
as availability, may suggest locations such as the need for both primary
and secondary disaster-recovery locations.
• The System Context work product identifies the location of any actors,
whether these actors are people or external systems.
The initial locations identified for the YourTour system as a result of
considering the various inputs are shown in the topology in Figure 8.16.
This figure shows a Remote Office location where customers and tour
organizers can access the YourTour application from an Internet-enabled
device, a Branch Office location where Customers and Tour Organizers
can meet with a Sales Clerk to book a tour, a Central Office where
information from all remote offices and branch offices is consolidated, a
MyPay Data Center that houses the MyPay payment system, and a
MyReservation Data Center that houses the MyReservation reservation
system. Although the MyPay Data Center and MyReservation Data Center
are not within your direct control, you may need to deploy elements of
the YourTour solution in these locations to facilitate integration with the
relevant systems, which is why they are included. This will be confirmed
(or otherwise) as you develop the detail of the integration solution.
Figure 8.16. Locations in the YourTour System

Step: Identify Nodes

Having identified the locations, you move on to the identification of the

nodes that will reside in each of the locations and on which components
will eventually be deployed. At this stage, nodes are purely logical
containers with no technology or product-specific attributes identified
(unless specific constraints that have been mandated are noted). You
concern yourself with such detail when you consider the physical
architecture.

In the step, the architect reviews all available inputs to identify the nodes
that the system under development is to be distributed across.
Identification of nodes is based on an analysis of, in particular,
the Functional Requirements, Non-Functional
Requirements, Functional Model, Existing IT Environment,
and Architecture Decisions work products. These work products are
discussed in the following sections. In addition, you may consider
any Architecture Proof-of-Concept that has been created.

Functional Requirements

The Functional Requirements work product helps you understand who

the system actors are and the functionality that each actor requires. Given
this information, you can determine what computing resources are
required to support the execution of the system.

Non-Functional Requirements

The Non-Functional Requirements work product may suggest the need

for particular qualities of service, or different levels of service for a given
quality, to be exhibited by the system. This suggestion then implies the
need for different nodes to be introduced. The derivation of qualities that
each node must exhibit can follow an approach similar to that taken for
components, in which you consider each non-functional requirement in
turn and allocate requirements to nodes as a result.

Existing IT Environment

The Existing IT Environment work product identifies nodes that already

exist and which may be used to support the execution of components of
the system under development, either new components that are built or
existing components that are interfaced to as part of the solution.
Functional Model

The Functional Model work product identifies the components to be

supported by the deployment environment, which may suggest the need
for particular computing resources.

Architecture Decisions

The Architecture Decisions work product may suggest the use of certain
nodes. As an example from the YourTour system, Figure 8.17 shows
nodes placed in the Central Office location. This figure is based on the
assumption that, for now, all tour-related components (both tour process
control and tour services) will be added to one logical server: the Tour
Booking Server. You may change this decision later as you refine the
architecture based on your understanding of the requirements, the extent
to which you have met all the requirements (especially those related to
qualities), and the results of the execution of any architecture proof-of-
concept that has been created.

Figure 8.17. Nodes Assigned to the Central Office Location

In addition, the Content Management Server will host a content

management application. A separate server is used for content
management for security reasons and also because content development
has different availability requirements. Specifically, content needs to be
developed only during normal working hours, whereas the Tour Booking
Server has much more stringent availability requirements.

The Security Server contains specific security-related software, and you

anticipate that this capability will need to be separated physically from
components on other nodes. Similarly, a separate Integration Server is
provided to accommodate any specific integration software required.

Task: Verify Architecture

PURPOSE
The purpose of this task is to verify that the architecture work products are
consistent and to ensure that any concerns that cut across the architecture work
products have been addressed consistently.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect

STEPS
• Plan verification.
• Hold kickoff meeting.
• Perform individual verification.
• Hold verification meeting.
• Perform rework.
• Perform follow-up.
ROLE OF THE ARCHITECT
• Leading the verification of the architecture to ensure that architecture work
products are consistent.
• Ensuring that any concerns that cut across the architecture work products (a
quality such as performance, for example) have been addressed consistently.
• Ensuring that all defects discovered during the verification are addressed
without breaking the overall architecture.
• Ensuring that any architecture decisions that come out of the verification
exercise are captured.

The architecture work products can get out of step for various reasons,
such as the fact that they sometimes are developed by different roles.
The Functional Model is developed by the Application Architect, for
example, whereas the Deployment Model is developed by
the Infrastructure Architect. Although you may feel that you’ve
addressed certain aspects of integration to external systems in
the Functional Model, these assumptions may be invalidated by
decisions made with respect to the Deployment Model.

The purpose of this task, therefore, is to look at each architecture work

product in turn to ensure consistency with any related work products
before you move on to provide additional details, as discussed in
the Detail Functional Elements and Detail Deployment
Elements tasks. This task should ensure that any concerns that cut across
the architecture work products (such as security concerns) have been
addressed consistently. In examining this alignment, you also refer to the
requirements work products, especially the System Context, Functional
Requirements, and Non-Functional Requirements work products.
Verification is different from validation which focuses on the system as a
whole rather than individual work products. See the sidebar “Concept:
Verification and Validation” for a discussion on both of these techniques.

It is worth noting that the set of work products considered in this task
extends beyond the core Functional Model and Deployment
Model work products to consideration of the Architecture
Decisions and Architecture Proof-of-Concept work products, because
any decisions that have been made and any results gleaned from a proof-
of-concept must also be consistently applied across the architecture work
products.

Concept: Verification and Validation

In this book, we use the terms verification and validation as defined by the
Software Engineering Institute (SEI) in its approach to establishing software
maturity models (Ahern 2008).
Verification allows the architect to determine whether the work products, at the
current point in the overall development process, are consistent with the inputs
used to create them (such as other work products and any development standards
that have been mandated). In general terms, verification helps you detect defects
in the work products early and therefore prevent later rework. Verification helps
you answer the question “Am I building the system right?” Techniques that
support verification include inspection of work products, tracing from solution
components to requirements, and using the automatic verification tools that are
available in some modeling environments.

Validation focuses on the system as a whole rather than on individual work

products. It is concerned with ensuring that the system satisfies the stated
requirements. Validation helps you answer the question “Am I building the right
system?” In other words, does the system satisfy the stated requirements, or has
something else been built? This process includes consideration of both functional
and non-functional requirements, including the important constraints of time,
budget, and resources. Validation typically is performed by reviews with subject-
matter experts and stakeholders, as well as black-box testing.

One of the goals of verification is to find and remove any defects present
in work products. Many techniques exist for achieving this goal, such as
reviews, walk-throughs, and inspections. The level of ceremony
attributed to this task depends on many factors, especially the complexity
of the architecture. At one end of the spectrum, this task can be a
relatively simple informal review that involves the architect looking at the
architecture work products, noting any inconsistencies, and correcting
the work products accordingly. At the other end of the spectrum, you
apply a rigorous technique for systematically walking through each
architecture work product in turn, and this approach is the one described
here. Our assumption is that the technique described here can easily be
varied for any given situation and scaled down as necessary.

The technique is based on the concept of an inspection and involves

checking a given work product against related work products (such as
those that were input to its creation). In addition, a checklist may be used
to aid the reviewer. In inspecting the Deployment Model, the reviewer
might use a checklist item to ensure that all components in
the Functional Model (an input to the inspection) have been placed on
nodes in the Deployment Model, for example.

The steps in this task follow the classic inspection process first suggested
by Michael Fagan (Fagan 1976) and are shown in Figure 8.18, adapted for
the purposes of performing inspections of architecture work products.
For a more complete description of the inspection process as it refers to
software development, refer to Software Inspection (Gilb 1993).
Figure 8.18. Verification Steps

Step: Plan Verification

Thorough planning is essential to the success of an architectural

verification. All work products to be verified are gathered, all participants
are identified, and a decision is made as to how the participants will be
briefed (via e-mail or a kickoff meeting, for example).

Step: Hold Kickoff Meeting

This step is optional but is performed if the participants are unfamiliar

with the concept of inspections, their roles in the inspection, or the
material to be inspected. The idea is to provide the team members some
background on the materials to be inspected. Participants may be given
checklists to help focus their comments, because each participant is asked
to look at particular aspects of the work products involved.

Step: Perform Individual Verification

The participants are sent or given the material that they are to inspect,
and then spend time inspecting the work products and making note of the
defects they discover. The time required to do this clearly varies
depending on the size of the work products being inspected. Although this
exercise may seem to be very heavyweight, finding defects early can
reduce rework. To assist in the inspection of work products, participants
can be given checklists that identify specific things to look for.
Step: Hold Verification Meeting

The purpose of this meeting is to formally record and categorize all

defects, as well as other issues or questions, identified during the
individual verifications. Having a separate meeting to verify the
architecture nearly always leads to additional defects being discovered
jointly by the group that were not discovered individually. Verification
meetings are not the place to solve problems or discuss issues; they are
simply a means of focusing on the recording of defects in a Review
Record. For a verification meeting to run smoothly, it usually needs to be
run by an experienced moderator who can quickly shut down discussions
that are likely to arise when technical people (who like to solve problems)
gather.

Step: Perform Rework

Rework is the step of the verification task in which the defects found
during the verification meeting are resolved by the author. The relevant
work products are updated accordingly. It is also wise to understand the
likely cause of the defect and where in the process the defect was most
likely caused, so that the development process is improved as a result. If
the rework is extensive, the process may start again by returning to the
“Plan verification” step.

Step: Perform Follow-Up

The follow-up step ensures that all the defects found in the verification
meeting have been corrected. The moderator is responsible for verifying
that this is indeed the case.

Task: Build Architecture Proof-of-Concept

PURPOSE
The purpose of this task is to synthesize at least one solution (which may simply
be conceptual) that satisfies the architecturally significant requirements to
determine whether such a solution, as envisaged by the architect, exists.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect

STEPS
• Create architecture proof-of-concept.
• Document findings.
ROLE OF THE ARCHITECT
• Initiating the proof-of-concept and establishing the ground rules and scope of the
proof-of-concept.
• Working closely with any product vendors to give them clear guidance on what is
required of their product for the purposes of the proof-of-concept.
• Collating and interpreting the results of the proof-of-concept and for reporting
them back to stakeholders.
• Making any architecture decisions based on the results obtained from the proof-
of-concept.

The purpose of creating an Architecture Proof-of-Concept is to reduce

risk. This work product can take many forms, ranging from a list of
known technologies that seem appropriate to the solution or a simple
sketch of a conceptual model of a solution to an executable prototype.

For those architectures whose characteristics cannot be determined on

paper (or in models) and for which some form of empirical evidence is
required to satisfy the architect that certain architectural assumptions do
(or do not) hold, the Architecture Proof-of-Concept takes the form of
executable software. An example of when an executable prototype is
needed is when you need to determine the end-to-end performance of the
system, which theoretically can be calculated on paper but is best
determined by executing software on an infrastructure that is
representative of that envisaged in the solution. Considerable effort and
cost may be involved in producing a proof-of-concept, so it should be
done only when the risk is considered sufficiently great that not
mitigating the risk is likely to lead to even more cost later on.
The results from building and running the Architecture Proof-of-
Concept are documented and used to validate the assumptions or decide
which options are more feasible than others when more than one could
apply.

Step: Create Architecture Proof-of-Concept

An Architecture Proof-of-Concept is created for many reasons,

including the following:

• The functional requirements are novel or challenging. You may be

introducing new business function or processes into your organization,
for example.
• Particularly demanding qualities are demanded of the system under
development, such as high levels of availability or extremely fast response
times.
• New or unproven technologies (at least as far as the development team
is concerned) are required, such as new commercial-off-the-shelf (COTS)
packages.
• New standards are to be adopted.
• Interfaces to existing systems are complex or undocumented.
• New development tools are to be used, and you need to prove that
development can proceed with this tooling.

The inputs to this task reflect these different considerations and therefore
include the Functional Requirements, Non-Functional Requirements,
and Prioritized Requirements List work products, as well as
the Architecture Overview, Deployment Model, and Functional
Model architecture work products. In addition, one or more of the above
concerns may have been identified and captured either as a risk or as a
potentially looming issue in the project RAID Log. Alternatively, perhaps
one or more architecture decisions, as captured in the Architecture
Decisions work product, cannot be addressed until some prototyping
work has been done to test the various options.

In the YourTour system, particular challenges have been identified with

respect to the integration with the external MyPay payment engine and
the MyReservation reservation system, in terms of both access
mechanism and performance. You are also concerned with the security
model used in conjunction with these integrations. You create
an Architecture Proof-of-Concept to consider all these aspects of your
architecture.

Putting together an Architecture Proof-of-Concept can be challenging

because by definition, it is being done when the architecture is being
formulated and is to some extent in a state of flux. Remember, too, that
the proof-of-concept is typically considered to be throwaway and should
not be allowed to evolve into the actual system with all the inherent
dangers that can result, such as building on a foundation that is not robust
or extensible enough to support all the requirements.

Step: Document Findings

The results from executing the proof-of-concept are documented

accordingly as part of the Architecture Proof-of-Concept work product.

Task: Detail Functional Elements

PURPOSE
The purpose of this task is to refine the functional elements to the point that they
can be handed off to detailed design.

ROLES
Application Architect, Data Architect (secondary), Infrastructure Architect
(secondary)

STEPS
• Define component interfaces.
• Define operations and operation signatures.
• Define contracts between components.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.
Having outlined the functional elements in the Outline Functional
Elements task, you flesh out some of the details of these elements in this
task. Specifically, this task involves

• Defining the interfaces that your components provide and

require. Provided interfaces are those that a component makes available
for other components to use. Required interfaces are ones that the
component must use to complete some of its responsibilities.
• Specifying the interface operations and their signatures (that is, the
parameters passed, parameter types, and return values).
• Specifying the contract of behavior for each operation in terms of
preconditions and postconditions.

You may be asking, “Why should I be concerned with this level of detail,
especially in a logical architecture?” We believe that there are two
reasons:

• If the architect does not specify components to this level of detail, it will
be left to the designers and implementers to perform this task. They
typically work outside the architect’s immediate sphere of influence (and
may not even be in the same company or country) and therefore may
make decisions that are inconsistent with the architecture.
• Specifying components in this way allows you to make a link between
the logical Functional Model and the logical Data Model. Often, these
models are developed separately and independently, but this approach
allows you to ensure these two models are consistent in the early stages
of the project.

That said, it may not always be the case that components need to be
defined to this level of detail. If a component is expected to be realized by
a product or package or other off-the-shelf component, for example, it
probably is not necessary to go to the level of detail discussed here.

This task acknowledges any decisions captured in the Architecture

Decisions work product and names functional elements according to
terms defined in the Glossary.
Step: Define Component Interfaces

Components interact through interfaces. An interface is the vehicle by

which one component accesses the services of, and exchanges data with,
another component. Taking this approach is considered to be good
practice because the consumer is dependent only on the interface, not on
the provider’s implementation of the interface. Subsequently, it is easier
to replace one implementation with another so long as the same interface
is adhered to.

A component is characterized by the interfaces it provides (and the

operations available through each interface) and the interfaces it
requires. In implementing its provided interfaces, a component may
require the services of other components, in which case they use the
interfaces provided by these components. As you will see, the interfaces a
component provides and requires are derived from the responsibilities
assigned to the component.

The separation of interface from implementation also allows you to make

better-informed choices when you move from the logical to physical
architecture. The clearer the separation of responsibilities into interfaces
(realized by a component implementation), the more effectively you can
select the corresponding elements of the physical architecture. Dealing
with interfaces (and, as described later in the sidebar “Concept:
Preconditions and Postconditions,” operations, preconditions, and
postconditions) means that you have a very precise specification,
allowing you either to design the physical components more precisely or
to find products or packages that fit the interface specification more
closely.

In this step, you assign interfaces to the components that were identified
previously. Figure 8.19 shows an example of a component’s provided
interfaces: the Tour Booking Manager component providing
ITourBooking and IPayment interfaces.

Figure 8.19. A Component’s Provided Interfaces

Where do the interfaces in Figure 8.19 come from? Well, you take the
responsibilities you assigned to the components previously and grouped
them according how similar (or cohesive) they are. Each of these groups
of responsibilities then becomes an interface. In this example, all
responsibilities assigned to the Tour Booking Manager component that
deal with the actual booking of a tour have been grouped in an
ITourBooking interface, and the single responsibility for dealing with
payments has been assigned to an IPayment interface. By convention, the
name of each interface is prefixed with an I. The assignment of interfaces
is applied to all components in turn.

You may choose to refine any requirements realizations to show how

these interfaces are used rather than the components offering those
interfaces. Figure 8.20 provides a refined sequence diagram showing the
realization of the main flow of the Book Tour use case, using the
interfaces that have been identified (as opposed to the components that
offer these interfaces).
Figure 8.20. UML Sequence Diagram for the Book Tour Use Case (Main Flow)
Diagrams such as that shown in Figure 8.20 allow you to better
understand the interfaces that a given component requires. The result is
that you can show the provided and required interfaces of a given
component. Figure 8.21 shows the interfaces that are provided and
required by the Book Tour Controller component; the required interfaces
have been derived from Figure 8.20 and other diagrams like it that
describe the different flows of events for each use case. This summary
diagram can provide a complete specification of one or more components
and for this reason is referred to as a component specification
diagram (Cheesman 2001).
Figure 8.21. Component Specification Diagram for the Book Tour Controller
As discussed in the Outline Functional Elements task earlier in this
chapter, you could allocate certain non-functional requirements to the
operations associated with each component. When defining the interfaces
associated with a component, therefore, you can promote this allocation
to the equivalent operations on the interfaces. Earlier, a performance
requirement of 6 seconds was allocated to the make
reservations() operation on the Reservation System Boundary
component. This requirement in turn is allocated to the equivalent
operation on the IReservationSystem interface.

Step: Define Operations and Operation Signatures

In this step, you define interfaces in more detail by specifying the actual
operation names and signatures. The operation name usually is the same
as the responsibilities you assigned to each interface previously, though it
may be shortened or abbreviated if required.

The signature of each operation (in terms of inputs and outputs) can be
determined from its name to some extent. You could assume that the
responsibility add tour participant() is going to require information
defining the tour booking to which the participant is added and the tour
participant involved. You may also examine the sequence diagrams you
developed previously (as shown in Figure 8.20, for example) to determine
the data flows.
Operation parameters and any return values may be simple types, such as
String or Integer, or more complex business types. The set of business
types represents a logical Data Model, which is similar to and typically
derived from the Business Entity Model. A (partial) logical Data Model,
based on the Business Entity Model for YourTour, is shown in Figure
8.22, where the business types have the businessType UML stereotype
applied.
Figure 8.22. Logical Data Model

One particular area that can be explored further is the persistent nature
of the data that flows in the system. Consider the following
characterizations:

• Data is transient.Such data is relevant only for the duration of the

method invocation. A request to add two numbers and return the result,
for example, does not require the component to retain any information
relating to the calculation beyond the lifetime of the invocation.
Sometimes, however, the results of some calculations are retained, such
as a calculation that provides an insurance quote.
• Data represents a conversational state.Data may persist only for the
duration of a user session. The data may represent the contents of a
shopping cart that is lost when the user session terminates, for example.
Even in this case, however, a given implementation may retain the
contents of the cart beyond user sessions.
• Data is persisted.Persistent data is written out to a data store so that it
can be retained beyond the lifetime of the method invocation, beyond the
lifetime of the component instance, and beyond the lifetime of any user
session.

Persistent data that is written out to a data store is of particular interest,

because a relationship exists between the business types in the
logical Data Model and the components (and interfaces) that are
responsible for managing these types. A particular technique that
provides this linkage is described by Cheesman and Daniels (Cheesman
2001), where the authors introduce an interface responsibility diagram.
The purpose of such a diagram is to show which business types are
managed by which interfaces. The interface responsibility diagram
always includes the interface and all its operations (and can be
considered to be the interface equivalent of a component specification
diagram) as well as any business types managed by the interface. An
example is shown in Figure 8.23.
Figure 8.23. Interface Responsibility Diagram
An interface responsibility diagram is derived from the logical Data
Model by assigning a so-called core business type to a particular interface
that is responsible for managing that business type (and any related
noncore business types). A core business type essentially is one that is not
dependent on any other types for its existence. In this example,
TourBooking is considered to be a core business type, whereas
TourParticipant is not (because it depends on a TourBooking for its
existence). An interface usually is associated with a single business type,
and each business type is managed by exactly one interface. The
association between ITourBooking and TourBooking is shown in the
figure as a UML composite aggregation (the solid diamond symbol).

The interface responsibility diagram, therefore, is a specification of the

data that is managed by an interface (and any component that provides
this interface). The data itself is persistent, but the specification does not
say anything about how persistence is achieved. In other words, the
specification is logical rather than physical.
Step: Define Contracts Between Components

Having identified the components and their interfaces, you proceed to

define the contracts between those components. The concept of design by
contract was made famous by Bertrand Meyer (Meyer 1997) in the early
1990s. The contract in this sense is like any legal contract between two
parties, in which both parties have certain obligations in fulfilling the
contract. For components, the contract comes in the form of
preconditions and postconditions on each operation offered by the
interface on the component. See the sidebar “Concept: Preconditions and
Postconditions” for a brief introduction to the ideas that underlie the
concept of design by contract.

Concept: Preconditions and Postconditions

A precondition is the condition that must be satisfied before the operation

executes. If the precondition is true, you can guarantee that the postcondition will
be true also. If the precondition is not true when the operation is invoked,
however, the result of the operation cannot be guaranteed and is in fact
unspecified (that is, you cannot be sure what the operation will do or what value it
will return).

A postcondition specifies the state of the component after the operation has
executed, provided that the precondition is true. By state, we mean any data
(transient or persistent) for which the component is responsible.

Just as in law, preconditions and postconditions place obligations on the client and
provider of a contract. In terms of software, the client is the component that calls
the operation, and the provider is the component that implements the operation,
as summarized in Figure 8.24.

Figure 8.24. Client and Provider Obligations, and Benefits of Preconditions and
Postconditions
The purpose of having preconditions and postconditions on the operations of
component interfaces is to make explicit the responsibility of the caller before
invoking the operation. In other words, if something is listed as a precondition, it
does not have to be checked by the provider but is assumed to be true, which
ensures against too little or too much checking of the data being passed to the
operation. In software, too much checking is as bad as too little because it can lead
to program bloat, making software overly complex and difficult to maintain, as
well as providing more opportunities to introduce errors in the error-checking
code itself!

As described in Object-Oriented Software Construction (Meyer 1997), a

precondition does not stop the operation from being executed, and it is therefore
left up to the developer of the operation to determine how invalid preconditions
are handled (or not). If handled, this typically involves some form of exception
handling, either provided by the runtime environment or explicitly written by the
developer of the operation.

Preconditions and postconditions may be expressed using either the formal Object
Constraint Language (OCL) (Warmer 1999) or natural language. An advantage of
using a formal language is that it is possible to generate code that supports the
enforcement of constraints in a programming language (although you are more
likely to generate code from a physical architecture model than a logical
architecture model).

An example of a precondition in adding tour participant options to a tour

is “The number of participant options specified is not zero,” as shown
in Figure 8.25, where OCL has been used to specify the constraint. This
figure also shows a precondition expressed in natural language.

Figure 8.25. Example of Preconditions

Task: Detail Deployment Elements

PURPOSE
The purpose of this task is to refine the deployment elements to the point that they
can be handed off to detailed design.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect
STEPS
• Assign components to nodes.
• Define connections between nodes.
• Define connections between locations.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

Having outlined the deployment elements in the Outline Deployment

Elements task, you flesh out some of the details of these elements in this
task. Specifically, this task involves

• Assigning components to the relevant nodes

• Identifying the deployment units that allow components to be deployed
to their assigned nodes
• Deriving the connections between nodes and locations, based on the
messages that flow between components

The results of this task are included primarily in the Deployment

Model work product. This task takes into consideration any decisions
captured in the Architecture Decisions work product and names
deployment elements according to terms defined in the Glossary.

Step: Assign Components to Nodes

Having identified the logical deployment elements, you make the

connection between the Functional Model and Deployment Model by
assigning components in the Functional Model to nodes in
the Deployment Model. Components are assigned to nodes based on two
main factors:

• The type of component.A boundary component, for example, typically

resides on a node that is connected to the associated device (in the case of
a user interface) or external system. An entity component resides on or
close to the node housing the data access mechanism (such as a database
server).
• The required qualities to be exhibited by the system, such as
performance, availability, and security.Components that need to be
highly available may need to be placed on nodes that are marked as being
high availability or on nodes that are duplicated so that if one fails, the
other can take over.

As well as identifying nodes that support components that provide the

business functionality, this task identifies nodes needed to support any
services required: print servers, application servers, file servers, security
servers, data management servers, transaction servers, system
management servers, and so on.

Figure 8.26 shows an example from the YourTour system of the allocation
of components to nodes. This figure introduces the concept of
a deployment unit that provides a link between the components to be
deployed and the nodes being deployed to. Logical deployment units are
discussed in the sidebar “Concept: Logical Deployment Units.”
Figure 8.26. Components Assigned to Nodes in the Central Office Location

Figure 8.26 depicts the Central Office location. Here, you see three
deployment units for those elements deployed to the Tour Booking
Server (one for each type of component: boundary, control, and entity), a
single deployment unit for those elements deployed to the Content
Management Server, a single deployment unit for those elements
deployed to the Security Server, and a single deployment unit for those
boundary components that represent interfaces to external systems. A
deployment unit is represented as a UML artifact.

Step: Define Connections Between Nodes

When components that interact have been placed on nodes, you need to
ensure that communication can take place among them if they are
distributed across nodes. In the logical architecture, you don’t concern
yourself with whether the physical connection is point to point or via an
intermediary mechanism such as a messaging bus; you simply represent
the connection as an association between the two nodes. You consider the
physical mechanisms involved when you consider the physical
architecture. Figure 8.27 shows the nodes previously identified for the
Central Office location with simple associations between nodes added.
Figure 8.27. Nodes and Connections in the Central Office Location

Concept: Logical Deployment Units

The concept of a deployment unit represents a package of components that is

subsequently deployed on one or more nodes. Put another way, it is the concept of
a deployment unit that allows a component to be deployed on a node. So why do
you need this intermediary?

The concept of a deployment unit is particularly relevant in a physical architecture,

where you don’t deploy components directly to nodes. In a Java EE environment,
for example, you first must package your executables in a JAR file of some sort, and
it is the JAR file that is deployed to a physical node.

This separation can be useful in a logical architecture, too, when you want to
deploy the same set of elements to different nodes for some reason and want to
represent the packaging once (in a deployment unit). This technique also provides
consistency in the approach taken to specifying the logical architecture and the
physical architecture. A more important reason for considering logical deployment
units, however, is that it gives the architect an opportunity to associate particular
qualities with a set of components. This goal is achieved by grouping those
components that require a particular quality of service into a deployment unit,
which is then deployed to a node that provides the quality of service required.

Boundary components, control components, and entity components, for example,

typically require different qualities of service, and you can distinguish them by
placing them in separate deployment units. A boundary component is concerned
with the nature of the interface to the corresponding external actor, the location of
the external actor, the required hours of service, and the amount of concurrent use
supported by this interface. A control component is concerned with the amount of
concurrent execution that must be supported and the response times required. An
entity component is concerned with the amount of information being handled, the
volatility of the information, and the amount of concurrent access. As a general
rule of thumb, therefore, you separate boundary, control, and entity components
into separate deployment units, because this practice gives you a first indication
that these elements must be considered differently as you refine the architecture.

The associations are added as a result of the interactions that take place
among the components deployed on each of the nodes. These interactions
are described by sequence diagrams such as that shown in Figure
8.20 earlier in this chapter. Connections have been added as shown
in Figure 8.28 because:

• Some of the components supported by the Tour Booking Server and

some of the components supported by the Content Management Server
need to access the relevant components supported by the Security Server
to authenticate users.
• Components supported by the Content Management Server need to
deploy content using components supported by the Tour Booking Server.
• Components deployed to the Integration Server may need to access
components on the Security Server to ensure that they are authorized to
access the external system.
• Components on the Tour Booking Server need to access external
systems, which they do through the Integration Server. In addition, one of
those systems is the CRM System that is also located in the Central Office,
so you see a connection between the Integration Service and the CRM
Server.
Figure 8.28. Locations and Connections

Step: Define Connections Between Locations

You can extend this thinking to derive connections between locations

also, although such connections are often quite obvious and don’t need a
thorough analysis to determine. Figure 8.28 shows a number of locations
and the connections between them. These connections are derived from
the connections between the nodes that are found in those locations. As
just discussed, connections between nodes are identified by analyzing the
messages sent between the components deployed on those nodes. Figure
8.28 also shows the actors present at each location. (It is a coincidence
that the same actor appears in only one location in the figure; it is quite
possible for the same actor to be present in several locations.)

Task: Validate Architecture

PURPOSE
The purpose of this task is to validate that the architecture supports the
requirements as currently stated.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect, Project Manager (secondary)

STEPS
• Plan validation.
• Review architecture.
• Document findings.
• Assess risks and make recommendations.
ROLE OF THE ARCHITECT
• Planning and leading the validation.
• Documenting the findings.
• Noting any risks or issues and identifying appropriate mitigations.

As discussed in the sidebar “Concept: Verification and Validation” earlier

in this chapter, validation helps answer the question “Am I building the
right system?” In other words, does the system satisfy the stated
requirements, or has something else been built?

Even though you are validating a logical architecture, it’s still possible to
evaluate the architecture against the requirements. You can take several
approaches to validate the architecture, and the specific techniques you
use at a given point in time may vary depending on where you are in the
overall project life cycle and the current state of the architecture. Early in
the project, for example, it may be best to validate the architecture simply
by presenting the architecture to the key stakeholders. Later in the
project, you may perform a more rigorous and systematic walk-through
of the architecture. As you will see in Chapter 9, “Creating the Physical
Architecture,” validation of the physical architecture may also consider
characteristics of the executing system.

In validating the architecture in this task, you focus not only on the
technical aspects of the architecture, but also on the context within which
the architecture exists, including the requirements from which the
architecture has been derived as well as the realities of delivery based on
the architecture that has been defined. In these respects, this task
encompasses a broad set of considerations:

• Understanding the broader business context of the

architecture.What are the key requirements and commitments that have
been made to the stakeholders? What are the organizational aspects to
the project that must be understood?
• Assessing whether the proposed architecture is fit for purpose,
given the requirements.Here, you assess the technical aspects of the
architecture. Does the architectural solution satisfy the requirements at
the current level of elaboration in the project?
• Determining the ability to deliver.The architecture has a major
bearing on what skills are required to develop the system, as well as what
is required for the development and test environment. The idealized view
of what is required needs to be balanced with what is realistically
achievable. This particular consideration emphasizes the close
relationship between the architect and Project Manager.
• Identifying and assessing technical risks.What risks are outstanding,
and are they being formally managed? What is the potential effect on the
project if these risks become issues? How can the risks be mitigated and
contained?

In validating the architecture, sometimes it is useful to take a few key use

cases and walk through them to ensure that the architecture supports the
use cases. The sidebar “Concept: Scenario-Based Validation” discusses
one such approach to this form of validation.
Validation can take many forms, ranging from a presentation to the
relevant personnel by the architect (or architecture team) through to an
exercise that spans several days. The very general steps outlined in this
task are intended to cover this broad spectrum. The level of formality is
dependent on many factors, of course, including the complexity of the
solution, where the project is in terms of the overall project life cycle, and
the number of stakeholders involved.

The Validate Architecture task focuses on those stakeholders that are

internal to the project, such as the Project Manager, Developers,
and Testers. The Review Architecture with Stakeholders task, on the
other hand, focuses on external stakeholders that are not part of the
development team, such as the Application Owner and end users.

Concept: Scenario-Based Validation

To divide and conquer the task of validating the architecture, often it is useful to
consider a set of key scenarios that are used to walk through the architecture and
that allow the architect to demonstrate the architecture in action—in terms, for
example, of the decisions that have been made, the elements that comprise the
architecture and their collaboration, and the qualities that the architecture
exhibits.

A well-known scenario-based approach is the Architecture Tradeoff Analysis

Method (ATAM) from the SEI (Clements 2002), as well as its predecessor, the
Software Architecture Analysis Method (SAAM) (Clements 2002). The ATAM
considers a set of scenarios in which each scenario focuses on either the
functionality offered by the system or the qualities exhibited by the system. In
either case, this approach affords the architect the opportunity to convey the
architecture in the context of each scenario. The ATAM encompasses the
tasks Validate Architecture and Review Architecture with Stakeholders, which
are described elsewhere in this chapter.

One aspect of the ATAM is architecture evaluation, which follows a series of steps:

1. Present the ATAM. The approach is described, and any questions

regarding the evaluation process are answered.
2. Present the business drivers. The business motivation for the
development effort and key architectural drivers are described.
This step often is performed by someone from the business, the
customer, or the project manager.
 3. Present the architecture. The architect describes the architecture
and how it addresses the business drivers. This step typically is
performed by considering the various views that describe the
architecture.
4. Identify the architectural approaches. In this step, the
architectural approaches taken are determined, typically by asking
questions of the architect. The approaches are often described in
terms of high-level architecture decisions, such as the selection of
particular architectural styles and significant elements.
5. Generate the quality attribute utility tree. The key system
qualities are determined, specified in terms of scenarios, and
prioritized. The scenarios refine any rather vague qualities, such as,
performance into more specific scenarios that can be measured,
resulting in a utility tree. The main purpose of this step is to ensure
that the relevant set of scenarios used to validate the architecture is
selected. “In effect, the utility tree tells the evaluation team where
to probe the architecture” (Clements 2002).
6. Analyze the architectural approaches. The evaluation team
determines the applicability of the architectural approaches taken
in terms of satisfying the business drivers previously described for
each of the prioritized scenarios. Any risks are noted.
7. Brainstorm and prioritize scenarios. Whereas previous steps
consider the more technical scenarios against which the
architecture should be evaluated, this step considers the bigger
picture and invites all stakeholders to contribute scenarios by
which the architecture should be evaluated.
8. Analyze the architectural approaches. This step is the equivalent
of step 6 but takes any new scenarios into account.
9. Present the results. The information from the ATAM is
summarized and presented to the stakeholders.

Step: Plan Validation

Validation of the architecture should be planned appropriately, because it

involves identifying the key personnel to participate in the validation,
scheduling any meetings required, and preparing and distributing
materials (the inputs to this task) before any meeting. The validation is a
team effort, and the Lead Architect and Project Manager should both be
involved in this step.
Step: Review Architecture

The architect presents the architecture to the internal stakeholders and

answers any questions. The presentation typically commences with a
statement of the business drivers for the solution; then the architect
presents the architecture. External stakeholders are considered in
the Review Architecture with Stakeholders task.

In particular, the internal stakeholders will be interested in seeing the big

picture of how the architecture addresses the system requirements—the
primary objective of validating the architecture. In this respect, the
architect typically highlights the high-priority requirements (functional
and non-functional) and indicates how each requirement is addressed in
terms of the architecture being presented. It is important to show how
elements of the architecture can be traced back to the requirements by
using some form of traceability matrix.

One important aspect of reviewing the architecture is ensuring that all the
requirements, as originally stated by the stakeholders, have been dealt
with. This is where having some form of traceability—linking
architectural elements back to requirements—comes into its own. Well-
defined traceability allows reviewers to trace from the architecture back
to the requirements to see how each requirement has been satisfied.

While reviewing the architecture, it is useful to have a checklist available

to ensure that the right questions are asked and nothing is missed.
Appropriate checklists, aligned with the architecture description
framework introduced in Chapter 4, “Documenting a Software
Architecture,” are provided in Appendix B, “Viewpoint Catalog.” These
checklists also help architects prepare for this task, because the checklists
remind you of the questions that need to be answered in the review.

Step: Document Findings

As the presentation proceeds, various items may not have been addressed
adequately in the architecture, or questions may remain unanswered. All
such comments should be recorded to ensure that they’re addressed, and
all such findings are documented in the Architecture Assessment work
product.
If it becomes apparent that the architecture cannot be validated against
the stated performance requirements because the requirements are not
described adequately, the finding might be as shown in Table 8.7.

Table 8.7. Example Architecture Validation Finding

Step: Assess Risks and Make Recommendations

After documenting all findings, the next step is deciding what risks are
associated with each finding. It is important that risks clearly state the
potential impact on the delivery of the project. As well as stating the risks,
it is helpful to quantify the risks according to the likelihood of their
actually occurrence and the potential impact on the project if the risks
actually occur. For each risk, you should also make some statement or
recommendation regarding risk mitigation, as shown in Table 8.8, by
doing one of the following things:

• Removing the risk from the project by changing the solution

• Containing or reducing the risk by adding estimation contingency,
mitigation tasks, excess capacity, or other measures to reduce the risk
• Accepting the risk without changing anything but possibly providing an
alternative plan or approach if the risk materializes

Table 8.8. Example Architecture Assessment Finding with Risk and

Mitigation Added

Risks identified in the Architecture Assessment also should have an

entry in the RAID Log to ensure that they get tracked by the project.
Issues may be identified during the assessment and these issues should
also be tracked in the project RAID Log. This task may also result in one
or more Change Requests being raised against work products that have
been examined.

Task: Update Software Architecture Document

PURPOSE
The purpose of this task is to document the architecturally significant elements in
the Software Architecture Document.

ROLE
Lead Architect

STEP
• Update software architecture document.
ROLE OF THE ARCHITECT
• The architect is responsible for this task.

Step: Update Software Architecture Document

In this step, the architect updates the relevant views in the Software
Architecture Document. The outline of the Software Architecture
Document is discussed in Chapter 4, “Documenting a Software
Architecture.” In terms of that structure, the various sections are
populated from the content of the work products that have been created,
as shown in Table 8.9. Just as the requirements view is populated from
the various requirements-related work products, you can populate the
functional, deployment, and validation views from the various
architecture-related work products that are output from the tasks
described in this chapter. You can also populate the cross-cutting views
that are part of the architecture description framework too.
Table 8.9. Alignment of Sections in the Software Architecture
Document and Work Products

When populating the Software Architecture Document, it is important

to remember that a difference exists between the architecture definition
as defined in various (detailed) architecture work products and the
architecture definition as defined in the Software Architecture
Document. The purpose of the Software Architecture Document is to
provide a vehicle for bringing together all the relevant architecture-
related information in one place for the purpose of communicating and
reviewing the architecture (and the document sometimes is referred to as
a deliverable as a result). Therefore, the document often is a subset of all
the information available in all the work products.

Task: Review Architecture with Stakeholders

PURPOSE
The purpose of this task is to baseline the logical architecture work products and
obtain stakeholder agreement that the architecture, at its current level of
elaboration, addresses the defined requirements.

ROLES
Application Architect (secondary), Data Architect (secondary), Infrastructure
Architect (secondary), Lead Architect, Stakeholder

STEPS
• Baseline work products.
• Assemble work products.
• Review work products.
ROLE OF THE ARCHITECT
• Ensuring that the correct work products have been baselined.
• Leading the review.
• Answering questions and providing clarifying remarks as the review proceeds.

The purpose of reviewing the architecture with the stakeholders is to

ensure that their concerns have been addressed or will be addressed. The
logical architecture may not yet address all concerns (some concerns may
not be addressed until the physical architecture is defined), but it should
be a major step on the way to doing so.

Architecture reviews are architectural testing, a safety net for the

architect, planned and conducted in line with a risk-based testing
strategy. (Buschmann 2009)

We recommend that before performing the review, you formally baseline

the architecture and put it under change control so that from now on, all
changes in requirements that affect the architecture can be controlled
against this baseline. Whether baselining takes place before or after the
review is a matter of some debate. Our preference, however, is to baseline
first and handle review comments under change control. This method
prevents the vicious circle of being unable to baseline the architecture
because the review has highlighted problems, and addressing the
problems results in an architecture that needs to be re-reviewed. Much
has been written on performing architecture reviews, but one of the most
definitive sources is the Software Architecture Review and Assessment
(SARA) Report (SARA 2002).

Step: Baseline Work Products

Baselining work products very simply consists of selecting the current set
that represents the architecture (which are the ones output from this
activity) and ensuring that the set is stored in a configuration
management system with suitable version numbers applied. Then you
need to publicize this set of work products as being the baseline so that it
can be referred to for all follow-up activities, such as performing detailed
design or defining the physical architecture (which we describe
in Chapter 9, “Creating the Physical Architecture”).

Step: Assemble Work Products

The primary input to the architecture review is the Software

Architecture Document. All other work products may be made available
for reference purposes during the review, however, including the
requirements work products from which the architecture has been
derived. As discussed in the previous task, the Software Architecture
Document is populated from the various architecture-related work
products, and these work products may also be included in the review.

Step: Review Work Products

In this step, you review the architecture work products. This review may
be no more than walking through the content of the Software
Architecture Document, with the supporting work products available
for reference if needed. Any problems discovered are documented
in Change Requests. When the review is complete, you briefly capture
the results of the review, including any action items, in a Review Record.
Anything that needs to be raised as a project issue should be tracked in
the project RAID Log.
The review itself, depending on the architecture under review, may last
from a few hours to a few days (or longer). Reviews typically examine the
many aspects of the architecture in a similar vein to the verification
performed, including clarification of the goals of the architecture (in line
with the stated requirements), agreement on priorities, examination of
the trade-offs made (such as flexibility versus performance), and
consideration of the risks.

This review serves as a quality gate for an iteration that ensures that the
logical architecture is stable enough to support subsequent tasks, such as
the detailed design of the logical architecture, the creation of an outline
test plan, or the population of a project plan. As a result, it is important
that the relevant parties participate in the review, including the Project
Manager, Testers, and Developers, for example. In addition,
the Application Owner will be interested in getting an overview of the
architecture and an understanding of how it will meet the key strategic
requirements, and users will need assurance that the key business
requirements have been met.

SUMMARY
Defining a logical architecture is a critical part of the overall software
development process that, if performed well, results in a more robust and
understandable architecture, with a clear separation of concerns and a
balanced division of responsibility between system elements. Defining the
logical architecture is also a stepping stone that helps you move from the
system requirements to the physical architecture. The Create Logical
Architecture activity discussed in this chapter leads into the Create
Logical Detailed Design activity (discussed in Chapter 1, “Introduction”),
which fleshes out any remaining detail that may be required at a logical
level, such as the detail of a particular business rule.

In the next chapter, we describe how to use the logical architecture (and
logical detailed design) to derive a physical architecture that directly
supports subsequent development activities.

Chapter 9. Creating the Physical

Architecture
In this chapter, we move from the logical architecture discussed
in Chapter 8, “Creating the Logical Architecture,” to the creation of the
corresponding physical architecture. Unlike its logical counterpart, the
physical architecture acknowledges all the products and technologies that
will be used for detailed physical design and, ultimately, coding.

As described in Chapter 4, “Documenting a Software Architecture,” a

model moves through discrete levels of realization during its life from an
initial model whose content is very conceptual to a model whose content
is detailed enough to be used as the basis for implementation. In this
chapter, we show how the two key models used to describe the
architecture of a system—the Functional Model and the Deployment
Model—move from containing purely logical (or technology-independent)
elements to containing physical (or technology-specific) elements.

In this chapter, we describe each of the tasks that produce the physical
architecture that realizes the requirements defined in Chapter 7,
“Defining the Requirements,” and that evolves the logical architecture
defined in Chapter 8. We assume that several work products are input to,
and output from, the Create Physical Architecture activity, as shown
in Figure 9.1. As you can see from this figure, consideration of the physical
architecture involves both requirements and the logical architecture
work products.
Figure 9.1. Input and Output Work Products of the Create Physical
Architecture Activity
MOVING FROM LOGICAL TO PHYSICAL
ARCHITECTURE
Because the logical architecture is one of your primary inputs, when
moving from the logical to physical architecture, you should understand
what this input entails. As well as considering the requirements on the
system, you must consider the various elements defined in the logical
architecture, a diagram from which is shown in Figure 9.2. This figure
contains both functional and deployment elements and shows many of
the items that you need to consider in moving from the logical to physical
architecture, including components, locations, nodes, node connections,
and deployment units. Subsystems, component interfaces, operations, and
various relationships are not shown to simplify the diagram. Each of these
elements is discussed later in this chapter.
Figure 9.2. Subset of the Logical Architecture

In moving from logical to physical architecture, you make several choices:

• Technology.This choice includes the platforms that will be used to

define the execution environment, such as the Java Platform Enterprise
Edition (Java EE) or Microsoft .NET, as well as any programming
languages used to implement any components.
• Products.This choice includes products that support the
implementation and execution of any components, such as application
servers and database servers, as well as hardware selection. Refer to the
sidebar “Concept: Product” for a definition of what is meant by product in
this context.
• Reusable assets.Software assets (as discussed in Chapter 5, “Reusable
Architecture Assets”) include packaged applications, existing
components, and any legacy applications. You may also select hardware
that is available from the existing IT environment.
• Custom development.You may decide, for various reasons, that certain
components should be custom built. Custom-built components provide
the ultimate in flexibility because they are completely under your control.
Such components usually target a specific set of capabilities and may be a
cheaper option than purchasing a product if you need only a fraction of
the capability that the product provides. In some cases, you may also
build custom hardware.

Concept: Product

Moving from the logical to physical architecture requires you to make decisions
regarding technologies and products. We use the term product to represent
something that is sourced from outside the organization, as opposed to something
that is developed in-house. A product may represent software or hardware.
A software product may be a complete application or part of an application (such
as a configurable package or component). A commercial product (sometimes
referred to as a commercial-off-the-shelf, or COTS, product) is one that is acquired
through sale, lease, or license and includes licensed open-source products. From
the perspective of a software development project, a commercial product requires
you to consider product procurement.

APPLYING THE PROCESS

As described in Chapter 3, “Method Fundamentals,” the architecture
discipline follows the profile shown in Figure 9.3.
Figure 9.3. Physical Architecture and Iterative Development
The tasks associated with defining the physical architecture can start in
an iteration of the Inception phase, when you may decide to base your
solution on a set of existing software and hardware assets, for example.
You place greater emphasis on these tasks in the Elaboration phase, when
you concentrate on architecting the major (or, as we often call them,
architecturally significant) elements of the system. As you move into the
iterations of the Construction phase, physical-architecture tasks taper off
as the focus shifts to completing the implementation, based on the
architecture that has been defined thus far.

We may give the impression that there is a clean separation of logical and
physical architecture and that they are always performed in a simple
sequence.

You should remember, however, that an architecture is derived both top-

down and bottom-up. Although you can derive the physical architecture
from the logical architecture, some physical elements may be givens (and
specified as constraints on the solution, for example) and you can model
them straight away at a physical level without first considering the logical
elements (although you may choose to represent the physical elements in
any logical model in an abstract form).

One thing you should avoid, however, is mixing logical and physical
concepts in the same model or diagram. Mixing these concepts can lead to
confusion about what elements have been addressed at a physical level
and may skew any effort estimates for the completion of the architecture
work. Mixing logical and physical elements in a single model or diagram is
a form of view overloading (Rozanski 2005) and generally should be
avoided. In this book, therefore, we always show logical and physical
concepts in separate diagrams.

CREATING THE PHYSICAL ARCHITECTURE:

ACTIVITY OVERVIEW
The creation of the physical architecture is simply a particular focus of the
architecture tasks, so it should be no surprise therefore that the tasks
themselves are exactly the same as those used to define the logical
architecture, as shown in Figure 9.4. The only difference is the emphasis
on the physical, rather than logical, aspects of the system under
development.

Figure 9.4. Overview of the Create Physical Architecture Activity

Following is a summary of these tasks, with a focus on the creation of the

physical architecture:

• The purpose of the Survey Architecture Assets task is to identify

reusable architecture assets that can be applied to the system under
development. You base your survey on the requirements and the logical
architecture that has been defined.
• The purpose of the Define Architecture Overview task is to identify
and describe the major elements of the system under development. The
physical architecture reflects the selection of key technologies, products,
and reusable assets.
• The purpose of the Document Architecture Decisions task is to
capture the key decisions made in shaping the architecture and the
rationale behind them. The emphasis in creating the physical architecture
is on decisions related to the selection of technologies, products, and
reusable assets.

• The purpose of the Outline Functional Elements task is to identify the

major functional elements (subsystems and components) of the system
under development. The focus is on how the functional elements are
realized by products, reusable assets, and custom software elements.
• The purpose of the Outline Deployment Elements task is to identify
the locations across which the system under development will be
deployed and the nodes within each location. The focus is on identifying
physical computer platforms and other hardware devices, such as routers
and firewalls.
• The purpose of the Verify Architecture task is to verify that the
architecture work products are consistent and to ensure that any
concerns that cut across the architecture work products (a quality such as
performance, for example) have been addressed consistently. This task is
performed with respect to the elements that comprise the physical
architecture.
• The purpose of the Build Architecture Proof-of-Concept task is to
synthesize at least one solution (which may simply be conceptual) that
satisfies the architecturally significant requirements (or the required
subset of these requirements) to determine whether such a solution, as
envisaged by the architect, exists. In terms of the physical architecture,
you accommodate the technologies, products, and reusable assets that
have been selected.
• The purpose of the Detail Functional Elements task is to refine the
functional elements to the point that they can be handed off to detailed
design. You ensure the presence of enough detail describing the physical
architecture to make this handoff possible.
• The purpose of the Detail Deployment Elements task is to refine the
deployment elements to the point that they can be handed off to detailed
design. Again, you ensure the presence of enough detail describing the
physical architecture to make this handoff possible.
• The purpose of the Validate Architecture task is to validate that the
system as a whole is going to support the various stakeholder requests.
• The purpose of the Update Software Architecture Document task is to
document the architecturally significant elements in the Software
Architecture Document. The various views are updated to reflect the
physical aspects of the architecture.
• The purpose of the Review Architecture with Stakeholders task is to
obtain stakeholder agreement that the architecture, at its current level of
elaboration, addresses the defined requirements. This task clearly means
gaining agreement that the physical architecture is sufficient.

Because this chapter essentially repeats the tasks that we defined

in Chapter 8, “Creating the Logical Architecture,” albeit focusing on
physical rather than logical elements, we do not include the entire set of
task descriptions in this chapter. Therefore, the reader should assume
that all roles, work products, and steps are the same unless we say
otherwise. As we discuss each task in this chapter, we refer to any logical
elements that may have been created and that are at your disposal.

In Chapter 8, you saw that the tasks that focus on functional elements and
deployment elements are divided into outline tasks and detail tasks. We
said that the outline tasks focus on those elements that are most
significant to the architecture and that would be the responsibility of
the Lead Architect on the project. The detail tasks are focused on the
less-significant elements and are the responsibility of the architect with
the relevant focus—such as the Application Architect, Infrastructure
Architect, or Data Architect. Table 9.1 summarizes the physical
elements considered in this chapter.

Table 9.1. Elements Considered in the Outline and Detail Tasks

TASK: SURVEY ARCHITECTURE ASSETS
When creating the logical architecture, you focus on assets that help you
define the basic structures and interactions of architectural elements.
When creating the physical architecture, you look for physical assets that
help you realize the logical level structures and any interactions between
logical elements. In this respect, the logical architecture acts as a set of
requirements and constraints on the physical assets you might choose to
realize your architecture.

As mentioned in Chapter 8, “Creating the Logical Architecture,” this task is

typically performed several times in the course of an iteration, because
the reuse of architecture assets is always at the forefront of an architect’s
mind at various points during the creation of the physical architecture.
This reuse reflects the many types of reusable assets that may be
considered, ranging from a technology-specific reference architecture to a
technology-specific design pattern.

As a simple example, suppose that you have decided that the YourTour
system will have a separate content management subsystem, the
requirements for which will be analyzed and captured as responsibilities
of the relevant functional element. For now, you are assigning a single
Content Management component to the Content Management subsystem.
That assignment may change later if you decide that you need to
decompose the subsystem further or to source parts of it from different
vendors. (The database may be separate from the content management
workflow, for example.) The need for a content management solution was
identified in both the logical Architecture Overview as well as the
logical Functional Model. Furthermore, you will have determined the
non-functional requirements on this component. Table 9.2 summarizes
the characteristics of this component.
Table 9.2. Component Description for the Content Management
Component

Based on the description of the Content Management component, you

would look for one or more existing assets that satisfy as many of these
responsibilities and qualities as possible and draw up a list of potential
candidate assets. Clearly, if no suitable asset can be found, you may look
to a commercially available software product that you could use for this
component. If no suitable candidates are found, you would need to
consider building your own component.

It’s important to remember that the Survey Architecture Assets task

considers both software and hardware. Therefore, you may also consider
those assets identified from the Existing IT Environment work
product—including existing systems and infrastructure—that can be
reused.

TASK: DEFINE ARCHITECTURE OVERVIEW

The purpose of this task is to identify and describe the major elements of
the system under development that reflect any technology, product, and
reusable asset selections that have been made.

While you are realizing the Functional Model and Deployment Model in
terms of technology-specific elements, it may be useful to reflect these
elements in an Architecture Overview of the physical architecture. As
for its logical counterpart, this Architecture Overview provides an initial
sketch of the envisaged physical architecture.

Figure 9.5 shows the Architecture Overview that represents physical

elements of the YourTour system, in which (as you will see) a decision
has been made to base the architecture on Java EE technologies. (The use
of Java EE is not shown explicitly in the figure, which shows only
deployment elements.). As you can see from this figure, the
updated Architecture Overview is influenced by the logical architecture
but now shows physical nodes, rather than logical subsystems.
Figure 9.5. Physical Architecture Overview for YourTour
The connectivity shown in Figure 9.5 entails specific security
considerations. The figure also includes firewalls to indicate the proposed
security zones for the YourTour system. The placement of such firewalls
follows the application of a standard pattern (IBM 2009) for systems that
are accessed from the web, with an initial firewall protecting the system
as a whole and another firewall providing additional security for
elements that reside in the internal network.

When creating the Architecture Overview representing the physical

architecture, you should refer to the requirements that have driven the
logical architecture, as well as the Architecture Overview representing
the logical architecture. Although the logical architecture provides a first
approximation of the architecture required, it may not take all the
requirements into account—specifically, constraints that mandate the use
of particular technologies or products. The Architecture
Overview representing the physical architecture, on the other hand, does
acknowledge such constraints, which is why you see specific references to
the MyPay payment engine and the MyReservation reservation system
in Figure 9.5; these elements are constraints on the solution that have
been specified. Specifically addressing the non-functional requirements in
the physical architecture is discussed in the sidebar “Concept: Addressing
Non-Functional Requirements.”

Concept: Addressing Non-Functional Requirements

One of the major factors affecting the physical architecture is the approach taken
to address non-functional requirements (both qualities and constraints). Although
the architect takes certain steps to address these requirements in the logical
architecture, such requirements are addressed more explicitly and fully in the
physical architecture.

In particular, many approaches take a rather idealized approach to deriving the

logical architecture, wherein networks are infinitely fast; computers never fail; and
processing power, disk space, and memory are infinite. You cannot escape such
considerations when defining the physical architecture, however. Any “optimal”
architecture that you may have described is brought back to reality quickly as you
consider the physical considerations of the architecture in its environment.

The Architecture Overview is meant to be just that: an overview of the

proposed architecture for communicating with various stakeholders. It is
not meant to be a rigorous specification of the architecture from which a
system could be built. This is the purpose of the more-
detailed Functional Model and Deployment Model, which we focus on
in subsequent tasks in this chapter.

TASK: DOCUMENT ARCHITECTURE DECISIONS

When considering the physical architecture, the architect makes decisions
regarding the selection of particular technologies, products, reusable
assets, and the like. In particular, the architect makes buy-versus-build
decisions (which are discussed in more detail in the Outline Functional
Elements task later in this chapter). It is important that the decisions be
captured adequately to reflect the options that were considered and the
rationale for deciding which option was selected.

When making such decisions, you have several useful inputs. The RAID
Log helps you focus on those areas where decisions need to be made. The
architecture models (that is, the Data Model, Deployment Model,
and Functional Model work products) ensure that any decision is made
in the context of the evolving architecture. The Architecture
Assessment and Architecture Proof-of-Concept work products are
sources of quantitative information for selecting the right option and
actually arriving at a decision.

TASK: OUTLINE FUNCTIONAL ELEMENTS

This task focuses on realizing the logical subsystems and components by
identifying their physical counterparts.

Mapping Logical Functional Elements to Physical Functional

Elements

This task focuses on identifying the subsystems and components that will
comprise the physical architecture by ensuring that the logical
subsystems and components that have been identified are realized
appropriately.

In Chapter 8, “Creating the Logical Architecture,” a subsystem is defined as

a set of related components. That definition holds true for the physical
architecture too, where a physical subsystem represents a set of related
physical components. The mapping of logical subsystems to physical
subsystems is normally fairly straightforward, and typically one-to-one.
However, we may create additional subsystems that reflect technology-
specific considerations. For example, we may identify a set of physical
components that do not map one-to-one with their logical counterparts,
and it would make sense to create additional subsystems within which
these components reside.

A physical subsystem could also represent a product which, although

made up of several loosely coupled components, typically bundles all
these components together. If you had chosen to procure a customer
relationship management (CRM) subsystem rather than reuse an existing
CRM system, for example, you might find that it consists of separate
components for contact management, billing, order management, and so
on (elements that you had considered separately) sold together as a
single integrated subsystem.

In terms of components, the realization of a logical component by a

physical component is not always one-to-one, and all the following
mappings are possible:

• One-to-one.You can realize a logical component by using a single

physical component if the responsibilities assigned to the logical
component can be satisfied completely by one physical component. The
Content Management component of the YourTour application may be
mapped completely to a product, for example.
• One-to-many.You can realize a logical component by using more than
one physical component if, for example, you cannot realize that
component exactly with a product or packaged application and have to
part-buy and part-build components. In this case, you may have to
separate responsibilities across more than one physical component and
provide a way of communicating among these components.
• Many-to-one.You can realize many logical components by using a single
physical component if you find that, for example, you can address the
performance requirements only if you combine two logical components
into a single physical component.

The preceding examples are specific examples of when to map, split, or

aggregate when moving from logical components to physical components.
A more complete checklist of things to consider is provided in the sidebar
“Checklist: Mapping Logical Components to Physical Components.”

Checklist: Mapping Logical Components to Physical Components

Consider a one-to-one mapping between a logical component and a physical

component when:

• A single physical component can support all the responsibilities of the

corresponding logical component, using an appropriate implementation
technology without breaking any of the principles of coupling, cohesion, or
granularity that you use when assigning responsibilities to components.
• A single physical component can support any non-functional requirements
without the need for either a one-to-many or a many-to-one mapping.

Consider a one-to-many mapping between a logical component and physical

components when:

• Many physical components are required to realize the logical component. The
physical components may be a combination of several products and custom built
components.
• Many physical components are required to support different service-level
characteristics that have been assigned to the logical component. In the case of
YourTour, for example, the ability to book a tour probably is needed 24 hours a
day, but canceling a tour usually is required only during a normal working day, as
this task probably requires additional confirmation and checking from a booking
clerk.
• Many physical components are required to accommodate a particular
architectural pattern that has been selected and that requires the responsibilities
assigned to a logical component to be realized in multiple physical components.

Consider a many-to-one mapping between logical components and a physical

component when:

• A single physical component, such as a product, encapsulates the responsibilities

assigned to several logical components.
• A single physical component supports a service-level characteristic required of
several logical components. Business rules that were spread across multiple
logical components may need to be maintained in one place and may be brought
together in a single rules-engine component, for example.
• A single physical component that realizes several logical components is required
to accommodate a particular architectural pattern that has been selected.
As far as possible, the logical architecture tries to ensure that components
are independent of technology; the logical architecture can therefore be
implemented with different technologies and products. In practice, when
choosing technologies and products to realize the logical architecture, you
must remember that each technology has its own idiosyncrasies, which
means that you have to do some work to interpret these differences to
ensure an unambiguous specification of the components so that they can
be further detailed and implemented. Then the physical architecture
becomes a blueprint for designers and developers to follow.

A simple example is consideration of the implementation of interfaces in a

programming language. You may have put a great deal of effort into
specifying interfaces at a logical level to help yourself make better-
informed decisions when selecting physical elements. Also, you may have
a one-to-one mapping between logical and physical elements and may
want to retain the interfaces as best you can in the physical architecture.
Although interfaces are supported explicitly in some programming
languages, such as Java and C#, they are not supported explicitly in
languages such as C++, C, and COBOL, so you would need to devise a
scheme to support interfaces in these languages.

Another area that warrants consideration is how any technology provides

exception handling, transaction handling, persistence, integration, and the
like. Such areas often represent architectural mechanisms, which are
among the types of assets discussed in Chapter 5, “Reusable Architecture
Assets.”

Identifying Physical Functional Elements

Following is an obvious sequence in which you can identify physical

subsystems and components:

1. Survey the complete set of logical subsystems and components

contained in the Functional Model, and for each, decide whether it
will be realized with an available asset or product, or whether it
needs to be built.
2. For each component that is to be realized with an asset or product,
liaise with the Project Manager to initiate the procurement
process to buy that product.
 3. For each subsystem or component that is to be built, decide on the
implementation technology, and provide enough guidance to
ensure that detailed design and implementation of the component
can proceed smoothly.

Here, we use the term buy to mean procuring anything that already exists,
including any of the types of assets discussed in Chapter 5, “Reusable
Architecture Assets,” and products from commercial software or
hardware vendors. The asset may already exist in the organization (that
is, it was developed for another project or as part of a corporate reuse
program). Guidance on whether to buy or build varies from organization
to organization as well as project to project. In deciding whether to buy or
build, it is worth reviewing the checklist in the sidebar “Checklist: Buy
versus Build Decisions.”

We strongly recommend that the architect be involved in procurement

decisions, especially where the requirements are complex and several
alternatives must be considered. It is important that the overall technical
integrity of the system under development be maintained; the architect
has the big-picture view of what this system should be, so the architect is
the person best placed to be involved in this process and ensure this
integrity.

When several options are available, it is worth recording these options

and the rationale for the final selection in the Architecture Decision work
product. Remember that when you are considering these options, it is
important to look at both non-functional and functional criteria. A
product or asset may appear to satisfy all your functional requirements
but may be woefully inadequate when it comes to qualities such as
performance and availability, especially if the product or asset is
immature or relatively new to the market.

Checklist: Buy versus Build Decisions

The following questions can be applied when trying to make “buy versus build”
decisions. In this checklist, the term product typically refers to something from
outside the organization, but we use the same term in this checklist to refer to
reusable assets inside the organization, because you need to ask many of the same
questions when reusing assets that have been produced by another team or
business unit.
• Does a corporate-wide policy favor buy versus build (or the other way around)?
• In the event that no products exist that completely provide the required
functionality, is it worth considering changing the requirements so that a product
can be reused?
• If an existing product requires a lot of customization before it can be used, would
it be better to custom-build the solution instead?
• Is the required component leading edge or unique in the sense that no
comparable products exist or, if they do, are likely to be unstable or immature?
• Is the product vendor financially sound?
• What support options are available from the vendor?
• How are problems raised and escalated with the vendor, and what service-level
agreements (SLAs) are offered (such as turnaround times for problem fixes)?
• Are any financial implications related to any ongoing maintenance costs of using
an existing product (including upgrades)?
• Have maintenance costs been factored into the decision and the total cost of
ownership (TCO) calculated?
• Does the product vendor have an acceptable policy regarding migration that
allows, for example, data to be migrated with minimal disruption to ongoing
operations?
• Does integration of any product require specialist skills that are hard to come by?
• Is customization of any product particularly onerous and time-consuming, which
could lead to schedule slippage?
• Is any product required dependent on other products or platforms, and have
these products or platforms been factored into the decision-making process?
• Is the product at the correct version number to be compatible with other
products that may be used? (Vendors often issue new versions of products that
may make the products at least temporarily incompatible with other products—
either their own or those from other vendors.)
• Does any product have credible references of previous (and successful) use?
• Does the vendor have a long-term road map for the product?
• Is the vendor credible and aligned with where you want to go as a user?
• Are the product release timelines acceptable?
• Are any suitable cost-free options available, such as open-source software that
isn’t licensed? (Although this class of software may be perceived as being too risky
for an enterprise to build mission-critical systems, it may have been built by a
dedicated online community of developers and may even be of higher quality than
commercial software. For a certain class of system, this route can be very
favorable. When using open-source software, you should be aware that even
though the license may be free, you will have ongoing support costs.)

In conclusion, most IT systems are a combination of off-the-shelf products

and assets and custom-built elements. Ensuring that all these elements
work together, while satisfying the system’s requirements, is clearly the
responsibility of the architect.

Procuring Products

After you decide which components need to be procured, you probably

need to follow some kind of procurement process to ensure that the
products are selected in the proper way, as discussed in the sidebar
“Guideline: Product Selection.”

The reusable assets you seek to procure may align with the architectural
layers if you have used a layering strategy based on reuse. In particular,
you can separate the following:

• Business-specific elements, such as a CRM system or enterprise

resource planning (ERP) system.
• Business-independent elements, such as security packages (lightweight
directory-access protocol servers and public key infrastructure software,
for example), systems management software, relational database
management systems, application servers, transaction processing
monitors, and system software (operating systems, for example).
Guideline: Product Selection

Following is a simple technique for selecting software products:

1. Review the criteria for product selection. Most organizations have a

list of preferred vendors as well as criteria for product selection. If
an Enterprise Architecture exists, that architecture almost certainly
includes policies that also guide the selection of products. You
should review the criteria to ensure that rules and policies are met.
2. Identify the criteria that will be used to perform an evaluation of
candidate products, some of which may be considered to be
mandatory (resulting in a failure if not met) and some of which are
simply desirable.
 3. Determine how the criteria will be scored, which may be as a binary
value (the candidate either does or does not meet the criterion), a
fixed value (from a set of possible values, such as “very good,”
“good,” “average,” or “poor,” for example), or a range of values (any
number between 0 and 10, for example). Also consider whether a
weighting factor should be applied to some criteria, as not every
factor will be equal when you determine the suitability of the
product for the system under development.
4. Identify a candidate list of products that may meet the evaluation
criteria defined. Clearly, this step may require a considerable
amount of research, including requests to vendors to present their
products, as well as visits to sites where the products are already
being used (reference sites).
5. Perform the actual evaluation by assessing each candidate and
recording the assessment against the criteria. In some
circumstances, it may be necessary to create prototypes to assess
the relative merits of competing vendor products. These prototypes
may be built by the architecture team or by the vendors themselves.

Accommodating Technology-Specific Patterns

An excellent resource to have on hand when moving to a particular

technology is a set of technology-specific patterns. Many vendors produce
patterns that describe how to use their products, which may include
elements based on open standards. IBM (IBM 2009), Sun (Sun 2009), and
Microsoft (Microsoft 2009) all provide advice and guidance on their
websites for this purpose. These patterns can be used to see how
particular components might be implemented. Sun, for example, produces
a set of Java EE blueprints (Sun 2009) that show how Java EE constructs
can be applied.

The following examples use Java EE to highlight certain principles. We

provide a summary of Java EE in the sidebar “An Overview of the Java
Platform, Enterprise Edition (Java EE).”

An Overview of the Java Platform, Enterprise Edition (Java EE)

Figure 9.6 summarizes some of the key technologies used in a typical Java EE
application, aligned by architectural tier.
Figure 9.6. Java EE Overview

This figure contains the following elements:

• A markup language (such as HTML or XML). The markup language is rendered

on a client device (such as a web browser).
• Java Servlets (servlets). A servlet defines how a request from the client is
processed and how a response is generated. Servlets execute in a web container
(described later in this sidebar).
• JavaServer Pages (JSPs). A JSP is a text document that, like a servlet, describes
how a request is processed and a response generated. JSPs provide an alternative
to servlets when generation of statements in a markup language (such as HTML) is
required. JSPs execute in a web container. The JavaServer Faces (JSF) framework
builds on JSP technology.
• Enterprise JavaBeans (EJBs). An EJB is responsible for implementing an aspect
of the business logic of a Java EE application and for storing, where relevant,
persistent data. EJBs execute in an EJB container.
• Java DataBase Connectivity (JDBC). JDBC provides programmatic access to a
relational database.
• Java Persistence API (JPA). JPA supports persistence of data through an object-
to-relational mapping, allowing persistent objects to be treated as plain old Java
objects (PoJos). This is achieved through Java annotations that declare the
persistent fields of an object and that in essence provide a mapping between a field
of the object and a field in a database table. An annotation is metadata that
declares some intent for the platform to add some functionality via injection at
run-time.
• Java API for XML Web Services (JAX-WS). JAX-WS provides support for
SOAP/XML-based web services.
• Java Message Service (JMS). JMS provides a standard interface to reliable
asynchronous messaging implementations (such as IBM’s WebSphere MQ).
• Java EE Connector Architecture (JCA). One of the common requirements of an
enterprise application is to connect to external resources. Some of these resources
may be external applications accessed via a vendor-specific protocol. JCA provides
a standard means for providing resource adapters (more commonly known
as connectors).
CONTAINERS
Central to the J2EE platform is the concept of a container. A container provides
run-time support for application components (such as JSPs, servlets, and EJBs)
that execute within it. An EJB container provides component life-cycle
management (the container creates and removes application components as
required), transaction management, security, and persistence support to the EJBs
that execute within it, for example.

EJB INTERFACES
A client’s access to an EJB is provided through interfaces. A client never interacts
directly with the EJB implementation, as the Java EE platform maps the methods of
the interface to the equivalent methods of the EJB implementation. The EJB
interface can be declared for local (co-located) or remote (distributed) access.

SESSION, ENTITY, AND MESSAGE-DRIVEN EJBS

EJBs come in three distinct flavors: session beans, entity beans, and message-
driven beans.

Session beans, as the name suggests, are beans whose state is valid in the context of
a user session. The Java EE platform specifies two types of session beans: stateless
session beans and stateful session beans. A stateless session bean is intended to be
very lightweight in that it maintains no conversational state whatsoever. Stateless
session beans are often used as controllers that coordinate a series of interactions
between other EJBs but don’t actually maintain any state of their own. A stateful
session bean, on the other hand, does maintain in-memory state between one
invocation and the next within the context of the user session. A shopping cart, for
example, could be implemented as a stateful session bean.
Entity beans represent coarse-grained elements that manage long-lived state;
therefore, they are provided support for persistence. Examples of entity beans are
Customer, Order, and Product. An entity bean may use the JDBC API, but may also
use the EJB3/JPA APIs if an object-to-relational mapping managed by the platform
is required.

In addition to session beans and entity beans, the Java EE platform specifies
message-driven beans. Message-driven beans are designed to support
asynchronous communication. A client sending messages to message-driven beans
does not block waiting for a response after sending a message.

For all types of EJBs, annotations can be provided that allow the EJB container to
manage the EJB appropriately. In addition, annotations allow the automatic
generation of a web service wrapper for the EJB.

In addition to deciding among the various patterns available, you need to

decide how, given the selected technologies, elements in the logical
architecture are mapped to elements in the physical architecture.
Following are some simple rules based on the selection of the Java EE
platform:

• A boundary component that represents an interface with a person will

be implemented using JSPs and servlets.
• A boundary component that represents an interface with an external
system will be implemented as a session EJB and use JMS to provide
connectivity.
• A control component will be implemented as a session EJB.
• An entity component will be implemented as an entity EJB.

Putting this all together, Figure 9.7 provides an example of a technology-

specific pattern using the YourTour Book Tour Controller logical
component. In this figure, the Book Tour Controller provides and requires
various interfaces. The logical architecture infers that the Book Tour
Controller is stateless, in that any request passed to it is simply passed on
to the appropriate required interface.
Figure 9.7. Component Specification Diagram for the Book Tour Controller
In moving from the logical to physical architecture, the Sun Java EE
pattern session façade has been chosen. The session façade pattern
“defines a higher-level business component that contains and centralizes
complex interactions between lower-level business components” (Sun
2009). Figure 9.8 shows the structure of this pattern.
Figure 9.8. Session Façade Java EE Pattern

As you can see, the session façade is implemented as a session EJB and
manages relationships between one or more BusinessObjects. Each
BusinessObject is instantiated as either a session bean or an entity bean.
When implementing the session façade pattern, you need to make several
architectural decisions, such as the following:

• Should the session façade be a stateful or a stateless session bean? This

decision depends on the interface provided by the session façade. A
scenario that needs only one method call to complete a given service is
nonconversational and so can be implemented with a stateless session
bean. If the scenario requires multiple method calls to complete, however,
the service is conversational, which means that some state must be saved
between each method invocation. In this scenario, a stateful session bean
would be used to implement the session façade.
• How should the business object be implemented? The choices given by
the pattern are that the business object can be a session bean or an entity
bean. Session beans typically provide a business service that does not
maintain any persistent data, whereas entity beans do maintain
persistent data.

Figure 9.9 shows how the session façade pattern has been used to realize
the Book Tour Controller component. The BookTourController façade
provides a single interface for accessing all information related to a tour
booking, including tour participants, their preferred options, and
payment information related to the booking. The façade is a stateless
session bean because it maintains no state between method invocations.
This session façade wraps several session EJBs, all acting as business
objects in the pattern:

• A TourManager session EJB, which manages tour information

• A TourBookingManager session EJB, which manages tour booking
information
• A ReservationSystem session EJB, which acts as an interface to the
reservation system
• A PaymentEngine session EJB, which acts as an interface to the payment
engine
Figure 9.9. Tour Booking Manager Realized as a Session Façade

To describe the characteristics of the physical elements more completely,

you may create a set of requirements realizations based on physical
elements to ensure that the relevant responsibilities are assigned to them.
As discussed in Chapter 8, “Creating the Logical Architecture,” you
typically achieve this goal by producing one or more sequence diagrams
to show how components interact to realize the requirements. See the
sidebar “Concept: Requirements Realizations in the Physical
Architecture” for a brief discussion of the merits of creating these types of
diagram for the physical architecture.

Concept: Requirements Realizations in the Physical Architecture

In Chapter 8, “Creating the Logical Architecture,” we introduce the concept of

a requirements realization. This concept allows you to express explicitly how a
given requirement (functional or non-functional) is realized in terms of solution
elements. In that chapter, we show how requirements are realized in terms of
logical elements. You can use the same approach to show how requirements are
realized in terms of physical elements.

The extent to which you perform this task in the physical architecture depends on
several factors, however. If you have chosen not to create a logical architecture
(for reasons described in Chapter 8), you cannot imply any realization of
requirements by tracing the physical elements to the logical elements from which
they are derived and which in turn trace to the requirements they realize. In this
case, you may choose to perform a relatively extensive analysis of how
requirements are realized by physical elements. At the other extreme, if you have
performed an extensive analysis of how requirements are realized by logical
elements, you may not explicitly show the realization of any requirements by
physical elements, because we can imply this by tracing physical elements to those
logical elements that do realize the requirements.

The most common approach lies somewhere between the two options: You realize
a key set of requirements in terms of logical elements but also selectively show
how certain requirements are realized in terms of physical elements.

Figure 9.10 shows a sequence diagram containing components from the

physical architecture that realize the main flow of the Book Tour use case.
In creating such diagrams, we are defining operations on the target EJBs.
In addition, we could have created a similar diagram showing a use-case
flow of events realized in terms of interactions between user interface
elements, such as JSP pages.

In Figure 9.10:

• The client calls the session façade, BookTourController, to get a list of

tours. The BookTourController calls the TourManager EJB to get a list of
tours.
• The client calls the BookTourController to select a tour. The
BookTourController calls the TourBookingManager EJB to create a new
tour booking.
• The client calls the BookTourController to add tour participants. The
BookTourController calls the TourBookingManager EJB to add the tour
participants to the booking.
• The client calls the BookTourController to add tour participant details.
The BookTourController calls the TourBookingManager EJB to add the
options for each tour participant.
• The client calls the BookTourController to book the tour. The
BookTourController calls the TourBookingManager session EJB to record
the payment details associated with the tour booking. Then the
BookTourController calls PaymentEngine session EJB to make the
payment with the payment system. Finally, the BookTourController calls
the ReservationSystem session EJB to place the reservations by using the
reservation system.
Figure 9.10. Participants in the Main Flow of the Book Tour Use Case

TASK: OUTLINE DEPLOYMENT ELEMENTS

This task focuses on identifying the physical deployment elements in
terms of technologies, products, and custom-built elements. This task is
concerned with the following:

• Overall hardware configurations that address the required service-level

characteristics, such as fail-over, scalability, and security.
• Specifications of the hardware required, such as processors (based on
their speed), disk configurations, and network bandwidth and latency.
• Specifications of the software required (such as operating-system
software), together with required versions and any detailed
configurations.
• Product selection of hardware and software for computers and the
networks that connect them.

Mapping Logical Deployment Elements to Physical Deployment

Elements

The mapping of logical locations to physical locations is simply a case of

identifying the number of physical locations in the solution. For example,
a “branch office” logical location may be mapped to physical locations of
“New York branch office” and “Tokyo branch office.” You may not always
have such a straightforward one-to-one mapping of logical nodes to
physical nodes, however. As for the functional elements, the transition
from the logical to the physical architecture may result in splitting or
aggregating nodes for various reasons:

• One-to-one.You can realize a logical node by using a single physical

node if the specification of the logical node can be satisfied completely by
one physical node.
• One-to-many.A single logical node may need to be split across multiple
physical nodes to meet performance, availability, or other non-functional
requirements. Clearly, this has implications not only for the deployment
elements, but also for the functional elements (which may themselves
need to be split to accommodate the physical distribution).
• Many-to-one.Logical nodes may end up as being partitions on physical
nodes rather than separate processing units; a physical node may satisfy
the needs of more than one logical node. Consolidation of more than one
logical node into a single physical node may also be required when, for
example, a packaged application has been selected that is deployed to a
single physical node (to provide tighter coupling but improved
performance and management, for example) whose capabilities were
originally architected as residing on separate nodes.

Identifying Physical Deployment Elements

Taking into account the general guidance in the preceding sections, you
can develop the physical deployment elements as follows:

1. For each logical location, define how many physical instances of this
location there will be and where, geographically, these locations
will be placed.
2. For each node assigned to the logical location being considered,
create a corresponding physical node (bearing in mind the need to
split or aggregate nodes, as described in the preceding section).
3. Tag the node with an alignment to a specific hardware product
(assuming that nodes are procured and not built). Where no
obvious alignment exists, simply list candidates, and identify the
preferred option based on the requirements (especially non-
functional requirements). This may result in multiple nodes
residing at a single location, where each node represents a
candidate hardware product.
4. Size the physical nodes by reviewing the non-functional
requirements and—based on required throughput, availability,
scalability, and so on—coming up with suitably sized platforms
(that is, platforms with a suitable number of instances, amount of
disk space, processor speed, and so on). On a large, distributed
system, this task is a significant one in its own right and may
involve doing detailed performance modeling, possibly aided by
building a further Architecture Proof-of-Concept to support the
sizing estimates.

Figure 9.11 shows the level of detail you would expect after following the
preceding steps. The figure shows the Central Office location of the
YourTour system, which physically resides in London, and shows the
servers, workstations, and other devices together with their physical
attributes. In particular, you see the addition of a database server with an
associated disk array for storing any YourTour persistent data.
Figure 9.11. The Central Office Location in the Physical Deployment Model

We have also shown the likely connections that will be needed between
the nodes. These connections will be confirmed and updated as necessary
when deploying the physical components onto the nodes in the
task Detail Deployment Elements. Connections from the Admin Client
are not shown, as there is a connection to all other nodes in this figure
(with the exception of the Disk Array, which is a device).

It’s also possible to show the number of nodes required at each location
within a Unified Modeling Language (UML) model by creating a
composition aggregation relationship between the location and the nodes
it contains. Then this relationship can show the multiplicity of the
relationship. Figure 9.12 shows that the London Central Office location
has five Admin Client nodes. This information is clearly important in
procuring hardware—the topic of the next section.
Figure 9.12. Representing the Number of Nodes at a Given Location
Procuring Hardware

The logical Deployment Model acts as a specification for the deployment

elements that are needed to realize the system under development.
Unlike the case with functional elements, it is much more likely that items
needed to realize the deployment aspects of the system will be bought
rather than built. Unless the system under development is very
specialized, it is highly unlikely that anything other than off-the-shelf
hardware will be used to realize the physical node descriptions specified
in the physical architecture.

Having decided which hardware elements need to be bought (procured),

you probably need to follow some kind of procurement process to ensure
that the hardware is selected in the proper way, as discussed in the
sidebar “Guideline: Product Selection” earlier in this chapter. This
guidance is most relevant when a choice of hardware is available, with
many options supporting the same hardware specification.

TASK: VERIFY ARCHITECTURE

As stated previously when we considered the logical architecture
in Chapter 8, “Creating the Logical Architecture,” the Functional
Model and Deployment Model usually are developed by different roles,
and the two models inevitably become misaligned to some extent. The
purpose of this task is to ensure that the architecture is defined
consistently across these work products, and they have, together,
addressed all of the requirements.

As stated in Chapter 8, “Creating the Logical Architecture,” verification

helps you answer the question “Am I building the product right?” In other
words, have you followed the method and conformed to any development
standards? The secondary purpose of this task is to ensure that all
decisions, as captured in the Architecture Decisions work product and
possibly quantified by data obtained from any Architecture Proof-of-
Concept (discussed next), are reflected in the architecture models.

TASK: BUILD ARCHITECTURE PROOF-OF-CONCEPT

After you make the key decisions about the specific technologies to be
used in the architecture, it often makes sense to prove the architecture
through the creation of an Architecture Proof-of-Concept. Then you can
use information gleaned from building and executing this proof-of-
concept to refine the architecture. The sidebar “Checklist: When to Create
an Architecture Proof-of-Concept” provides some examples of when a
proof-of-concept may be required.

Checklist: When to Create an Architecture Proof-of-Concept

An Architecture Proof-of-Concept should be considered when any of the following

statements hold true:

• Are some functional requirements only partially addressed and require further
proving?
• Is performance or any of the other required system qualities likely to be an issue,
and do detailed metrics proving that the system is likely to meet these qualities
need to be established?
• Are some components considered to be high risk or leading edge in what they are
required to do and, therefore, need to be proved?
• Are products being used that need to interface with other products or existing
systems, and do these interfaces need to be proved?
• Do products being used have an existing user interface that you need to show to
end users to verify that their needs are satisfied?
• Are products or packages being used that require complex customization or
configurations? (Some products can be configured in many ways, which can affect
the performance or availability of the product.)

The context and scope of the Architecture Proof-of-Concept are usually

decided by reviewing the various architecture models, which will
highlight one or more areas of concern from the above list. You should
also examine the project RAID Log to help determine which areas of
technical risk have been identified and ensure that the proof-of-concept
focuses on addressing these areas where necessary and applicable.
TASK: DETAIL FUNCTIONAL ELEMENTS
As for the Outline Functional Elements task, each technology has its
own idiosyncrasies that influence the detailing of the functional elements
defined in terms of interfaces and operation signatures. You know, for
example, that you access the EJB implementations through a business
interface rather than directly (and that the Java EE environment will
inject the right code into the application to make this access possible).

In this task, you take these idiosyncrasies into account while providing
enough information to allow designers and developers to build the
system. Then the physical architecture becomes a blueprint for designers
and developers to follow. The execution of this task follows, exactly, the
description given for detailing functional elements in the logical
architecture, as discussed in Chapter 8, “Creating the Logical
Architecture.”

In practice, especially with standard technologies such as Java EE and

.NET, often it is sufficient simply to associate a technology-specific pattern
with the element concerned in terms of providing a detailed-enough
specification to support detailed design or coding. Consider the
BookTourController shown in Figure 9.13, which shows the operations
that have been assigned to it based on the realization of all the use-case
flows in which it participates.
Figure 9.13. Operations on the BookTourController Session EJB

You know that the BookTourController is a stateless session EJB. You may
also stipulate, in a pattern, that all EJBs be fronted by a JavaBean class
that provides simplified access to EJBs. Rather than specify this JavaBean
class, you can simply state the pattern once and imply these elements
without ever expressing them explicitly in your models. This approach
can apply to other elements too, which can be useful because then you
can keep your models as simple as possible (and not clutter them with
unnecessary detail) without losing any useful detail.

You can add further detail by providing the operations signatures as well
as preconditions and postconditions. Detailing the signatures in this way
in the physical architecture ensures that the components are defined
unambiguously in terms of their interface. This means you can hand the
components over to the developers to implement, safe in the knowledge
that (provided that the interface is complied with) the component will be
implemented as intended.

Figure 9.14 shows the same BookTourController session EJB together

with the Java classes that are used as parameter and return types. Again,
you would look to the logical architecture to get a sense of the
information that needs to be passed in each operation but also apply any
technology-specific considerations when specifying these elements in
your physical architecture.
Figure 9.14. Parameter Types on Operations of the BookTourController Session EJB

As you did for the logical architecture, it is in the detailing of

the Functional Model that you make the connection between
components (and their interfaces) in the Functional Model and elements
in the Data Model (although this time, the Data Model is considered in
terms of physical tables). Clearly, you have identified elements that are
persistent (in a Java EE environment, this is data managed by the entity
EJBs or JPA objects). A subset of the persistent elements is shown
in Figure 9.15, which uses a UML profile to describe the structure of a
relational database (where each class represents a database table, certain
attributes are stereotyped as being a primary key, and a foreign key is
implied by a role name on an association). The structure of the database
reflects the structure of any persistent classes and is influenced by the
business types identified in the logical architecture, as well as
the Business Entity Model. Although not shown in Figure 9.15, it is also
possible to explicitly show a relationship between a database table and
any persistent classes that use this table.
Figure 9.15. Extract from the Physical Data Model

TASK: DETAIL DEPLOYMENT ELEMENTS

Detailing deployment elements is concerned primarily with identifying
the deployment units that associate the physical components with the
physical nodes and the connections that must exist between nodes to
support the interactions between the physical components.

Having identified the physical components and specified them to the level
where they can be procured or built, you can consider where these
components are deployed physically. This task considers the following:
• For custom-built components, determining how these components will
be packaged in such a way that they can be deployed to the relevant
physical nodes by identifying suitable deployment units.
• For products that have been selected, reviewing the product
documentation and working out how the products are to be deployed
alongside the system under development. For any customizable
components (such as packaged applications) that have been selected, you
also need to ensure that all configuration options and any customizations
that need to be made are specified.

Table 9.3 shows the mapping of a subset of the physical components to

deployment units for the YourTour application. This mapping is a
reflection of the deployment units identified in the logical architecture
but takes technology considerations into account, as well as the fact that
these physical components need to be deployed on different servers, as
shown in Figure 9.16. JSPs and servlets are deployed in a WAR file,
whereas EJBs are deployed in a JAR file on the Java EE platform, for
example.
Figure 9.16. Components Assigned to Servers (Subset) in the London Central Office

Table 9.3. Mapping Components to Deployment Units

As well as assigning components to deployment units, you can assign the
deployment units to the relevant nodes. Figure 9.16 depicts a subset of
the updated Deployment Model for the YourTour Central Office location,
showing the placement of the tourBookingUIComponents.war and
tourBookingEntities .jar deployment units. Any connections are added or
refined as a result of the interactions that take place among the
components deployed on each of the nodes.

Although diagrams such as that shown in Figure 9.16 are good for
showing summary information of deployments, you can capture only so
much detail in such diagrams. In most real-world scenarios, you are likely
to need additional supporting information, such as that shown in Table
9.4. This detailed physical specification of the node shows all components
deployed to it, including technical elements such as the middleware and
operating system.

Table 9.4. Component Mapping for the Tour Booking Server Node
Remember that at this stage the detailed physical design has still not been
done; the architect is simply providing guidance to ensure that the
detailed physical design will be done within necessary constraints (to
ensure the integrity of the architecture). Planning early how the system
will be packaged and deployed is particularly important for large,
complex, distributed systems, which may have many different elements to
be deployed. When packaging the software into appropriate deployment
units, you should consider the following:

• The linkage with any configuration management and change-control

processes and systems. The deployment units must reflect the right
versions of the various components and products they contain. On a
related note, you should consider dependencies among the different
software elements, especially where common libraries are needed that
may come from different vendors.
• The physical mechanism by which the software will be shipped and
installed (such as providing access over the Internet, shipping disks, or
sending someone out to install the software physically).
• Considerations involving internationalization and various locale-specific
data and resources that must be made available.
• The various testing environments that must be supported and the
software configuration needs for each environment. Most systems require
at least unit, integration, system, and acceptance testing to be performed,
and each system may well require a different environment in which to
perform that testing. How software will be deployed in these
environments and how it will be promoted between environments is very
much the concern of the architect.

The architect should also be conscious of certain operational concerns

that need to be accommodated after the software has been deployed,
because these concerns can affect the physical architecture. The architect
should consider the following:

• The mechanism by which any new system is populated with data. The
architect needs to focus not only on how new data gets put into the
system (users, products, customers, and so on), but also on how existing
data gets migrated from the system that is being replaced (if this is the
case). Data migration is the name given to the process of loading data
from an existing system onto the new system. In a large, complex
development, this process may be a complete project itself, requiring the
analysis of existing data, the cleansing of that data to remove errors and
duplications, and the development of a strategy for how existing data will
be moved (a “bigbang” approach in which data is moved wholesale just
before cutover to the new system, for example, or a phased approach in
which data is moved a piece at a time). Data migration might also
introduce new subsystems and components into the architecture, such as
an Extract, Transform, and Load (ETL) subsystem or file-transfer
components.
• Constraints involved in scheduling updates to existing systems,
especially if those systems are live and need to be running around the
clock.

During this task, you also refine the number of each type of physical node
required by considering some of the required service-level characteristics
involving performance, availability, and scalability. High or continuous
availability may be achieved only by ensuring duplication of some nodes,
for example, so that if one node fails, another can be switched in.
Similarly, scalability requirements may demand the use of multiple
processors (referred to as vertical scalability) or multiple nodes (referred
to as horizontal scalability), and such considerations add to the more
detailed specification of the deployment nodes as a result.

Based on the connections between nodes (and locations) defined in the

physical architecture, you can also determine how these connections will
be realized using either the existing network or new network devices
such as local- or wide-area networks, routers, bridges, and so on. This
task entails sizing the traffic across those connections that result from
implementing the new system to ensure that sufficient capacity is
available, so that that the network does not become a bottleneck and
adversely affect performance.

TASK: VALIDATE ARCHITECTURE

Validating the physical architecture builds on the task of the same name
performed during the specification of the logical architecture and
addresses the question, “Am I building the right system using the set of
technologies and products that have been selected?” In other words, will
the system meet the stated requirements and, therefore, meet
stakeholders’ expectations?

The steps that you carry out in performing the validation are the same as
those described for the corresponding task in defining the logical
architecture. The criteria being addressed are different, however, or at
least have a different focus. The criteria to consider when performing an
architecture validation at the physical level are similar to those for the
logical-level architecture; appropriate checklists are provided
in Appendix B, “Viewpoint Catalog.”

When you are validating the architecture, all the models built so far (that
is, the Functional Model, Deployment Model, and Data Model) will be
validated against known requirements. In addition, key decisions
documented in the Architecture Decisions work product (and
supported by the Architecture Proof-of-Concept) will be used during
the validation together with the Architecture Overview work product.

TASK: UPDATE SOFTWARE ARCHITECTURE

DOCUMENT
The Software Architecture Document is updated to reflect the physical
architecture that has been defined. As we mention earlier in this book, the
purpose of the Software Architecture Document is to provide a vehicle
for summarizing all the relevant architecture-related information in one
place for the purpose of communicating and reviewing the architecture.
This document usually is a subset of all the information available in the
referenced work products.

The challenge you face in updating the Software Architecture

Document to include the physical architecture is deciding whether to
extend any existing document or to break a potentially large document
into several separate documents that together comprise the Software
Architecture Document work product. This separation can be achieved
in several ways. You could separate based on logical versus physical
architecture or by architectural view, for example.

The main reasons for bringing together the architecture work products in
one overarching work product (the Software Architecture Document)
is to allow the work done to date to be communicated to all team
members and also reviewed by stakeholders so that they can sign off.

With respect to stakeholder signoff, most projects of any significant size

have one or more authorization-to-proceed (AtP) points, which need to
be passed successfully before the release of further funding or resources.
To satisfy the input to an AtP, the significant work products that are to be
reviewed as part of that AtP usually need to be baselined at an agreed
level. This is one of the primary reasons for creating the Software
Architecture Document, which serves as a point-in-time view of the
architecture that stakeholders can review and agree on.

TASK: REVIEW ARCHITECTURE WITH

STAKEHOLDERS
This task is almost identical to the equivalent task described in Chapter 8,
“Creating the Logical Architecture,” although it is performed with respect
to the physical architecture. In this task, you first baseline the physical
architecture work products and then review the Software Architecture
Document and supporting architecture work products with the key
stakeholders. Any problems discovered are documented in Change
Requests. When the review is complete, you briefly capture the results of
the review, including any action items, in a Review Record.

This review serves as a quality gate and ensures that the physical
architecture is stable enough to support tasks that depend on it. As a
result, it is important that the relevant parties participate in the review—
the Project Manager, Testers, and Developers, for example.

SUMMARY
Developing software architecture is an iterative process. The architect
must continuously refine, verify, and validate the architecture and also
gain agreement with stakeholders who have interests in the system under
development. Furthermore, as information is gathered and requirements
are better understood, the architect is able to move from a conceptual
view of the architecture to a more physical view.
In this chapter, we have shown how you can refine and elaborate on the
elements in the logical architecture by applying the same process pattern
to create a physical architecture that clearly identifies the technologies,
products, assets, and custom-built elements used to design and build the
system.

Chapter 10, “Beyond the Basics,” examines other aspects of a software

development project, as well as the particular challenges of architecting
in complex environments.

Chapter 10. Beyond the Basics

The process discussed in Chapters 7 through 9 focuses on describing the

essential tasks performed in a typical software development project, with
emphasis on the role of the architect. The context for this description is a
relatively straightforward tour booking system.

In this chapter, we examine other aspects of a software development

project and, in particular, the involvement of the architect with respect to
other aspects of software development not discussed so far, such as test,
configuration management, change management, and the development
environment. In addition, even though the case study exemplifies various
architectural challenges, such as addressing system qualities and
considering integration and packaged applications, additional
complexities may also warrant consideration. These complexities include
accommodation of large systems, large teams whose work must be
coordinated, and a distributed development team—all of which are
considered in this chapter.

THE ARCHITECT AND THE PROJECT TEAM

As the technical lead for the project, the architect has an influence on
many aspects of a software development project. We discuss the
involvement of the architect in the requirements discipline in Chapter 7,
“Defining the Requirements.” In Chapter 8, “Creating the Logical
Architecture,” and Chapter 9, “Creating the Physical Architecture,” we
focus on the core architecting tasks in which the architect is involved.
The purpose of this section is to examine other aspects of a software
development project and, in particular, the involvement of the architect
with respect to other disciplines and, therefore, with other roles on the
team.

[A discipline is a] primary categorization mechanism for organizing tasks

that define a major “area of concern” and/or cooperation of work effort.
(OpenUP 2008)

The Architect and Requirements

The role of the architect with respect to requirements is discussed in

detail in Chapter 7, “Defining the Requirements.” In that chapter, you see
that the architect has a varied set of responsibilities with respect to
requirements, as summarized in Figure 10.1. The most significant
contributions made by the architect are to ensure that the more technical
users of the system (such as the System Administrator) are considered, to
ensure that the more technical requirements (especially non-functional
requirements such as qualities and constraints) are captured and detailed
appropriately, and to assist with the prioritization of requests and the
resulting requirements.
Figure 10.1. The Role of the Architect with Respect to Requirements

The Architect and Development

The purpose of the development discipline is to perform detailed design

tasks, to define the organization of the implementation, to implement the
detailed design elements, to unit-test the implementation, to integrate the
work of individual developers, and ultimately to produce an executable
system.

Clearly, the architecture is input to the detailed design activities, because

it identifies the major components of the system and their interfaces, as
discussed in some detail in Chapter 9, “Creating the Physical
Architecture,” including the identification of deployment units such as the
executable work products. The architect’s influence does not end there,
however. As shown in Figure 10.2, the architect is also responsible for the
architecturally significant aspects of the implementation such as the
implementation structures that will be used to organize the source code.
A well-structured implementation supports concurrent development,
whereby different elements of the system can be implemented in parallel
by different developers (or teams of developers). The architect is also
responsible for identifying any development-related standards,
guidelines, and reusable assets.
Figure 10.2. The Role of the Architect with Respect to Development

Another consideration for the architect with regard to implementation is

the sequence in which the various elements of the implementation are
integrated to provide the delivered system. Again, the architecture
provides an excellent guide in terms of integration and testing. It should
be possible to create the system as a succession of builds that are
individually integrated and tested, for example. While such
considerations may appear to be rather detailed, an architect avoids such
details at their peril, as discussed in the sidebar “Pitfall: Avoiding the
Technical Details.”
As well as providing specific input on certain technical matters relating to
development, architects are also responsible for the technical outcome as
a whole, and they apply themselves accordingly. This situation is true of
all disciplines and the development discipline in particular. Rather than
involving themselves only in those areas for which they are responsible,
architects typically work closely alongside project team members to guide
and mentor them in their work. In particular, the architect ensures that
any architecture decisions and standards are complied with.

Pitfall: Avoiding the Technical Details

In Chapter 2, “Architecture, Architect, Architecting,” we say that it is important for

the architect to have technology knowledge, design skills, and a level of
programming skills. Although architects may focus primarily on the significant
elements of the architecture, on occasion they need to get involved in the details in
terms of the detailed design and coding.

A particular pitfall for architects is always handing off the details to others,
considering such details to be outside their concern. Such architects lose the
respect of their teammates and tend to get a bad reputation with many negative
characterizations, such as being hand-wavers, being remote from the project in
their ivory tower, or being able to talk the talk but not walk the walk. Good
architects get their hands dirty and, when required to, get deeply involved in the
technical details.

The Architect and Test

The purpose of the test discipline is to find and document defects in

software quality, to advise about perceived software quality, and to
validate that the system functions as designed and as required.
Complementing the unit testing performed in the development discipline,
the test discipline focuses on the integrated units provided by the
developers and the system as a whole.

In particular, the test discipline considers integration testing, system

testing, and acceptance testing. Integration testing, as its name suggests,
focuses on testing the work of several developers as an integrated
whole. System testing focuses on testing the entire system and validating
the end-to-end functioning of the system. Acceptance testing typically is
the final test action before the software is deployed in production. The
goal of acceptance testing is to verify that end users can use the software
to execute the functionality of the system.

The architect’s participation in the test discipline is shown in Figure 10.3.

The architect ensures that the architecture is testable and, more
informally, tested. From the perspective of testability, the architect
ensures that the system can be assessed with respect to the defined
functional and non-functional requirements. In terms of non-functional
requirements, the architect must ensure that run-time qualities can be
assessed and, depending on the constraint defined, any constraints
assessed. If a requirement states that all communication between the
system and external systems be encrypted, for example, there must be
some way of capturing the information being passed from the system to
the external systems so that the encryption can be assessed.

Figure 10.3. The Role of the Architect with Respect to Test

In addition, it is in the best interest of the architect to ensure that the

system under development has been tested thoroughly, because the
quality of the resulting system is largely their responsibility, as they are
the technical lead on the project. As such, architects often work with the
test team to ensure that the more challenging requirements on the system
result in a corresponding emphasis on the testing activities. Because the
architect contributes to the prioritizing of requirements (and, therefore,
to the requirements considered within a given iteration) and identifying
the solution elements that satisfy the requirements, the architect is in a
good position to identify those areas of the system that should be tested
at any point in time. The architect also works with the test team to
determine whether any opportunities exist for optimizing the creation of
test harnesses (and test data).
The Architect and Project Management

The purpose of the project management discipline is to provide a

framework for managing the project; to provide practical guidelines for
planning, staffing, executing, and monitoring the project; and to provide a
framework for managing risk.

As mentioned in Chapter 2, “Architecture, Architect, Architecting,” the

architect supports the planning process in terms of scheduling, work
allocation, cost analysis, risk management, and skills acquisition, as
shown in Figure 10.4. In Chapter 2, we conclude that much of the support
provided is because the architecture identifies the significant components
in the system and the relationships between them, and then uses this
information appropriately.
Figure 10.4. The Role of the Architect with Respect to Project Management

Although there is a separation between a person and a role in the process

described in this book (whereby the same person can play many roles), a
particular pitfall is for the same person to take on the role of architect
and Project Manager, as discussed in the sidebar “Pitfall: The Architect
and Project Manager Are the Same Person.”

The Architect and Configuration Management

The purpose of the configuration management discipline is to identify and

manage elements that should be placed under configuration management
control. Many elements need to be accommodated: documents, models,
source code, executable code, project plans, test scripts, and so on. These
elements are versioned individually and also assigned to one or
more configurations, where a configuration defines a particular version of
a system or part of a system. Elements may be entire work products (if a
single file represents the entire work product) or parts of a work product
(if a file represents part of a work product, such as a use-case
specification representing part of the Functional Requirements work
product).

A necessary element of a configuration management strategy is

appropriate tooling that supports a repository of all elements (and,
therefore, of the project work products). The tooling is used throughout
the project life cycle and contains both current and historical versions of
the elements. A good configuration management tool also provides
measurements based on the information it holds, such as the rate of
change of elements (which may provide an indication of stability and may
be of particular interest to the architect).

The repository structure often is a reflection of both the work products

that are defined for the project and, for certain elements, the architecture
that has been defined (when storing models or code, for example). This
alignment makes it easier for team members to identify where to place
their work in the version control system. Therefore, the architect ensures
that appropriate structures are defined, as shown in Figure 10.5. Failing
to perform this alignment is discussed in the sidebar “Pitfall:
Configuration Management Ignores the Architecture.”
Figure 10.5. The Role of the Architect with Respect to Configuration Management

Pitfall: The Architect and Project Manager Are the Same Person

The role of the architect and the role of the Project Manager are both significant
and often time-consuming. These two roles also have very different focuses. A
project in which a single person plays both roles is rarely successful, because there
is always a bias toward one role or the other. As a result, one of these roles is
performed inadequately. The beneficial interplay that always occurs between
architect and Project Manager is also missing, although it may go on in the
person’s head!

This structuring should also minimize the need to compare and merge
changes as practitioners work on the various elements concurrently. In
addition to defining the structure of the elements in the configuration
management repository, the architect helps define the approach to
changing elements stored in the repository. It may be decided that only
one person at a time can work on a source-code file, for example. In this
case, the file in question is locked when it is checked out, meaning that
others can get a copy of the file but cannot change it. If you decide that
two or more practitioners can work on the same file concurrently, it will
be necessary to compare and merge changes when each practitioner
checks his or her changes into the repository.

Configuration management also has a close relationship with any build-

and-release mechanisms in place. Such mechanisms automate the steps
for compiling, testing, and packaging software for distribution. Each step
will result in files being accessed from the configuration management
system so that, for example, the final executable system is constructed
from the correct versions of the constituent parts.

Pitfall: Configuration Management Ignores the Architecture

Development teams can get themselves into real trouble if they pay insufficient
attention to the configuration management strategy. This situation can occur when
a team does not appreciate the relationship between architecture and
configuration management. The main symptom is that a system is built that does
not reflect the changes that have been made in the project work products.

This situation may occur when files are stored in the wrong place in the
configuration management repository because the structure is not well defined.
Old versions of elements (which are stored in the correct repository location) are
then used by practitioners in preference to the most recent versions (which are
stored in the wrong repository location).

Another reason is that changes in files are lost as different practitioners fail to
compare and merge their changes correctly when too many practitioners are
allowed to work on the same files at the same time. This situation typically is the
result of inadequate consideration of what information is stored in what files and
how the files are likely to be accessed by practitioners in doing their work.
Both of these challenges can be influenced by the architect, who is able to make
informed decisions regarding the files being stored and the access that will be
required. The architect in particular wants to encourage as much concurrent work
as possible while ensuring that a simple configuration management repository
structure is in place, with associated policies.

The Architect and Change Management

Another discipline closely related to configuration management is change

management. The purpose of the change management discipline is to
restrict and audit changes to work products. In particular, a change
management discipline includes consideration of the organization
elements required (such as a change-control board) to assess the cost,
schedule, and impact of a change in an existing system. It also includes the
ability to track changes in work products, which serves as a history and
rationale of changes made in the software. Finally, the change
management discipline is concerned with measuring the current state of
the product based on the type, number, rate, and severity of defects found
and fixed during the course of product development.

Given this scope, an important benefit of architecting is that it supports

impact analysis, allowing architects to reason about the impact of making
a change before it is undertaken, as shown in Figure 10.6. An architecture
identifies the major architectural elements and their interactions, the
dependencies between elements, and the traceability from these elements
to the requirements that they realize. A change in a requirement can be
analyzed in terms of the impact on the elements that collaborate to
realize this requirement, for example. Similarly, the impact of changing a
given element can be analyzed in terms of the other elements that depend
on it. Such an analysis can also greatly assist in determining the cost of a
change and the risk associated with making the change. This information
is used when the change-control board (in which the architect
participates) prioritizes the change.
Figure 10.6. The Role of the Architect with Respect to Change Management
The Architect and the Development Environment

The purpose of the development environment discipline is to provide a

software development environment that will support the development
team. The environment itself comprises several elements and, in larger
organizations, may have a department or team that is dedicated to
providing this environment. This team may even include the role of a
development environment architect (Eeles 2008).

The elements of a development environment include a method or process

that describes how the members of the development team should work
together, tools to automate aspects of the method, materials for enabling
team members in particular skills, and infrastructure to support the
method, tools, and enablement. In addition, the environment may include
the organization that supports the environment, such as a dedicated
support department, as well as guidance on how a project adopts the
environment.

The architect is involved in several of these elements, as shown in Figure

10.7. The architect is responsible, for example, for defining any
architecture standards or guidelines that the team should use (including
any standard for documenting the architecture) that are part of the
method. In general terms, a standard is something that must be adhered
to and, from an architecture-related perspective, could encompass
technology standards (such as Java Enterprise Edition [EE] standards),
development standards (such as design or programming standards), and
so on. A guideline, on the other hand, provides prescriptive guidance on
how to undertake one or more activities (such as how to identify
architecturally significant solution elements from the system
requirements).
Figure 10.7. The Role of the Architect with Respect to the Development
Environment
The architect also provides input on any tools selected, because these
tools need to support the development standards that the architect has
mandated. If the architect has stipulated that Unified Modeling Language
(UML) will be used for documenting the architecture and detailed design,
for example, a suitable UML modeling tool is required. Similarly, if the
implementation technology is Java-based, appropriate Java tooling is
required. In addition, the architect ensures appropriate integration
between the tools, such as the ability to transform from UML to Java code
(in the example given), and vice versa, if these transformations are
considered to be desirable. This thinking, of course, can be applied to
other technology stacks, such as .NET. The architect also ensures that an
appropriate infrastructure is in place to support not only the
development tooling, but also the execution and test of the system under
consideration.

The Architect and Business Analysis

The architect may want to undertake business analysis to gain an

understanding of current problems in the organization and identify areas
of potential improvement. This improvement may be provided through
the implementation of applications that automate aspects of the business.
Such automation may address problems such as poor performance or
excessive human error, for example.

Business analysis may also be undertaken to ensure that customers, end

users, and developers have a common understanding of the structure of
the target organization. This understanding may be communicated as
precise definitions of roles, responsibilities, and interactions between
elements of the organization. This understanding often takes the form of
a Target Operating Model (TOM) or organizational blueprint.
Business analysis can also be undertaken when deriving requirements on
applications that are built to support the organization. A particular
application may be required to interoperate with other applications (that
automate other aspects of the business), for example, and may be
accessed by certain roles within the organization (that might result in a
requirement to access the application through certain devices, such as a
cell phone for mobile users).

On a closely related note, business analysis is also undertaken when a

perspective that spans individual applications is required and business
alignment is valuable. An excellent example is the identification of
common business tasks and entities that ultimately leads to the
identification of business-relevant services in a service-oriented
architecture (SOA). Such services may support the execution of several
business processes and are reused within several applications.

The outputs from business analysis is discussed, to some extent,

in Chapter 7, “Defining the Requirements,” where we consider the use of
the Business Process Model, Business Entity Model, and Business
Rules work products. These work products are used to derive the system
requirements needed to support the target organization. In some
situations, such work products are not readily available. Understanding
the broader context within which the system exists can be of great value,
however, so the only option is for the development team that is delivering
the system to perform some amount of business analysis. This is why we
include this discipline in this discussion.

All the business analysis work products influence the work of the
architect either directly or indirectly. These work products influence the
system requirements and therefore indirectly influence the work of the
architect. The architect also appreciates the broader context within which
the system must operate, however, and refers to the business analysis
work products, if they exist.

THE ARCHITECT AND EXTERNAL INFLUENCES

The architecture of an IT system, which is the focus of this book, is not
developed in isolation. Several external influences guide its definition and
must be taken into account if the system is to meet all its requirements
and address the stakeholder concerns. In particular, four external
influences nearly always need to be considered in the context of the
project that is responsible for developing a system (including its
architecture). These external influences are

• Enterprise architecture
• Design authority
• Infrastructure provider
• Application maintenance provider

These influences and their relationships to the development project and

the associated system are shown in Figure 10.8 and described in the
sections that follow. Both enterprise architect and enterprise architecture
are included.
Figure 10.8. External Influences on the IT System Architecture

The relationships shown in Figure 10.8 are

• Enterprise architect, design authority, infrastructure provider, and

application maintenance provider are all kinds of stakeholders.
• Enterprise architects create an enterprise architecture.
• An enterprise architecture provides guidance for a development project.
• A design authority governs the development project.
• A development project develops a system.
• A design authority interprets the policies and principles laid down by
the enterprise architecture.
• An infrastructure provider runs the deployed system when the
development project is complete.
• An application maintenance provider maintains the system after it has
been deployed.

Enterprise Architecture

According to The Open Group Architecture Framework (TOGAF), the

primary reason for developing enterprise architecture is

To support the business by providing the fundamental technology and

process structure for an IT strategy. This in turn makes IT a responsive
asset for a successful modern business strategy. (TOGAF 2009)

Although there is no industry-wide agreement on exactly what enterprise

architecture is, most descriptions seem to agree that it should cover these
four areas:

• Business architecture.This area includes the strategies, goals, policies,

key business processes, and organizational aspects (roles and
organizational structures) of the business.
• Information architecture.This area includes the key information
assets of the organization, including logical and physical data models,
resources, and metadata.
• Application architecture.This area includes inventories and logical
and physical models that describe the application software and interfaces,
and how they support the business processes of the organization.
• Technology architecture.This area describes the physical hardware
needed to support the deployment of the applications and data. It
typically also includes middleware, database software, communications,
transaction processing, operating systems, and programming languages.

This book is not about enterprise architecture, but it recognizes that

when an organization has defined such an architecture, systems that are
built need to comply with the areas that the enterprise architecture
covers. Several work products that we introduce in earlier chapters may
be in the domain of the enterprise architecture and act as inputs into the
tasks in the architecting process we describe in Chapters 7 through 9.
• Enterprise Architecture Principles.We envisage these principles as
covering one or more of the four architecture areas just described and see
it as the role of the design authority to ensure that the project team
developing the system complies with those principles.
• Business Entity Model.This work product defines the main business
entities in the enterprise as part of the information architecture.
Architects use a subset of this work product to define the logical Data
Model.
• Business Process Model.This work product defines the key business
processes that form the business architecture.
• Business Rules.This work product defines the key business rules that
govern how the business operates and is also part of the business
architecture.
• Existing IT Environment.This work product may be developed by the
enterprise architect as part of the application and technology
architecture. It is a catalog of parts that describes the current IT systems.

Design Authority

The design authority is responsible for the overall technical integrity of

the system and provides the necessary governance that links the IT
system under development to the enterprise architecture goals,
strategies, and principles, thus ensuring that the system will meet the
requirements. One of the key reasons for having a separate design
authority overseeing the development of a system is to reduce the risk of
cost overruns or failure to meet the requirements or schedule. A design
authority can take various forms, depending on the size and complexity of
the system:

• For a small system, the design authority may be just the Lead Architect.
The system is small enough that it can be understood by one person, who
can ensure the overall technical integrity is being maintained.
• For a system of medium complexity, the design authority may be a
dedicated architect with one or more specialist architects reporting to
him or her on a part-time basis.
• For a large and complex system, the design authority may consist of a
full time team of architects with a design authority lead and various
specialist roles reporting to the team.
The responsibilities of the design authority are many and varied, but most
design authorities assume at least the following responsibilities:

• Define and run the various controls that are needed to ensure that the
architecture is developed consistently and supports the requirements.
• Ensure compliance with all mandated internal and external standards
and regulatory controls.
• Ensure that an effective development process (and tooling) is in place
and is being followed.
• Be accountable to the various stakeholders that have concerns and
interests in the system, and act as the interface between the technical
team developing and building the system and the stakeholders.

Design authorities sometimes are incorrectly called technical design

authorities. In the authors’ opinion, however, a design authority should be
a mixture of business and technical roles, so to prevent confusion, the
term technical probably should not be used.

The work products discussed in the process described in this book, which
are relevant to the design authority, are

• The Enterprise Architecture Principles developed by the enterprise

architects that need to be complied with
• The Architecture Decisions to which the design authority contributes
• The Architecture Assessment that is produced as the result of
performing an architecture validation (one of the key ways of ensuring
compliance with internal and external standards)

Infrastructure Provider

When a system has been developed, it needs to be operated on a suitable

infrastructure (that is, on computer platforms, networks, and other
hardware). The organization providing this infrastructure may or may
not be part of the organization for which the system was built. In the era
of cloud computing, the infrastructure provider often is external to the
organization that uses the system.

To know what it needs to do to run and operate the system, the

infrastructure provider needs to be involved in the development process
as a key stakeholder. The infrastructure provider provides input into
the Non-Functional Requirements (since the provider needs to convey
what is and isn’t possible) and is involved in developing the Deployment
Model, which is the primary work product that describes the
infrastructure to be built. The provider is involved in any architecture
reviews and has an interest in the Architecture Assessment work
product that is the result of performing an architecture validation.

Application Maintenance Provider

Just as the infrastructure provider may be an external provider, so may

the people who maintain the application after the system has been
developed and deployed, particularly when economies of scale can be
obtained by having multiple applications maintained by dedicated
maintenance staff. More likely, however, applications are maintained
remotely in regions that have lower labor costs and that can provide
dedicated maintenance teams around the clock.

The application maintenance provider clearly needs to understand the

details of the applications to be maintained, so it needs to provide its
requirements early in the development of the system. These
requirements usually focus on particular qualities that need to be
achieved, such as maintainability, portability, and manageability, because
they may indicate constraints on what is possible or, alternatively, want
early indicators of skills and resources that they may need to acquire. As
such, the application maintenance provider usually is one of the
stakeholders providing input into the Non-Functional
Requirements work product. This provider also is interested in
the Functional Model and Data Model in particular, as these models
provide high-level descriptions of the applications and data that need to
be maintained.

ARCHITECTING COMPLEX SYSTEMS

In Chapters 7 through 9, we have looked at the approach that an architect
might take in architecting a relatively straightforward system for a
medium-scale project—that is, one that has between 10 and 100 people
working on it. In this section, we look at some of the challenges of
architecting complex systems, such as those that involve systems of
systems with more than 100 people typically being involved in the
development. Figure 10.9 shows a summary of such complexities and the
best practices that are used to address them.
Figure 10.9. Challenges of Complex Systems and Associated Best Practices

These characteristics are not necessarily independent, of course. A system

that has a large number of functions to be developed is also likely to need
a large number of people to develop those functions. Separating the
various challenges, however, allows us to describe each challenge in the
following sections. For each challenge, we discuss the following:

• Why the characteristic is considered to be a property of a complex

system
• Any additional considerations that should be made when developing the
architecture of such a system
• The effect on the architecture tasks that allow the architect to develop
the architecture for such a system

Many Distinct Functions Are Being Developed

A system that is large in scope is not necessarily complex. The system

may have many screens to create or many transactions to be described,
for example. If all these elements follow a common pattern, the challenge
is simply one of manpower, not of complexity. If such patterns are not
readily visible, however, the system is deemed to be complex due to its
sheer size. This situation has ripple effects in all aspects of the
development effort, from requirements to architecture to coding to test.

In terms of the architecture and the tasks performed by the architect,

separation of concerns is a sensible approach to managing such
complexity. This topic is discussed in the sidebar “Best Practice: Ensure
That the Architecture Is Componentized Appropriately.”

Many People Are Involved in Development

Many metrics can be used to measure the size of a system. One metric that
is sure to indicate system complexity is the number of resources (people)
required to develop the system. The complexity arises not through the
sheer amount of work to be performed, but through the communication
that is required among the people. Such communication channels
sometimes break down, such as when important messages do not
propagate to those who need to know. In addition, it is important for the
work itself to be coordinated in an appropriate manner and every effort
should be made to ensure that everyone is working to plan, delivering the
various project work products at the right time and in the right order.

Best Practice: Ensure That the Architecture Is Componentized Appropriately

Appropriate chunking or componentization of the architecture can help you

address many challenges of complex systems. In preceding chapters, we discuss
several techniques that fall into the category of componentization:

• Consideration of the architecture at both a logical and physical level.A

logical architecture in particular can provide a set of high-level abstractions that
allows you to reason about the complexity.
• Consideration of a layered architecture.Different elements of the architecture
reside in different layers, which can help you by providing suitable homes for the
architectural elements.
• Consideration of subsystems.Separation of the architecture into subsystems,
with each subsystem comprising a cohesive set of elements, can help you focus on
the bigger picture without getting bogged down in the detail.
• Consideration of coupling and cohesion heuristics when identifying
components.Separation of the architecture into components (in the most general
sense) that have a cohesive set of responsibilities and well-defined interfaces, and
that are reused throughout the architecture, can also help you manage complexity.
These heuristics apply equally to deployment elements in accommodating a highly
distributed system.

These techniques translate into distinct practices and tasks performed by the
architect.

When many teams are involved in a project, it is crucial to develop an

outline architecture as soon as possible to allow the project to be
structured based on a separation of concerns (such as a team per
subsystem), because the allocation of resources and work items is
influenced by the architecture to some extent. If a packaged application is
to be used to implement a major aspect of the system, for example, the
sooner this situation is identified, the better, because a significant portion
of the effort (and therefore resources) may need to focus on customizing
this packaged application, and this task may require particular skills to be
available at a particular time.

Again, this situation can benefit from an appropriate separation of

concerns, as discussed in the preceding sidebar, “Best Practice: Ensure
That the Architecture Is Componentized Appropriately.” In addition, to
ensure the integrity of the architecture, it is wise to establish architecture
standards for the development and to ensure that these standards are
adopted through appropriate governance, as described in the sidebar
“Best Practice: Establish and Govern Architecture Standards.”

Best Practice: Establish and Govern Architecture Standards

To ensure the integrity of the architecture across the team (which may be large
and distributed), it is important to establish the relevant standards that all team
members conform to when designing or developing the solution. Such standards
may include architecture and design patterns to be applied, modeling standards,
and programming standards. Enforcement of such standards can be governed by a
design authority, if one is in place.

If the application of a standard results in work products being created in a

consistent form (all components must expose one or more interfaces, for example),
it may be possible to automate adherence to such standards if supporting
development tools are available.
A particular industry standard for thinking about automation as a fundamental
aspect of the development approach is provided by the Model Driven Architecture
(MDA) initiative from the Object Management Group (OMG). MDA defines several
concepts, as shown in Figure 10.10.

Figure 10.10. MDA Concepts and Terminology

MDA defines several categories of models:

• Computation Independent Model (CIM).This model defines elements that are

independent of the type of solution, whether this solution is software, hardware,
or people. Business models fall into this category and include the Business
Process Model and Business Entity Model.
• Platform Independent Model (PIM).This model defines elements that are
technology independent. The Functional Requirements, Non-Functional
Requirements, logical Functional Model, and logical Deployment Model fall
into this category.
• Platform Specific Model (PSM).This model acknowledges technology. The
physical Functional Model and physical Deployment Model fall into this
category.
• Code.Although not often considered to be a model, the source code that
comprises the system is also an abstraction (it must be converted to machine code
before it executes, even if an interpreted language is used, rather than a compiled
language).

A transformation is another concept that MDA emphasizes. A transformation

defines the rules by which a model is transformed into another and is a good way
of enforcing consistency and, therefore, architecture integrity. Figure 10.11 shows
an example in which a PIM is transformed into a PSM for Enterprise JavaBeans
(EJBs, which represent large-grained solution components), a PSM for SQL
(representing the persistent elements in a relational database), and a PSM that
describes the rules for mapping from EJBs to SQL (sometimes referred to as
an object-to-relational mapping). The PSM defining EJBs can be transformed into
code, as can the PSM defining SQL and also the object-to-relational mapping. Each
of these transformations may or may not be automated in a tool. Even if a human
being performs the transformation manually, however, the concept of a
transformation still applies.

Figure 10.11. Transformations from PIM to PSM to Code

The System Is Highly Distributed

The system itself may be deployed across many organizational and

geographic boundaries. Such systems have additional complexity
associated with them because:

• There are additional system interfaces to contend with. These interfaces

support the distributed nature of the system, where elements of the
system must communicate across this distributed environment.
• There may be additional human interfaces to consider. A given
geography may impose particular regional requirements that must be
accommodated.
• There may be additional stakeholders to consider. Additional
geographies may require communication with new stakeholders that
provide input to the project.
• Additional operational considerations must be taken into account.
Provision of appropriate networking must be considered, and qualities
such as performance and availability become harder to meet.
• Time-zone differences can also provide challenges in terms of time-
dependent operations. It may not be clear when it would be appropriate
to schedule batch runs if an off-peak period is preferred for such actions,
for example. Also, it may be appropriate to perform certain operations at
the end of the business day (particularly in financial institutions), but the
concept of “end of day” is unclear.
• It may be necessary to segregate business data for both technical and
regulatory reasons.
• Deployment across the distributed environment involves more
locations. Each location may have its own nuances that need to be
accommodated.

In terms of the architecture, a focus on the deployment aspects of the

system can help address some of these challenges. The Deployment
Model work product, for example, allows the various deployment
elements to be debated, such as locations, nodes, and the connections
between them. In addition, the architect models locations in terms of both
logical (such as a Store) and physical (such as Orlando store and Tampa
store) elements, for example, allowing the consideration of placement of
functional elements on deployment elements to be made very early in the
process. In addition, architecting highly distributed systems can benefit
from an appropriate separation of concerns, as discussed earlier in this
chapter in the sidebar “Best Practice: Ensure That the Architecture Is
Componentized Appropriately.”

The Development Team Is Distributed

Complex systems are often developed by teams that are not physically co-
located. There are many reasons for this arrangement, including cost
reduction through the use of cheaper labor (from a supplier in a different
location), and shortened delivery times by allowing development to
proceed around the clock (by developers in different geographies and
time zones). Although distributed development may indeed help, it also
adds to the complexity. Communication between individuals becomes
more difficult when different languages, time zones, and cultures are
taken into consideration, for example. In addition, appropriate
architectural and project governance needs to be in place to ensure that
the elements of the system are delivered as required.

In particular, it is essential that clear and unambiguous specifications,

along with any standards that must be adhered to, be produced and
delivered to any remote teams. The deliverables required and acceptance
criteria must also be very clearly defined. The architect can help ensure
that such an approach is taken.

Geographically distributed development can benefit from an appropriate

separation of concerns, as discussed in the sidebar “Best Practice: Ensure
That the Architecture Is Componentized Appropriately” earlier in this
chapter. This separation will allow the system to be subdivided in a
manner that effectively supports a level of concurrent development. In
addition, for the various teams to work consistently and to ensure the
integrity of the architecture, there should be a focus on relevant
standards that should be adopted, together with an appropriate and
consistent development toolset, as described earlier in this chapter in the
sidebar “Best Practice: Establish and Govern Architecture Standards.”

Use standards to express architectural concerns that cross geographic

boundaries. This technique may extend to organizational boundaries,
which can be as severe as distant geographic location. It might even
extend to organizations separated only by one floor in a building. Small
geographic distances can loom large if the building architecture doesn’t
support close interworking. (Coplien 2005)

Another focus when dealing with distributed teams is the manner in

which the teams’ work is coordinated and integrated. From a
coordination perspective, this task comes down largely to project
management, in that the content of the architecture can help guide the
project planning. The architecture can also guide the sequence in which
independently developed elements of the system are brought together,
integrated, and tested as a unit. There may also be a focus on validation
and verification tasks to ensure that the distributed teams are both
delivering the right thing and delivering the thing right.

Operational Qualities Are Extremely Challenging

A system may need to exhibit operational (run-time) qualities that are

extremely challenging. Service levels such as ensuring the system is
available 99.999 percent of the time, supporting very rapid response
times in a distributed system, or moving large amounts of data around in
a sensible time frame are all challenging. Such complex operational
environments require the architect to balance the sometimes-conflicting
non-functional requirements of, say, achieving high-performance service
levels and at the same time delivering on time and to a given budget.

As discussed in Chapters 7 through 9, it is critical from the outset to focus

actively on the non-functional requirements, on the development of those
requirements and on an approach for addressing them. For systems with
difficult or challenging non-functional requirements, there is even more
reason to focus on them. A life-support machine that does not meet its
availability requirements will never see the light of day, for example.
Therefore, such requirements can represent the most-challenging
requirements of the system under development. As a result, architects
often place corresponding emphasis on proving that such qualities have
been addressed by creating relevant architecture proofs of concept. The
emphasis on such qualities is discussed in the sidebar “Best Practice:
Ensure That Qualities Drive the Architecture Definition.”

Where a system must address a particularly challenging quality or

capability, it is appropriate to select a viewpoint that provides the
necessary focus and that is populated using appropriate work products.
Some examples of such viewpoints and associated work products are

• Usability Viewpoint.For systems that have challenging usability

requirements, such as user interfaces that may potentially be used by
thousands or even millions of users, there may be a complete sub-project
that deals with this aspect of the system. If this is the case, then a usability
cross-cutting viewpoint may be selected that is populated by specific
Usability Requirements and User Interface Model work products.
• Performance Viewpoint.Where high-performance systems are to be
built, the Performance cross-cutting viewpoint described in Chapter 4,
“Documenting a Software Architecture,” may be populated by a specific
Performance Model work product. Performance models are used to
establish whether the system is likely to meet all of its performance
requirements by using simulation, measurement, benchmarking, and
rules of thumb to validate how the system is likely to perform.
• Availability Viewpoint.For systems that need to be highly available,
the Availability cross-cutting viewpoint described in Chapter 4,
“Documenting a Software Architecture,” may be populated by a specific
Availability Model. Availability models use various modeling techniques
such as reliability graphs and fault trees to establish the likely availability
of a system.
Best Practice: Ensure That Qualities Drive the Architecture Definition

The architecture of a system is not wholly focused on functionality provided by the

system; it is equally concerned with the qualities that the executing system
exhibits. The architect is responsible for ensuring that these qualities meet or
exceed the requirements on the system. Therefore, it is essential for the architect
to ensure that such qualities are captured, described, considered, and verified
throughout the course of the project.

• Security Viewpoint.When security is a particular concern, the Security

cross-cutting viewpoint described in Chapter 4, “Documenting a Software
Architecture,” may be populated by Security Requirements, Security
Architecture, and Security Threat Analysis work products.

There Is a System of Systems

Another characteristic of complex systems is that they may be composed

of subsystems that are significant enough to be considered systems in
their own right. Also, the system for which an architect is responsible may
actually be a subsystem of something much larger. Both situations could
be true, as shown in Figure 10.12, which shows a system (System C) in
context of those systems with which it is related.
Figure 10.12. A System of Systems
In this figure, System C is a subsystem of System A and has three
subsystems of its own: E, F, and G. All the systems in question may be
developed within their own projects and have their own architecture. The
systems are not completely independent, of course—something that we
explore in this section. Acknowledgment of a system-of-systems approach
is described in more detail in the sidebar “Best Practice: Formally
Describe the Architecture as a System of Systems.”

Best Practice: Formally Describe the Architecture as a System of Systems

The decomposition of a system into a number of subsystems is widely recognized

and described in the system of interconnected systems architectural pattern
(Jacobson 1997). This pattern can be used to describe the relationship between a
system and its subsystems. In the pattern, the overall system is referred to as
the superordinate system, whereas each of the subsystems is referred to as
a subordinate system. An important characteristic of the pattern is that it
is recursive, meaning that a subordinate system may also have subsystems of its
own and be superordinate in relation to them. The system of interconnected
systems pattern can be applied to many initiatives, such as the following:

• Service-oriented architecture (SOA).In this case, the SOA can itself be

considered to be the system (normally at an enterprise-wide or organization-wide
level), with each service representing a subsystem within the SOA.
• Enterprise architecture.As discussed in Chapter 2, “Architecture, Architect,
Architecting,” an enterprise architecture considers elements of hardware,
software, people, and information with a link to business objectives such as
business agility and organizational efficiency. In terms of the pattern, the
enterprise represents the overall system, where the elements of the enterprise
represent the subsystems.
• Systems engineering.Similarly, systems engineering is concerned with
hardware, software, people, and information. The system as a whole can be
decomposed into subsystems that may also contain each of these different types of
elements.
• Strategic reuse.Reusable assets by definition do not exist in isolation (because
they are intended to be reused within several contexts). A fundamental premise of
any strategic reuse initiative, therefore, is to define the services that each asset
provides and any services that the asset requires. These assets and their
relationships can be described in terms of a system of systems, where the
containing asset represents the system and the reused asset represents a
subsystem. This thinking is particularly relevant to the creation of a software
product line representing a set of systems that applies to a particular industry
segment and that is created from a common set of reusable assets. Software
product lines are discussed in detail in Design and Use of Software Architectures:
Adopting and Evolving a Product-Line Approach (Bosch 2000) and Software
Product Lines: Practices and Patterns (Clements 2001).
• Application integration.Application integration is concerned with developing a
solution that includes the integration of several existing systems. Such efforts are
driven to a large extent from the bottom up because elements of the solution
already exist, but some top-down effort is still required to understand the context
within which such existing systems will fit. Often, techniques such as wrapping
interfaces to existing software applications are required, together with a good
understanding of available middleware technologies that can be used to interact
with such applications. With regard to the system of interconnected systems
pattern, the integrated enterprise application is considered to be the overall
system, and each integrated application is considered to represent a subsystem.
• Packaged application development.Packaged applications can be considered
to be customizable frameworks that allow you to build a family of related
applications that support a certain aspect of a business, such as customer
relationship management or human resources. These frameworks can be
considered at two levels. First, such frameworks often implement a piece of a
larger system. In this context, the packaged application (or a piece of the packaged
application) represents a subsystem. Second, such frameworks are often large and
complex, and thinking of them as systems in their own right can help you
understand how the packaged application will be applied in terms of what pieces
will be used as is, what pieces will be used after modification or configuration, and
what pieces will not be used at all. Indeed, such applications are often split into
modules, each having specific application functions that can be considered
subsystems in their own right.

In describing a system of systems, various architectural principles need to

be accommodated, a formalism of which can be found in the Model-
Driven Systems Development approach from IBM Rational (MDSD 2009),
formerly known as RUP for Systems Engineering (RUP SE), which is now
part of the Rational Unified Process (RUP 2008). This is the work of Dr.
Murray Cantor and others. MDSD specifically supports systems
engineering initiatives (but can be applied to other initiatives too), where
a system is defined as follows:

[A system is] a set of resources that provide services that are used by an
enterprise to carry out a business purpose or mission. System
components typically consist of hardware, software, data, and workers.
(Cantor 2003)

The neat thing about the MDSD approach is the set of techniques for the
allocation of system requirements to subsystems (both functional and
non-functional), in which a subsystem itself may also comprise software,
hardware, people, and data. One of these key techniques, joint realization,
is one of the cornerstones of MDSD. This technique shows how both
system functional and non-functional requirements are jointly realized
across the different types of element that comprise the system, in terms of
software, hardware, people, and data. MDSD attempts to tackle, head on,
the well-known problems that arise when such elements are considered
in isolation.

The result of applying the MDSD approach is a set of loosely coupled and
highly cohesive subsystems, each with its own set of requirements
(functional requirements to be met, qualities to be exhibited, and
constraints to be accommodated) that allows each subsystem to be
treated as a system in its own right.

SUMMARY
This chapter complements earlier chapters by introducing topics not
discussed elsewhere in this book—typically, those that are beyond a basic
understanding of the role of the architect in a typical software
development project.

In particular, we examined the involvement of the architect with respect

to several software development disciplines not discussed earlier in the
book, as well as some additional considerations of the architect when
faced with complex systems. This chapter has only scratched the surface
of addressing the challenges of complex systems, however. This area is
receiving much-deserved attention in the industry.

IN CONCLUSION: A NOTE FROM THE AUTHORS

As stated at the start of this book, our purpose is to convey a series of
practices that can be applied in total or in part to the process of
architecting. We’ve tried to build a foundation of essential knowledge that
every architect should have and that we’ve gradually built on during the
course of this book, concluding with a discussion of more advanced topics
that are themselves worthy of a book of their own.

However you use the content of this book, and whether you’re an aspiring
architect or an advanced practitioner, we hope that your application of
the various practices is successful. Finally, remember that even the best of
best practices can be improved!

Appendix A. Software Architecture Metamodel

This appendix contains the complete definition of the metamodel of

concepts used within this book.

The relationships in the metamodel shown in Figure A.1 are

• A system has an architecture.

• A system fulfills one or more missions.
• A system has one or more stakeholders.
• A system inhabits an environment.
• An environment influences a system.
• An architecture is described by an architectural description.
• An architectural description identifies one or more stakeholders.
• An architectural description identifies one or more concerns.
• An architectural description provides a rationale.
• A stakeholder has one or more concerns.
• A concern is important to one or more stakeholders.
• A development project is staffed by a team.
• A development project follows a development process.
• A development project develops a system.
• The development process includes architecting.
• The team includes an architect.
• The architect performs architecting.
• The architect creates an architecture.
• The architect is a kind of stakeholder.
• Architecting results in an architecture.
• Rationale justifies one or more architecture decisions.
• An architecture decision addresses one or more concerns.
• An architectural description is organized by one or more views.
• A view consists of one or more models.
• A model participates in one or more views.
• A model participates in one or more architectural descriptions.
• A view conforms to a viewpoint.
• An architectural description selects one or more viewpoints.
• A viewpoint established methods for one or more models.
• A viewpoint is used to cover one or more concerns.
Figure A.1. Software Architecture Metamodel
DEFINITION OF METAMODEL TERMS

This section contains a definition of the terms used in the metamodel.

architect

The person, team, or organization responsible for systems architecture.

(IEEE 1471 2000) This term is synonymous with software architect.

architecting

The activities of dening, documenting, maintaining, improving, and

certifying proper implementation of an architecture. (IEEE 1471 2000)
This term is synonymous with software architecting.

architectural description

A collection of products to document an architecture. (IEEE 1471

2000)

architecture
The fundamental organization of a system embodied in its components,
their relationships to each other, and to the environment, and the
principles guiding its design and evolution. (IEEE 1471 2000)

architecture decision

Conscious design decisions concerning a software system as a whole, or

one or more of its core components. These decisions determine the
non-functional characteristics and quality factors of the system.
(Zimmermann 2008).

concern

Those interests which pertain to the system’s development, its

operation, or any other aspects that are critical or otherwise important
to one or more stakeholders. Concerns include system considerations
such as performance, reliability, security, distribution, and evolvability.
(IEEE 1471 2000)

development process

A set of partially ordered steps performed for a given purpose during

system development, such as constructing models or implementing
models. (UML 2.0 2003)

development project

A project is a temporary endeavor undertaken to create a unique

product or service. Temporary means that every project has a definite
beginning and a definite ending. Unique means that the product or
service is different in some distinguishing way from all similar products
and services. Projects are often critical components of the performing
organizations’ business strategy. (RUP 2008)

environment

The environment, or context, determines the setting and circumstances

of developmental, operational, political, and other influences upon that
system. (IEEE 1471 2000)

mission
A use or operation for which a system is intended by one or more
stakeholders to meet some set of objectives. (IEEE 1471 2000)

model

Models provide the specific description, or content, of an architecture.

For example, a structural view might consist of a set of models of the
system structure. The elements of such models might include
identifiable system components and their interfaces, and
interconnections among those components. (IEEE 1471 2000)

rationale

A set of reasons or a logical basis for a course of action or a belief.

(OED)

stakeholder

An individual, team, or organization (or classes thereof) with interests

in, or concerns relative to, a system. (IEEE 1471 2000)

system

[1] [A software system is] A collection of components organized to

accomplish a specic function or set of functions. The
term system encompasses individual applications, systems in the
traditional sense, subsystems, systems of systems, product lines,
product families, whole enterprises, and other aggregations of interest.
A system exists to fulll one or more missions in its environment. (IEEE
1471 2000)
[2] An integrated composite that consists of one or more of the
processes, hardware, software, facilities, and people, that provides a
capability to satisfy a stated need or objective. (IEEE 12207 1995)

team

A small number of people with complementary skills who are

committed to a common purpose, performance goals, and approach for
which they hold themselves mutually accountable. (Katzenbach 1993)

view
A representation of a whole system from the perspective of a related set
of concerns. (IEEE 1471 2000)

viewpoint

A specification of the conventions for constructing and using a view. A

pattern or template from which to develop individual views by
establishing the purposes and audience for a view and the techniques
for its creation and analysis. (IEEE 1471 2000)

Appendix B. Viewpoint Catalog

This appendix contains a summary of the viewpoints used in this book,

which we introduced in Chapter 4, “Documenting a Software
Architecture.” In that chapter, we discussed the concepts of basic and
cross-cutting viewpoints.

[An architectural viewpoint represents] a specification of the conventions

for constructing and using a view. A pattern or template from which to
develop individual views by establishing the purposes and audience for a
view and the techniques for its creation and analysis. (IEEE 1471 2000)

The various viewpoints are shown in Figure B.1, a figure reproduced

from Chapter 4.
Figure B.1. The Architecture Description Framework
This chapter uses a template to describe each of the viewpoints, which
contains the following items:

• Description.A brief description of the viewpoint.

• Stakeholder concerns.The stakeholder concerns that the viewpoint
addresses.
• Stakeholders.The stakeholders addressed by this viewpoint.
• Work products.The work products that are referenced by a view
defined by this viewpoint.
• Examples.One or more examples.
• Checklist.One or more questions that can be considered when verifying
and validating the architecture or reviewing the architecture with
stakeholders.

An obvious omission in this template is a detailed discussion of the

techniques that you might use when applying the viewpoint. Although
some techniques are discussed in the process-related chapters (Chapters
7 through 9), the omission of specific techniques in this appendix is
deliberate. Many good books are available that can assist with the details
of requirements definition, performance modeling, security management,
and the like.

In considering this catalog, you should remember that the architecture

description standard used in this book can be refined and extended as
required. You may see the inclusion of information, concurrency, and
other viewpoints if you deem them to be of significance for the system
under development, for example.

STAKEHOLDER SUMMARY
Each viewpoint in this catalog lists the stakeholders that are addressed by
the viewpoint. Table B.1 summarizes the stakeholders considered in this
catalog. You can use this summary as a starting point when identifying the
stakeholders in the architecture in any given situation. This table also
indicates the scope of each stakeholder; internal stakeholders are those
within the current development team, whereas external stakeholders are
not. Although not included in this table, it is assumed that the architect is
a stakeholder in all viewpoints.

Table B.1. Stakeholder Summary

BASIC VIEWPOINTS
This section contains descriptions of the basic viewpoints.

Requirements Viewpoint

Functional Viewpoint

Deployment Viewpoint
Validation Viewpoint
CROSS-CUTTING VIEWPOINTS
This section describes each of the cross-cutting viewpoints.

Application Viewpoint

Infrastructure Viewpoint
Systems Management Viewpoint

Availability Viewpoint

Performance Viewpoint
Security Viewpoint

VIEW CORRESPONDENCE
Not included in the descriptions of the preceding viewpoints are any
relationships between a view defined by a given viewpoint and any other
views. The placement of a component on a node is a concern of both a
functional view and a deployment view, for example, and you may want
all components identified in the functional view to be deployed to nodes
in the deployment view.
Rather than describe view correspondence in each of the preceding
sections, we chose to minimize duplication by providing Table
B.2 instead. This table indicates the correspondence between all the
views in the architecture description framework. The intention is to allow
you to look across the rows for each viewpoint you are adopting to see
what correspondence (and, therefore, completeness and consistency)
needs to exist.

Table B.2. View Correspondence

Appendix C. Method Summary

This appendix contains a summary of the method referred to in this book.

An overview of the fundamental concepts associated with a method is
provided in Chapter 3, “Method Fundamentals.”

ROLES
A role defines the behavior and responsibilities of an individual or a set of
individuals working together as a team, within the context of a software
development organization. A role is responsible for one or more work
products and performs a set of tasks.

The roles within the project team (as described in this book) are shown
in Figure C.1.
Figure C.1. The Project Team

Table C.1 provides a summary of the roles within the project team.

Table C.1. Role Summary

WORK PRODUCTS
A work product is a piece of information or physical entity that is
produced and/or used during the execution of the process. Examples of
work products include models, plans, code, executables, documents,
databases, and so on. The work products used in this book are shown
in Table C.2.

Table C.2. Work Product Summary

Figure C.2 shows the alignment of work products and viewpoints.

Figure C.2. Viewpoints and Work Products

ACTIVITIES
An activity represents a grouping of tasks. The activities described
in Figure C.3 follow the flow described in Chapter 7, “Defining the
Requirements,” Chapter 8, “Creating the Logical Architecture,”
and Chapter 9, “Creating the Physical Architecture.” In addition, this
figure shows the more detailed design activities that would be
undertaken within the overall development process, although these
activities are not discussed in detail in this book. You should remember
that in an iterative development process, each of these activities is
executed within a single iteration.
Figure C.3. Activity Overview

TASKS
A task is a unit of work that provides a meaningful result in the context of
the project. It has a clear purpose, which usually involves creating or
updating artifacts. In the following sections, the various tasks are grouped
according to the activity to which they belong. Each activity has an overall
activity diagram that shows the flow between the tasks, as well as a table
that summarizes the steps for each task.

Activity: Define Requirements

The flow between the tasks that comprise the Define

Requirements activity is shown in Figure C.4 and a summary of each task
is given in Table C.3.
Figure C.4. Tasks in the Define Requirements Activity

Table C.3. Define Requirements: Task Summary

Activity: Create Logical Architecture

The flow between the tasks that comprise the Create Logical
Architecture activity is shown in Figure C.5 and a summary of each task
is given in Table C.4.
Figure C.5. Tasks in the Create Logical Architecture Activity
Table C.4. Create Logical Architecture: Task Summary
Activity: Create Physical Architecture

The work products are identical to those in the Create Logical

Architecture activity and are not repeated here.

PHASES
[A phase is] a specialized type of activity that represents a significant
period in a project normally ending with a decision checkpoint, major
milestones, or a set of deliverables. Phases typically have well defined
objectives and provide the basis for how the project work will be
structured. (OpenUP 2008)

Inception

The Inception phase is where the business case for the project is
established and concurrence among all stakeholders on the objectives for
the project is established. Inception is where the architect focuses on
ensuring that the project is both valuable and feasible. Table C.5 presents
a summary of the objectives and milestone evaluation criteria for the
Inception phase.

Table C.5. Inception Phase Summary

Elaboration

The Elaboration phase is where the architecture is established to provide

a stable foundation for the design and implementation that is performed
during the Construction phase. This phase, therefore, is of particular
relevance to architects and certainly is where architects expend the
majority of their effort. Table C.6 presents a summary of the objectives
and milestone evaluation criteria for the Elaboration phase.

Table C.6. Elaboration Phase Summary

Construction

The Construction phase is where the remaining requirements are

clarified and development of the system is completed against the
baselined architecture established during the Elaboration phase. Between
the Elaboration and Construction phases, the focus shifts from
understanding the problem and identifying key elements of the solution
to developing a deployable product. Table C.7 presents a summary of the
objectives and milestone evaluation criteria for the Construction phase.

Table C.7. Construction Phase Summary

Transition

The Transition phase is where the architect ensures that the software is
available to, and accepted by, its end users. This phase is where the
system is deployed into the user’s environment for evaluation and testing.
The focus is on fine-tuning the product and on addressing configuration,
installation, and usability issues. By the end of the Transition phase, the
project should be in a position to be closed out. Table C.8 presents the
objective and milestone evaluation criterion for the Transition phase.

Table C.8. Transition Phase Summary

Appendix D. Architectural Requirement

Checklist

This appendix contains a checklist of potential requirements that have

particular architectural significance. Such a checklist can be used when
gathering stakeholder requests and when reviewing requirements, for
example.

There are several classifications of requirement types. One such

classification is the FURPS classification (Grady 1992); the acronym
stands for functionality, usability, reliability, performance,
and supportability. A similar classification is defined in ISO standard 9126
(ISO 9126 2001), where requirements are classified for external and
internal quality and for quality in use. In this standard, “external and
internal quality characteristics” are functionality, reliability, usability,
efficiency, maintainability, and portability. Quality in use characteristics
are effectiveness, productivity, safety, and satisfaction. A characterization
of various non-functional requirements (qualities in particular) is also
given in Software Architecture in Practice, 2nd ed. (Bass 2003), where the
authors consider qualities of the system, business qualities, and qualities
of the architecture itself.

The classification used in this book is based on the FURPS classification,

with particular emphasis on non-functional requirements
(the URPS in FURPS). In this appendix, we extend this classification to also
emphasize constraints as an essential part of the checklist (which some
would refer to as FURPS+). You are encouraged to adopt such a checklist,
amend as required, and apply it to your own projects.
FUNCTIONAL REQUIREMENTS
Functional requirements describe functions that the system should exhibit
when used under defined conditions.

Functional requirements usually are specific to the system under

development, so we don’t include a checklist of all functional
requirements that should be considered. Instead, this book advocates
use-case modeling as a technique for capturing the majority of functional
requirements, based on the needs of the actors that interact with the
system.

Some functional requirements are not necessarily best captured in use

cases and are referred to, in this book, as system-wide functional
requirements (in the sense that they are not associated with a particular
use case). A requirement to provide a secure system, for example, is a
functional requirement that pervades the entire system and is not tied to
a particular use case. Table D.1 provides some examples of functional
requirements that happen to be system-wide and that often are of
particular interest to the architect.

Table D.1. Examples of System-Wide Functional Requirements

USABILITY REQUIREMENTS
Usability requirements describe the degree to which the system is
understood and used. Table D.2 defines some usability requirements.

Table D.2. Examples of Usability Requirements

RELIABILITY REQUIREMENTS
Reliability requirements describe the degree to which the system provides
a defined level of operational performance. Table D.3 defines some
reliability requirements.

Table D.3. Examples of Reliability Requirements

PERFORMANCE REQUIREMENTS
Performance requirements describe the degree to which the system
provides a defined level of execution performance. Table D.4 defines
some performance requirements.

Table D.4. Examples of Performance Requirements

SUPPORTABILITY REQUIREMENTS
Supportability requirements describe the degree to which the system can
be supported. Table D.5 defines some supportability requirements.

Table D.5. Examples of Supportability Requirements

CONSTRAINTS
A constraint is a restriction on the degree of freedom we have in
providing a solution. (Leffingwell 2000)

In essence, constraints represent restrictions on the solution, in that they

restrict the available options.

Business Constraints

Some of the constraints imposed upon an architect may come from the
business. Table D.6 defines some constraints that are related to the
business.

Table D.6. Examples of Business Constraints

Architecture Constraints

Various architectural mechanisms may be constrained. Table D.7 defines

some constraints that are imposed on the architecture. Many more
mechanisms may be at play in any given situation, of course.

Table D.7. Examples of Architecture Constraints

Development Constraints

Additional constraints may be imposed on any detailed design and

development. Table D.8 defines some constraints that are imposed on the
development and run-time environments.
Table D.8. Examples of Development Constraints

Physical Constraints

Table D.9 defines some constraints that are imposed by the physical
environment. Such requirements are particularly relevant when the
hardware housing the software is itself constrained in some way. Cellular
phones, airplanes, and military hardware (such as tanks) all place
physical constraints on the computing hardware, for example, and such
constraints may themselves impose constraints on the software that
executes on this hardware.

Table D.9. Examples of Physical Constraints

Glossary

This glossary defines the terms used throughout this book.

activity

A grouping of tasks.

antipattern

A commonly occurring pattern or solution that generates decidedly

negative consequences. An antipattern may be a pattern in the wrong
context. (Brown 1998)

application framework

The partial implementation of a specific area of an application.

architect

The person, team, or organization responsible for systems architecture.

(IEEE 1471 2000) This term is synonymous with software architect.

architecting

The activities of dening, documenting, maintaining, improving, and

certifying proper implementation of an architecture. (IEEE 1471 2000)
This term is synonymous with software architecting.

architectural description

A collection of products to document an architecture. (IEEE 1471

2000)

architectural mechanism

Common concrete solutions to frequently encountered problems. They

may be patterns of structure, patterns of behavior, or both. (SPEM
2007)

architectural style

A family of systems defined in terms of a pattern of structural

organization. More specifically, an architectural style defines a
vocabulary of components and connector types, and a set of constraints
on how they can be combined. (Shaw 1996)
architecture

The fundamental organization of a system embodied in its components,

their relationships to each other, and to the environment, and the
principles guiding its design and evolution. (IEEE 1471 2000)

architecture decision

Conscious design decisions concerning a software system as a whole, or

one or more of its core components. These decisions determine the
non-functional characteristics and quality factors of the system.
(Zimmermann 2008).

business rule

A statement that defines or constrains some aspect of the business. It is

intended to assert business structure or to control or influence the
behavior of the business. (Business Rules Group 2000).

component

A component represents a modular part of a system that encapsulates

its contents and whose manifestation is replaceable within its
environment. A component defines its behavior in terms of provided
and required interfaces. As such, a component serves as a type whose
conformance is defined by these provided and required interfaces
(encompassing both their static as well as dynamic semantics). One
component may therefore be substituted by another only if the two are
type conformant. (UML 2.2 2009)

concern

Those interests that pertain to the system’s development, its operation,

or any other aspects that are critical or otherwise important to one or
more stakeholders. Concerns include system considerations such as
performance, reliability, security, distribution, and evolvability. (IEEE
1471 2000)

constraint

A restriction on the degree of freedom we have in providing a solution.

(Leffingwell 2000)
design authority

The role that takes specific responsibility for the overall technical
integrity of the system and provides the necessary governance that
links the IT system under development to the enterprise architecture
goals, strategies, and principles, thus ensuring the system will meet the
requirements.

development process

A set of partially ordered steps performed for a given purpose during

system development, such as constructing models or implementing
models. (UML 2.0 2003)

development project

A temporary endeavor undertaken to create a unique product or

service. Temporary means that every project has a definite beginning
and a definite ending. Unique means that the product or service is
different in some distinguishing way from all similar products and
services. Projects are often critical components of the performing
organizations’ business strategy. (RUP 2008)

discipline

A primary categorization mechanism for organizing tasks that define a

major “area of concern” and/or cooperation of work effort. (OpenUP
2008)

domain

An area of knowledge or activity characterized by a set of concepts and

terminology understood by practitioners in that area. (UML User Guide
1999)

enterprise architecture

The set of principles, guidelines, policies, models, standards, and

processes that, when aligned with business strategy and information
requirements, guide the selection, creation, and implementation of
solutions that are aligned with future business direction.
environment

The environment, or context, determines the setting and circumstances

of developmental, operational, political, and other inuences upon that
system. (IEEE 1471 2000)

functional requirement

Descriptions of the behaviors (functions or services) of the [IT] system

that support user goals, tasks or activities. (Malan 2001)

iteration

A short and set duration division of a project. Iterations allow you to

demonstrate incremental value and obtain early and continuous
feedback. (OpenUP 2008)

method

A regular and systematic way of accomplishing something; the detailed,

logically ordered plans or procedures followed to accomplish a task or
attain a goal. (RUP 2008)

mission

A use or operation for which a system is intended by one or more

stakeholders to meet some set of objectives. (IEEE 1471 2000)

model

The specific description, or content, of an architecture. For example, a

structural view might consist of a set of models of the system structure.
The elements of such models might include identifiable system
components and their interfaces, and interconnections among those
components. (IEEE 1471 2000)

non-functional requirement

Requirements that include constraints and qualities. (Malan 2001)

packaged application
A large-grained commercial off-the-shelf product that provides a
significant amount of capability (and reuse), such as a
Customer Relationship Management (CRM) application, or an
Enterprise Resource Planning (ERP) application.

pattern

A common solution to a common problem in a given context. (UML

User Guide 1999)

phase

A specialized type of activity that represents a significant period in a

project normally ending with a decision checkpoint, major milestones,
or a set of deliverables. Phases typically have well-defined objectives
and provide the basis for how the project work will be structured.
(OpenUP 2008)

practice

An approach to solving one or several commonly occurring problems.

Practices are intended as “chunks” of process for adoption,
enablement, and configuration. (RUP 2008)

process

See development process.

quality

Properties or characteristics of the system that its stakeholders care

about and hence will affect their degree of satisfaction with the system.
(Malan 2001)

rationale

A set of reasons or a logical basis for a course of action or a belief.

(OED)

reference architecture
An architecture associated with a particular domain of interest and
typically includes many different architectural patterns, applied in
different areas of its structure.

reference model

An abstract representation of entities, their relationships and behavior,

in a given domain of interest, and which typically forms the conceptual
basis for the development of more concrete elements. Examples
include a business model, an information model, and a glossary of
terms.

reusable asset

A solution to a recurring problem. A reusable asset is an asset that has

been developed with reuse in mind (RAS 2004)

role

The responsibilities of an individual, or a set of individuals working

together as a team, within the context of a software development
organization. A role is responsible for one or more work products and
performs a set of tasks.

stakeholder

An individual, team, or organization (or classes thereof) with interests

in, or concerns relative to, a system. (IEEE 1471 2000)

subsystem

A set of related components.

system

[1] A collection of components organized to accomplish a specic

function or set of functions. The term system encompasses individual
applications, systems in the traditional sense, subsystems, systems of
systems, product lines, product families, whole enterprises, and other
aggregations of interest. A system exists to fulll one or more missions in
its environment. (IEEE 1471 2000) [2] An integrated composite that
consists of one or more of the processes, hardware, software, facilities,
and people, that provides a capability to satisfy a stated need or
objective. (IEEE 12207 1995)

task

A unit of work that provides a meaningful result in the context of the

project. It has a clear purpose, which usually involves creating or
updating work products. All tasks are performed by appropriate roles.

team

A small number of people with complementary skills who are

committed to a common purpose, performance goals, and approach for
which they hold themselves mutually accountable. (Katzenbach 1993)

traceability

The mechanism by which we trace (identify and measure) from one set
of development elements to another.

validation

A process that focuses the system as a whole, rather than individual

work products. It is concerned with ensuring that the system satisfies
the stated requirements.

verification

Verification allows us to determine whether the work products, at the

current point in the overall development process, are consistent with
the inputs used to create them (such as other work products and any
development standards that have been mandated).

view

A representation of a whole system from the perspective of a related set

of concerns. (IEEE 1471 2000)

viewpoint

A specification of the conventions for constructing and using a view. A

pattern or template from which to develop individual views by
establishing the purposes and audience for a view and the techniques
for its creation and analysis. (IEEE 1471 2000)

viewpoint catalog

A collection of viewpoints.

work product

A piece of information or physical entity that is produced and/or used

during the execution of the process. Examples of work products include
models, plans, code, executables, documents, databases, and so on.

References

Agile Manifesto 2009. “The Agile

Manifesto.” www.agilemanifesto.org (accessed April 2, 2009).
Ahern 2008. Ahern, Dennis M., Aaron Clouse, and Richard Turner.
2008. CMMI Distilled: A Practical Introduction to Integrated Process
Improvement, 3rd ed. Boston: Addison-Wesley.
Alexander 1964. Alexander, Christopher. 1964. Notes on the Synthesis of
Form. Cambridge, MA: Harvard University Press.
Alexander 1977. Alexander, Christopher, Sara Ishikawa, and Murray
Silverstein. 1977. A Pattern Language. New York: Oxford University Press.
Alexander 1979. Alexander, Christopher. 1979. The Timeless Way of
Building. New York: Oxford University Press.
Ambler 2000. Ambler, Scott W. 2000. The Unified Process Elaboration
Phase. Lawrence, KS: R&D Books.
Ambler 2008. Ambler, Scott, and Celso Gonzalez. 2008. “Agile Model-
Driven
Development.” www.stickyminds.com/BetterSoftware/magazine.asp?fn=c
ifea&ac=367 (accessed April 4, 2009).
Barbacci 2003. Barbacci, Mario R., Robert Ellison, Anthony J. Lattanze,
Judith A. Stafford, Charles B. Weinstock, and William G. Wood. 2003.
“Quality Attribute Workshops (QAWs),” 3rd
ed. www.sei.cmu.edu/publications/documents/03.reports/03tr016.html
(accessed April 4, 2009).
Bass 2003. Bass, Len, Paul Clements, and Rick Kazman. 2003. Software
Architecture in Practice, 2nd ed. Boston: Addison-Wesley.
Bittner 2003. Bittner, Kurt, and Ian Spence. 2003. Use Case Modeling.
Boston: Addison-Wesley.
Booch 2009. Booch, Grady. 2009. “Handbook of Software
Architecture,” www.handbookofsoftwarearchitecture.com (accessed April
4, 2009).
Bosch 2000. Bosch, Jan. 2000. Design and Use of Software Architectures:
Adopting and Evolving a Product-Line Approach. Harlow, England:
Addison-Wesley.
Brown 1998. Brown, William, Raphael Malveau, Hays McCormick and
Thomas Mowbray. 1998. AntiPatterns: Refactoring Software,
Architectures, and Projects in Crisis. New York: John Wiley and Sons.
Buschmann 1996. Buschmann, Frank, et al. 1996. Pattern-Oriented
Software Architecture: A System of Patterns. Chichester, England: John
Wiley and Sons.
Buschmann 2009. Buschmann, Frank, and Christa Schwanninger. 2099.
“Architecture Reviews.” Frank Presentation at OOP, Munich, Germany,
2009.
Business Rules Group 2000. The Business Rules Group. 2000. “Defining
Business Rules: What Are They
Really?” www.businessrulesgroup.org (accessed April 4, 2009).
Cantor 2003. Cantor, Murray. 2003. “Rational Unified Process for Systems
Engineering.” The Rational
Edge. http://download.boulder.ibm.com/ibmdl/pub/software/dw/ration
aledge/aug03/f_rupse_mc.pdf (accessed April 4, 2009).
Cheesman 2001. Cheesman, John, and John Daniels. 2001. UML
Components: A Simple Process for Specifying Component-Based Software.
Boston: Addison-Wesley.
Clements 2001. Clements, Paul, and Linda Northrop. 2001. Software
Product Lines: Practices and Patterns. Boston: Addison-Wesley.
Clements 2002. Clements, Paul, Rick Kazman, and Mark Klein.
2002. Evaluating Software Architectures: Methods and Case Studies.
Boston: AddisonWesley.
Clements 2003. Clements, Paul, et al. 2003. Documenting Software
Architectures: Views and Beyond. Boston: Addison-Wesley.
Cockburn 2000. Cockburn, Alistair. 2000. Writing Effective Use Cases.
Boston: Addison-Wesley.
Conallen 2003. Conallen, Jim. 2003. Building Web Applications with UML,
2nd ed. Boston: Addison-Wesley.
Coplien 2005. Coplien, James, and Neil Harrison. 2005. Organizational
Patterns of Agile Software Development. Upper Saddle River, NJ: Prentice
Hall.
Eeles 2008. Eeles, Peter. 2008. “The Rise of the Development
Environment Architect.” The Rational
Edge. www.ibm.com/developerworks/rational/library/edge/08/apr08/e
eles/index.html (accessed April 4, 2009).
Fagan 1976. Fagan, Michael. 1976. “Design and code inspections to reduce
errors in program development.” IBM Systems Journal 15:3;182–211.
Fowler 1997. Fowler, Martin. 1997. Analysis Patterns: Reusable Object
Models. Menlo Park, CA: Addison-Wesley.
Gamma 1995. Gamma, Erich, Richard Helm, Ralph Johnson, and John
Vlissides. 1995. Design Patterns: Elements of Reusable Object-Oriented
Software. Reading, MA: Addison-Wesley.
Gilb 1988. Gilb, Tom. 1988. Principles of Software Engineering
Management. Wokingham, England: Addison-Wesley.
Gilb 1993. Gilb, Tom, and Dorothy Graham. 1993. Software Inspection.
Wokingham, England: Addison-Wesley.
Grady 1992. Grady, Robert B. 1992. Practical Software Metrics for Project
Management and Process Improvement. Upper Saddle River, NJ: Prentice
Hall.
Herzum 2000. Herzum, Peter, and Oliver Sims. 2000. Business Component
Factory. New York: John Wiley and Sons.
Hofmeister 2000. Hofmeister, Christine, Robert Nord, and Dilip Soni.
2000. Applied Software Architecture. Reading, MA: Addison-Wesley.
Hofmeister 2005: Hofmeister, Christine et al. 2005. “Generalizing a Model
of Software Architecture Design from Five Industrial Approaches.”
Proceedings of the 5th Working IEEE/IFIP Conference on Software
Architecture (WICSA5). Washington, DC: IEEE Computer Society.
Hopkins 2008. Hopkins, Richard, and Kevin Jenkins. 2008. Eating the IT
Elephant: Moving from Greenfield Development to Brownfield. Upper
Saddle River, NJ: IBM Press.
IAA 2009. IBM. “Insurance Application Architecture.” www-
03.ibm.com/industries/insurance/us/detail/solution/P669447B27619A
15.html (accessed April 4, 2009).
IBM 2009. “IBM patterns for e-
business.” www.ibm.com/developerworks/patterns/ (accessed April 4,
2009).
IEEE 1061 1992. IEEE Computer Society. 1992. Standard for a Software
Quality Metrics Methodology. IEEE Std 1061-
1992. http://standards.ieee.org/reading/ieee/std_public/description/se
/1061-1992_desc.html (accessed April 4, 2009).
IEEE 12207 1995. IEEE Computer Society. 1995. IEEE Standard for
Information Technology—Software Life Cycle Processes. IEEE Std 12207-
1995. http://ieeexplore.ieee.org/ISOL/standardstoc.jsp?punumber=5410
(accessed April 4, 2009).
IEEE 1471 2000. IEEE Computer Society. 2000. Recommended practice
for architectural description of software-intensive systems. IEEE Std
1471-
2000. http://standards.ieee.org/reading/ieee/std_public/description/se
/1471-2000_desc.html (accessed April 4, 2009).
ISO 9126 2001. International Organization for
Standardization/International Electrotechnical Commission. 2001.
ISO/IEC 9126-1:2001. Software engineering—Product quality—Part 1:
Quality
model. www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm
?csnumber=22749 (accessed April 4, 2009).
Jacobson 1992. Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and
Gunnar Overgaard. 1992. Object-Oriented Software Engineering: A Use
Case Driven Approach. Wokingham, England: Addison-Wesley.
Jacobson 1997. Jacobson, Ivar, Martin Griss, and Patrik Jonsson.
1997. Software Reuse: Architecture, Process and Organization for Business
Success. Harlow, England: Addison-Wesley.
Katzenbach 1993. Katzenbach, Jon R., and Douglas K. Smith. 1993. The
Wisdom of Teams. Boston: Harvard Business School Press.
Kruchten 1995. Kruchten, Philippe. 1995. “The ‘4+1’ View Model of
Software Architecture.” IEEE Software 12:6;42–50.
Kruchten 1995-2. Kruchten, Philippe. 1995. “Mommy, Where Do Software
Architectures Come From?” Proceedings of 1st International Workshop
on Architectures for Software Systems, Seattle, 1995.
Kruchten 1999. Kruchten, Philippe. 1999. “The Architects: The Software
Architecture Team.” Donohoe, Patrick, ed. Proceedings of the First
Working IFIP Conference on Software Architecture (WICSA1). Deventer,
Netherlands: Kluwer Academic Publishing.
Kruchten 2000. Kruchten, Philippe. 2000. The Rational Unified Process: An
Introduction, 2nd ed. Reading, ME: Addison-Wesley.
Leffingwell 2000. Leffingwell, Dean, and Don Widrig. 2000. Managing
Software Requirements: A Unified Approach. Reading, MA: Addison-
Wesley.
Malan 2001. Malan, Ruth, and Dana Bredemeyer. 2001. “Defining Non-
Functional
Requirements.” www.bredemeyer.com/pdf_files/NonFunctReq.PDF (acce
ssed April 4, 2009).
Marasco 2004. Marasco, Joe. 2004. “On Politics in Technical
Organizations.” The Rational
Edge. www.ibm.com/developerworks/rational/library/4690.html (acces
sed April 4, 2009).
McGovern 2004. McGovern, James, Scott W. Ambler, Michael E. Stevens,
James Linn, Vikas Sharan, and Elias K. Jo. 2004. A Practical Guide to
Enterprise Architecture. Upper Saddle River, NJ: Prentice Hall.
MDA 2009. Object Management Group. 2009. “Model Driven
Architecture.” www.omg.org/mda/ (accessed April 4, 2009).
MDSD 2009. IBM Redbooks. 2009. “Model Driven Systems Development
with Rational
Products.” www.redbooks.ibm.com/abstracts/sg247368.html (accessed
April 4, 2009).
Meyer 1997. Meyer, Bertrand. 1997. Object-Oriented Software
Construction, 2nd ed. Upper Saddle River, NJ: Prentice-Hall.
Microsoft 2009. “Microsoft Patterns and Practices Developer
Center.” http://msdn.microsoft.com/en-
gb/practices/default.aspx (accessed April 4, 2009).
OED 2009. AskOxford.com. www.askoxford.com (accessed April 4, 2009).
OpenUP 2008. Open Unified Process, Version 1.5.0.1.
2008. http://epf.eclipse.org/wikis/openup/ (accessed April 4, 2009).
RAS 2004. Reusable Asset Specification. Object Management Group, Inc.
Document number 04-06-06. www.omg.org/cgi-bin/doc?ptc/2004-06-
06 (accessed April 4, 2009).
Royce 1998. Royce, Walker. 1998. Software Project Management: A Unified
Framework. Upper Saddle River, NJ: Addison-Wesley.
Royce 2005. Royce, Walker. 2005. “Successful software management
style: Steering and balance.” The Rational
Edge. www.ibm.com/developerworks/rational/library/mar05/royce/ (a
ccessed April 4, 2009).
Rozanski 2005. Rozanski, Nick, and Eoin Woods. 2005. Software Systems
Architecture: Working with Stakeholders Using Viewpoints and
Perspectives. Upper Saddle River, NJ: Addison-Wesley.
RUP 2008. Rational Unified Process. IBM Rational Software, Version
7.5. www.ibm.com/software/awdtools/rmc (accessed April 4, 2009).
SARA 2002. Software Architecture Review and Assessment (SARA)
Report, Version 1.0. Henk Obbink, Henk, et al.
2002. http://philippe.kruchten.com/architecture/SARAv1.pdf (accessed
April 4, 2009).
Schwaber 2002. Schwaber, Ken, and Mike Beedle. 2002. Agile Software
Development with Scrum. Upper Saddle River, NJ: Prentice Hall.
SEI 2009. Software Engineering Institute (SEI) Architecture
website. www.sei.cmu.edu/architecture (accessed April 4, 2009).
Shaw 1996. Shaw, Mary, and David Garlan. 1996. Software Architecture:
Perspectives on an Emerging Discipline. Upper Saddle River, NJ: Prentice
Hall.
SPEM 2007. Software & Systems Process Engineering Metamodel
Specification, Version 2.0. Object Management Group, Inc. Document
number 07-08-07, October
2007. www.omg.org/technology/documents/formal/spem.htm (accessed
April 4, 2009).
Stevens 1974. W. P. Stevens, G. J. Myers, L. L. Constantine. 1974.
“Structured design.” IBM Systems Journal 13:2;115.
Sun 2009. Sun Java
BluePrints. http://java.sun.com/blueprints/patterns/index.html (accesse
d April 4, 2009).
TOGAF 2009. The Open Group Architecture Framework. TOGAF
8.1.1. www.opengroup.org/architecture/togaf8-
doc/arch/toc.html (accessed April 4, 2009).
Tyree 2005. Tyree, Jeff, and Art Akerman. 2005. “Architecture Decisions:
Demystifying Architecture.” IEEE Software 22:2.
UML 2.2 2009. UML 2.2 Superstructure Specification. Object Management
Group, Inc. Document number 09-02-02, February
2009. www.omg.org/docs/formal/09-02-02.pdf (accessed April 4, 2009).
UML User Guide 1999. Booch, Grady, James Rumbaugh, and Ivar Jacobson.
1999. The Unified Modeling Language User Guide. Reading, MA: Addison-
Wesley.
von Halle 2001. von Halle, Barbara. 2001. Business Rules Applied. New
York: John Wiley and Sons.
Warmer 1999. Warmer, Jos, and Anneke Kleppe. 1999. The Object
Constraint Language: Precise Modeling with UML. Reading, MA: Addison-
Wesley.
Wirfs-Brock 1990. Wirfs-Brock, Rebecca, et al. 1990. Designing Object-
Oriented Software. Englewood Cliffs, NJ: Prentice Hall.
Zachman 1987. Zachman, John. 1987. “A Framework for Information
Systems Architecture.” IBM Systems Journal 26:3.
Zimmermann 2008. Zimmermann, Olaf, et al. 2008. “Combining Pattern
Languages and Reusable Architectural Decision Models into a
Comprehensive and Comprehensible Design Method.” Proceedings of 7th
IEEE/IFIP Working Conference on Software Architecture. Los Alamitos, CA:
IEEE Computer Society.