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