You are here: | ||
<<< Previous | Home | Next >>> |
This chapter provides guidelines for using architecture patterns.
Patterns for describing Enterprise Architectures are becoming increasingly important to practitioners. The diverse and multi-disciplinary nature of Enterprise Architecture requires that patterns be developed in different disciplines, domains, and levels of detail.
Previous versions of this standard did not fully embrace architecture patterns due to their perceived lack of maturity. Today, many organizations are using patterns to describe their architectures at various levels ranging from software design patterns to business patterns. It remains true that there is no single standard for describing Enterprise Architecture patterns. However, it can be said that there is a pattern for describing patterns.
A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others" (Source: Analysis Patterns - Re-usable Object Models, by M. Fowler).
In the TOGAF standard, patterns are considered to be a way of putting building blocks into context; for example, to describe a re-usable 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 to identify combinations of Architecture and/or Solution Building Blocks (ABBs/SBBs) 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, published in 1979. 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 Re-usable Object-Oriented Software (Gamma et al., 1994). This book describes simple and elegant solutions to specific problems in object-oriented software design.
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 (Buschmann et al., 1996). The elements described below will be found in most patterns, even if different headings are used to describe them.
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.
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 architecture 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 the use of terminology.
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, the authors define these three types of patterns as follows:
It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing
the relationships between them.
It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.
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 architecture patterns in this context still refers solely to software architecture. Software architecture is certainly an important part of the focus of the TOGAF standard, but it is not its only focus.
In this section we are concerned with patterns for enterprise 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 enterprise information systems - comprising software, hardware, networks, and people - as opposed to purely software systems.
Although architecture patterns have not (as yet) been integrated into the TOGAF standard, each of the first four main phases of the ADM (Phases A through D) gives an indication of the stage at which relevant re-usable architecture assets from the Enterprise Architecture Continuum should be considered for use. Architecture patterns are one such asset.
An enterprise that adopts a formal approach to the use and re-use of architecture patterns will normally integrate their use into the Enterprise Architecture Continuum.
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.
Relevant architecture patterns may well be identified in the work on business scenarios.