The Journal of Systems and Software 83 (2010) 1735–1758

Contents lists available at ScienceDirect

The Journal of Systems and Software

journal homepage: www.elsevier.com/locate/jss

How do architecture patterns and tactics interact? A model and annotation

Neil B. Harrison a,b,∗ , Paris Avgeriou b
a
Department of Computer Science, Utah Valley University, Orem, UT,USA
b
Department of Mathematics and Computing Science, University of Groningen, Groningen, The Netherlands

a r t i c l e i n f o a b s t r a c t

Article history: Software architecture designers inevitably work with both architecture patterns and tactics. Architecture
Received 10 June 2009 patterns describe the high-level structure and behavior of software systems as the solution to multi-
Received in revised form 20 April 2010 ple system requirements, whereas tactics are design decisions that improve individual quality attribute
Accepted 20 April 2010
concerns. Tactics that are implemented in existing architectures can have significant impact on the
Available online 15 June 2010
architecture patterns in the system. Similarly, tactics that are selected during initial architecture design
significantly impact the architecture of the system to be designed: which patterns to use, and how they
Keywords:
must be changed to accommodate the tactics. However, little is understood about how patterns and tac-
Software architecture
Patterns
tics interact. In this paper, we develop a model for the interaction of patterns and tactics that enables
Quality attributes software architects to annotate architecture diagrams with information about the tactics used and their
Tactics impact on the overall structure. This model is based on our in-depth analysis of the types of interactions
involved, and we show several examples of how the model can be used to annotate different kinds of
architecture diagrams. We illustrate the model and annotation by showing examples taken from real
systems, and describe how the annotation was used in architecture reviews. Tactics and patterns are
known architectural concepts; this work provides more specific and in-depth understanding of how they
interact. Its other key contribution is that it explores the larger problem of understanding the relation
between strategic decisions and how they need to be tailored in light of more tactical decisions.
© 2010 Elsevier Inc. All rights reserved.

1. Introduction of general software systems and aims to satisfy several func-

tional and non-functional requirements. Architecture patterns
The architecture of a software-intensive system is the foun- contain the major components and connectors of the system
dation upon which the system is implemented to satisfy the to be built. Most modern software architectures use one or
system requirements (note that in this paper, references to ““archi- more architecture patterns (Harrison and Avgeriou, 2008a). (Note
tecture” refer to the architecture of software-intensive systems; that patterns exist at levels other than architecture, such as
see IEEE, 2000). The requirements include both functional and design; in this paper, references to patterns refer to architec-
non-functional requirements. The non-functional requirements, or ture patterns.) Architecture patterns are chosen in response to
quality attribute requirements, are extremely important, and can early design decisions, including decisions about how to sat-
be even more important than the more visible functional require- isfy functional requirements, non-functional requirements (quality
ments (Barbacci et al., 2003), and even drive software architecture attributes), and physical constraints (such as physical distance
design (O’Brien et al., 2005). The architecture is designed by making between user and service provider.) Thus architecture patterns pro-
a number of design decisions in order to influence the require- vide the major structures in which multiple design decisions are
ments. Two types of important design decisions are the application realized.
of architecture patterns and tactics. An important class of design decisions is those that concern
Architecture patterns are common architectural structures quality attributes; such decisions are often called tactics (Bass et
which are well understood and documented (Buschmann et al., al., 2003). A tactic is a design decision that aims to improve one
1996; Harrison et al., 2007; Schmidt et al., 2000; Shaw, 1988). specific design concern of a quality attribute. For example, a design
Each pattern describes the high-level structure and behavior concern concerning the quality attribute “security” is how to pre-
vent attacks on the system; an associated design decision (tactic) is
to authenticate users. As with patterns, the structures and behav-
∗ Corresponding author at: Department of Computer Science, Utah Valley Univer-
ior of the tactics may also shape the architecture, but usually at
sity, 800 West University Parkway, Orem, UT 84058, USA.
a smaller scale; this is natural as tactics concern a single quality
E-mail addresses: [email protected] (N.B. Harrison), attribute while patterns address a number. Tactics usually become
[email protected] (P. Avgeriou). part of a pattern alongside other structures.

0164-1212/$ – see front matter © 2010 Elsevier Inc. All rights reserved.
doi:10.1016/j.jss.2010.04.067
1736 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Because tactics must be realized within architecture patterns, architecture patterns and tactics. This paper describes and cate-
the relationship between the two needs special study. Architecture gorizes these interactions, shows how they apply in architectural
patterns and tactics have an influence on each other as their struc- design, and provides a way to annotate architectural diagrams so
ture and behavior need to co-exist within the architecture. This is that others can easily understand where these interactions take
a common case of dependencies between design decisions: former place.
decisions constrain subsequent decisions. We need to distinguish By applying this model, an architect can learn the nature of the
between two cases: changes to a software architecture that must be made in order to
implement desired quality attributes. This can lead to:
• Brownfield development: in the case of evolving legacy systems
the patterns are already in place and the architect may need to – Better ability to assess whether a particular architecture pattern
apply additional tactics to improve the quality attribute require- is appropriate for the system being designed.
ments. In this case, a tactic may require small or large changes to – Better ability to estimate the development effort required –
the patterns in order to fit in the architecture for its implemen- instead of guessing at how a quality attribute will be imple-
tation. mented, one can see the architectural components that must be
• Greenfield development: in the case of designing systems from
changed or added to implement it. That means less guesswork
scratch, an architect can first select patterns and then fit the and fewer surprises later in development.
tactics (top-down), or first select tactics and then see which pat- – Ability to evaluate alternative approaches to implementing
terns can incorporate them (bottom-up) or select both patterns quality attributes, namely evaluating alternate tactics that
and tactics iteratively (meet-in-the-middle). The second case is accomplish the same thing. You might have considered one, but
the most common as the architect usually starts making minor may pick a different one because it is easier to implement in the
design choices by selecting tactics and other structures (e.g. for architecture.
functional requirements and physical constraints of the system), – Reuse of this knowledge through the use of known patterns and
then selects a pattern that can incorporate these choices and sub- tactics.
sequently selects more tactics and other structures. – Better understanding of the architecture; namely why certain
structures were put in place or how and why the architecture
In both cases we need information about how the pattern- patterns used were modified.
related and tactic-related decisions influence one another. The
information may be used to modify the pattern, or if one has not
The structure of the rest of the paper is as follows: Section 2 lays
selected an initial pattern yet, it can be used to understand the
groundwork by describing patterns, quality attributes, and tactics.
tradeoffs of selecting one pattern versus another. Specifically we
Section 3 presents a general model of the interaction of patterns
need information about how much a pattern must be changed in
and tactics. Section 4 explores how patterns and tactics interact.
order to implement certain tactics. Of course, this also reflects how
Section 5 shows how to make the interaction of tactics and pat-
easy or difficult it is to implement the tactics in the pattern.
terns visible in architecture documentation, through architecture
In practice, for any given tactic, we may not know which parts
diagram annotations. Section 6 contains several case studies where
of the pattern make it easy or difficult to implement that tactic.
the annotation method has been used. Sections 7 and 8 describe
Furthermore, architects and developers often do not understand
related and future work.
why a tactic is easy or difficult to implement in a given pattern.
This makes it difficult to make informed choices about alternative
tactics, and to assess the costs and benefits of tactics to achieve 2. Background: patterns, quality attributes, and tactics
quality attributes. In short, their ability to effectively satisfy the
critical quality attributes for a system is compromised. 2.1. Architecture patterns
Several sources (Cloutier, 2006; Harrison and Avgeriou, 2007a)
have documented that certain architecture patterns have ben- Patterns are solutions to recurring problems. A software pat-
efits or liabilities for certain quality attributes. However, such tern describes a problem and the context of the problem, and
descriptions are generally very high level; while they give general an associated generic solution to the problem. The best known
guidance, they do not explain the positive or negative consequences software patterns describe solutions to object-oriented design
in sufficient detail to identify specific parts of the pattern that are problems (Gamma et al., 1995), but patterns have been used in
impacted by certain quality attribute tactics, and exactly what that many aspects of software design, coding, and development. Archi-
impact consists of. In fact, current pattern documents do not even tecture patterns describe an abstract, high-level system structure
mention tactics at all. and its associated behavior (Maranzano et al., 2005). Architecture
We have studied one quality attribute (reliability) in depth to patterns generally dictate a particular high-level, modular system
understand the interaction of its tactics with the most well-known decomposition. Numerous patterns have been written for software
architecture patterns (Harrison and Avgeriou, 2008b). We found architecture, and can be used in numerous software architecture
that there are many interactions, and that there are several types methods (Harrison and Avgeriou, 2007b; Bosch, 2000; Jansen and
of interactions, varying from pattern to pattern. The interactions Bosch, 2005; Shaw and Garlan, 1996).
between patterns and tactics are indeed rich and varied. An important advantage of patterns is that the consequences of
Therefore, without detailed knowledge of the architecture pat- using the architecture pattern are part of the pattern. The result
terns used and how they interact with the quality attribute tactics, of applying a pattern is usually documented as “consequences” or
an architect can easily miss important interactions. Furthermore, “resulting context” and is generally labeled as positive (“benefits”)
without an understanding of the types of interactions, an architect or negative (“liabilities”). Many of the benefits and liabilities con-
will not even know what to look for. In addition, one will not easily cern quality attributes; for example, a benefit of the Layers pattern
understand how and why a pattern is modified in order to satisfy a states, “Standardized interfaces between layers usually confine the
quality attribute. effect of code changes to the layer that is changed . . . This supports
In order to help architects and designers understand the intri- the portability of a system.” A liability of the same pattern states, “A
cate relations between a system’s architecture design decisions and layered architecture is usually less efficient than, say, a monolithic
its quality attributes, we describe a model of interaction between structure of a ‘sea of objects’.” (Buschmann et al., 1996) However,
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1737

