<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore"
    xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf"
    epf:version="1.5.0" xmi:id="-SJrpVySJ2npYs8NwGvnHjw"
    name="arch_mechanism,_mzxI0A4LEduibvKwrGxWxA" guid="-SJrpVySJ2npYs8NwGvnHjw" authors="Mark Dickson"
    changeDate="2008-10-15T06:30:40.704-0700" changeDescription="Simplified text explaining mechanism concept"
    version="1.0.0">
  <mainDescription>&lt;h3>&#xD;
    What are Architectural Mechanisms?&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Architectural Mechanisms are common solutions to common problems that can be used during development to minimize&#xD;
    complexity.&amp;nbsp; They represent key technical concepts that&amp;nbsp;will be standardized across the solution.&amp;nbsp;&#xD;
    Architecture mechanisms facilitate the evolution of architecturally significant aspects of the system. They allow the&#xD;
    team to maintain a cohesive architecture whilst enabling implementation details to be deferred until they really need&#xD;
    to be made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Architectural Mechanisms are&amp;nbsp;used to satisfy architecturally significant requirements. Usually those are&#xD;
    non-functional requirements such as performance and security issues.&amp;nbsp;When fully described, Architectural&#xD;
    Mechanisms show patterns of structure and behavior in the software. They&amp;nbsp;form the basis of&amp;nbsp;common&#xD;
    software&amp;nbsp;that will be&amp;nbsp;consistently applied&amp;nbsp;across the product being developed. They also form the basis&#xD;
    for standardizing the way that the software works; therefore, they are an important element of the overall software&#xD;
    architecture. The definition of architecture mechanisms also enable decisions on whether existing software components&#xD;
    can be leveraged to provide the required behavior; or whether new software should be bought or built.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The value in defining architecture mechanisms is that they:&#xD;
&lt;/p>&#xD;
&lt;ol>&#xD;
    &lt;li>&#xD;
        Explicitly call out&amp;nbsp;aspects of the solution mechanics that are common across the system. This helps you plan.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Put down markers for the developers to build those aspects of the system once and then re-use them. This reduces&#xD;
        the workload.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Promote the development of a consistent set of services. This makes the system easier to maintain.&#xD;
    &lt;/li>&#xD;
&lt;/ol>&#xD;
&lt;p>&#xD;
    An&amp;nbsp;Architectural Mechanism can have three states: Analysis, Design and Implementation.&amp;nbsp;These&#xD;
    categories&amp;nbsp;reflect the maturity of the mechanism's description. The state changes as successive levels of detail&#xD;
    are uncovered during when you refine &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html&quot;&#xD;
    guid=&quot;_HrZGIA4MEduibvKwrGxWxA&quot;>Architecturally Significant Requirements&lt;/a>&amp;nbsp;into working software. The categories&#xD;
    are summarized in the table that follows.&#xD;
&lt;/p>&lt;strong>States of an Architectural Mechanism&lt;/strong> &#xD;
&lt;table style=&quot;WIDTH: 806px; HEIGHT: 228px&quot; cellspacing=&quot;0&quot; cellpadding=&quot;2&quot; width=&quot;806&quot;&#xD;
summary=&quot;Types of Architectural Mechanism&quot; border=&quot;1&quot;>&#xD;
    &lt;tbody valign=&quot;top&quot;>&#xD;
        &lt;tr>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                State&#xD;
            &lt;/th>&#xD;
            &lt;th scope=&quot;col&quot;>&#xD;
                Description&#xD;
            &lt;/th>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Analysis&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                &lt;p>&#xD;
                    A conceptual solution to a common technical problem. For example,&amp;nbsp;persistence is an abstract&#xD;
                    solution to the common requirement to store data. The purpose of this category is simply to identify&#xD;
                    the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes&#xD;
                    for that mechanism.&#xD;
                &lt;/p>&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Design&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                &lt;p>&#xD;
                    A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of&#xD;
                    this category is to guide precise product or technology selection.&#xD;
                &lt;/p>&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
        &lt;tr>&#xD;
            &lt;td>&#xD;
                Implementation&#xD;
            &lt;/td>&#xD;
            &lt;td>&#xD;
                &lt;p>&#xD;
                    A further refinement from a design mechanism into a specification for the software. This can be&#xD;
                    presented as a design pattern or example code.&#xD;
                &lt;/p>&#xD;
            &lt;/td>&#xD;
        &lt;/tr>&#xD;
    &lt;/tbody>&#xD;
