| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd"> |
| <!-- VERSION rmc:7.1.0 --> |
| <html xmlns="http://www.w3.org/1999/xhtml"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> |
| <!-- START NON-TRANSLATABLE --> |
| <title>openup&#92;guidances&#92;concepts&#92;&#92;executable_architecture.xmi</title> |
| </head> |
| <!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. --> |
| <body> |
| Element Name: executable_architecture.xmi<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: presentationName<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:presentationName,_O1kAANvfEduv2KOT-Teh6w CRC: 3038226205 -->Executable Architecture<!-- END:presentationName,_O1kAANvfEduv2KOT-Teh6w --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: briefDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:briefDescription,_O1kAANvfEduv2KOT-Teh6w CRC: 1111665287 -->An executable architecture is a stable build that realizes a set of validated architecturally significant requirements.<!-- END:briefDescription,_O1kAANvfEduv2KOT-Teh6w --> |
| <br/><br/><br/> |
| <!-- START NON-TRANSLATABLE --> |
| Attribute: mainDescription<br/><br/> |
| <!-- END NON-TRANSLATABLE --> |
| <!-- START:mainDescription,-0R8BZWlcCQ3Rj84jY2M3Kw CRC: 2321023359 --><p> |
| An executable architecture is a <a class="elementLink" href="./../../../openup/workproducts/build_95D7D8FD.html" guid="_0YuXEMlgEdmt3adZL5Dmdw">Build</a> |
| that realizes a subset of the architecture. This build is used to validate that a subset of the <a class="elementLink" href="./../../../openup/guidances/concepts/architecturally_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Architecturally Significant Requirements</a> is correctly implemented. The subset |
| will include all architecturally significant requirements when the architecture is complete. 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 a build indicating the build |
| contains stable architecturally significant functionality. |
| </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. 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 later in development, a conscious decision can be made to carry this risk forward until the |
| architecture can be fully implemented. In this case, the executable architecture will not contain the entire <a class="elementLink" href="./../../../openup/guidances/concepts/software_architecture_59A08DE0.html" guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>. |
| </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 desireable 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 a build from later in the development cycle is that the |
| executable architecture is the result of a period of development (for example 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><!-- END:mainDescription,-0R8BZWlcCQ3Rj84jY2M3Kw --> |
| </body> |
| </html> |
