OpenUP/OpenUP_baseline_EN/library/openup_basic/guidances/concepts/core_principle_focus.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-HTMJFV29MTZkKWqnIo01Gg" name="core_principle_focus,_9gocwMvoEdqukPpotm3DYg" guid="-HTMJFV29MTZkKWqnIo01Gg" authors="Steve Adolph" changeDate="2006-09-27T16:35:45.896-0700" changeDescription="Added first draft of content." version="0.02">
  <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    Without an architectural foundation, a system will evolve in an inefficient and haphazard way. Such a system often
    proves difficult to evolve, reuse, or integrate without substantial rework. It is also difficult to organize the team
    or communicate ideas without the common technical focus that the architecture provides.
&lt;/p&gt;
&lt;p&gt;
    Therefore, use the architecture as a focal point for developers to align their interests and ideas by articulating the
    essential technical decisions through the growing architecture.
&lt;/p&gt;
&lt;h3&gt;
    Practices
&lt;/h3&gt;
&lt;p&gt;
    The next sections describe the practices associated with this principle.
&lt;/p&gt;
&lt;h4&gt;
    Create the architecture for what you know today
&lt;/h4&gt;
&lt;p&gt;
    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 , thus increasing overall cost with little actual benefit to show for it.
&lt;/p&gt;
&lt;p&gt;
    Therefore, 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: if you have the skill to architect something today,
    then clearly you must also have the skill to architect it tomorrow when you actually need to.
&lt;/p&gt;
&lt;h4&gt;
    Cope with complexity by raising the level of abstraction
&lt;/h4&gt;
&lt;p&gt;
    Software is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it becomes
    difficult for the team to develop a common understanding of the system, because it is hard to see the bigger picture.
&lt;/p&gt;
&lt;p&gt;
    Therefore, use models to raise the level of abstraction to focus on important high-level issues, 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&gt;
&lt;h4&gt;
    Let the problem drive the solution
&lt;/h4&gt;
&lt;p&gt;
    The architecture may become difficult to maintain and adapt to new stakeholder needs when technology, rather than the
    problem, drives the solution.
&lt;/p&gt;
&lt;p&gt;
    Therefore, let the needs of the stakeholders guide the architecture, instead.
&lt;/p&gt;
&lt;h4&gt;
    Organize the architecture into loosely coupled, highly cohesive components
&lt;/h4&gt;
&lt;p&gt;
    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&gt;
&lt;p&gt;
    Therefore, organize the architecture of the system into components that to maximize cohesion and minimize coupling.
    This improves comprehension, increases flexibility, and increases opportunities for re-use.
&lt;/p&gt;
&lt;h4&gt;
    Reuse existing assets
&lt;/h4&gt;
&lt;p&gt;
    It is wasteful to build what you can simply reuse, download, or even buy.
&lt;/p&gt;
&lt;p&gt;
    Therefore, 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 distorting the architecture or relaxing a constraint.
&lt;/p&gt;
&lt;h4&gt;
    Leverage the architecture as a collaborative tool
&lt;/h4&gt;
&lt;p&gt;
    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&gt;
&lt;p&gt;
    Therefore, create and evolve the system architecture with the intention of using it to align the developer’s 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&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>