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