blob: a1b573cc140d994945f305211f97f242dae466a4 [file] [log] [blame]
<?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.4/uma.ecore"
xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmlns:rmc="http://www.ibm.com/rmc"
rmc:version="7.2.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>