Analysis mechanisms provide conceptual sets of services which are used by Analysis Classes. They offer a convenient short-hand for fairly complex behaviors which will ultimately have to be worried about, but which are out of scope for the analysis effort. Their main purpose is to allow us to capture the requirements on these yet-to-be designed services of the system without having to be concerned about the details of the service provider itself.

Now we must begin the refine the information gathered on the analysis mechanisms. The steps for doing this are as follows:

Identify the clients of each analysis mechanism. Scan all clients of a given analysis mechanism, looking at the characteristics they require for that mechanism. For example, a number of Analysis Classes may make use of a Persistence mechanism, but their requirements on this may widely vary: a class which will have a thousand persistent instances has significantly different persistence requirements than a class which will have four million persistent instances. Similarly, a class whose instances must provide sub-millisecond response to instance data will require a different persistence approach than a class whose instance data is only accessed through ad-hoc queries and batch reporting applications.

Identify characteristic profiles for each analysis mechanism. There may be widely varying characteristics profiles, providing varying degrees of performance, footprint, security, economic cost, etc. Each analysis mechanism is different - different characteristics will apply to each. Many mechanisms will require estimates of the number of instances to be managed, and their expected size in terms of the expected number of bytes. The movement of large amounts of data through any system will create tremendous performance issues which must be dealt with.

Group clients according to their use of characteristic profiles. Form groups of clients that seem to share a need for an analysis mechanism with a similar characteristics profile; identify a design mechanism based on each such need. These groupings provide an initial cut at the design mechanisms. An example analysis mechanism, "inter-process communication", may map onto a design mechanism "object request broker". Different characteristic profiles will lead to different design mechanisms which emerge from the same analysis mechanism. The simple persistence mechanism in analysis will give rise to a number of persistence mechanisms in design: in-memory persistence, file-based, database-based, distributed, etc. The design mechanisms are refinements of the analysis mechanisms, based on different characteristic profiles.

Proceed bottom-up and make an inventory of the implementation mechanisms (see Concept: Design and Implementation Mechanisms) that you have at your disposal:

• Mechanisms offered by a middleware product or component framework.
• Mechanisms offered by operating systems.
• Mechanisms offered by a component.
• Mechanisms offered by a class library.
• Legacy code (see also Task: Incorporate Existing Design Elements)
• Special purpose packages: GUI builder, Geographical Information System, DBMS, etc.

Determine where existing implementation mechanisms can be used and where new implementation mechanisms need to be built.

Design mechanisms provide an abstraction of the implementation mechanisms, bridging the gap between Analysis Mechanisms and Implementation Mechanisms. The use of abstract architectural mechanisms during design allows us to consider how we are going to provide architectural mechanisms without obscuring the problem-at-hand with the details of a particular mechanism. It also allows us to potentially substitute one specific implementation mechanism for another without adversely affecting the design.

Determine the ranges of characteristics. Take the characteristics identified for the design mechanisms to determine reasonable, economical, or feasible ranges of values to use in the candidate-implementation mechanism.

Consider the cost of acquisition for purchased components. For candidate implementation mechanisms, consider the cost of acquisition or licensing, the maturity of the product, relationship with the vendor, support, etc. in addition to purely technical criteria.

Conduct a search for the right components, or build the components. You will often find that there is no apparently suitable implementation mechanism for some design mechanisms; this will trigger a search for the right product, or identify the need for in-house development. You may also find that some implementation mechanisms are not used at all.

The choice of implementation mechanisms is based not only on a good match for the technical characteristics, but also on the non-technical characteristics, such as cost. Some of the choices may be provisional; almost all have some risks attached to them: performance, robustness, and scalability are nearly always concerns and must be validated by evaluation, exploratory prototyping, or inclusion in the architectural prototype.

The role of the Software Architect in this task is to decide upon and validate these mechanisms by building, or integrating them, and verifying that they do the job, then consistently impose them upon the rest of the system design. The software architect role collaborates with the process engineer role to document the mechanisms and details regarding their use in project-specific design guidelines. See Task: Prepare Project Specific Guidelines. The relationship (or mapping) of analysis mechanisms to design mechanisms to implementation mechanisms, and the associated rationale for these choices, should be documented in the Software Architecture Document. The mechanisms themselves are Design Model elements (such as Design Package, Design Class, and Design Subsystem) which are detailed in Artifact: Design Model as part of their respective design tasks.