<?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.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" xmi:id="-DaViM3u8Xhmt2TjYWSDRHg" name="new_guideline,_2QW_oJ3gEdye5InZC-5rHQ" guid="-DaViM3u8Xhmt2TjYWSDRHg" changeDate="2009-02-18T13:22:22.890-0800" version="7.2.0">
  <mainDescription>&lt;p>&#xD;
    Use reference architectures and architectural patterns to assist in making decisions.&amp;nbsp; Good architects know to use&#xD;
    the work of others when making decisions and &quot;a good architecture is full of patterns&quot;.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Some decisions relate to compliance with standards and policies.&amp;nbsp; These need to be taken into account when&#xD;
    understanding the context of the problem as well as justifying the decision. Examples of standards and policies which&#xD;
    will affect architectural decisions are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Security and privacy policies.&amp;nbsp; For example authentication, authorization, auditing and non-repudiation&#xD;
        policies.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Operations and recovery policy.&amp;nbsp; For example error handling and reporting, recovery and rollback policies.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Data management policies. For example persistence, security and privacy policies.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Interoperability standards. For example repository interfaces using SQL, JDBC or adapters that interface to legacy&#xD;
        systems.&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Making an architectural decision usually depends on experience as well as a thorough understanding of what qualities&#xD;
    constitute a good architecture.&amp;nbsp; Here are some properties to be aware of when making an architectural decision:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Consistency - All parts of the architecture are in harmony, and there are common approaches to partitioning and&#xD;
        allocation.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Completeness - Everything has been provided.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Correctness - Structure and behavior are consistent with governing principles and concepts; there are no ambiguous&#xD;
        properties.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Well-formedness - The architecture is well defined, and all aspects can be logically related.&amp;nbsp; All&#xD;
        descriptions should be precise, accurate, and traceable to formal constructs. All architectural components should&#xD;
        be highly cohesive.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Orthogonality - Architectural components are independent and loosely coupled.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Generality – Architectural components work in other contexts.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Extensibility - The architecture can be extended.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Transparency - You can use the system without knowing its implementation.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Openness – Architectural components can be modified and integrated in alternate ways.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Parsimony - There should be &quot;economy of function&quot; and everything should be needed, that is,&amp;nbsp;there is no&#xD;
        unnecessary function or redundancy.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Simplicity – A good architecture should be &quot;as simple as possible but no simpler.&quot;&#xD;
    &lt;/li>&#xD;
&lt;/ul>&lt;br />&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
