<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI 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">
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-bR5MJm49VvD9HwIX54AxgQ" name="solution_architect,_kBoEwMWUEe6PpZUqNEM0jA" guid="-bR5MJm49VvD9HwIX54AxgQ">
    <refinedDescription>&lt;p>&#xD;
    &quot;Idea Gostaran&quot; Projects are related and their software solutions are architecturally related.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-pxtBMIZo9zDQiuPxpn_Okw" name="general_architecture_owner,_kBoEwsWUEe6PpZUqNEM0jA" guid="-pxtBMIZo9zDQiuPxpn_Okw">
    <refinedDescription>&lt;p>&#xD;
    He is responsible for&amp;nbsp;designing the Extensible&amp;nbsp;General Architecture.&amp;nbsp;After it is designed,it&#xD;
    is&amp;nbsp;discussed in a team of architects. They review the architecture and if they decided to use it, he is&#xD;
    responsible for reviewing the architecture based on new requirements in every project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-kJx0RkZ2gULy-i3iLghOVw" name="extensible_general_architecture,_kBoExMWUEe6PpZUqNEM0jA" guid="-kJx0RkZ2gULy-i3iLghOVw">
    <refinedDescription>&lt;p>&#xD;
    It contains a general and abstracted view to solution architecture. As projects are related and we can reuse components&#xD;
    and concepts in each project, we&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-wE21b9sdj4qoDj6yvAq9rg" name="architecture_notebook,_HMrBIcXgEe6PpZUqNEM0jA" guid="-wE21b9sdj4qoDj6yvAq9rg">
    <refinedDescription>&lt;p>&#xD;
    It provides a place for maintaining the list of architectural issues, along with the associated architectural&#xD;
    decisions, designs, patterns, code documented (or pointed to), and so forth -- all at appropriate levels to make it&#xD;
    easy to understand what architectural decisions have been made and remain to be made.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is helpful for architects to use this artifact to collaborate with other team members in developing the architecture&#xD;
    and to help team members understand the motivation behind architectural decisions so that those decisions can be&#xD;
    robustly implemented. For example, the architect may put constraints on how data is packaged and communicated between&#xD;
    different parts of the system. This may appear to be a burden, but the justification in the Architecture Notebook can&#xD;
    explain that there is a significant performance bottleneck when communicating with a legacy system. The rest of the&#xD;
    system must adapt to this bottleneck by following a specific data packaging scheme.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This artifact should also inform the team members how the system is partitioned or organized so that the team can adapt&#xD;
    to the needs of the system. It also gives a first glimpse of the system and its technical motivations to whoever must&#xD;
    maintain and change the architecture later.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-H8chLlMI1aorP3qtBn3m3w" name="risk_analysis,_hVbTUcWLEe6PpZUqNEM0jA" guid="-H8chLlMI1aorP3qtBn3m3w"/>
</xmi:XMI>
