<?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.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="-HTMJFV29MTZkKWqnIo01Gg"
    name="core_principle_focus,_9gocwMvoEdqukPpotm3DYg" guid="-HTMJFV29MTZkKWqnIo01Gg"
    authors="Steve Adolph" changeDate="2008-01-23T17:14:28.752-0800" changeDescription="Added first draft of content."
    version="0.02">
  <mainDescription>&lt;h3>&#xD;
    Introduction&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The architecture of a software system is the organization or structure of the system's significant components&#xD;
    interacting through interfaces, with components composed of successively smaller components and interfaces.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often&#xD;
    proves difficult to extend, reuse, or integrate without substantial rework. It is also difficult to organize the team,&#xD;
    or to communicate ideas without the &lt;b>common technical focus&lt;/b> that the architecture provides.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Focus on the architecture early to minimize risks and organize development.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Practices&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    Create the architecture for what you know today&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    As Albert Einstein said, make everything as simple as possible, but no simpler. Software projects are&#xD;
    resource-constrained, and the desire of developers to create elegant solutions may lead to a system of greater&#xD;
    complexity than the stakeholder requires. Efforts to future-proof a system in a turbulent or uncertain environment will&#xD;
    likely lead to code bloat, which increases overall costs and complexity with few real benefits.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Create architectures that address the stakeholder's real needs, and provide appropriate flexibility and speed for the&#xD;
    requirements as they are known today. Avoid the desire, no matter how well-intentioned, to speculate on future&#xD;
    requirements and thereby over-engineer the architecture. There is a distinction between over-architecting and building&#xD;
    an architecture that is flexible and extensible. For example, there may not be an apparent reason for creating three&#xD;
    architectural layers in a system, but it is probable that the system will grow in ways one can't predict, so we should&#xD;
    architect for that.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Leverage the architecture as a collaborative tool&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Lack of a common understanding by developers about a system leads to indecision and contrary opinions among developers,&#xD;
    and can quickly paralyze the project. Developers may have different mental models of the system and work at cross&#xD;
    purposes to each other.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Create and evolve the system architecture with the intention of using it to align the developers' competing mental&#xD;
    models of the system. A good architecture facilitates collaboration by providing a common vocabulary for all&#xD;
    discussions regarding the system under development.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Cope with complexity by raising the level of abstraction&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it is&#xD;
    difficult for the team to develop a common understanding of the system, because it's hard to see the bigger picture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Use models to raise the level of abstraction to focus on important high-level decisions, such as relationships and&#xD;
    patterns, rather than getting bogged down in details. Modeling raises the level of abstraction, and allows the system&#xD;
    to be more easily understood from different perspectives.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Organize the architecture into loosely coupled, highly cohesive components&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Tight coupling between components makes a system fragile and difficult to understand. Software is expensive to create,&#xD;
    so if existing components can be reused, that may reduce effort required to create a system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Organize the architecture of the system into components to maximize cohesion and minimize coupling. This improves&#xD;
    comprehension, and increases flexibility and opportunities for re-use.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Reuse existing assets&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    It is wasteful to build what you can simply reuse, download, or even buy.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those assets do not&#xD;
    exactly meet their needs, or those assets are of poor quality. Be prepared to balance the savings you can realize using&#xD;
    an existing asset, even if the asset requires you to make some accommodation in the architecture or relax a constraint.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>