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:
-
Explicitly call out aspects of the solution mechanics that are common across the system. This helps you plan.
-
Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces
the workload.
-
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
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.
|