Architectural Patterns
Introduction U.S. Treasury Architecture Development Guidance IBM's Patterns of e-Business
Patterns for system architecting are very much in their infancy. They have been
introduced at this time essentially to draw them to the attention of the systems
architecture community as an emerging important resource, and as a placeholder for
hopefully more rigorous descriptions and references to more plentiful resources in future
versions of TOGAF.
They have not (as yet) been integrated into TOGAF. However, in the following, we attempt
to indicate the potential value to TOGAF, and to which parts of the TOGAF ADM they might
be relevant.
Background
A "pattern" has been defined as “an idea that has been useful in one
practical context and will probably be useful in others.” [M.Fowler, “Analysis
Patterns – Reusable Object Models, Addison Wesley, ISBN 0-201-89542-0].
In TOGAF, patterns are considered to be a way of putting building blocks into context:
for example, to describe a reusable solution to a problem. Building Blocks are what you
use: patterns can tell you how you use them, when, why, and what trade-offs you have to
make in doing so.
Patterns offer the promise of helping the architect identify combinations of
architectural and/or solution building blocks that have been proven to deliver effective
solutions in the past, and may provide the basis for effective solutions in the future.
Pattern techniques are generally acknowledged to have been established as a valuable
architectural design technique by Christopher Alexander, a buildings architect, who
described this approach in his book "The Timeless Way of Building", Oxford
University Press, 1979, ISBN 0-19-502402-8. This book provides an introduction to the
ideas behind the use of patterns, and Alexander followed it with two further books (A
Pattern Language, and The Oregon Experiment) in which he expanded on his description of
the features and benefits of a patterns approach to architecture.
Software and buildings architects have many similar issues to address, and so it was
natural for software architects to take an interest in patterns as an architectural tool.
Many papers and books have been published on them since Alexander's 1979 book, perhaps the
most renowned being "Design Patterns: Elements of Reusable Object-Oriented
Software", by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison
Wesley, October 1994, ISBN 0-201-63361-2. This book describes simple and elegant solutions
to specific problems in object-oriented software design.
Content of a Pattern
Several different formats are used in the literature for describing patterns, and no
single format has achieved widespread acceptance. However, there is broad agreement on the
types of things that a pattern should contain. The headings which follow are taken from Pattern-Oriented Software
Architecture: A System of Patterns, by F. Buschmann, R. Meunier, H. Rohnert,
P.Sommerlad, and M. Stal, John Wiley and Sons, 1996, ISBN 0-471-95869-7. The elements
described below will be found in most patterns, even if different headings are used to
describe them.
- Name: A meaningful and memorable way to refer to the pattern, typically
a single word or short phrase.
- Problem: A description of the problem indicating the intent in
applying the pattern - the intended goals and objectives to be reached within the context
and forces described below (perhaps with some indication of their priorities).
- Context: The pre-conditions under which the pattern is
applicable - a description of the initial state before the pattern is applied.
- Forces: A description of the relevant forces and constraints, and how
they interact/conflict with each other and with the intended goals and objectives. The
description should clarify the intricacies of the problem and make explicit the kinds of
trade-offs that must be considered. (The need for such trade-offs is typically what makes
the problem difficult, and generates the need for the pattern, in the first place.) The
notion of "forces" equates in many ways to the "qualities" that
architects seek to optimize, and the concerns they seek to address, in designing
architectures. For example:
- Security, robustness, reliability, fault-tolerance
- Manageability
- Efficiency, performance, throughout, bandwidth requirements, space utilization
- Scalability (incremental growth on-demand)
- Extensibility, evolvability, maintainability
- Modularity, independence, reusability, openness, composability (plug 'n play),
portability
- Completeness and correctness
- Ease of construction
- Ease of use
- ... etc.
- Solution: A description, using text and/or graphics, of how to achieve
the intended goals and objectives. The description should identify both the solution's
static structure and its dynamic behavior - the people and computing actors, and their
collaborations. The description may include guidelines for implementing the solution.
Variants or specializations of the solution may also be described.
- Resulting Context: The post-conditions after the pattern has been
applied. Implementing the solution normally requires trade-offs among competing forces.
This element describes which forces have been resolved and how, and which remain
unresolved. It may also indicate other patterns that may be applicable in the new context.
(A pattern may be one step in accomplishing some larger goal.) Any such other patterns
will be described in detail under Related Patterns.
- Examples: One or more sample applications of the pattern which
illustrate each of the other elements: a specific problem, context, and set of forces; how
the pattern is applied; and the resulting context.
- Rationale: An explanation / justification of the pattern as a whole, or
of individual components within it, indicating how the pattern actually works, and why -
how it resolves the forces to achieve the desired goals and objectives, and why this is
"good". The Solution element of a pattern describes the external structure and
behavior of the solution: the Rationale provides insight into its internal workings.
- Related Patterns: The relationships between this pattern and others.
These may be predecessor patterns, whose resulting contexts correspond to
the initial context of this one; or successor patterns, whose initial
contexts correspond to the resulting context of this one; or alternative
patterns, which describe a different solution to the same problem, but under different
forces; or co-dependent patterns, which may / must be applied along with
this pattern.
- Known Uses: Known applications of the pattern within existing systems,
verifying that the pattern does indeed describe a proven solution to a recurring problem.
Known Uses can also serve as Examples.
Patterns may also begin with an Abstract providing an overview of the pattern and
indicating the types of problems it addresses. The Abstract may also identify the target
audience and what assumptions are made of the reader.
Terminology
Although design patterns have been the focus of widespread interest in the software
industry for several years, particularly in the object-oriented and component based
software fields, it is only recently that there has been increasing interest in
architectural patterns - extending the principles and concepts of design patterns to the
architecture domain.
The technical literature relating to this field is complicated by the fact that many
people in the software field use the term "architecture" to refer to software,
and many patterns described as "architecture patterns" are high-level software
design patterns. This simply makes it all the more important to be precise in use of
terminology.
Architectural Patterns and Design Patterns
The term "design pattern" is often used to refer to any pattern which
addresses issues of software architecture, design, or programming implementation. In Pattern-Oriented Software
Architecture: A System of Patterns, by F. Buschmann, R. Meunier, H. Rohnert,
P.Sommerlad, and M. Stal, John Wiley and Sons, 1996, ISBN 0-471-95869-7, the authors
define these three types of patterns as follows:
- An Architectural Pattern expresses a fundamental structural
organization or schema for software systems. It provides a set of predefined subsystems,
specifies their responsibilities, and includes rules and guidelines for organizing the
relationships between them.
- A Design Pattern provides a scheme for refining the subsystems or
components of a software system, or the relationships between them. It describes commonly
recurring structure of communicating components that solves a general design problem
within a particular context.
- An Idiom is a low-level pattern specific to a programming language. An
idiom describes how to implement particular aspects of components or the relationships
between them using the features of the given language.
These distinctions are useful, but it is important to note that "architectural
patterns" in this context still refers solely to software architecture. Software
architecture is certainly an important part of the focus of TOGAF, but it is not its only
focus.
In this section we are concerned with patterns for system
architecting. These are analogous to software architecture and design patterns,
and borrow many of their concepts and terminology, but focus on providing re-usable models
and methods specifically for the architecting of information systems - comprising
software, hardware, networks, and people - as opposed to purely software systems.
Patterns and Views
Architecture Views are selected parts of one or more models representing a complete
system architecture, focusing on those aspects that address the concerns of one or more
stakeholders. Patterns can provide help in designing such models, and in composing views
based on them.
Patterns and Business Scenarios
Relevant architectural patterns may well be identified in the work on Business
Scenarios.
Architectural Patterns In Use
Two examples of architectural patterns in use are outlined in the following
subsections, one from the domain of an IT customer organzation's own architectural
framework, and the other from a major system vendor who has done a lot of work in recent
years in the field of architectural patterns.
- The U.S. Treasury Architecture Development Guidance (TADG) document
provides a number of explicit architectural patterns, in addition to explaining a
rationale, structure, and taxonomy for architecural patterns as they relate to the U.S.
Treasury.
- The IBM Patterns for e-Business web site gives a series of
architectural patterns that go from the busines problem to specific solutions, firstly at
a generic level and then in terms of specific IBM product solutions. A supporting resource
is IBM's set of "Red Books".
The following material is intended to give the reader pointers to some of the places
where architectural patterns are already being used and made available, in order to help
readers make their own minds up as to the usefulness of this technique for their own
environments.
The U.S. Treasury
Architecture Development Guidance (TADG) document - formerly known as the Treasury
Information System Architecture Framework ( TISAF) - provides a number of explicit
architectural patterns.
Section 7 of the TADG document describes a rationale, structure,
and taxonomy for architecural patterns, while the patterns themselves are formally
documented in Appendix D. The architectural patterns presented embrace a larger set of
systems than just object-oriented systems. Some architectural patterns are focused on
legacy systems, some on concurrent and distributed systems, and some on real-time systems.
TADG Pattern Content
The content of an architectural pattern as defined in the TADG document contains the
following elements:
- Name. Each architectural pattern has a unique, short descriptive name.
The collection of architectural pattern names can be used as a vocabulary for describing,
verifying, and validating information system architectures.
- Problem. Each architectural pattern contains a description of the
problem to be solved. The problem statement may describe a class of problems or a specific
problem.
- Rationale. The rationale describes an explains a typical specific
problem that is representative of the broad class of problems to be solved by the
architectural pattern. For a specific problem, it can provide additional details of the
nature of the problem and the requirements for its resolution.
- Assumptions. The assumptions are conditions that must be satisfied in
order for the architectural pattern to be usable in solving the problem. They include
constraints on the solution and optional requirements that may make the solution more easy
to use.
- Structure. The architectural pattern is described in diagrams and words
in as much detail as is required to convey to the reader the components of the pattern and
their responsibilities.
- Interactions. The important relationships and interactions among the
components of the pattern are described and constraints on these relationships and
interactions are identified.
- Consequences. The advantages and disadvantages of using this pattern
are described, particularly in terms of other patterns (either required or excluded) as
well as resource limitations that may arise from using it.
- Implementation. Additional implementation advice that can assist
designers in customizing this architectural design pattern for the best results.
TADG Architectural Patterns
The TADG document contains the following patterns.
Architectural Design Pattern Name |
Synopsis |
Client-Proxy
Server |
Acts as a
concentrator for many low-speed links to access a server |
Customer
Support |
Supports
complex customer contact across multiple organizations |
Reactor |
Decouples an
event from its processing |
Replicated
Servers |
Replicates
servers to reduce burden on central server |
Layered
Architecture |
A
decomposition of services such that most interactions occur only between neighboring
layers |
Pipe and
Filter Architecture |
Transforms
information in a series of incremental steps or processes |
Subsystem
Interface |
Manages the
dependencies between cohesive groups of functions (subsystems) |
The IBM Patterns for
e-business web site provides a group of reusable assets aimed at speeding the process
of developing e-business applications. A supporting IBM web site is Patterns
for e-business Resources (also known as the "Red Books").
The rationale for IBM's provision of these patterns is to:
- Provide a simple and consistent way to translate business priorities and requirements
into technical solutions
- Assist and speed up the solution development and integration process by facilitating the
assembly of a solution and minimizing custom one-of-a-kind implementations.
- Capture the knowledge and best practices of experts and make it available for use by
less experienced personnel.
- Facilitate the reuse of intellectual capital such as Reference Architectures, Frameworks
and other architecture assets.
IBM's patterns are focused specifically on solutions for e-business, i.e., those which
allow an organization to leverage web technologies in order to re-engineer business
processes, enhance communications, and lower organizational boundaries with
- customers and shareholders (across the Internet);
- employees and stakeholders (across a corporate Intranet); and
- vendors, suppliers, and partners (across an Extranet).
They are intended to address the following challenges encountered in this type of
environment:
- High degree of integration with legacy systems within the enterprise and with systems
outside the enterprise
- The solutions need to reach users faster. This does not mean sacrificing quality, but it
does mean coming up with better and faster ways to develop these solutions
- Service Level Agreements are critical
- Need to adapt to rapidly changing technologies and dramatically reduced product cycles
- Address an acute shortage of the key skills needed to develop quality solutions
IBM define five types of Pattern:
- Business Patterns - which identify the primary Business Actors, and
describe the Interactions between them in terms of different archetypal business
interactions such as:
- Self Service (a.k.a. User-to-Business) - Users accessing transactions on a 24x7 basis
- Collaboration (a.k.a. User-to-User) - Users working with one another to share data and
information
- Information Aggregation (a.k.a. User-to-Data) - Data from multiple sources aggregated
and presented across multiple channels
- Extended Enterprise (a.k.a. Business-to-Business) - Integrating data and processes
across enterprise boundaries
- Integration Patterns - provide the "glue" to combine Business
Patterns to form solutions. They characterize the Business Problem, Business
Processes/Rules, and Existing Environment, to determine whether front-end or back-end
integration is required.
- Front-end integration - a.k.a. Access Integration - is focused on providing seamless and
consistent access to business functions. Typical functions provided include Single-signon,
Personalization, Transcoding etc.
- Back-end integration - a.k.a. Application Integration - is focused on connecting,
interfacing or integrating databases and systems. Typical integration can be based on
Function, Type of Integration, Mode of Integration, and by Topology.
- Composite Patterns are previously identifed combinations and selections
of Business and Integration Patterns, for previously identified situations such as:
Electronic Commerce Solutions, (public) Enterprise Portals, Enterprise Intranet Portal,
Collaboration ASP, etc.
- Application Patterns. Each Business and Integration Pattern can be
implemented using one or more Application Patterns. An Application Pattern characterizes
the coarse-grained structure of the application - the main application components,
the allocation of processing functions and the interactions between them, the degree of
integration between them, and the placement of the data relative to the applications.
- Runtime Patterns. Application patterns can implemented by Runtime
patterns, which demonstrate non-functional, service level characteristics, such as
Performance, Capacity, Scalability, and Availability. They identify key resource
constraints and best practices.
The IBM web site also provides specific (IBM) product mappings for the run-time
patterns, indicating specific technology choices for implementation.
Some Pattern Resources
Copyright © The Open Group, 2001