Artifact: Architectural Proof-of-Concept
This artifact represents a experimental solution to the architecturally significant requirements that are identified early in the project.
Domain:  Architecture
Work Product Kinds:  Concept
Purpose

To demonstrate the feasibility of the project using the selected candidate architecture or to mitigate one or more architecturally significant risk(s).

Relationships
Key Considerations

The decision about whether or not this artifact is required and what form it should take depends on:

  • How well the domain is understood. If the domain is unfamiliar, having an proof-of-concept of the architecture may not only help to explore possible solutions, but may also help the customer and development organizations to understand and clarify requirements.
  • The novelty of the system. If the development organization has constructed many similar 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.
  • When any of the requirements are judged to be particularly onerous, even though the domain is familiar and the system is precedented. For example, when ultra-high transaction rates or extreme reliability are required.
Tailoring
Reasons for not needingThis artifact 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.
Representation Options

This artifact 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
More Information