Artifact: Architectural Proof of Concept |
|
 |
This work product is a solution, which might simply be conceptual, to the architecturally-significant requirements that are identified early in a project. |
Domains: Architecture |
|
Purpose
The purpose of the Architectural Proof-of-Concept is to determine whether there exists, or is likely to exist, a
solution that satisfies the architecturally-significant requirements.
|
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Process Usage |
|
Tailoring
Impact of not having | The higher the risk, the more effort needs to be put into this architectural synthesis activity early in a project (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 the project is credible. However, it has to be recognized that all risks
cannot be eliminated at the beginning of a project. Risk-mitigation activities, including continuing architectural
explorations, must continue throughout the project. |
Reasons for not needing |
The decision about whether or not an Architectural Proof-of-Concept is required and what form it needs to take depends
on:
-
how well the domain is understood - if the domain is unfamiliar, the Architectural Proof-of-Concept might not only
explore possible solutions, but might 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 or not, even though the domain is familiar and the system is precedented, any of the requirements are
judged to be particularly onerous; for example, ultra-high transaction rates or extreme reliability are required
|
Representation Options |
The Architectural Proof-of-Concept can 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
|
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.
|
|