Proof of Concept

Right Skills, Focus and Experience


For the adoption of new technology a proof of concept (PoC) is often a required step in risk mitigation. A PoC can build team understanding, capability and confidence, help identify technical and business challenges and provide a sound basis for estimating long term implementation costs. However executing a successful PoC takes the right skills, focus and experience. At an early stage of the project it’s vital to clearly identify the goals and scope and then work closely with stakeholders to manage expectations.


Many of our long term projects development and middleware integration projects start with a PoC. We are flexible and can provide both architects and middleware experts to help select the right products and design the candidate solution and develop an executable architecture to validate operation. As your team gains in experience we can then assume a coaching and mentoring role maximizing skills transfer.

Evaluating the Benefits

The benefits of a system can be weighed according to three categories:

  • Functionality
    PoCs can help to evaluate if a product, service or application can meet the business and non functional requirements
  • Technology
    PoCs can validate that a solution conforms to a company’s existing architecture and technology requirements. They can help to validate Capital Expenditure (Capex) in respect to licensing and hardware costs.
  • Process and People
    Changes to processes and education of additional skills for staff are two important requirements that should be also considered as part of a PoC. Unidentified additional re-training and increased staff costs can have negative impacts on overall Operational Expenditure (Opex).

Capex vs Opex

Capex (or Capital Expenditure) is a business expense incurred to create future benefit i.e. acquisition of assets that will have a useful life beyond the tax year. e.g. expenditure on assets like building, machinery, equipment or upgrading existing facilities so their value as an asset increases.

On the other hand, those expenditures required for the day-to-day functioning of the business, like wages, utilities, maintenance and repairs fall under the category of Opex (operational expenditure). Opex is the money the business spends in order to turn inventory into throughput. Operating expenses also include depreciation of plants and machinery which are used in the production process.

Risk Assessment

Risk assessment can be used by enterprises to manage risk exposure in respect to pursuing strategic goals. It is an important tool used which can be used to estimate how significant each risk is to achieving overall goals. The risks concerning a new architecture should be documented in a structured manner for future reference. These will help to manage risk exposure for the future architecture decisions.

The risk assessment process usually consists of the following steps:

  • Identify risks
    The goal of this step is to gather all potential risk for assessment. For this step several workshops and brainstorming sessions should be held with technical and domain experts.
  • Develop assessment criteria
    Criteria were defined to help classify and evaluate risk along several dimensions such as integrity and performance. This assessment included technical as well as organization and process related risks.
  • Assess risks
    Assessing risks consists of assigning values to each risk and opportunity using the previously defined criteria. This was accomplished in two stages, initially using qualitative techniques (such as architectural complexity) followed by a more quantitative analysis (such as “as is” performance and availability requirements) of the most important risks.
  • Prioritize risks
    Risk prioritization is the process of determining risk management priorities by comparing the level of risk against predetermined target risk levels and tolerance thresholds. Risk is viewed not just in terms of financial impact and probability, but also subjective criteria such as reputational impact, security vulnerability, time to market and availability of development skills.
  • Respond to risks
    The results of the risk assessment process serve as the primary input to risk responses (such as accept, reduce, share, or avoid), cost-benefit analyses are usually performed, a response strategy formulated, and risk response plans developed. A proof of concept is an example of a “reduce” response to integrity, performance and architectural risks.