| <?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="-0R8BZWlcCQ3Rj84jY2M3Kw" |
| name="new_concept,_O1kAANvfEduv2KOT-Teh6w" guid="-0R8BZWlcCQ3Rj84jY2M3Kw" changeDate="2008-09-03T17:26:10.881-0700" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| An executable architecture is an implementation that realizes the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>. It is used to validate that the <a class="elementLink" href="./../../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a>&nbsp;are correctly implemented. It
 |
| validates the architecture as an integrated whole through integration tests. The team gains feedback about the
 |
| architecture from the customer or stakeholder by providing the executable architecture for verification. This way the
 |
| executable architecture helps to assure that the core functionality is stable enough to build the remainder of the
 |
| system.
 |
| </p>
 |
| <p>
 |
| An executable architecture is not a work product. It's an identification or attribute of the implementation,
 |
| indicating&nbsp;that the implementation&nbsp;contains stable architecturally significant functionality.&nbsp;
 |
| </p>
 |
| <p>
 |
| Each version of an executable architecture should be more complete and robust than previous versions. The final
 |
| executable architecture contains all the elements that make up the architecture and should validate all architecturally
 |
| significant requirements. There may be rare exceptions where a portion of the architecture can't practically be
 |
| implemented until later due to uncontrollable circumstances such as constraints with third part software or unique
 |
| resources that are unavailable.&nbsp;Delaying any part of the architecture should be avoided as it raises significant
 |
| technical risk later in the project. But if circumstances dictate that some architectural risk can't be mitigated
 |
| until&nbsp;later in development, a&nbsp;conscious decision can be made to carry this risk forward until the
 |
| architecture can be fully implemented.
 |
| </p>
 |
| <p>
 |
| It's also possible to include non-architectural elements into an executable architecture. This will most likely happen
 |
| when addressing high risk issues early in the development cycle, which is an excellent practice. Two examples of
 |
| non-technical risks are resource risks and competitive risks. It may be desirable to obtain a difficult-to-get resource
 |
| early so they can work on a unique piece of the software now, rather than hoping the resource will be available later.
 |
| Or it may be useful to implement and deploy some early features to maintain market share against a competitor. Think of
 |
| the executable architecture as a way to mitigate architectural risk, which is the most significant technical risk in a
 |
| project. From this perspective, it's appropriate to mitigate other risks in the executable architecture.
 |
| </p>
 |
| <p>
 |
| The difference between the executable architecture and the implementation later in the development cycle is that the
 |
| executable architecture is the result of a period of development (for example&nbsp;an iteration) that's dedicated to
 |
| elaborating the architecture. Later iterations build onto the executable architecture but are not flagged as an
 |
| executable architecture because they extend the system's functionality beyond the architectural framework.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
