Concept: Architectural Mechanism
Architectural Mechanisms are common solutions to common problems that can be used during development to minimize complexity.
Relationships
Main Description

Architectural Mechanisms are used to satisfy architecturally significant requirements. When fully described, Architectural Mechanisms show patterns of structure and behavior in the software. They form the basis of common software that will be consistently applied across the product being developed. They also form the basis for standardizing the way that the software works; therefore, they are an important element of the overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing software components can be leveraged to provide the required behaviour; or whether new software should be bought or built.

Defining architectural mechanisms is all about making choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about producing detailed design or software. This is a common misunderstanding. The creation of detailed design and software that shows *how* specific mechanisms are satisfied is a development task.

The value in defining architecture mechanisms is that they:

  1. Explicitly call out aspects of the solution mechanics that are common across the system. This helps you plan.
  2. Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces the workload.
  3. Promote the development of a consistent set of services. This makes the system easier to maintain.

An Architectural Mechanism can have three states: Analysis, Design and Implementation. These categories reflect the maturity of the mechanism's description. The state changes as successive levels of detail are uncovered during when you refine Architecturally Significant Requirements into working software. The categories are summarized in the table that follows.

States of an Architectural Mechanism
State Description
Analysis

A conceptual solution to a common technical problem. For example, persistence is an abstract solution to the common requirement to store data. The purpose of this category is simply to identify the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.

For more information on Analysis Mechanisms, see Concept: Analysis Mechanism.

Design

A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this category is to guide precise product or technology selection.

For more information on Design Mechanisms, see Concept: Design Mechanism.

Implementation

A further refinement from a design mechanism into a specification for the software. This can be presented as a design pattern or example code.

For more information on Implementation Mechanisms, see Concept: Implementation Mechanism


Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation mechanisms. These are synonyms and merely represent the architecture mechanisms in different states of development. The transition from one state to another can often be obvious or intuitive. Therefore, it can be achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The important point here is that these categories of mechanisms apply to the same concept in different states. The only difference between them is one of refinement or detail.

The following diagram illustrates the transition of Architectural Mechanisms from one state to another.

State Machine for Architectural Mechanisms

Architectural Mechanism States 

For more information on how a mechanism progresses though these states, see Guideline: Evolving Architectural Mechanisms

The main reason for using architecture mechanisms as an approach to analysis and design is that they facilitate the evolution of architecturally significant aspects of the system. They allow the team to maintain a cohesive architecture whilst enabling implementation details to be deferred until they really need to be made.

See Example: Architectural Mechanisms for a list of typical mechanisms. See Example: Architectural Mechanism Attributes for some examples of atttibutes that can be specificed for mechanisms.

More Information