<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription 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="_H4gOYKYTEdmvhNXG0Oc2uA"
    name="architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw" guid="_H4gOYKYTEdmvhNXG0Oc2uA"
    changeDate="2008-08-15T12:25:02.765-0700" version="1.0.0">
  <mainDescription>&lt;p>&#xD;
    This artifact&amp;nbsp;describes the &lt;a class=&quot;elementLink&quot; href=&quot;./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html&quot; guid=&quot;__O7tAMVvEduLYZUGfgZrkQ&quot;>Software Architecture&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p> It provides a place for maintaining the list of architectural issues, along &#xD;
  with the associated architectural decisions, designs, patterns, code documented &#xD;
  (or pointed to), and so forth -- all at appropriate levels to make it easy to &#xD;
  understand what architectural decisions have been made and remain to be made. &#xD;
&lt;/p>&#xD;
&lt;p> It is helpful for architects to use this artifact to collaborate with other &#xD;
  team members in developing the architecture and to help team members understand &#xD;
  the motivation behind architectural decisions so that those decisions can be &#xD;
  robustly implemented. For example, the architect may put constraints on how &#xD;
  data is packaged and communicated between different parts of the system. This &#xD;
  may appear to be a burden, but the justification in the Architecture Notebook &#xD;
  can explain that there is a significant performance bottleneck when communicating &#xD;
  with a legacy system. The rest of the system must adapt to this bottleneck by &#xD;
  following a specific data packaging scheme. &lt;/p>&#xD;
&lt;p> This artifact should also inform the team members how the system is partitioned &#xD;
  or organized so that the team can adapt to the needs of the system. It also &#xD;
  gives a first glimpse of the system and its technical motivations to whoever &#xD;
  must maintain and change the architecture later.&lt;br />&#xD;
&lt;/p></mainDescription>
  <purpose>To capture and make architectural decisions and to explain those decisions to &#xD;
developers.&amp;nbsp;</purpose>
  <impactOfNotHaving>Without this artifact, there will be no coordination of the individual design &#xD;
efforts, and it will be difficult to establish and communicate an overall architectural &#xD;
vision of the project.</impactOfNotHaving>
  <reasonsForNotNeeding>&lt;p> This artifact is not required if an existing reference architecture is being &#xD;
  used or another approach or set of artifacts are being used to document the &#xD;
  architecture. This artifact may not be needed if the design is relatively straight-forward &#xD;
  and does not have any architecturally significant risks. &lt;/p></reasonsForNotNeeding>
  <briefOutline>&lt;p dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;> At a minimum, this artifact should do &#xD;
  these three things:&lt;/p>&#xD;
&lt;ul dir=&quot;ltr&quot;>&#xD;
    &lt;li>&#xD;
        &#xD;
    &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;> List guidelines, decisions, and constraints &#xD;
      to be followed &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &#xD;
    &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;> Justify those guidelines, decisions, and constraints &#xD;
    &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &#xD;
    &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;> Describe the Architectural Mechanisms and &#xD;
      where they should be applied&lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;> Team members who were not involved in &#xD;
  those architectural decisions need to understand the reasoning behind the context &#xD;
  of the architecture so that they can address the needs of the system. Consider &#xD;
  adding more information when appropriate. A small project shouldn't spend a &#xD;
  lot of time documenting the architecture, but all critical elements of the system &#xD;
  must be communicated to current and future team members. This is all useful &#xD;
  content: &lt;/p>&#xD;
&lt;ul dir=&quot;ltr&quot;>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Goals and philosophy of the architecture&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Architectural assumptions and dependencies&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            References to architecturally significant requirements&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            References to architecturally significant design elements&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Critical system interfaces&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Packaging instructions for subsystems and components&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Layers and critical subsystems&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Key abstractions&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &#xD;
    &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;> Key scenarios that describe critical behavior &#xD;
      of the system &lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul></briefOutline>
</org.eclipse.epf.uma:ArtifactDescription>