Since a Technical Proof of Concept actually validates a component design and produces executable code, it is difficult
to document a running example. This document will simply highlight scenarios which may warrant the development of
a Technical Proof of Concept.
1. In order to fit a particular customer's existing IT platform, a project was implemented using Smalltalk and
COBOL with C++ infrastructure code. This particular combination of technologies was at that time totally unknown
in the relevant development shop, so a small subsection of the product was developed as a Technical Proof of
Concept. It included the bare minimum to demonstrate the compatibility of the components and measure the
end-to-end performance characteristics of a simple transaction. The transaction was measured using a desktop
object on the client, the messaging service between the client and the host, and a simple server component. The
following results were produced:
-
Metrics for the performance and capacity characteristics of the technology, such as message size information and
turnaround time.
-
Outline requirements for tools to monitor and verify the cost of the technology, in this case the incorporation of
trace points in the application logic to support performance analysis and debugging.
-
Recommendations that some of the technology should not be used. In this case, the proposed version of
Smalltalk was replaced with one from another supplier because of the inefficiency of the garbage collection
process.
-
Developer guidance on the most effective way to use the technology, for example on how to reduce total time
perceived by the end-user by overlapping client and server processing.
2. Another project development team performed some initial work to learn exactly how MQSeries worked. The
output from this was in the form of flow diagrams that identified the areas within the product that could become
performance concerns.
3. A third project required an interface to an existing system. The new interface had aggressive performance
requirements. A Technical Proof of Concept was created to validate the design options for maximizing the
throughput of the interface.
On a fourth project, the designers were unsure which batch architecture would yield the shortest overnight run
time. The cost of actually developing more than one option was prohibitive, so a detailed simulation of the
various options was carried out using a tool to determine which was the most effective. Note that this approach
should only be used with great care, as any simulation is only as good as the data that goes into it (refer to the
Performance Model WPD).
|