Artifact: Architectural Proof-of-Concept

Artifacts > Analysis & Design Artifact Set > Architectural Proof-of-Concept

Architectural Proof-of-Concept	The Architectural Proof-of-Concept is a solution - which may simply be conceptual - to the architecturally significant requirements that are identified early in Inception.
Role:	Software Architect
Optionality:	The Architectural Proof-of-Concept may be omitted when the problem domain is well-understood, the requirements are well-defined, the system is well-precedented and its development is evaluated as having low risk.
More information:
Purpose Representation Timing Responsibility Tailoring

Input to Activities:

Assess Viability of Architectural Proof-of-Concept

Output from Activities:

Construct Architectural Proof-of-Concept

Purpose

The purpose of the Architectural Proof-of-Concept is to determine whether there exists, or is likely to exist, a solution which satisfies the architecturally significant requirements.

Representation

The Architectural Proof-of-Concept may take many forms, for example:

a list of known technologies (frameworks, patterns, executable architectures) which seem appropriate to the solution;
a sketch of a conceptual model of a solution using a notation such as UML;
a simulation of a solution;
an executable prototype.

The Architectural Proof-of-Concept is (optionally) developed in the inception phase, to help determine the feasibility of the project, assess the technical risks attaching to its development, and formulate and refine the architecturally significant requirements.

Responsibility

The Software Architect is responsible for the Architectural Proof-of-Concept.

Tailoring

The decision on whether an Architectural Proof-of-Concept is required, and what form it should take, will depend on:

how well the domain is understood - if the domain is unfamiliar, the Architectural Proof-of-Concept may not only explore possible solutions, but may also help the customer and development organizations understand and clarify requirements;
the novelty of the system - if the development organization has constructed many such systems previously then it should not be necessary to build a proof-of-concept - it should be possible to base a determination of feasibility on existing reference architectures and technologies;
whether, even though the domain is familiar and the system precedented, any of the requirements are judged to be particularly onerous: for example, ultra-high transaction rates or extreme reliability are required.

The higher the risk, the more effort should be put into this architectural synthesis activity in inception (with the expectation of more realistic results from the models produced and assessed), so that all stakeholders can be convinced that the basis for committing funds and continuing into elaboration is credible. However, it has to be recognized that all risk cannot be eliminated in this phase, the inception phase should not be distorted into a de-facto elaboration phase.

Rational Unified Process