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
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
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 needing | This 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
|