Architectural mechanisms represent key technical concepts that will be standardized across the solution. They are refined during the project through three states, represented by the three categories of Architectural Mechanisms:

• Analysis Mechanisms, which give the mechanism a name, brief description and some basic attributes derived from the project requirements
• Design Mechanisms, which are more concrete and assume some details of the implementation environment
• Implementation Mechanisms, which specify the exact implementation of each mechanism

When the Architect initially identifies an architectural mechanism they are putting down a marker that says to the team, "We are going to handle this aspect of the system in a standard way. We'll figure out the details later." As the project proceeds, the architectural mechanisms are gradually refined until they become part of the software.

Analysis Mechanisms

Analysis mechanisms are the initial state for an architectural mechanism. They are identified early in the project and represent bookmarks for future software development. They allow the team to focus on understanding the requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are discovered by surveying the requirements and looking for recurrent technical concepts. Security, persistence and legacy interface are some examples of these. In effect, the Architect is collating the requirements that describe architecturally significant topics bringing them together in a single list. This makes them easier to manage.

Analysis mechanisms are described in simple terms:

• Name: Identifies the mechanism.
• Basic attributes: Define the requirements of the mechanism. These attributes can vary depending upon the mechanism being analyzed. Refer to Example: Architectural Mechanism Attributes for more guidance.

Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line with iteration objectives. It is not necessary to develop the entire set of architecture mechanisms into working software in a single pass. It is often more sensible to develop only those mechanisms required to support the functionality to be delivered in the current iteration.

Design Mechanisms

Design mechanisms represent decisions about the concrete technologies that are going to be used to develop architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated than that (though of course, the effort involved in making the decision can sometimes be quite complex).

The decision on when to refine an architectural mechanism from an analysis state to a design state is largely arbitrary. Often there will be constraints on the project that force the decision on some of these issues. For example, there may be a corporate standard for databases which mean that the decision for the persistence mechanism can be made on day 1 of the project.

On other occasions the decision may point to products that the project team has not yet acquired. If so, the decision needs to be made in time to enable the required products to be made available to the team.

It can often be useful to develop some prototype code to prove that these decisions are sound. The Architect should be confident that the technologies being selected are able to fulfill the requirements. The attributes captured against the corresponding analysis mechanisms should be used as criteria to prove the validity of the decisions.

Implementation Mechanism

An implementation mechanism specifies the actual implementation for the architectural mechanism (hence the name). It can be modeled as a design pattern or presented as example code.

The best time to produce the implementation mechanism is usually when the first piece of functionality that needs it is scheduled for development. The Architect and Developer work together to develop this.