Task: Demonstrate the Architecture
Present at least one solution that proves the planned architecture will meet the requirements.
Discipline:  Analysis & Design
Purpose
To reduce the risk of re-working the software architecture by illustrating at least one architecture that will support the requirements of the system.
Relationships
RolesPrimary Performer: Additional Performers:
InputsMandatory: Optional:
Outputs
Main Description

Projects are at risk of spending time developing an architecture that will not support the requirements of the system. This task mitigates the risk of reworking the architecture by describing at least one potential architecture via the Architectural Proof-of-Concept. The objective is to describe just enough of the architecture before building it to be confident that the approach will succeed.

Demonstrating that an architectural approach will succeed can be very informal or very formal. If a team is building software similar to systems they've done in the past, or on top of well understood frameworks (e.g. J2EE), it may take very little explanation to be confident of the architectural approach. If the team is new, or is building software based on new technology, significant research, description, and prototyping may be required before achieving enough confidence to proceed with a specific architecture.

Steps
Define objectives

Define the scope and objectives of the proof-of-concept.

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 for the proof-of-concept that addresses the objectives.

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 Guideline: Create Architectural Proof of Concept for guidance on selecting an aproach and validating the proof-of-concept.

Construct the proof-of-concept

Construct the architectural proof-of-concept using the chosen construction approach.

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

Verify the proof-of-concept meets its objectives.

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

Examine the proof-of-concept to determine if the architecture will meet its objectives.

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.

More Information