TOGAF: Architecture Patterns

From Glitchdata
Jump to navigation Jump to search

A "pattern" has been defined as: "an idea that has been useful in one practical context and will probably be useful in others" [Analysis Patterns - Re-usable Object Models].

In TOGAF, 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.

US Treasury Architecture Development Guidance (TADG)

The content of an architecture pattern as defined in the TADG document contains the following elements:

  • Name
    • Each architecture pattern has a unique, short descriptive name. The collection of architecture pattern names can be used as a vocabulary for describing, verifying, and validating Information Systems Architectures.
  • Problem
    • Each architecture 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 and explains a typical specific problem that is representative of the broad class of problems to be solved by the architecture 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 architecture 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 architecture 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.

IBM Patterns for e-Business

IBM has some high-level patterns too

Related ADM Guidelines & Techniques