The proof-of-concept purpose is to demonstrate the feasibility of the project using the selected architecture candidate or to mitigate one or more architecturally significant risks.

• Architect

• Architect

• Analyze Architectural Requirements

• Demonstrate the Architecture

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

• How well the team understands the domain. If the domain is unfamiliar, having an architectural proof of concept may help not only to explore possible solutions, but also to help the customer and development organizations 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 produce a proof-of-concept for the architecture. It should be possible to base a determination of feasibility on existing reference architectures and technologies.
• When any of the requirements are particularly onerous. You may need the proof of concept even though the domain is familiar and you have built a similar system before if, for example, ultra-high transaction rates or extreme reliability are required.

This artifact may take any of several forms, including these examples: 

• List of known technologies (frameworks, patterns, executable architectures) that seem appropriate to the solution
• Sketch of a conceptual model of a solution using a notation, such as UML
• Simulation of a solution
• Executable prototype

• Architectural Proof of Concept