Artifact: Technical Proof of Concept
A Technical Proof of Concept (POC) can be used to clarify areas of uncertainty, confirm requirements, or prove the feasibility of a selected approach. It will also provide information required to make certain decisions regarding the design of the solution. A Technical POC intends to reduce risk to the project.
Domains: Architecture
Purpose

The purpose of a Technical Proof of Concept is to explore a technology new to the project team, or to resolve a significant technical issue within the design. For each release (or build cycle), there may be areas of uncertainty for which you may decide to build a Technical Proof of Concept. The findings and experience gained from building a Technical Proof of Concept not only benefit the current project, but potentially future projects facing similar situations.

In addition to its primary goal of resolving key technical issues, a Technical Proof of Concept may also point to other issues, or shed a light on complementary issues.

A Technical Proof of Concept is only developed when needed. Many projects do not need to construct one. However, if the suitability or performance characteristics of any proposed component is in question, and information is not available from another source (for example, a Technical Proof of Concept from a previous project), then developing a Technical Proof of Concept should be considered.

Description
Main Description

[**
A POC does not have to be a software executable: see the comments on the task and be explicit about the alternatives. Consider using text from RUP.
**]

A Technical Proof of Concept is an early build of some part, or all, of a proposed system design. The Technical Proof of Concept specifically addresses any new or challenging technical aspects of that proposed design. It may be needed for a number of reasons:

  • To assess the technical viability of the design of a specific component
  • To assess a specific area of the application from a usability perspective
  • To collect key technical information regarding the service-level characteristics of the entire solution as documented in the Operational Model: Unsized, or of a specific component within that planned solution
  • To verify the compatibility of a component with other parts of the solution
  • And many others

Technical Proofs of Concept involve the construction of partial or complete systems from hardware and software, or the development of application or technical code. The earlier a Technical Proof of Concept is built, the better. It will usually be developed during the early stages of a project, and will involve an early build of the component, or components, under investigation. It quickly addresses the particular characteristics to be investigated for the component.
Selected RepresentationRational Software Architect
Key Considerations

When considering whether or not to create a Technical Proof of Concept, it is advisable to consider the following:

  • The cost associated with developing a Technical Proof of Concept is generally not small, since it produces executable code itself; therefore, the cost must be seriously weighed against the expected benefits.
  • Since only certain high risk components are validated in a Technical Proof of Concept, and it in itself may not go through formal design and build cycles, it is not intended for a Technical Proof of Concept to grow into the project’s overall solution. Highly-focused components may be used in the solution, but a Technical Proof of Concept must not become the foundation of the solution.
Tailoring
Impact of not havingA Technical Proof of Concept is built as needed. Many projects do not need one. However, if a project has areas of technical uncertainty or technical risk, then a Technical Proof of Concept should be seriously considered. Without it, there is increased risk of encountering technical problems at the end of the project. The primary goal of this work product is to lessen the risk of failure due to unforeseen technical problems.
Reasons for not needingThe project may not have areas of technical uncertainty or risk. It may be composed of tried, tested, and understood technology, or reliable technical data may be available for the performance characteristics of the proposed components (for example, from the Technology Research activity). In these cases, a Technical Proof of Concept may not be necessary.
Representation Options

Generally, a Technical Proof of Concept will result in executable code and some findings. The representation for this varies as widely as the technology being proven.

Notation

Because of the wide range of possible activities, including executable code, no specific notation applies.

More Information
Guidelines
Estimation Considerations

©  Copyright IBM Corp. 1987, 2009.  All Rights Reserved. 

©  Copyright ABC Corp. 2009.  All Rights Reserved.

Includes materials licensed from IBM and Eclipse.  See  IBM copyright  and Eclipse copyright .