&lt;/table>&lt;br />&#xD;
&lt;p>&#xD;
    For more information on these different types of mechanisms, see the attached concepts.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation&#xD;
    mechanisms.&amp;nbsp;These are synonyms and merely represent the architecture mechanisms in different states of&#xD;
    development. The transition from one state to another&amp;nbsp;can often be obvious or intuitive. Therefore, it can be&#xD;
    achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer.&amp;nbsp;The&#xD;
    important point here is that these categories of mechanisms apply to the same concept in different states. The only&#xD;
    difference between them is one of refinement or detail.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The following diagram illustrates the transition of Architectural Mechanisms from one state to another.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;strong>State Machine for Architectural Mechanisms&lt;/strong>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;img style=&quot;WIDTH: 876px; HEIGHT: 115px&quot; height=&quot;113&quot; alt=&quot;Architectural Mechanism States&quot;&#xD;
    src=&quot;./resources/ArchMechStates.JPG&quot; width=&quot;600&quot; />&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    What Information Should be Captured for Architectural Mechanisms?&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The information captured for each architectural mechanism category/state is different (though the information can be&#xD;
    seen as refinements of each other):&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Analysis Mechanisms&lt;/strong>, which give the mechanism a name, brief description and some basic&#xD;
        attributes&amp;nbsp;derived from&amp;nbsp;the project requirements&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Design Mechanisms&lt;/strong>, which are more concrete and assume some details of the implementation&#xD;
        environment&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Implementation Mechanisms&lt;/strong>, which specify the&amp;nbsp;exact implementation of&amp;nbsp;each mechanism&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    When&amp;nbsp;a mechanism is&amp;nbsp;initially identified, it can be considered a marker that says to the team, &quot;We are going&#xD;
    to handle this aspect of the system in a standard way. We'll figure out the details later.&quot; As the project proceeds,&#xD;
    the architectural mechanisms are gradually refined until they become part of the software.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Analysis Mechanisms&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Analysis mechanisms&amp;nbsp;are the initial state for an architectural mechanism. They are identified early in the project&#xD;
    and represent&amp;nbsp;bookmarks for future software development. They allow the&amp;nbsp;team to focus on understanding the&#xD;
    requirements without getting distracted by the specifics of a complex implementation. Analysis mechanisms are&#xD;
    discovered by surveying the requirements and looking for recurrent technical concepts.&amp;nbsp;Security, persistence and&#xD;
    legacy interface are some examples of these. In effect, the analysis mechanism is where the requirements that&#xD;
    describe&amp;nbsp;architecturally significant topics&amp;nbsp;are collated and brought&amp;nbsp;together in a single list. This&#xD;
    makes them easier to manage.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Analysis mechanisms are described in simple terms:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;strong>Name:&lt;/strong> Identifies the mechanism.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;strong>Basic attributes:&lt;/strong> Define the requirements of the mechanism. These attributes can vary depending&#xD;
        upon the mechanism being analyzed. Refer to &lt;a class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html&quot;&#xD;
        guid=&quot;_eQ_s8Om5Edupia_tZIXEqg&quot;>Example: Architectural Mechanism Attributes&lt;/a>&amp;nbsp;for more guidance.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Once the list of analysis mechanisms has been defined it can be prioritized and the mechanisms refined in line&#xD;
    with&amp;nbsp;iteration&amp;nbsp;objectives. It is not necessary to develop the entire set of architecture mechanisms into&#xD;
    working software in a single pass. It is often more sensible to develop only those mechanisms required to support the&#xD;
    functionality to be delivered in the current iteration.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Design Mechanisms&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Design mechanisms&amp;nbsp;represent decisions about the concrete technologies that are going to be used to&amp;nbsp;develop&#xD;
    architectural mechanisms. For example, the decision to use an RDBMS for persistence. It's often no more complicated&#xD;
    than that (though of course, the effort involved in making the decision can sometimes be quite complex).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The decision on when to refine an architectural mechanism from an analysis state to a design state is largely&#xD;
    arbitrary. Often there will be constraints on the project that&amp;nbsp;force the decision on some of these issues. For&#xD;
    example, there may be a corporate standard for databases which mean that the decision&amp;nbsp;for the&amp;nbsp;persistence&#xD;
    mechanism can be made on day 1 of the project.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    On other occasions the decision may point to products that the project team has not yet acquired.&amp;nbsp;If so,&amp;nbsp;the&#xD;
    decision needs to be made in time to enable the required products to be made available to the team.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It can often be useful to develop some prototype code to prove that these decisions are sound. The &lt;a&#xD;
    class=&quot;elementLink&quot; href=&quot;./../../../core.default.role_def.base/roles/architect_E7A12309.html&quot;&#xD;
    guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a> should be confident that the technologies being selected are able to&#xD;
    fulfill the requirements. The attributes captured against the corresponding analysis mechanisms should be used as&#xD;
    criteria to prove the validity of the decisions.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Implementation Mechanism&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    An implementation mechanism&amp;nbsp;specifies the actual implementation for the architectural mechanism (hence the&#xD;
    name).&amp;nbsp;It can be modeled as a design pattern or presented as&amp;nbsp;example code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The best time to&amp;nbsp;produce the&amp;nbsp;implementation mechanism is usually when the first piece of functionality that&#xD;
    needs it is scheduled for development. Architects and developers work together to develop this.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    For examples of the kinds of information that you might capture for a mechanism, see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/examples/architectural_mechanism_attributes_B0ECA2F7.html&quot;&#xD;
    guid=&quot;_eQ_s8Om5Edupia_tZIXEqg&quot;>Example: Architectural Mechanism Attributes&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>