Define objectives
List the questions and unknown quantities about the architecture that must be understood to be 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 archtecture are at risk and need to be understood before investing
significant effort in the project. For example, if new 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 understand what issues other
organizations have had with integrating the third-party software.
Decide on construction approach
Select a format that:
-
Illustrates the architectural philosophy of the system.
-
Addresses the objectives defined earlier.
-
Identifies key architectural elements such as areas that may have performance or security issues.
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 aproach and
validating the proof-of-concept.
Construct the proof-of-concept
This effort could take less than a day or up to a few days, depending on the construction approach
selected. 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 defined for the proof-of-concept. Verify that the objectives can be met by assuring the
questions and risks in the architecture can be answered or mitigated by examining the proof-of-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 the examination depends on the construction approach. If a prototype is used for the proof-of-concept, it
must be executed and evaluated. If a model is used (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 created in previous steps.
It's possible 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 a different architectural approach will be needed,
which will require a new proof-of-concept.
|