<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="_H4gOYKYTEdmvhNXG0Oc2uA" name="architecture_notebook,_0XAf0MlgEdmt3adZL5Dmdw" guid="_H4gOYKYTEdmvhNXG0Oc2uA" changeDate="2008-08-15T00:25:02.000-0700" version="1.0.0">
  <mainDescription>&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></mainDescription>
  <purpose>To capture and make architectural decisions and to explain those decisions to developers.&amp;nbsp;</purpose>
  <impactOfNotHaving>Without this artifact, there will be no coordination of the individual design efforts, and it will be difficult to&#xD;
establish and communicate an overall architectural vision of the project.</impactOfNotHaving>
  <reasonsForNotNeeding>&lt;p>&#xD;
    This artifact is not required if an existing reference architecture is being used or another approach or set of&#xD;
    artifacts are being used to document the architecture. This artifact may not be needed if the design is relatively&#xD;
    straight-forward and does not have any architecturally significant risks.&#xD;
&lt;/p></reasonsForNotNeeding>
  <briefOutline>&lt;p dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    At a minimum, this artifact should do these three things:&#xD;
&lt;/p>&#xD;
&lt;ul dir=&quot;ltr&quot;>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            List guidelines, decisions, and constraints to be followed&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Justify those guidelines, decisions, and constraints&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Describe the Architectural Mechanisms and where they should be applied&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    Team members who were not involved in 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 adding more information when&#xD;
    appropriate. A small project shouldn't spend a lot of time documenting the architecture, but all critical elements of&#xD;
    the system must be communicated to current and future team members. This is all useful content:&#xD;
&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;
        &lt;div style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
            Key scenarios that describe critical behavior of the system&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul></briefOutline>
</org.eclipse.epf.uma:ArtifactDescription>
