<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-KXvzdy6aJTFPQRS-UK5dvA" name="new_roadmap,_Odpz8NciEdy1nJEYZGzN4A" guid="-KXvzdy6aJTFPQRS-UK5dvA" changeDate="2008-08-11T10:28:42.000-0700" version="7.2.0">
  <mainDescription>&lt;h3>&#xD;
    Getting started&amp;nbsp;&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Begin by making sure that the team and key stakeholders understand what software architecture is and the value of&#xD;
    capturing it in a separate artifact. See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html&quot;&#xD;
    guid=&quot;__O7tAMVvEduLYZUGfgZrkQ&quot;>Concept: Software Architecture&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    After there is agreement that the architectural information should be captured, it is important to come to an agreement&#xD;
    on what architectural information you want to capture and what format it should take. Review the &lt;a&#xD;
    class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html&quot;&#xD;
    guid=&quot;_0XAf0MlgEdmt3adZL5Dmdw&quot;>Artifact: Architecture Notebook&lt;/a> and associated guidance. Agree on what you want to&#xD;
    document.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Next, review &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/arch_views_viewpoints_7A6CD31.html&quot;&#xD;
    guid=&quot;_kgtcoNc8Edyd7OybSySFxg&quot;>Concept: Architectural Views and Viewpoints&lt;/a> and &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html&quot;&#xD;
    guid=&quot;_mzxI0A4LEduibvKwrGxWxA&quot;>Concept: Architectural Mechanism&lt;/a>. Both are crucial to understanding how to define&#xD;
    and communicate the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Now you can turn your attention to deciding, as a team, how and when the architectural tasks should be performed.&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        If you are working on a new project and you are at the beginning of the lifecycle, review &lt;a&#xD;
        class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.tech.evolutionary_arch.base/tasks/envision_the_arch_FF123A81.html&quot;&#xD;
        guid=&quot;_0f-1oMlgEdmt3adZL5Dmdw&quot;>Task: Envision the Architecture&lt;/a>.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        If you are working on a project that is already underway, take time to document the decisions that have already&#xD;
        been made and continue to evolve the architecture as development proceeds. See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
        href=&quot;./../../../practice.tech.evolutionary_arch.base/tasks/refine_the_arch_7723A69E.html&quot;&#xD;
        guid=&quot;_0gRJgMlgEdmt3adZL5Dmdw&quot;>Task: Refine the Architecture&lt;/a>.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;h3>&#xD;
    Common pitfalls&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The architect should not work in isolation and just throw an architectural specification over the wall to the&#xD;
    developers. This requires too much documentation and makes it difficult for team members to understand why the&#xD;
    architecture needs to work the way it does. Building the architecture is an activity that requires collaboration to be&#xD;
    successful.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Avoid creating significant and detailed architectural documentation for agile projects. Don't get caught up in defining&#xD;
    exactly what the structure of the Architecture Notebook should be. Focus on capturing the key decisions and the&#xD;
    rationale for these decisions. Refer to more detailed documentation where necessary, and don't duplicate material. Keep&#xD;
    the documentation clear and concise. Make sure that the people who use the architecture (the development team) are&#xD;
    comfortable with the format and content of the architecture. Is there more or different information that they would&#xD;
    like to see? Would they like to see less, instead?&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Document important decisions. Team members may be close by and you may be in constant contact with them, but teams&#xD;
    change and software architects move on to other projects. Failure to document important decisions raises the risk of&#xD;
    failure later because future team members won't have the benefit of being involved in today's collaborative decisions.&#xD;
    Consider future team members as collaborators that you simply don't have the opportunity to speak to face-to-face.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
