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.


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.

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.


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:

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 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.

U.S. Treasury Architecture Development Guidance (TADG) document

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:

TADG Architectural Patterns

The TADG document contains the following patterns.

Architectural Design Pattern Name


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


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)

IBM's Patterns for e-Business

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:

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

They are intended to address the following challenges encountered in this type of environment:

IBM define five types of Pattern:

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