the information is incomplete; it does not cover all the well-known which tactics to use) that could be difficult to implement correctly
quality attributes. and maintain. Unfortunately, as noted above, the information about
In addition, this information is currently inadequate. The impact the relationship between architecture patterns and tactics is not
of a pattern on a quality attribute is often given simply as a positive adequate.
or negative impact (Harrison and Avgeriou, 2008a; Cloutier, 2006),
but how that maps to a real system is not explained. In addition,
2.3. Patterns and tactics
architecture patterns are general solutions, thus their impact on
quality attributes largely depends on how the pattern is used in the
There is a close relationship between architecture patterns and
architectural design. Even more detailed elaborations of the impact,
tactics. Bass et al. explain that tactics are “architectural build-
such as given in the excerpt above, currently do not explain how
ing blocks” from which architecture patterns are created; that
impact on quality attributes may be mitigated, or how the archi-
patterns package tactics (Bass et al., 2003). They also illustrate
tecture can be changed to achieve the quality attribute of interest.
through example how the selection of tactics helps determine the
selection of the architecture patterns used, which then leads to
2.2. Quality attributes and tactics
further selection of tactics. Thus we see that patterns, while they
may be largely composed from tactics, also provide the starting
Quality attributes are characteristics that the system has, as
point for incorporation of tactics. For example, a case study of
opposed to what the system does (Sommerville, 2007), such as
the use of Attribute-Driven-Design (Wood, 2007) shows how the
usability, maintainability, performance, and reliability. Quality
client–server pattern is selected very early, in the architecture. One
attributes are not simply met or not met, but rather, satisfac-
of the reasons for the selection of the early structure is to help
tion is along a scale, always viewed within the specific context
satisfy reliability requirements by providing a persistent storage
of a scenario: given a system state and specific input, the out-
service with state information. Subsequently, tactics are incorpo-
put is required to extend within specific limits (Bass et al., 2003;
rated into the structure provided by the pattern that further satisfy
Bachmann et al., 2005). A particular challenge of quality attributes
reliability and availability requirements through duplication and
is that because they tend to be system-wide characteristics, system-
other tactics.
wide approaches are needed to satisfy them; these approaches are
As noted earlier, the selection of architecture patterns to use is
defined at the system architecture level and not the component
taken very early. Of course, it encompasses various tactical deci-
level.
sions as well, but many others are yet to come. Bass et all put it
Typically, systems have multiple important quality attributes,
nicely: “. . . in relating tactics to patterns the architect’s task has
and decisions made to satisfy a particular quality attribute may
only just begun when the tactics are chosen. Any design uses mul-
affect another quality attribute. For example, decisions to maximize
tiple tactics, and understanding what attributes are achieved by
processing speed may come at the cost of additional mem-
them, what their side effects are, and the risks of not choosing other
ory needed. Therefore, architects must make tradeoff decisions:
tactics is essential to architecture design.” (Bass et al., 2003, p. 126)
whether to implement software in a way that optimizes one qual-
Of course, not all software development is greenfield; it is often
ity attribute to the detriment of another. One approach for analysis
necessary to enhance quality attributes of existing systems. In fact,
of tradeoffs is given in (Bachmann et al., 2005). The Architecture
this is probably much more common than designing a new system.
Tradeoff Analysis Method (ATAM) is an architecture evaluation
This means that tactics must be added to the existing architecture
method that focuses on achievement of quality goals (Bass et al.,
patterns, regardless of how difficult it is. Knowledge of the interac-
2003; Clements et al., 2002c). Steps include prioritizing quality
tion of patterns and tactics helps the system maintainer understand
attribute scenarios, and analyzing architectural approaches. The
how to implement a given tactic in a given architecture.
Cost Benefit Analysis Method (CBAM) (Bass et al., 2003) builds on
ATAM to include business goals and economic issues. It develops
architectural strategies that correspond to quality attribute scenar- 3. A model of patterns, quality attributes, and tactics
ios and makes tradeoffs based on their costs and benefits.
Tactics are measures taken to improve quality attributes (Bass This model shows in general terms how patterns, quality
et al., 2003). For example, a duplication scheme to improve the attributes, and tactics are related to each other, and how they are
reliability (nonstop operation) of the system is a tactic. Tactics related to the overall architecture. It provides the framework for
impact the architecture patterns in various ways. In some cases, discussion of the detailed ways that tactic implementations affect
a tactic may be easily implemented using the same structures the patterns used. It also provides a foundation for the description of
(and compatible behavior) as a particular architecture pattern. On a method of annotating architecture diagrams in a way that shows
the other hand, a tactic may require significant changes to struc- the impact of implementing tactics on the architecture (Fig. 1).
ture and behavior of the pattern, or may require entirely new The model is comprised of entities associated with a system’s
structures and behavior. In this case, implementation of the tac- architecture with respect to patterns and tactics; these may rep-
tic, and future maintenance of the system, are considerably more resent structures and behavior, as both patterns and tactics have
difficult and error-prone. Tactics may be “design time,” or overall structural and behavioral parts. We discuss each of the entities in
approaches to design and implementation, such as “hide informa- the figure in turn. Let us begin with the architecture. An architec-
tion” to improve modifiability, or may be “runtime tactics,” which ture consists of architecture pattern implementations in order to
are features directed at a particular aspect of a quality attribute, satisfy architectural concerns. (The architecture may also contain
such as “authenticate users” to improve security. In this paper we structures that are not part of any pattern implementation, though
concern ourselves only with runtime tactics. they do not concern this discussion.)
Because of the importance of quality attributes, it is critical that An architectural concern is a requirement on the system to be
they be considered during early design; during system architecture. built, such as a feature to be implemented (IEEE, 2000; Hofmeister
Indeed, we find that architects often consider them simultaneously et al., 2005). A special type of architectural concern is a quality
(Harrison and Avgeriou, 2007b; Harrison et al., 2006). However, attribute. Quality attributes are important architectural concerns,
unless the relationship between the architecture patterns and the and can have profound impact on the overall structure of the
tactics being used is well understood, architects risk making archi- architecture. However, quality attributes are often the difficult
tectural decisions (either concerning which patterns to use or architectural concerns to satisfy. Whereas architectural partitions
1738 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 1. Pattern, quality attribute, and tactic model.

(see patterns below) often readily fit functional requirements, qual- called reliability) is “Fault Detection.” Two tactics for fault detec-
ity attributes are system wide, and are satisfied through measures tion are “Ping/Echo” and “Heartbeat (dead man timer)” (Bass et
that cut across such partitioning. Quality attribute scenarios are al., 2003). We note that while the model applies to both design
often used to specify requirements on quality attributes (Bass et time and runtime tactics (see Bass et al., 2003), we have focused
al., 2003). primarily on runtime tactics for simplicity.
Tactics are measures implemented to improve quality The implementation of tactics improves the level of its qual-
attributes. Tactics that do the same thing are grouped into ity attribute. For example, the tactic “authentication” improves the
categories, also called design concerns in ADD (see Wood, 2007.) level of the Security quality attribute. However, tactics may also
These design concerns are selected following the quality attribute have side effects on other quality attributes. These side effects are
scenarios. For example, security can be improved by resisting usually negative.
attacks, detecting attacks, and recovering from attacks. These are The left side of the figure shows architecture patterns and their
design concerns (or categories of tactics) for security. The tactics relations. An architecture pattern is a solution to an architec-
within each category are implementations of the category. Tactics tural problem, which is usually described as a set of architectural
for the “resisting attacks” design concern include the following: concerns or forces. The pattern satisfies multiple architectural
Authenticate users, Authorize Users, Maintain Data Confidentiality, concerns, but may also have side effects on other architectural
Maintain Integrity, Limit Exposure, and Limit Access. concerns. A pattern may have different variants, and in fact, the
In some cases, tactics are alternate ways of implementing a variant used is often based on the tactics used (Bachmann et al.,
design concern. For example, a design concern for availability (often 2007).
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1739

Fig. 2. Pattern participants in a typical diagram of an e-commerce system (simplified).

The solution of architecture patterns consists of components 4. Interaction of patterns and tactics
and connectors between them; together, these comprise the pat-
tern participants. The pattern participants are interrelated; they As noted above, quality attributes are addressed through the
depend on each other. The pattern participants have both a struc- implementation of tactics. The implementation of tactics is done
ture and a behavior. The pattern provides a generic solution as a within the architectural structure of the system, including the
collaboration among the pattern participants. The pattern imple- structures of the architecture patterns used. Because this interac-
mentation is a concrete realization of a pattern, including reification tion can be very important, we study it in depth in this section. In
of all its components and connectors. an expansion of the upper part of Fig. 1, we see that pattern par-
The relationship between the pattern participants and the tac- ticipants consist of components and connectors, and that tactics
tics is significant. The code used to implement tactics can reside impact each in various ways, which are described below. In Fig. 3,
entirely within the pattern participants, in which case the pattern the boxes represent instances of components, connectors, pattern
remains the same. However, implementing tactics often requires participants, or tactics. For simplicity, we have omitted other enti-
changes to the pattern participants: in some cases, it is merely nec- ties usually employed in Architecture Description Languages such
essary to replicate a pattern participant. In other cases, the structure as ports, roles, and bindings; they are out of the scope of this paper
and behavior of a participant must be significantly modified, or but an interesting subject of future study.
even new structures and behaviors added which are not part of In this portion of the model, we see that quality attributes are
the original pattern. We describe these changes in detail in later improved through the implementation of runtime tactics. The tac-
sections. tics are implemented in the participants (generally the components
For example, consider a simple e-commerce application, con- and connectors) of the patterns used in the architecture of the sys-
sisting of multiple web clients that access a central server. (For tem. Note that connectors should be considered first class entities
simplicity, we give only parts of its architecture.) Its Architec- (Shaw, 1996).
ture contains Pattern Implementations of the following Architecture We are particularly interested in the relationship between the
Patterns: Broker, Layers, and Repository. Each pattern consists of tactics and the pattern participants. This is a key relationship,
Pattern Participants, The following figure is a simplified but common because the tactic being implemented may or may not be read-
diagram of such an architecture. It shows the pattern participants, ily implemented, depending on what the pattern participants are,
but as is typical in architecture diagrams, it does not explicitly show and how they depend on each other. We explore this relationship
tactics. Comments in italics describe the pattern participants and in depth below.
discuss tactics (Fig. 2). Patterns can impact individual tactics by making it easier or
The Architectural Concerns include the features, the hardware more difficult to implement them.
and software platforms to be supported, security requirements, As described previously, quality attributes are satisfied through
reliability requirements, etc. Of these, security and reliability are the implementation of tactics. Because tactics are implemented
Quality Attributes. in the code, their implementation can be easier or more
A Design Concern used to satisfy part of the security Quality difficult depending on the structure and behavior of the sys-
Attribute is “resist attacks” (Bass et al., 2003), and a Tactic to imple- tem they are implemented in – its architecture. In fact, the
ment it is “authenticate users.” This tactic is often implemented by structure and behavior of a tactic ranges from highly compat-
adding a Layers’ Pattern Participant; namely an authentication layer ible with the structure and behavior of a pattern to almost
above all other layers. completely incompatible with them. Naturally, the closer the
1740 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 3. Interaction of patterns and tactics.

Table 1
Changes to pattern components.

Type of structure change Description Impact

Implemented in The tactic is implemented within a component of the Only a single component must change, and in a minor
pattern. The external interface of the component does fashion. This is the easiest type of change to
not have to change. (This is a special case of the Modify implement.
type, described below.)
Replicates A component is duplicated. This is usually done to Small changes are often required in the duplicated
implement redundancy, for reliability, or to implement component, as well as components that interface to it.
concurrency for performance. (This is a degenerate These changes are still usually easy to implement.
form of the “Add, in the pattern” type of change.)
Add, in the pattern A new instance of a component is added to the The component must be written, of course, but the
architecture. The component follows the structure of changes required by the interfacing components are
the architecture pattern, thus maintaining the integrity easy and well defined. These changes are easy or
of the architecture pattern. moderately easy to implement.
Add, out of the pattern A new component is added to the architecture which In addition to adding the new component, other
does not follow the structure of the pattern. This components must change, often in significant ways.
causes the architecture of the system to deviate from This is not only difficult to implement, the changed
the intent of the pattern structure can make future maintenance more difficult
Modify A component’s structure changes (as opposed to Such changes generally mean that other components
adding new components in or out of the pattern.) must also change. The changes can range from minor
to very difficult.
Delete A component is removed We have never observed it. One might consider the
selection of a simpler variant of a pattern some sort of
a delete; for example, using a variant of MVC that
combines the model and view.

structures match, the easier it is to implement the task in the In addition to pattern components, the connectors between the
pattern. components are affected. It is certainly the case that changes to the
The structure and behavior of a system are obviously inter- components may cause corresponding changes in the associated
twined, but are generally discussed and documented separately. connectors’ ports, interfaces, etc. The table below shows changes
Likewise, we will discuss the interaction of patterns’ and tactics’ to components, followed by a table showing the changes to the
structures, followed by a discussion of the interaction of their connectors (Table 2).
behaviors. We then describe the magnitude of the interactions, and We show examples of each of the changes below. Short descrip-
end this section by showing an example of tactic data for a quality tions of the patterns and tactics used here can be found in
attribute and a few patterns. The example gives data chiefly about Appendix A.
the impact of the tactics on the structure of the patterns.

4.1. Interaction of structure in patterns and tactics Table 2

Changes to pattern connectors.
We have identified several types of changes that a pattern’s
Type of change to a component Corresponding change to
structure might undergo when a tactic is implemented, as shown in connectors
Table 1. The information may be used to modify the pattern, or if one
Implemented in No change.
has not selected an initial pattern yet, it might be used to under-
Replicates Connectors added between
stand the tradeoffs of selecting one pattern versus another. The replicated components and other
types of structure change are listed in general order of amount of components. They may be within
impact on the structure of the pattern; that is, the earlier types gen- the structure of the pattern.
erally have less impact than the later types. However, the amount Add, in the pattern New connectors added within the
pattern structure.
of impact depends on the pattern and the tactic. In particular, mod- Add, out of the pattern New connectors added outside the
ification of a component has a large range of potential impact. Each pattern structure.
pattern/tactic pair must be individually examined to determine the Modify New or modified connectors
impact. Magnitude of impact will be discussed after the discussion needed, probably outside the
pattern structure.
of behavior.
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1741

1. Implemented in: Implementing the Ping/Echo reliability tactic in tecture looks quite a bit different from the pure Pipes and Filters
a Broker architecture: the Ping/Echo tactic has two major com- architecture.
ponents, the component issuing the ping and keeping the time, 5. Modify: Consider a Blackboard architecture. The reliability tac-
and the components responding to the ping messages with an tic Checkpoint and Rollback is to be implemented. Because the
echo. Since the Broker component already maintains commu- behavior of processing in a Blackboard system is somewhat
nication to all the server components, the Broker becomes the emergent, it will be very difficult to define checkpoints to which
component that issues the ping. The server components simply one can roll back. Defining such checkpoints is counter to the
respond to it. This requires a small change to the messaging pro- very idea of a Blackboard. An alternative might be to log all inputs
tocol (the connector), but the change can be lessened further. The in order, so one could presumably reconstruct the sequence of
work requests to the server components can double as the ping events, but this could be cumbersome, and require significant
messages, and their responses can be the echo messages. In this storage. In any case, the blackboard component must undergo
case, only minor changes are required in the broker component, significant changes, though no additional component is added.
and the other components have few if any changes. Changes to connectors would be minor or even unnecessary.
2. Replicates: In a client–server architecture, improved perfor-
mance is often needed, so the Introduce Concurrency tactic 4.2. Interaction of behavior in patterns and tactics
is used. It simply duplicates the server component. A connec-
tor between the servers may be added to allow the duplicated Within behavior, one can consider the actions of the software,
servers communicate and share load. This configuration is often and the state transitions of the software. We will focus on the
used in web-based download servers that have local mirror sites. actions because they are more general: every state transition is
3. Add, in the pattern: Security of a layered system can be enhanced accomplished by an action. Within actions, we see two notable
by adding the Authentication tactic as an additional layer on issues:
top of everything. The security layer is a new component and
associated connector, but it is within the structure of the Layers
architecture. Changes to the other parts of the system will likely 1. Sequences of actions: Sequences of actions are often repre-
be confined to the (former) top layer of the system. sented in message sequence diagrams, particularly for messages
4. Add, out of the pattern: Consider a Pipes and Filters-based sys- between different components.
tem that needs to add the Ping/Echo reliability tactic. Ping/Echo 2. Timing of actions: Some actions must be completed within a
requires a component to manage the pinging, and to know who certain time limit. Different actions are taken if the action does
does not answer. However, Pipes and Filters has no possible can- not finish within its allotted time. (In some cases, such as hard
didate components, so one must be added. Furthermore, each real time systems, the integrity of the system is compromised if
filter must now respond – in good time – to the ping messages, actions do not complete on time.)
requiring new connectors. This may mean that each filter must
implement an interrupt handling mechanism. The new archi- We discuss each below.

Table 3
Structure and behavior changes in pattern participants.

Type of structure change Typical behavior change Impact

Implemented in Actions are added within the sequence of the This type of behavior change is easy to
component. Timing changes are mainly limited to the implement. Timing of the component is well
component. defined. The timing of the component can be
modeled or compared to the previous version,
which can be used to assess the impact on
system realtime requirements.
Replicates When a component is replicated, its sequence of Changes in the actions are limited to the
actions is copied intact, most likely to different controlling components, and as such are quite
hardware. Ideally, their behavior does not change at easy to implement. In unusual cases, the
all. Whatever component that controls the replicated parallelism of replicated components can
component requires actions added, normally within its slightly improve timing, if it is properly
sequence. exploited.
Add, in the pattern The new component added comes with its own This action is moderate work, because new
behavior. In most cases, the behavior will have to actions must be developed. Timing changes are
follow the constraints of the pattern; the new mainly limited to the added component.
component’s actions are within the message sequence
of the pattern.
Add, out of the pattern The component added will have its own behavior. The The new component does not have to work
actions do not have to follow the pattern; in fact, they within the constraints of the pattern’s action
may be an action sequence that is independent of the sequences, which may make the addition of
sequences in the pattern. the component easier. However, every point
where the new component interacts with the
existing components must somehow deal with
asynchronous actions of the new component.
This implies, for example, interrupt processing.
This is likely significant work.
Modify The change to the structure of a component implies The magnitude of the work needed depends on
changes or additions within the action sequence of the the situation. However, note that interfaces of
component that are more significant than those found the component may change, which means that
in “Implemented in.” It is conceivable but unlikely that the behavior of other components must
any actions are added independent of the component’s change correspondingly.
action sequence. (Note that the magnitude of
modifications can vary widely; in some cases “Modify”
is lower impact than “Add out of the pattern.)
1742 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

4.2.1. Adding action sequences are within the sequence of actions – encryption must follow
Most of the behavior of architecture patterns is characterized the actions of each filter. By the way, this implementation also
as action sequences. For many common patterns, these sequences requires that decryption be done in a filter before each filter –
can be found depicted in message sequence charts (Maranzano et each filter becomes three!
al., 2005). These charts depict the essential common sequences of 5. Add, out of the pattern: Consider adding the security tactic, Intru-
actions in systems using these patterns. Tactics also have behavior, sion Detection to the Layers pattern. Intrusion Detection runs as
namely the sequence of actions that satisfy the quality attribute an independent process that monitors the open ports on a sys-
concern. The behavior of tactics can change the behavior of the tem for attempts to intrude. It is added as a component out of the
pattern by adding or modifying action sequences of the tactic to pattern. Its actions are completely independent of the applica-
those of the pattern. tion. It makes it straightforward to implement. But what should
The following are examples: it do when it detects intrusion attempts? Should it raise a warn-
ing immediately? If so, the Layers system must handle interrupts
1. Adding the security tactic “authenticate users” adds a sequence from it. Should it simply log the events? If so, the Layers system
of actions at the beginning of the action sequence that initiates needs to have behavior added to occasionally check the log files
an interactive user session. and clean them out. In this case, the actions can be part of the
2. Adding the “Ping/Echo” reliability tactic adds a sequence of Layers’ normal sequence of actions.
action that is controlled by a clock, independent of any other 6. Modify: Consider a Layers architecture in which the reliabil-
actions in the system. It also adds timing behavior: sending the ity tactic Passive Redundancy (warm spare) is implemented. Of
pings is controlled by time, and the responses must come within course there is replication of the most of the system (all except
a certain time or the tardy component is considered to be dead. the top layer, perhaps). Then behavior must be added to a cer-
tain layer to send updates to the warm spare. This requires more
substantial action additions, because the system must determine
Behavior changes are associated with structural changes. Let what state information to send, and the spare system must be
us revisit the types of structural changes, and note the types of modified to replicate the active’s state through the state mes-
behavior changes that are associated with them. sages. Although it is likely that these additions are all within the
They are as follows, given in general order of increasing impact existing action sequences, the changes are significant.
(Table 3).
Let us look at some examples:
4.2.2. Time behavior
It is important to consider not only actions but timing of actions.
1. Implemented in: The Ping/Echo reliability tactic can be added
Obviously, the addition of any actions causes the timing of the sys-
within the structure of the Broker pattern. The behavior of the
tem to change in some way. Because functionality is being added,
tactic is to periodically send ping messages to selected compo-
in most cases, the timing change means that the overall process-
nents, and they reply. The broker’s action sequence is to wait for
ing can take longer. (Exceptions include adding parallel processing
requests from clients, and distribute the requests to appropriate
and other performance-related tactics.) The timing change is often
servers. To implement Ping/Echo, the broker can use the clock
not important. In many cases, changes in the timing of the system
to decide when to send ping messages, just as it sends client
or component are small enough that the timing change can easily
requests out. It must add behavior to keep track of responses.
be ignored. However, if there are any critical timing constraints in
The servers must add behavior to respond to ping messages right
any part of the system, the impact of implementing the tactic on
away.
the timing of the system must be examined. We discuss timing in
2. Replicates: Consider the Hot Spare tactic implemented in the
detail in a later section.
Broker pattern. A server is replicated, and the broker controls
The timing changes caused by the implementation of a tactic
it. The servers have no changes in their actions. Sequences
may or may not be of concern, depending on the nature of the tactic
of actions are added to the broker as follows: broker sends
and the timing constraints of the system. Timing can be a system-
requests to two servers. It must also manage them, perhaps
wide issue – just because a component’s action sequence is left
using Ping/Echo to determine their health. These are all additions
unchanged by a tactic, one cannot automatically assume that the
within the broker’s normal sequence of actions.
timing of that component is not compromised. If different compo-
3. Add, in the pattern: consider the addition of the Authentica-
nents share the same processor, changes in the actions of one can
tion security tactic to the Layers pattern. An additional layer for
impact the timing of the others.
authentication is added on top of all the other layers. It adds
Tactics impact the timing of the system in two main ways. First,
behavior to handle the authentication, which must come before
the tactic may add new timing constraints to the system. Second,
other actions in the system. For example, requests for service
the tactic may change the timing of the system in a meaningful way
must pass through the authentication layer to ensure that the
(i.e., change the timing enough that we care.) Each of these ways
requestor is authenticated, then the normal sequence of actions
can be either explicit or implicit. We explain each in more detail
proceeds.
below.
4. Another example of addition within the pattern is adding the
Encryption tactic to the Pipes and Filters pattern. This is interest-
ing to consider because there are two obvious ways encryption 1. Adding new timing, explicit: In this case, the tactic contains
might be added. In the first way, all the filters might operate specific timing requirements in its specification. The most obvi-
within a secure environment, and encryption is applied to the ous example is the Ping/Echo reliability tactic. In this tactic, a
final product. In this case, a filter containing the encryption central control component sends out sanity pings, and requires
actions is added to the end of the Pipes and filters configuration. that other components respond within a certain time. Note
The behavior of the other filters is not affected. In the other case, that although the timing itself is implemented in a central
the filters are distributed across an insecure network, and the component, timing requirements extend to each of the compo-
results of one filter must be encrypted before the data is passed nents being monitored: each component must respond within
to another filter. In this case, each filter must add another filter a certain time. Therefore, the time behavior of all the respond-
for encryption after it. But like the first case, the added actions ing components must be examined to ensure that the timing
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1743

requirements of the echo message can be met, and that the time participants (e.g., no new message sequences between partici-
behavior of the component itself is not compromised by servic- pants added.) These types of changes are “Replicates” or “Add,
ing the ping messages. in pattern.” Structure changes (“Modify”) are minor. For exam-
2. Adding new timing, implicit: In this case, the tactic does not ple, the Layers pattern supports the active redundancy tactic by
contain specific timing requirements. However, certain timing replicating the layers, and adding a small distribution layer on
constraints can be inferred in the behavior of the tactic. For top. Although another layer is added, it is entirely consistent with
example, the Passive Redundancy (Warm Standby) reliability the pattern.
tactic has implicit constraints. In this tactic, a standby compo- 3. Neutral (∼): The pattern and the tactic are basically orthogo-
nent receives regular state updates from the active. There is an nal. The tactic is implemented independently of the pattern,
implicit requirement that the warm standby be able to process and receives neither help nor hindrance from it. For example,
each state update message before the next one comes. Oth- consider implementing the reliability tactic “Ping/Echo” in the
erwise, the state messages would either back up or would be Model View Controller (MVC) pattern: there is no inherent con-
discarded, or would force the active to wait until the standby flict between them. But MVC has no natural place for handling
catches up. The first two would cause loss of synchronization them either, such as an exception handling layer one might
between the active and the standby, and the third would cause implement in the Layers pattern. Therefore, MVC neither helps
performance problems. Therefore, the standby must process nor hinders the implementation of Ping/Echo.
state messages fast enough to keep up. 4. Significant Changes (−): The changes needed are more signifi-
3. Changing Existing Timing, Explicit: These are tactics that explic- cant. They may consist of “Implemented in,” “Replicates,” and
itly change the performance of the system. In general, they add “Add in pattern” where behavior changes are substantial. More
no new behavior. All the performance tactics (processing speed) often, they include significant “Modify” or minor “Add out of pat-
intend to change the timing of the system. For example, the tactic tern” changes. For example, the Presentation Abstraction Control
Add Concurrency improves the timing of the system. Naturally, manages simultaneous user sessions. Implementing a Rollback
there are no tactics that explicitly (i.e., purposely) degrade the tactic would likely require significant extra code to ensure that
timing of the system. different interfaces are synchronized.
4. Changing Existing Timing, Implicit: This case is where a tactic 5. Poor Fit (− −): Significant changes are required to the pattern in
changes the timing of the system as a side effect; there is no order to implement the tactic. These consist of significant “Mod-
intent to do so. In nearly all cases, the change is to cause process- ify” and/or “Add out of pattern” changes. The structure of the
ing to take longer, although in many cases, the timing change is pattern begins to be obscured. Adding the tactic requires the
too small to be of concern. Virtually all tactics introduce some addition of behavior that is different from the original behavior of
change in timing., though most are small. An interesting example the pattern. For example, introducing Ping–Echo into a Pipes and
is the Voting reliability tactic. In this tactic, different components Filters pattern requires a new central controlling component,
work on the same problem. Their results are compared, and a along with the capability in each filter component to respond to
voting scheme is used in the cases where the results differ. The the ping in a timely manner.
implicit timing change is that all the voter components must
complete their tasks before further progress can be made. Thus While the above list gives an overview of the levels of mag-
the performance is limited by the slowest voter. nitude of impact, a key determiner of magnitude is the number
of pattern participants that must change. Clearly, as the number
4.3. Magnitude of impact of participants that change increases, effort for implementation,
maintenance, and understanding increase. And the opportunities
The sections above describe the ways in which structure and for errors increase.
behavior of the patterns are changed by the implementation of tac- Most changes involve the addition of a component (namely
tics. An important consideration is the size of the impact. The size replication or adding in or outside the pattern; see above.) Typi-
of the impact – how much a pattern must change – is an indicator cally, this requires adding a corresponding connector, and changing
of the work required to implement the tactic, how error-prone the an existing component that communicates with the component.
implementation might be, and how difficult it might be to see the Thus we see that three changes becomes a natural “break point,”
pattern in the system at a later time. However, although one can get for impact. The same applies to the “Modify” change: a change
a general sense of the magnitude of the impact of types of changes, it to a component typically requires a corresponding change to its
can vary depending on the particular pattern and tactic. Therefore, connector as well as the component it communicates with. “Imple-
it is necessary to examine each pattern-tactic combination. mented in” is a minor change to a single component. This gives the
We defined a five-point scale to describe how difficult it is to following table of magnitude for each type of change (Table 4).
implement a particular tactic in a given pattern. It is based on the It is not uncommon for a tactic to involve more than one type of
impact on the structure and behavior of the pattern. The descrip- change; for example, add in the pattern (adding a new component
tions, expanded from (Harrison and Avgeriou, 2008b), follow: and connector) and Modify (an existing component.) In such a case,
one would consider the upper and lower ranges of both types of
1. Good Fit (+ +): The structure of the pattern is highly compatible changes. In this example, add in the pattern (2 changes) has a range
with the structural needs of the tactic. Most or all of the changes of ++ to +, and Modify (1 change) has a range of ++ to −. This gives a
required are the “Implemented in” type, and the behavior of total range of ++ to −, but it is biased toward the positive end; the
the pattern and tactic are compatible. Any structure changes modification required is likely minor.
(“Modify”) required are very minor. For example, the Broker A particular consideration is the case where a tactic aligns with
architecture strongly supports the Ping–Echo tactic because the a previous tactical decision. Within the meta-model, two tactics
broker component already communicates with other compo- would affect the same pattern participants in the same way; they
nents, and is a natural controller for the ping messages. have overlapping impacts. Obviously, the effort to implement the
2. Minor Changes (+): The tactic can be implemented with few tactic is much less than if it were implemented in the pattern with-
changes to the structure of the pattern, which are minor and out the previous tactic. We can model the difficulty of the second
more importantly, are consistent with the pattern. Behavior tactic by considering that it is implemented in the architecture as
changes are minor, and generally encapsulated within pattern it now stands – including the previously implemented tactic. This
1744 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Table 4
Impact magnitude as a function of number of participants impacted.

Change type Number of changes Impact range Comments

Implemented in 1 ++ to + Should impact only a single participant.

Replicates 3 or less ++ to +
More than 3 + to ∼

Add, in the pattern 3 or less ++ to +

More than 3 + to ∼

Add, out of the pattern 3 or less ∼ to −

More than 3 − to − −

Modify 3 or less ++ to − The wider range indicates inherent variability of modify.

More than 3 ∼ to − −

could, for example, result in the impact on a pattern participant still send the heartbeat in response to a timer. (Add out of the
being “Implemented in” or “add, in the pattern”, rather than “add, pattern, along with moderate changes to each filter compo-
outside the pattern.” Case Study 1 shows such an example. This nent.)
begs the question of whether the order of tactic implementation is c. Exceptions: − −: The problem here is who should catch an
significant; we address this in Section 7. exception when one is thrown. If the exception can be com-
It is important to note that the architecture of every system is pletely handled within a single filter component, then there
different, and has different requirements and constraints, resulting is no problem. However, if the filter cannot fully handle the
in a unique structure. We see this reflected in the ranges given in exception, who needs to know? Depending on the application,
the above table. Therefore, the impact of a tactic on an architecture it may be the subsequent filter (simple modifications needed
could be different from our findings. As such, these findings should to the filters), or a central process might need to know (add
be taken as general guidelines. They are most useful as guides for out of the pattern, along with moderate changes to each filter
comparisons of tactics and of patterns, and as helps for implemen- component.)
tation. 2. Recovery – Preparation and Repair
Note that while we consider impact on development effort, a. Voting: + +: To implement voting, create different filters as
there is another dimension of impact; namely that a tactic may the voting components. Create the receiving component (the
impact other quality attributes; e.g., tactical decisions taken to voter) as a filter. To distribute the input to the different voting
improve security often have a detrimental effect on performance. filters, use a pipe that has one input and multiple outputs (e.g.,
Such tradeoffs must also be taken into account, and are also part the Unix “tee” command.) (Add in the pattern, but the work
of the architectural tradeoff analysis one must do (Bass et al., besides using different algorithms in the different filters is
2003). very straightforward; almost trivial.)
b. Active Redundancy: + +: Replicate filter components. Send the
4.4. Impact data example: reliability same stimuli to redundant filters. Use a pipe or a final filter to
receive the results from the redundant filters. You can arrange
This example describes the impact of several common reliability it so you take the first one finished, which improves perfor-
tactics on one pattern, the Pipes and Filters pattern. Each paragraph mance; a common goal in Pipes and Filters. (Replicate, plus
begins with an assessment of the magnitude of the impact, fol- add a trivial pipe or filter to handle the results, as well as a
lowed by a description of the structural and behavioral issues of distribution pipe, as noted in Voting. As in voting, the adds
implementing the tactic in a Pipes and Filters architecture. here are trivial.)
In order to be complete for reliability tactics, each common c. Passive Redundancy: −: Replicate the filter you are backing
reliability tactic must be analyzed for each common architecture up. Then modify the primary filter to send occasional updates
pattern. The analysis for one other pattern, Layers, is available in to the backup filter. The backup filter must be modified to
(Harrison and Avgeriou, 2008b), but there are many other com- receive the updates, rather than the normal input data. A pipe
mon architecture patterns. In addition, other quality attributes have or trivial filter is needed to handle the results, just as in Active
their own sets of common tactics. Redundancy. This can be done within the pattern, but Active
Redundancy is generally a superior tactic, and it fits so well,
4.4.1. Pipes and filters that this pattern is not recommended with Pipes and Filters.
Summary: The Pipes and Filters pattern is chiefly used for (Replicate, plus significant changes to the filters.)
sequential actions such as processing data streams or incremen- d. Spare: +: Set up a device as the spare, with the ability to run
tal processing. Its hallmarks are performance and flexibility, but it as any of the different filters. Create a new filter that handles
is often also found in highly reliable systems. It has a few significant distribution of work. It must detect when a filter does not
liabilities that must be overcome in such systems. respond to sending work (e.g., did the data write fail), and then
initialize the spare as that kind of filter. (Add in the pattern,
1. Fault Detection but the new filter is not trivial.)
a. Ping/Echo: − −: A central monitoring process must be added, 3. Recovery – Reintroduction
which must communicate with each filter. Each filter must be a. Shadow: +: In Pipes and Filters, Shadow is implemented sim-
modified to respond in a timely manner to the ping messages. ilarly to Voting. In this case, the receiving component checks
This not only affects the structure of the pattern, but may con- the results from the shadow against the results of the primary
flict with realtime performance. (Add out of the pattern, along filter to see if they are correct. It may be necessary to com-
with moderate changes to each filter component.) municate the state of the shadow filter back to the filter that
b. Heartbeat: − −: Similar to Ping/Echo. It is a bit easier to add distributes the work. Note that the shadow filter itself should
the heartbeat generating code to the filters, because they do need no changes. (Duplication with simple add in the pattern,
not have to respond to an interrupt. However, each filter must plus possible small Modify to two filter components.)
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1745

b. State Resynchronization: − −: The biggest problem with this 5.1. Documenting tactics in architectures
tactic is filters should not have states except within processing
of one piece of data. And in that case, it usually makes most Because implementing a tactic in an architecture can signifi-
sense to restart processing of that data from the beginning. cantly change the architecture patterns, it can be difficult to find
If you must to implement this tactic, define states for each the patterns in the architecture diagrams, making understanding of
filter and create a mechanism to restore a filter to the proper the system more difficult. This is particularly problematic in legacy
state when it comes back up. That may require a monitoring systems, where implementing tactics is actually a form of “archi-
process. (Major changes to components, plus possible add out tecture drift” (Rosik et al., 2008). Therefore, it is important to be
of the pattern.) able to easily reflect tactics in architecture documents, including
c. Rollback: − −: Check pointing is easy to do. However, once the existing ones.
data passes to the next filter, it is extremely hard to undo it Comprehensive architecture documentation presents multiple
– it is gone. If you must use it, use a monitoring process and views of the architecture (IEEE, 2000; Kruchten, 1995). A view is
a protocol of checkpoints to ensure the integrity of the data defined as a representation of a set of system elements and the rela-
at the end of each filter. (Add out of the pattern, plus major tionships associated with them (Clements et al., 2002a). Clements
changes to components.) et al. describe several different generic types of views, or view-
4. Prevention types, which highlight different characteristics of the architecture
a. Removal from Service: −: Use a monitoring process to decide (Clements et al., 2002a). Kruchten et al. also note different views
when to remove a filter from service. (Add out of the pattern. of the architecture (Kruchten, 1995). An important view of the
Minor changes may be needed for reconfiguration.) architecture is the components and connectors view. In spite of
b. Transaction: ∼: Filters work naturally on streaming data, the fact that as Clements et al. point out, no single view can fully
rather than transaction-oriented data. However, the first fil- represent an architecture, the components and connectors view
ter in a sequence might package the data into transactions, is the only architecture documentation of many systems. Informal
and later filters could operate on transactions of data (A triv- diagrams may consist of lines and boxes, where boxes usually rep-
ial example not directly related to reliability used by one of the resent some sort of components or sub-components, and the lines
authors in a college course is calculating bowling scores with between them represent some relationship between components.
a Pipes and Filters architecture. The first filter packages the Other architecture documentation may consist of UML, or employ
raw data into “frames”, and the second filter sums the scores ADLs or other formalisms (Allen and Garlan, 1994; Allen, 1997;
of each frame.) Shaw et al., 1995). However, the diagram styles vary widely; there
c. Process Monitor: −: Use a monitoring process to detect when a is no standard that is universally used in architecture diagrams
filter fails, and reconfigure the system. (Add out of the pattern. (Harrison and Avgeriou, 2008a).
Minor changes may be needed for reconfiguration.) These points lead to three requirements on a tactic documenta-
tion method:

5. Implementing tactics in patterns 1. In order to meet the needs of existing architectures, it should be
possible to apply it to existing architecture diagrams. Further-
How does one use the model presented above in the implemen- more, it should be clear what changes were made, and that the
tation of a system? changes are associated with adding tactics.
There are numerous processes for architectural design 2. It should be adaptable to differing amounts of formality in the
(Hofmeister et al., 2005), including some that explicitly involve existing description. Therefore, it should be semantic-free, but
architecture patterns (Harrison and Avgeriou, 2007b). Regardless ideally should allow for adding semantics as desired by the user.
of the process, one must weigh architectural alternatives, including 3. Any method of documenting tactics must be compatible with
which patterns and tactics to use. When one is considering which different architecture diagramming styles.
patterns and/or tactics to use, one needs to know: 4. It must be easy to add to the diagrams. If it is difficult, it will not
be used.
1. Where in an architecture under consideration would a tactic be
implemented? We propose a method of annotating architecture diagrams
2. What is the magnitude of the impact of a given tactic on a given with tactic implementation information. It is a clear way to doc-
architecture? ument the addition of tactics to architecture documents that is
also easy to use, allows the architectural components to remain
visible, and can annotate many different styles of diagrams. It is
If a legacy system is under consideration, one also needs to based on the types of changes to architecture patterns as described
know the implementation constraints when adding new tactics. earlier.
For example, if the Passive Redundancy tactic is added in order to There is a great deal of variation in styles of architecture dia-
improve the reliability quality attribute, one needs to know the grams. In our studies of 47 architecture diagrams (Harrison and
conditions and methods of data storage (including which reposi- Avgeriou, 2008a), we found that while all used boxes and lines,
tory architecture pattern is used – see Avgeriou and Zdun, 2005), the meanings of the boxes and lines differed. Few explicitly used
and where it sits in the architecture (e.g., as a layer in the Layers standard notations such as RUP or UML. Therefore, a key advan-
pattern.). tage of this annotation is that the annotation is not tied to any
Existing architecture methods deal with making decisions about one notation. Regardless of the architecture notation style used,
these questions (see related work section for details.) In order to people can continue to use it and add the annotation to show
help them do so, we show a method of annotating architecture the tactics added and changes required. This is especially true
diagrams with tactic information. It can be used, for example, to because the annotation is basically independent of the diagram
annotate the logical view of a 4 + 1 architecture (see (Kruchten, semantics. One can add annotations to boxes or lines as needed.
1995).) This annotation can be used to evaluate alternatives during And other methods besides the circles may be used. For example,
initial architecture, and can be used to show tactic information of UML components can be annotated through stereotypes or notes
existing systems. instead.
1746 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Table 5 Table 7
Sample quality attribute abbreviations. Types of change to pattern participants.

R Reliability Abbreviation Type

S Security I Implemented in
U Usability R Replicated
PF Performance AI Added, in the pattern
PO Portability AO Added, out of the pattern
M Maintainability M Modified
CP Capacity
CF Configurability
E Extensibility

Table 6
Sample tactic list.

ID Tactic

S1 Authorization (security ++)

S2 Encryption (security ++)
R3 Ping/Echo (reliability − −)
Fig. 4. Tactic implementation annotation style.
PF4 Concurrency (performance ∼)

The flexibility of annotation is shown in the examples and in the

case studies, which show annotations of diagrams with differing
semantics and syntax.

5.1.1. Annotation style

Fig. 5. Sample tactic implementation annotation.
The annotation method consists of two things: a list of tactics
applied and circles showing the location and type of changes to
the architecture for a tactic. The list of tactics consists of entries placing a circle on a pattern participant detracts from the clarity
that associate an implemented tactic with the circle that show its of the diagram, i.e., obscures the writing in a box, it may be placed
implementation. Each entry in the tactic list consists of a unique next to the participant.) Note that for a given tactic, the type of
identifier and the name of the tactic. The identifier consists an change may vary for different participants, so the change types may
abbreviation of the quality attribute, followed by a number. The vary accordingly. (That is why each circle contains a change type.)
number uniquely identifies changes for that tactic. The name of the Note that where tactics result in the addition of participants, the
tactic is the name as shown in the examples above. Each entry in latter are added to the diagram (as one would normally do), and
the tactic list also gives the magnitude, using the magnitude scale annotated with a circle.
given earlier. An entry may also contain additional explanatory text, This example shows the addition of the security tactic Autho-
if desired (examples of such text can be seen in the case studies.) rization and the reliability tactic Ping/Echo to the Pipes and Filters
A sample of quality attribute types follows. Note that there is architecture. Fig. 6 shows the Pipes and Filters architecture before
some disagreement among experts as to the taxonomy of quality the addition of the tactics. Authorization generally requires a single
attributes. Therefore, this is a sample list only, based on quality point of authorization, so a central authorization server is added to
attributes given in (International Standards Organization, 2001) provide authorization (Fernandez and Ortega-Arjona, 2009). When
(Table 5). a filter receives work, it first contacts the authorization server to
This is an example of a tactic list. The names in parentheses are receive permission for the work. We see that the authorization
for the reader’s convenience; architects may or may not choose to server and its connectors are added outside the pattern (abbrevi-
include them (Table 6). ation AO), while the filter components are modified (abbreviation
The types of changes to the pattern participants follow the M). The resulting architecture diagram shows authorization added
types described earlier; namely, implemented in, replicated, added (Fig. 7).
within the pattern, added outside the pattern, and modified. Each We now add the Ping/Echo Reliability tactic to this architecture.
circle contains an abbreviation for the type of change. We use the We can take advantage of the central authorization server to also
abbreviations as in Table 7. manage the ping messages, and rename it the Central Control.
The circle has the tactic id at the top, and the type of change Ideally, one has both the “before” and “after” diagrams; that is,
below, as Fig. 4. Figs. 6 and 8. However, the latest diagram should be sufficient to
Atypical circle looks like Fig. 5. both identify the architectural structure and guide the implemen-
This shows an addition to a component within the constraints of tation of the tactics.
the pattern, for the tactic listed as S1. If the previous table is being The above example shows an annotated structure diagram, with
used, S1 indicates the Authorization tactic for security. annotations added to components and connectors. In a similar
The circles are placed in the diagram on the pattern participant manner, annotations may be added to behavior diagrams. The same
(e.g. component, connector, message) that is changed for that tactic. change types are used as for structure diagrams. In behavior they
The circles should be placed on all the participants that change. (If have similar meanings, as described previously.

Fig. 6. A simple Pipes and Filters architecture.

 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1747

Fig. 7. Addition of authorization tactic to Pipes and Filters architecture. Note: In this diagram, the arrows on the connectors show possible direction of communication. The
connectors to the authentication server show that the authentication server can respond to the filters.

Where an architecture has both structure and behavior dia- implemented in the systems, but the architecture diagrams do not
grams, the same tactic identifiers should be used on both diagrams, indicate it.
so that one can easily recognize the impact of implementing a tactic
on both the structure and behavior of the architecture. 5.1.2.1. Google. This example shows the Google architecture, as
The following example shows a message sequence chart for Bro- described in (Brin and Page, 1998). We see the Shared Repository
ker pattern (from Buschmann et al., 1996) showing the addition of pattern in the upper right corner for Fig. 10; it is shared by at least
the Voting tactic, used to increase reliability (Bass et al., 2003). the Indexer and the Store Server. The Store server also serves as a
In Fig. 9, we see that the Broker component modifies its “find Broker of sorts for it. We choose to improve performance by adding
servers” action to find multiple servers that will participate in the the performance tactic, Add Concurrency. To do so, we replicate
voting. It adds additional “call service” messages to go to the voting the Repository component and modify the Store Server compo-
servers. When messages are received, the Broker adds behavior to nent to handle the duplication. The Indexer component may need
wait until all voters have responded, and then select the proper to change in a small way to handle multiple Repository compo-
response. We see that the behavior of the servers and the client do nents. We see in this example that the main change happens in one
not change. pattern (Repository), and an associated change happens in another
For simplicity, the diagram shows only two servers. pattern (Broker.)

5.1.2. Examples 5.1.2.2. Ambulance. Fig. 11 is from an ambulance information sys-

The following examples were taken from real architecture dia- tem, from (Stevens et al., 1998). The upper rectangle labeled
grams from (Booch, 2007). In each case, we added a tactic that “Statistics” is a Shared Repository. We wish to improve reliability
would be a likely candidate for that application. These exam- by duplicating the repository, using the Passive Redundancy (Warm
ples show how even with different architecture diagram styles, Spare) pattern. (Note: this improves the availability of the system
it is possible to annotate them with tactic information. We note by allowing the system to continue to operate if one of the databases
that it is entirely possible that the tactics we chose are already is to fail; reliability of data integrity is clearly already supported

Fig. 8. Addition of Ping/Echo to Pipes and filters with Authorization. Note that we reuse the connectors between the filters and the central controller.
1748 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 9. Broker message sequence diagram with voting added.

through the archive and recover components.) This diagram is Blackboard Monitor component. We see all these changes reflected
problematic because it is not clear what the large rectangles mean. in Fig. 12.
Most appear to designate association, such as the lower rectangle
labeled “Operator Windows,” but the one we are concerned with, 5.1.3. Uses for the notation
the Statistics rectangle, may in fact designate containment within Clements et al. (2002b) note that two major purposes of archi-
a common database component. Furthermore, we were unable to tecture documentation are for education and for communication
obtain the book that contains this diagram, so further information among stakeholders. Our studies given below indicate that it can
is unavailable. Even without this information, we understand that be useful as a communication tool to show where tactics are to
we must duplicate the data and manage the redundant databases. be implemented. It may also be useful in education (e.g. when
Clearly, the clients of the data should not have to know about the new members join the team), as it shows quickly and graphically
duplicated database, so that management must happen inside the where changes to the architecture have been (or will be) made to
Statistics rectangle. It appears that if it was not a containment rela- implement tactics. In the future, we intend to study and potentially
tion before, it certainly is now. We explain the tactic structure in provide evidence about the educational benefits of the annotation.
light of the uncertainty of the diagram; for illustration purposes, we A potential limitation of the utility of the notation is the com-
have put it in the tactic list. The notation does not specify where it plexity of systems; both the number of patterns employed and
should go. the number of tactics used. Our studies of software architectures
(Harrison and Avgeriou, 2008a), show that most (31 out of 47)
5.1.2.3. Speech recognition. The following example is of a speech architectures use more than one pattern, but only 6 used more than
recognition system, based on the Blackboard architecture pattern, 3 patterns. As shown in the examples and case studies, the notation
from (Shaw, 1991). The blackboard pattern consists of a central data is adequate for systems with 3 patterns. Of course, the number of
store, called the Blackboard component, a controlling component, tactics is more critical, and some systems can employ numerous
and several knowledge sources that are specialized for solving a tactics (Ozakaya et al., 2008). We see in the previous figures that
particular part of the overall task. some tactics affect only one or two components and connectors,
We wish to add the reliability tactic Voting. The idea here is that while other tactics have much wider impact. If many tactics with
speech recognition can be very difficult, and different algorithms wide impact are used, the resulting architecture diagram will be
may have different degrees of success at different times. To maxi- very cluttered, and likely unwieldy. In such a case, one may wish
mize the chances of accuracy, we implement two or more different to show either only the latest tactics added, or only the tactic rela-
algorithms and select the best result among them. (The best result tionships that are particularly notable. This problem is solved if the
might be obtained by taking the two outputs that are most similar, notation is supported by a tool: a designer can select to show or
for example.) hide tactics at will.
The diagram shows several components within the Blackboard A potential use is to facilitate identification of areas of compati-
component called “levels.” It is not clear whether they form a Lay- bility or conflict among the tactics themselves. We have seen where
ered architecture within the Blackboard, but it does not matter: we authorization enabled Ping/Echo, and the close relationship of the
want to re-implement the Blackboard component as a whole. We tactics’ implementations is reflected in Fig. 8.
put the tactic circle next to the Blackboard label to show this. This annotation is also potentially useful in software architec-
A voting scheme requires a Voter component to make the selec- ture reviews. Several researchers have documented the worth of
tion among the results. This appears to be a natural task for the software architecture reviews, but have also noted their high cost
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1749

Fig. 10. Google architecture with “add concurrency” tactic.

(Bass et al., 2006a; Abowd et al., 1997; Maranzano et al., 2005; architecture diagrams were annotated during the review, and the
Clements et al., 2002c). We are exploring low-cost architecture participants were able to easily see where to add the tactics. We
reviews, and have annotated architecture diagrams during some describe three of the studies below.
reviews as an aid in discussing changes to the architecture. While
the results are preliminary, the use of this annotation during archi- 6.1. Case study 1
tecture reviews appears to be very beneficial. The next section
presents three of these case studies. 6.1.1. Product description
We visited company “A” and studied the architecture of its flag-
6. Case studies ship product. (Proprietary concerns prevent giving the real name
of the company or revealing details of the product and its archi-
We have validated the model and annotation further by annotat- tecture.) Company A produces systems that perform sequential
ing diagrams associated with architecture reviews. In some cases, processing of certain materials. The systems consist of modules that
the annotations were added after the review, and annotated archi- perform specialized processing; these modules may be combined
tecture diagrams were given to the architects. In other cases, the in various ways to meet the customers’ needs. Each module con-
1750 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 11. Ambulance with “passive redundancy” tactic.

sists of specialized hardware and controlling software. Although found that measures to improve reliability had significant impact
modules perform their tasks autonomously, they are coordinated on the architecture.
by a central controlling module. The most significant reliability tactic employed was a form of
The product has several important quality attributes, and par- transaction rollback to handle faults encountered during materi-
ticular challenges associated with them. The three key quality als processing. This required the addition of a central managing
attributes are performance, modifiability, and reliability. All three component that communicates with each of the filter components.
are critical, and it would be difficult to say which is most important. This is adding a component outside of the architecture, resulting in
Performance is a key attribute in that the system must pro- significant change to the architecture. New communication links
cess customers’ materials as fast as possible – speed of processing must be added, and the filter components must add corresponding
contributes directly to the advertised capacity of the system. software.
In this case, modifiability means that the system may be config- The second reliability tactic to be implemented is the Ping–Echo
ured in many ways depending on the customer’s needs. tactic. This tactic addresses the potential problem of handling a
Reliability consists of processing the material correctly. This is filter component that crashes or otherwise becomes unavailable.
very important in this product; errors cannot be tolerated. How- Fortunately, the central manager and the associated communica-
ever, handling the material is inherently error-prone. Therefore, it tion links added for transaction rollback can be used to implement
is critical that the system have robust fault tolerance mechanisms. this tactic. Therefore, implementation of Ping–Echo is accom-
It is largely the responsibility of the software to implement fault plished by modifying existing components. But on the filter side,
tolerance. the modifications are potentially significant: Ping–Echo requires
that the ping-ed component respond in a timely manner. This
requires that each filter implement a prioritized message handling
6.1.2. Architecture
and response scheme. This could perturb normal timely processing
The physical nature of the task, coupled with the need to
of materials, and must be implemented carefully.
have flexibility in configuration and high speed processing, led
Fig. 14 shows the architecture, with annotation of the two tactics
the architects to a Pipes and Filters architecture. The filters con-
described above.
sist of hardware components with their associated software. The
components operate on physical materials (rather than data, as tra-
ditionally found in Pipes and Filters architectures), and pass it to the
6.1.4. Notes on the architecture
next filter in the chain. The Pipes are simply physical transfer mech-
There are two architectural considerations worthy of note. The
anisms carrying the materials from one to component to another.
first is that the central manager can provide other capabilities
Fig. 13 shows the basic architecture, without tactic information.
besides implementing the two tactics given here. The central man-
ager can manage the startup and shutdown of the entire assembly
6.1.3. Tactics employed and their impact on the architecture line. It can also dynamically reconfigure an individual component,
The Pipes and Filters pattern is a good fit for performance and if necessary. It is likely that even without these two tactics, there
modifiability (Harrison and Avgeriou, 2008a). However, it is gener- would be a need for the central manager component, even though
ally not a good fit for reliability (Harrison and Avgeriou, 2008b). We it significantly changes the Pipes and Filters pattern.
N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1751

Fig. 12. Speech recognition with “voting” tactic.

Fig. 13. Company A product architecture (before application of tactics).

1752 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 14. Company A: product architecture with tactic application shown by annotations.

Second, the failure of a single filter component has ramifications many opportunities for error and even fraud. Here are some fault
beyond itself. In particular, if a filter component encounters an error tolerance scenarios that should be handled gracefully:
or fails completely, the filters that precede it must not continue a. The worker punches in and neglects to punch out.
sending material to it. This requires that the central manager notify b. The client computer goes down after the worker punches in.
controllers to stop processing material. Fortunately, the communi- c. The link between the server and the client server goes down
cation infrastructure is available as part of the transaction rollback while the worker has punched in.
tactic, so no components need be added. Details of the messages d. The worker punches out without punching in.
used for these purposes could be annotated in message sequence e. The worker punches in from two different computers at the
diagrams, if desired. same time.
Note that the order of implementing the tactics appears to f. The server goes down.
be irrelevant. While the Ping/Echo tactic uses the infrastructure 3. Reliability (accuracy): like fault tolerance, the ability to manually
introduced by Transaction Rollback, if Ping/Echo is implemented correct entries allows some inaccuracies to be tolerated, but they
first, Transaction Rollback can use the infrastructure introduced by should be minimized.
Ping/Echo. 4. Performance (capacity): The system should support at least 50
A notable aspect of this architecture is that the tactics of Trans- simultaneous users, although this requirement is somewhat
action Rollback and Ping/Echo were part of the initial design of the flexible. There may be a concern with the performance of the
system; that is, the tactics shaped the architecture from the begin- software on the server side, but that is probably a later concern.
ning. The tactic annotation helps illustrate the purpose of the main 5. Performance (response time): Users should see reasonable
controller component, and can help show why this architecture response (exact response time figures were not given.)
deviates from the standard Pipes and Filters architecture.
6.2.2. Architecture
6.2. Case study 2 The architecture is dominated by the fact that the system is
data-centric, and that it must allow remote use. This led to an
6.2.1. Product description architecture based on the Repository and Broker patterns. Remote
This product is a web-based time tracking system for use by systems employ a thin client that communicates to a central server.
contractors to record time worked on various contracts. It allows a Processing of data on the server also led to Layers for part of the
contractor to log in and specify the contract being worked on, and system (Fig. 15).
the system records the time spent. It allows the data to be summa- This Diagram shows three prominent patterns. The client com-
rized for the purposes of generating payments to contractors. munication is handled by the component called “Common”, which
Because the contractors work from various locations, the system is functioning as a Broker. A database (the Repository pattern)
must allow remote access. However, this opens up opportunities underlies the entire system. On the right, we see the main pro-
for errors, including human errors. A key feature of the system is cessing of the system contained in three layers. We note that
its handling of erroneous situations. These situations may require the “Common” component communicates directly with the layers,
the ability to manually correct or update the time data. thus changing or “breaking” the Layers pattern; this was done to
The main quality attribute of the system is reliability. Perfor- improve response time. The change to the Layers pattern is not
mance (or capacity) is also worthy of note. The following aspects of noted in the architecture diagram, and may be missed by future
quality attributes were considered: architects and developers. The next diagram will annotate that
modification.

1. Reliability (sub-area: availability): It is desirable that the system

be available at all times. However, this does not appear to be a 6.2.3. Tactics employed and their impact on the architecture
critical need: contractors simply call and report when the system In order to improve the fault tolerance of the distributed sys-
is unavailable. tem, the Heartbeat tactic was suggested. The thin client must send
2. Reliability (sub-area: fault tolerance): Faults in the data can be regular heartbeats to the server. Heartbeat can be implemented
tolerated to a certain extent in that they can be manually cor- entirely within the Broker structures (consisting of the Broker and
rected. However, this is an area of concern, because it opens the thin clients) with no structural changes. In fact, heartbeat mes-
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1753

Fig. 15. Time manager architecture (before annotation).

sages often piggyback on other messages; this can be done in this The following quality attributes are important to this system:
case as well.
In order to prevent data from being corrupted, transaction 1. Reliability (accuracy and fault tolerance): The consequences of
rollback can be introduced. This tactic often comes as part of com- inaccurate data are serious: Customers get angry because they
mercial databases, so it is implemented within the Repository do not get the magazines they paid for. And it costs time and
pattern, with no structural changes needed. trouble to hunt down the error, even to the point of finding the
In order to improve performance, the Broker might bypass some original paper order and verifying it.
of the layers. This involves adding communication links outside the 2. Performance (capacity): The amount of data being handled is
Layers pattern. quite large for a system of this size. There are currently around 90
Fig. 16 shows the architecture, with the addition of the two thousand customers, and roughly one million orders. There are
tactics described above. around 1000 different magazine titles. However, because each
magazine can come from multiple suppliers, the real number
6.2.4. Notes on the architecture of magazines is three to four times that number. The system
The architects chose to use a different type of architecture dia- must handle not only this load, but larger amounts of data as the
gram than in other example in this text. Yet we see that the same business expands.
annotation method can be used on different types of diagrams. 3. Extensibility: There are numerous important capabilities that
The architecture shows the addition of a component used to will be needed in the future, so the system must be easily
bypass layers to improve performance. In this case, the com- extended.
mon component could easily be used to implement another 4. Security (authorization): It is important to keep the system safe
tactic, namely the Heartbeat tactic. However, the next case study from unauthorized use. In particular, data entry employees may
shows where the addition of a component (again, bypassing layers have different privileges.
to improve performance) causes difficulty when adding another 5. Performance: The system has no hard or soft real time needs, but
tactic. response time should be quick.

6.3. Case study 3 6.3.2. Architecture

The quality attributes played a significant role in the shaping
6.3.1. Product description of the architecture. The architects selected a commercial database
This product is a system that supports a magazine subscription that provided good reliability (such as transaction rollback.) It also
clearinghouse business. The system’s purpose is to collect, store, supported the high capacity needed for now and the future. The
and track information about customers and their magazine sub- architects used the Model View Controller (MVC) pattern, which
scriptions. supports extensibility.
Currently, customers mail orders for magazine subscriptions The controller part of the system was built using a layered
to the company. Clerks then enter the orders into the sys- framework (a commercial framework); however, it was found to
tem. The clerks may work from home, so remote access is have slow response time on occasion, so the architect took advan-
required. tage of another commercial product to bypass layers. This is a com-
Future enhancements may include allowing web-based order- mon way of “breaking” the Layers pattern in order to improve per-
ing. At this time it is not needed, because the targeted customers formance. At this point in the architecture, security needs have not
are prison inmates, who have limited web access. yet been considered. Fig. 17 shows the architecture up to this point.
1754 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Fig. 16. Time manager product architecture with tactic annotations.

In this diagram, we can see the Repository, as well as the Model, Controller layers (added within the pattern), and another compo-
View, and Controller components. We note that the views are nent was added before the component that bypasses the layers. This
remote, comprising the client side of the client–server pattern. We new component is outside any of the patterns. Of particular con-
also see the component that bypasses the layers. It is reasonably cern is that two different components perform the same function,
clear without additional annotation. leading to the probability of duplicated code.
However, authorization had not yet been added. In a layered
architecture, authorization can be easily added as an initial layer – 6.3.3. Tactics employed and their impact on the architecture
adding a component within the pattern structure (minor impact.) Fig. 18 shows the complete architecture, after the authoriza-
In this case, though, there were two paths through the system from tion components were added. We have annotated the diagram with
the views. Each required authentication. So a layer was added to the tactic information. The annotation highlights the components that
have been added.

6.3.4. Notes on the architecture

This architecture illustrates the case where the addition of com-
ponents outside the architecture patterns has a snowball effect –
adding the layer bypass component caused an extra authorization
component to be added, with duplicated code (Note that adding
a single authorization component above both components was
not feasible – it ended up defeating the performance gains that
the direct access component provided.) This has the potential to
adversely impact system maintenance. It is not clear whether it will
have any impact on extensibility, an important quality attribute
for this system. However, the close relationship between main-
tainability and extensibility makes this architecture a cause for
concern.
The architecture diagram, together with the annotation, should
encourage consideration of alternative architectures. The following
three alternatives might be considered:

1. Could the authorization be handled in the views component?

This is unlikely, since that would mean that the authorization
happens on a remote client, which itself is a security vulnerabil-
ity.
2. Could the authorization layer handle authorization for both
the layers and the bypassing component? This appears to be a
reasonable solution, but has one notable weakness. The autho-
rization component would have to make the decision about
Fig. 17. Subscription management system architecture (before annotation). whether to route requests through the layers or through the
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1755

Fig. 18. Subscription management system architecture with tactic annotations.

bypass. This would require the authorization component to have 6. We observed that the amount of documentation needed is
detailed application knowledge, which is well beyond its job. potentially small. Where documentation of interaction of archi-
3. Could the bypass be removed altogether? This is a tradeoff deci- tecture patterns and tactics exists, it can be leveraged to
sion between performance and maintainability. The architects minimize the amount of writing needed. Additional insights can
decided that the benefits of improved performance outweighed be added to the tactic description list as needed to increase clar-
the liabilities of increased maintenance difficulty. ity.
7. We observed that for simple architecture diagrams, the notation
6.4. Lessons learned is small enough that the architecture itself is not obscured. In the
diagrams above, the size of the boxes representing components
These case studies show several benefits of annotating architec- were rather small, but the tactic circles could still be placed so
ture diagrams with tactic information in this manner. We derived that the architecture itself was clear.
the participant observations through informal interviews with
participants in two architecture reviews, where the architecture We also observed several limitations to the annotation. They
diagrams were annotated during the review. In addition, three include the following:
architecture diagrams were annotated and emailed to the archi-
tects. In both cases, participants were asked whether they observed
benefits, and if so, what. We noted the following benefits: 1. The notation gives information about the location and general
type of changes needed to implement tactics. However, it does
not necessarily give specific information about the changes.
1. The participants observed that it clearly shows which compo- Of course, there is a tradeoff between information given and
nents must be modified, and gives a high-level idea of the nature both effort and clarity of architecture diagrams. This approach
of the changes that must be made or have already been made. attempts to maximize clarity and reduce effort; however addi-
2. The participants observed that it shows where tactics interact tional documentation might be desirable, especially for large
with each other. For example, the third case study shows the projects.
addition of tactics for both performance and security, where an 2. The notation is most effective when it can refer to detailed
additional authorization component was required because of the information about the interaction of patterns with tactics. Unfor-
component added for performance. tunately, much of that information in not published. This paper
3. We observed that the annotation can be used both to show the shows some samples of such data, but remaining information
addition of tactics to existing architectures and to show tactics must be written.
in the original architecture. 3. The consideration of design time tactics was out of the scope of
4. We observed that the annotation is adaptable to various styles our work. Investigation of applying the notation to design time
of component and connector architecture documentation. It can tactics is possible future work.
annotate both the components and the connectors with the same
notation. We established this by annotating different documen-
tation styles, as shown in the examples. 7. Related work
5. We observed that the annotation is easy to add; we were able
to annotate diagrams during the reviews. This is important, as Bass et al. (2003) have described many important tactics, and
it has been noted that effort required can hinder the amount of note that patterns and tactics interact. This paper explores this
architecture documentation done (Jansen and Bosch, 2004). relationship in depth.
1756 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Many architecture pattern descriptions include some explana- mentation might result in what Zdun calls “pattern variants.” Thus
tion or a pattern’s compatibility or incompatibility with certain Zdun’s work appears to be highly compatible with this work.
quality attributes (Maranzano et al., 2005). The interaction has been The IEEE 1471 standard (IEEE, 2000) describes a meta-model
described across more patterns and quality attributes in (Harrison of software architecture that includes, among other things, mul-
and Avgeriou, 2007a), though at a very high level. The interaction tiple views of the architecture as well as the satisfaction of
is characterized in more detail in (Harrison and Avgeriou, 2008a). stakeholder concerns. Our work focuses on stakeholder concerns
It has been explored in considerable detail for the well-known tac- of quality attributes, and shows how views of the architecture
tics of reliability interacting with one or two architecture patterns (particularly component and connector-based views) can be anno-
(Harrison and Avgeriou, 2008b). This paper describes the types of tated with such information. Thus it is compatible with this
interactions and presents a method of documenting the interac- meta-model.
tions. An important area of research is the interaction of multiple tac-
Numerous methods of architecture design have been pro- tics. Nearly every non-trivial system implements multiple tactics,
posed; several important such methods have been generalized by and they might not be independent of each other. We have seen
Hofmeister et al. (2005). The general model consists of three activi- in Fig. 8 how a tactic can be implemented to take advantage of
ties: Architectural analysis identifies the architecturally significant a previously implemented tactic. Thus it appears that the order of
requirements (ASRs) of the system; namely those requirements implementing tactics is significant. The Architecture-Driven Design
that influence its architecture. The second activity is architec- (ADD) method (Bass et al., 2003) acknowledges this. Bass et al.
ture synthesis, the creation of candidate architecture solutions to build on this to show how patterns and tactics show rationale and
address the ASRs. Architecture evaluation, the third activity vali- design changes over time (Bass et al., 2006b). This work captures
dates the candidate solutions against the ASRs. Our model shows ordering of tactic implementation. One could also capture a history
how quality attributes are architecturally significant, and provides of architecture snapshots, showing the addition of snapshots over
support for determining tradeoffs during synthesis and evaluation. time.
The model explicitly supports making such decisions in pattern-
based architecture design (PDAP) (Harrison and Avgeriou, 2007b),
8. Future work
and in quality attribute-based reasoning frameworks as proposed
by Bachmann et al. (2005). The annotation method is also compat-
There are several areas that require further research. These
ible, and can be used in architecture synthesis and evaluation.
include the following.
Architecture reviews have been identified as an important way
Our studies have shown that architects consider the annotation
to improve the quality of the software architecture (IEEE, 2000;
of architecture diagrams with tactic implementation information
Maranzano et al., 2005; Bianco et al., 2007; Obbink et al., 2002). We
useful. But longer term, how is it used? How useful is it for main-
have found that annotating an architecture diagram can be a useful
tainers who are learning the system architecture? This is an area
activity during an architecture review.
for long-term study.
In ATAM and ADD (Bass et al., 2003), the analysis of architectural
We have used the interaction information to help identify issues
tradeoffs is an important part of the architectural decision mak-
during architecture reviews (as noted in the case studies), and have
ing process. In particular, one considers tradeoffs among tactics.
begun using the annotations in the reviews as well. We expect to
Our analysis of the nature of impact of tactics on architecture pat-
use them further in order to better understand their benefits as well
terns supplements tradeoff analysis: it helps architects understand
as limitations in architecture reviews. It may also be beneficial to
and visualize where the impact of a tactic occurs, and how great
tie the tactics’ implementations to the risk themes of architecture
this impact is likely to be. This information helps provide specific
reviews as described by Bass et al. (2006a).
substance to be used in tradeoff analysis.
The interaction of multiple tactics as well as tactics on multiple
Several of these architecture methods center on various views
patterns should have additional study. We are considering how the
of the system. Clements et al. (2002a) describe general viewtypes of
magnitude of the impact of tactics changes when considered in the
module, component and connector, and allocation. The Siemens’ 4
context of multiple patterns.
Views method (Hofmeister et al., 2005) has four views: conceptual,
Another issue of multiple tactics is how the annotation method
execution, module and code architecture. The Rational Unified Pro-
scales. At what point does the annotation become less useful
cess 4 + 1 Views (Kruchten, 1995) centers on four views to describe
because it clutters the architecture diagram? While we have found
the architecture: logical view, process view, implementation view,
it scales up through six tactics, we do not know how it scales to
and deployment view. As shown, our annotation method is quite
very large systems.
flexible, but is most naturally applied to Siemens’ code architec-
We have concentrated on the run time tactics as described in
ture view and to the RUP logical view. It fits well within Clements’
(Bass et al., 2003). We find that the other tactics they describe,
component and connector viewtype.
design time tactics, tend to cut across all design partitions, and
Numerous formal models and architecture description lan-
are implemented implicitly in the code. Therefore, they are not as
guages (ADLs) have been developed for expressing architecture
good a fit for the model as are the run time tactics, nor do they
(Allen and Garlan, 1994; Allen, 1997; Shaw et al., 1995). They have
have as well-defined effects on patterns. The model and the design
different levels of support for modeling and representing patterns;
time tactics should be studied in more detail to determine how the
however the most popular ADLS have components and connectors
design time tactics can be represented in the model and annota-
as central building blocks of architecture descriptions. As we have
tion. Besides refinement of the model and annotation, it will lead
shown, our annotations can be applied to components and connec-
to greater insights about the nature of design time tactics versus
tors in architecture diagrams. We have not proposed any extensions
run time tactics.
to text-based ADLs that provide the annotation information; how-
ever the common focus on components and connectors makes it
clear that such augmentations are easily made. 9. Conclusions
Zdun (Zdun, 2007) has proposed design space analysis as a
method for the selection of architecture patterns and pattern vari- It has long been known that architecture patterns and qual-
ants. Quality attribute information is a key part of the design space ity attributes are not independent, but have significant interaction
information. Changes to the patterns to accommodate tactic imple- with each other. We have found that this relationship is very rich,
 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758 1757

and involves the implementation of quality attributes through tac- References

tics.
The interaction among patterns and (runtime) tactics falls into Abowd, G., et al., 1997. Recommended Best industrial Practice for Software
Architecture Evaluation. Software Engineering Institute, Technical Report
several general categories, based on the type of changes needed CMU/SEI-96-TR-025.
to the pattern in order to implement the tactic. The amount of Allen, R.J., 1997. A formal approach to software architecture. Doctoral Thesis, UMI
work required to implement a tactic in an architecture that uses Order Number: AAI9813815. Carnegie Mellon University.
Allen, R., Garlan, D., 1994. Formalizing architectural connection. In: Proc. Interna-
a pattern depends on the type of change, as well as the volume tional Conference on Software Engineering (ICSE), Sorrento, Italy, May 16–21.
of change needed. However, details of these interactions are dif- IEEE Computer Society Press, pp. 71–80.
ferent for each pattern/tactic pair, and must be investigated and Avgeriou, P., Zdun, U., 2005. Architectural patterns revisited – a pattern language.
In: 10th European Conference on Pattern Languages of Programs (EuroPLoP).
documented. Bachmann, F., et al., 2005. Designing software architectures to achieve quality
The interaction of tactics and patterns can easily be shown attribute requirements. IEE Proceedings 152 (4), 153–165.
in architecture diagrams using a simple method of annotation. Bachmann, F., Bass, L., Nord, R., 2007. Modifiability Tactics. Software Engineering
Institute, Technical Report CMU/SEI-2007-TR-002.
This annotation method is adaptable to many different types
Barbacci, M.R., et al., 2003. Quality Attribute Workshops (QAWs), 3rd edn. Software
of architecture diagrams and documentation. We have shown Engineering Institute, Technical Report CMU/SEI-2003-TR-016.
its use in various types of structural and behavioral archi- Bass, L., Clements, P., Kazman, R., 2003. Software Architecture in Practice. Addison-
tecture diagrams. We have used it to annotate several real Wesley.
Bass, L., et al., 2006a. Risk Themes Discovered Through Architecture Evaluations.
architecture diagrams, both during and after architecture reviews. Software Engineering Institute, Technical Report CMU/SEI-2006-TR-012.
It has shown itself to be useful for illustrating the changes Bass, L., Clements, P., Nord, R., Stafford, J., 2006b. Capturing and using rationale for
required. a software architecture (chapter). In: Dutoit, A., McCall, R., Mistrick, I., Paech, B.
(Eds.), Rationale Management in Software Engineering. Springer-Verlag.
Bianco, P., Kogtermanski, R.L., Merson, P., 2007. Evaluating a Service-Oriented
Architecture. Software Engineering Institute, Technical Report CMU/SEI-2007-
Appendix A. TR-015.
Booch, G., 2007. Handbook of Software Architecture: Gallery, http://www.booch.
com/architecture/architecture.jsp?part=Gallery (accessed 10.09.07).
Tables A1 and A2 are short descriptions of some patterns and
Bosch, J., 2000. The Design and Use of Software Architectures. Addison-Wesley,
tactics used in this paper. London.
Brin, S., Page, L., 1998. The anatomy of a large-scale hypertextual web search engine.
In: W3C International World Wide Web Conference, p. 11.
Table A1 Buschmann, F., et al., 1996. Pattern-Oriented Software Architecture: A System of
Common architecture patterns (From Avgeriou and Zdun, 2005). Patterns. Wiley.
Clements, P., et al., 2002a. Documenting Software Architectures: Views and Beyond.
Pattern Description
Addison-Wesley.
Client–server There are two kinds of components, clients and Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little, R., Nord, R., Stafford,
servers. The client requests information or J., 2002b. Documenting Software Architectures: Views and Beyond. Addison-
services from a server. Clients are optimized Wesley.
Clements, P., Kazman, R., Klein, M., 2002c. Evaluating Software Architectures: Meth-
for their application task, whereas servers are
ods and Case Studies. Addison-Wesley.
optimized for serving multiple clients.
Cloutier, R., 2006. Applicability of patterns to architecting complex systems. Doctoral
Broker The broker hides and mediates all
Dissertation, Stevens Institute of Technology.
communication between clients and servers in Fernandez, E.B., Ortega-Arjona, J.L., 2009. The Secure Pipes and Filters Pattern.
a system. In Proceedings of the 2009 20th international Workshop on Database and
Layers A system is structured into layers so that each Expert Systems Application (August 31 - September 04, 2009). DEXA. IEEE
layer provides a set of services to the layer Computer Society, Washington, DC, 181-185. doi:http://dx.doi.org/10.1109/
above and uses the services of the layer below. DEXA.2009.55.
Pipes and filters A complex task is divided into several Gamma, E., Helm, R., Johnson, R., Vlissides, J., 1995. Design Patterns: Elements of
sequential sub-tasks, each of which is Reusable Object-Oriented Software. Addison-Wesley, Reading, MA.
implemented by a separate independent Harrison, N., Avgeriou, P., 2007a. Leveraging architecture patterns to satisfy qual-
component, a filter, which handles only this ity attributes. In: First European Conference on Software Architecture, Madrid,
task. September 24–26, 2007. Springer, LNCS.
Harrison, N., Avgeriou, P., 2007b. Pattern-driven architectural partitioning – bal-
Blackboard A complex task is divided into smaller
ancing functional and non-functional requirements. In: First International
sub-tasks for which deterministic solutions are
Workshop on Software Architecture Research and Practice (SARP’07), San Jose,
known. The Blackboard uses the results of its
CA, July 1–6, 2007. IEEE Computer Society Press.
clients for heuristic computation and Harrison, N., Avgeriou, P., 2008a. Analysis of architecture pattern usage in legacy
step-wise improvement of the solution. A system architecture documentation. In: 7th Working IEEE/IFIP Conference on
control component monitors the blackboard Software Architecture, Vancouver, 18–22 February, pp. 147–156.
and coordinates the clients. Harrison, N., Avgeriou, P., 2008b. Incorporating fault tolerance techniques in
software architecture patterns’. In: International Workshop on Software Engi-
neering for Resilient Systems (SERENE’08), Newcastle upon Tyne (UK), 17–19
November, 2008. ACM Press.
Harrison, N., Avgeriou, P., Zdun, U., 2006. Focus group report: capturing architectural
knowledge with architectural patterns. In: 11th European Conference on Pattern
Table A2 Languages of Programs (EuroPLoP 2006), Irsee, Germany.
Common tactics (from Bass et al., 2003). Harrison, N., Avgeriou, P., Zdun, U., 2007. Architecture patterns as mechanisms for
capturing architectural decisions. IEEE Software 24 (4).
Tactic (associated QA) Description Hofmeister, C., Kruchten, P., Nord, R.L., Obbink, H., Ran, A., America, P., 2005. General-
izing a model of software architecture design from five industrial approaches. In:
Ping–Echo (reliability) One component issues a ping and expects to 5th Working IEEE/IFIP Conference on Software Architecture (WICSA), November
receive back an echo, within a predefined time, 06–10, 2005. IEEE Computer Society, pp. 77–88.
from the component under scrutiny. IEEE Recommended Practice for Architectural Description for Software-Intensive
Introduce concurrency Process requests in parallel by creating Systems. IEEE Computer Society, October 9, 2000.
(performance) additional threads to process different sets of International Standards Organization. Information Technology – Software Product
activities. Quality – Part 1: Quality Model, ISO/IEC FDIS 9126-1, 2001.
Authenticate users Ensure that a user or remote computer is Jansen, A., Bosch, J., 2004. Evaluation of tool support for architectural evaluation. In:
(security) actually who it purports to be through 19th IEEE Intl Conference on Automated Software Engineering (ASE2004), Linz,
passwords, etc. Austria, September 2004, pp. 375–378.
Checkpoint/rollback If a system fails with a detectably inconsistent Jansen, A.G., Bosch, J., 2005. Software architecture as a set of architectural design
decisions. In: 5th Working IEEE/IFIP Conference on Software Architecture
(reliability) state, restore it using a previous checkpoint of
(WICSA), November 06–10, pp. 109–119.
a consistent state.
Kruchten, P., 1995. The 4 + 1 view model of architecture. IEEE Software 12 (6).
1758 N.B. Harrison, P. Avgeriou / The Journal of Systems and Software 83 (2010) 1735–1758

Maranzano, J., et al., 2005. Architecture reviews: practice and experience. IEEE Soft- Wood, W.G., 2007. A Practical Example of Applying Attribute-Driven Design (ADD),
ware 22 (2), 34–43. Version 2.0. Software Engineering Institute, Technical Report CMU/SEI-2007-
O’Brien, L., Bass, L., Merson, P., 2005. Quality Attributes and Service-Oriented TR-005.
Architectures. Software Engineering Institute, Technical Report CMU/SEI-2005- Zdun, U., 2007. Systematic pattern selection using pattern language grammars
TN-014. and design space analysis. Software: Practice & Experience 37 (9), 983–1016,
Obbink, H., Kruchten, P., Kozaczynski, W., Hilliard, R., Ran, A., Postema, H., Lutz, Wiley.
D., Kazman, R., Tracz, W., Kahane, E., 2002. Report on software architecture
review and assessment (SARA). In: 24th International Conference on Software Neil Harrison is an assistant professor of computer science at Utah Valley Univer-
Engineering (ICSE), Orlando, Florida, May 19–25. ACM, pp. 675–1675. sity in Orem, Utah. Before that, he was a distinguished member of technical staff
Ozakaya, I., Bass, L., Sangwan, R., Nord, R., 2008. Making practical use of quality at Avaya Labs, where he developed communications software led software devel-
attribute information. IEEE Software Special Issue on Software Quality Require- opment teams. He has studied software development organizations for over ten
ments March/April. years and is a co-author of Organizational Patterns of Agile Software Development.
Rosik, J., Le Gear, A., Buckley, J., Ali Babar, M., 2008. An industrial case study of He has published numerous articles on software patterns, effective organizations,
architecture conformance. In: Second ACM-IEEE international Symposium on and software testing. He is acknowledged as the world’s leading expert on pattern
Empirical Software Engineering and Measurement, Kaiserslautern, Germany, shepherding and the pattern conference (PLoP) shepherding award is named after
October 09–10, 2008. ACM, pp. 80–89. him. Professor Harrison has a BS in Computer Science with High Honors and Univer-
Schmidt, D., Stal, M., Rohnert, H., Buschmann, F., 2000. Pattern-Oriented Software sity Scholar Designation from Brigham Young University, and an MS in Computer
Architecture: Patterns for Concurrent and Distributed Objects. Wiley. Science from Purdue University. He is a member of ACM, The Hillside Group Board
Shaw, M., 1988. Toward Higher-Level Abstractions for Software Systems, Tercer Sim- of Directors, and Hillside Europe.
posio Internacional del Conocimiento y su Ingerieria (October) 55–61. Reprinted
Dr. Paris Avgeriou is Professor of Software Engineering at the Department of Math-
in Data and Knowledge Engineering, 5 (1990), 19–28.
ematics and Computing Science, University of Groningen, the Netherlands. He heads
Shaw, M., 1991. Heterogeneous design idioms for software architecture. In: IEEE
the Software Engineering research group since September 2006. He has participated
Workshop on Software Specification and Design, October, p. 5.
in a number of national and European research projects on software engineering,
Shaw, M., 1996. Procedure calls are the assembly language of software interconnec-
that are directly related to the European industry of Software-intensive systems.
tion: connectors deserve first-class status. In: Lamb, D. (Ed.), Studies of Software
He has been co-organizing international workshops in conferences such as ICSE,
Design, Proceedings of a 1993 Workshop. Springer-Verlag, pp. 17–32, Lecture
ECOOP, ICSR, UML, ACM SAC and editing special issues for journals like IEEE Soft-
Notes in Computer Science, No. 1078.
ware. He is in the editorial board of Springer TPLOP. He is a member of IEEE, ERCIM,
Shaw, M., Garlan, D., 1996. Software Architecture: Perspectives on an Emerging
Hillside Europe and acts as a PC member and reviewer for several conferences and
Discipline. Addison-Wesley.
journals. He has received awards and distinctions for both teaching and research
Shaw, M., DeLine, R., Klein, D.V., Ross, T.L., Young, D.M., Zelesnik, G., 1995. Abstrac-
and has published more than 80 articles in peer-reviewed international journals,
tions for software architecture and tools to support them. IEEE Transactions on
conference proceedings and books. His research interests concern the area of soft-
Software Engineering 21 (April (4)), 314–335.
ware architecture, with a strong emphasis on architecture modeling, knowledge,
Sommerville, I., 2007. Software Engineering, 8th edn. Addison-Wesley Longman.
evolution and patterns.
Stevens, R., Brook, P., Jackson, K., Arnold, S., 1998. Systems Engineering. Prentice
Hall, Englewood Cliffs, NJ.