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