Define objectives
List the questions and unknown quantities about the architecture that must be understood to be reasonably confident of
the architectural approach. These issues guide the construction of the proof of concept. The success of the proof of
concept is measured by its ability to illuminate these issues.
The objectives describe what parts of the architecture are at risk and need to be understood before investing
significant effort in the project. For example, if new commercial off-the-shelf (COTS) software will be part of the
architecture, it may be useful to understand how the system under development will integrate with the COTS software and
to understand what problems other organizations have had with integrating the third-party software.
Decide on construction approach
Select a format that
-
Illustrates the architectural approach of the system.
-
Addresses the objectives of the solution that you have defined.
-
Identifies elements that are essential to the delivery of architecturally significant
requirements, such as performance or security.
The proof of concept can take many forms, depending on the novelty of the architecture and the difficulty of the
requirements. See Architectural Proof of Concept for guidance on selecting an approach and
validating the proof of concept.
Construct the architectural proof of concept
This effort could take less than a day or up to a few days, depending on the construction approach that you
select. However, a rare worst-case scenario could require constructing and validating up to 80% of the
actual architecture before achieving enough confidence that it will support the requirements.
Verify the proof of concept
Return to the objectives that you defined for the proof of concept. Verify that the proof of concept shows that you can
meet those objectives and that the proof answers questions or mitigates risks posed by the architectural concept.
Enhance the proof of concept if unanswered questions or unmitigated risks remain. This may require a different
construction approach for the proof of concept.
Examine the proof of concept
The form of this examination depends on the construction approach. If you use a prototype for the proof of concept, it
must be run and evaluated. If you use a model (expressed in UML, for example), it must be reviewed and evaluated by the
appropriate technical people. Use the list of objectives to guide how to assess the proof of concept. The proof of
concept must be measured against each objective that you created in previous steps.
It is possible that the proof of concept will indicate that a different architectural approach is required. In
other words, the proof of concept was successful in that it answered important questions about the architectural
approach, and those answers indicate the approach will not work. In this case, you will need a different architectural
approach, which may require a new proof of concept.
|