What Is a Blockchain Proof of Concept (PoC): The Big “Yes or No” Decision
Key Questions Answered
Launching a new business product or service involves a lot of preliminary groundwork, from ideation to initial research to building the final product and a number of steps in-between. One of the key activities along this chain is the proof of concept (PoC).
What Is a Proof of Concept (PoC)?
A proof of concept (PoC) is evidence of a business idea’s feasibility based on research and, usually, small-scale testing or preliminary piloting. PoC is usually documented in a case study or feasibility study document containing a conclusion with regard to the general viability of the business idea. A PoC is designed to answer the big “Go/No Go” question for a business idea or project.
What is Blockchain Proof of Concept?
In the context of blockchain projects, PoC is undertaken to demonstrate that the blockchain-based solution would meet the stakeholders’ business and technical expectations.
It should be noted that PoC is a rather loosely-defined term and may involve different activities depending on the project. In some PoC studies, there is extensive research on the business viability of the project and a limited amount of technical implementation. On the other end of the spectrum are the PoC projects, where both business estimates and thorough technical implementation are carried out.
Additionally, some companies use the PoC term interchangeably with terms such as a prototype or a minimum viable product (MVP), further contributing to the confusion. However, PoC is different from either a prototype or an MVP. It is a general feasibility estimate and might involve, as a part of it, project prototyping or, rarely, even an MVP.
Many companies have undertaken distinctively different activities under the banner of PoC. As such, there is no uniform or standardized “proof of concept template.”
Prototype vs. PoC vs. MVP: What are the Differences?
A prototype is a quick test version of a product aimed at the initial testing of its functionality. Prototypes are not finalized products and normally lack the full functional set.
MVPs are smaller-scale early versions of the final product. Unlike prototypes, they normally have the full functional set of the final product and are used to test the product’s early acceptance.
While prototypes and MVPs are the physical representations of a product, albeit at different stages of the product development lifecycle, PoCs are process-based qualitative conclusions of the product’s viability. As such, PoCs may involve prototypes or even MVPs, along with other activities and processes. PoCs are summarized in business documents such as feasibility studies, case studies, or dedicated PoC reports.
Within the context of blockchain projects, prototypes and MVPs may be built and tested to help frame the big question of the project’s PoC – should we implement it on a full scale?
Strictly speaking, the PoC conclusion does not require prototyping or an MVP. However, if prototyping is necessary for the initial technical feasibility estimates, it might be used within the larger PoC exercise.
In rarer cases, the PoC decision might even require an MVP to be deployed in a pilot mode. That normally happens when preliminary research, conceptualization, and even prototyping are not enough to provide the definitive answer to the PoC’s key “Go/No Go” question.
Some people take the view that PoC is a part of the product development lifecycle and comes before prototyping and MVP. However, PoC belongs in a different domain from the definitions of prototyping and MVP.
While PoC belongs to the domain of business decisions and processes, prototyping and MVP belong to the domain of the product’s different stages of readiness. As such, prototyping, and even MVP development might be a part of a PoC exercise.
An Example of Blockchain Proof of Concept
Businesses and government organizations across a variety of industries have conducted or are in the process of conducting numerous blockchain-related PoCs. Below, we cover one case study of a blockchain-related PoC to demonstrate the typical reasons behind, goals of, and conclusions from a PoC.
The case study covers a PoC undertaken by the Federal Reserve Bank of Boston, one of the 12 regional chapters of the US Federal Reserve Bank.
The Federal Reserve Bank of Boston – Testing an Ethereum-Based Solution for a Core Business Process
In 2016, US Federal Reserve Chairman Janet Ellen encouraged the banking industry representatives to investigate blockchain-based solutions. Later that year, another Federal Reserve governor, Lael Brainard, further confirmed the Fed’s interest in blockchain technology.
These signals served as a starting point for the Boston Federal Reserve to launch its PoC study in late 2016. The Boston Fed chose Ethereum (ETH) as the PoC platform. The decision to choose Ethereum was easily justified. At that time, Ethereum was the pioneer of smart contract technology, and very few other blockchains could support this new functionality.
The key goals that the Boston Fed set out for the PoC were:
- Learning about blockchain and smart contract technology to internalize the skill-set required
- Demonstrating the feasibility of blockchain application to the banking industry
- Testing core business processes with a view to eventually move them to blockchain
- Develop a working solution with minimal investment
The Boston Fed decided against outsourcing of the development effort on the project, in line with the first key goal – developing an internal skill-set for the technology.
After the Boston Fed technical team became familiar with the Ethereum platform, a candidate business process to apply blockchain technology was quickly identified.
The Boston Fed is responsible for the management of the Federal Reserve’s accounting platform. It is a massive platform, handling around 250,000 transactions per day. One important function on the platform is the update of the general ledger via reconciliation of the participating banks’ accounts. As transactions between banks occur, their accounts held at the Federal Reserve system need to be reconciled and added to the general ledger.
This process was chosen as a candidate for the application of blockchain. The Boston Fed’s team investigated the use of smart contracts in the reconciliation process.
The Boston Fed cited this PoC project as a great learning experience. Since the bank decided against outsourcing the technical expertise, the internal technical team became intimately familiar with the Ethereum development environment.
The Final Decision Based on PoC Result
The bank’s final conclusion, based on the PoC, was to not proceed with the blockchain solution. The decision was based on three main factors identified during the PoC:
- Ethereum provided limited functionality for specific database queries that required a detailed sub-setting of data. It was realized that in order to have the full data drill-down capabilities, the system would require an additional database query solution.
- Documentation and support for Ethereum were found to be limited, at least beyond the basic software development queries. When the bank’s technical team needed to enquire about more complex development tasks, the available information sources were lacking.
- Transaction processing on the Ethereum solution was considered too slow, even within the small private test network created by the technical team.
The case study above demonstrates some of the key elements of a good PoC exercise that we outline below. While these may not meet the definition of a “template for a PoC,” as PoCs may differ widely in their structure, the Boston Fed study is an example of a well-structured and well-executed PoC:
- The Boston Fed first received wider signals from the industry about an innovative or disruptive technology, in this case blockchain. It reacted promptly by launching a PoC.
- The bank clearly identified the key project goals before starting the PoC.
- The team at the bank launched a full test environment-based solution, essentially an advanced prototype.
- The technical team took time to familiarize themselves with the technology, and only then selected a suitable business process to test. This is an important point, as in some PoC studies, a business process is chosen before the company and its technical team have had time to familiarize themselves with the underlying technology.
- Clear, well-measured outcomes were derived on the basis of the PoC. In this particular case, these outcomes were used to decide against pursuing the Ethereum-based solution.
- The Boston Fed clearly documented its PoC for the wider public and industry observers to access and learn from. The PoC is available online on the Boston Fed’s website as well as a white paper in downloadable PDF format. This transparency is particularly important for government organizations and public companies. While many of them conduct PoC studies on a regular basis, detailed documentation or even a summary document is sometimes nowhere to be seen.
PoC refers to projects undertaken by organizations with the goal of answering the key question of a business idea’s feasibility. PoC is a somewhat generalized term, and the actual activities undertaken as part of it may vary widely. Although there is no definite structure applicable to all PoC studies, some of the core elements of a good blockchain PoC include:
- Clearly pre-defined goals of the project
- Using an advanced enough test solution to answer both business-related questions, i.e., is this project financially viable, and technical questions, e.g., is the chosen blockchain solution technically feasible and efficient enough for our goals?
- Familiarizing yourself with the technology’s features before selecting an appropriate business process or functional area to apply the technology to.
- Clearly-defined and measurable outcomes that will help provide a definitive answer to the key feasibility question.
- Good documentation of the PoC process and, in the case of government entities and public companies, transparency and public availability of the outcomes, even in cases when the project results in a decision not to proceed.