<?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" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1">
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-BZ8afnvoVBJs82vzcOBaCw" name="agree_technical_approach,_4ouDUdOEEdyqlogshP8l4g" guid="-BZ8afnvoVBJs82vzcOBaCw" version="7.2.0">
    <mainDescription>&lt;p>
    The goal of this activity is to define a technical approach to the system that supports the project requirements,
    within the constraints placed on the system and the development team. The architect should do the following:
&lt;/p>
&lt;ul>
    &lt;li>
        Work with the team to create an initial sketch of the technical approach to the proposed system
    &lt;/li>
    &lt;li>
        Ensure that the technical decisions are adequately captured and communicated
    &lt;/li>
    &lt;li>
        Ensure that the team has enough information to understand the approach that your are taking
    &lt;/li>
&lt;/ul>
&lt;p>
    The work done here does not seek to produce a detailed and comprehensive technical specification for the system.
    Rather, the approach should be to decide the overall technical approach at a high level.
&lt;/p>
&lt;p>
    You should focus on proving the architecture with working software. If the solution is similar to a previously produced
    solution (or is a well-known solution domain), then it will probably be good enough to reference that example as
    evidence of the feasibility of the approach. In some cases, it may be necessary to develop one or more prototypes to
    validate some of the decisions or clarify some of the requirements.
&lt;/p>
&lt;p>
    The conclusion of this work should produce just enough information to communicate the architecture to the team, and to
    demonstrate its viability to the customer. This allows the project to move forward, enabling you to refine and baseline
    the architecture.
&lt;/p></mainDescription>
    <howtoStaff>&lt;p>
    This activity is best carried out collaboratively by the team, with the architect acting as a focal point for
    coordinating and facilitating the decisions.
&lt;/p></howtoStaff>
    <usageNotes>&lt;p>
    The major effort occurs early in the project; thereafter, you should assess the system regularly to ensure that the
    design is still on track with the architecture.
&lt;/p></usageNotes>
  </org.eclipse.epf.uma:ProcessDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-5pBUhaIFdJ75MLPerQSnoA" name="architecture_notebook,_BWf5gtOKEdyqlogshP8l4g" guid="-5pBUhaIFdJ75MLPerQSnoA">
    <refinedDescription>&lt;p>&#xD;
    This artifact&amp;nbsp;describes the &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html&quot;&#xD;
    guid=&quot;__O7tAMVvEduLYZUGfgZrkQ&quot;>Software Architecture&lt;/a>.&#xD;
&lt;/p>&#xD;
&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.&lt;br />&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-raSQ2CIQMJXnNHFqWWi7Kg" name="envision_the_arch,_sjccUN_1EdyOsumnGvWsEg" guid="-raSQ2CIQMJXnNHFqWWi7Kg">
    <keyConsiderations>&lt;p>&#xD;
    It&amp;nbsp;is important to reduce the complexity of the&amp;nbsp;solution by raising the levels of abstraction.&amp;nbsp;For more&#xD;
    information, see &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html&quot;&#xD;
    guid=&quot;_we3F4ACpEdu8m4dIntu6jA&quot;>Guideline: Abstract Away Complexity&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is critical that this task be performed collaboratively with active involvement of other team members and project&#xD;
    stakeholders so that consensus and common understanding is reached. It is particularly vital to involve the&#xD;
    developer(s) throughout this task. The architecture effort&amp;nbsp;is about providing leadership and coordination of the&#xD;
    technical work rather than putting in a solo performance.&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    This task focuses on envisioning the initial architecture and outlining the&amp;nbsp;architectural decisions that will&#xD;
    guide development and testing. It relies on gathering experience gained in similar systems or problem domains to&#xD;
    constrain and focus the architecture so that effort is not wasted in re-inventing architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The results are captured for future reference and are communicated across the team. It is important that the team has&#xD;
    enough information to understand the technical approach being taken.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The architecture evolves organically over time by outlining and refining portions of it. A few people get together in a&#xD;
    room and sketch out what they think the architecture will be. This envisioning effort sets the foundation for&#xD;
    prototyping. If the solution is similar to a previously produced solution (or is a well-known solution domain), then it&#xD;
    will probably be good enough to reference that example as evidence of the feasibility of the approach. In some cases,&#xD;
    it may be necessary to develop one or more prototypes to validate some of the decisions or clarify some of the&#xD;
    requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The work done here does not seek to produce a detailed and comprehensive technical specification for the system.&#xD;
    Rather, the approach should be to decide the overall technical approach at a high level. The conclusion of this work&#xD;
    should produce just enough information to communicate the architecture to the team, and to demonstrate its viability to&#xD;
    the customer. This allows the project to move forward, enabling you to refine and baseline the architecture.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
</xmi:XMI>
