<?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-bP4wJKW0CrR9pL0yz20r3Q"
    name="new_guideline,_J6BKgNvIEduv2KOT-Teh6w" guid="-bP4wJKW0CrR9pL0yz20r3Q" changeDate="2007-07-20T09:28:21.240-0700"
    version="7.2.0">
  <mainDescription>&lt;p>&#xD;
    Architectural mechanisms represent key technical concepts that&amp;nbsp;will be standardized across the solution. They are&#xD;
    refined&amp;nbsp;during the project through three states, represented by the three categories of Architectural Mechanisms:&#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 the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/roles/architect.html&quot;&#xD;
    guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a> initially identifies an&amp;nbsp;architectural mechanism they are putting down&#xD;
    a marker that says to the team, &quot;We are going to handle this aspect of the system in a standard way. We'll figure out&#xD;
    the details later.&quot; As the project proceeds, the architectural mechanisms are gradually refined until they become part&#xD;
    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 &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../openup/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a> is collating the&#xD;
    requirements that describe&amp;nbsp;architecturally significant topics bringing them together in a single list. This makes&#xD;
    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;./../../../openup/guidances/examples/architectural_mechanism_attributes.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;./../../../openup/roles/architect.html&quot; guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a> should&#xD;
    be confident that the technologies being selected are able to fulfill the requirements. The attributes captured against&#xD;
    the corresponding analysis mechanisms should be used as 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. The &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/roles/architect.html&quot;&#xD;
    guid=&quot;_0X9iEMlgEdmt3adZL5Dmdw&quot;>Architect&lt;/a> and &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/roles/developer.html&quot;&#xD;
    guid=&quot;_0YDosMlgEdmt3adZL5Dmdw&quot;>Developer&lt;/a> work together to develop this.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>