BY KEITH PRITCHARD

This article was first published on TABB Forum, February 2019
Fancy your chances?

Blockchain is often viewed as a ‘must-have’ solution in many businesses and industries, particularly in financial services, but pressing the button on a blockchain project won’t necessarily result in an unqualified success. In fact, the odds are against you, as evidenced by a Deloitte report which found that, of the 26,885 blockchain projects started in 2016, only 8% of them are still being actively maintained now. Projects developed by organisations have a higher survival rate at 15% than those developed by users, but the report stated that, “The stark reality of open-source projects is that most are abandoned or do not achieve meaningful scale.”
So what lessons can we learn in how best to proceed and how to avoid the pitfalls?
There are many reasons why a blockchain project can fail and these include:

• Pursuing blockchain just because it’s the ‘must-have’ technology right now

• Lack of insufficient or inaccurate insight into the problem you are trying to solve

• Poorly thought out or inadequate business case justification

• Failure to consider alternative solutions which might have proved preferable

• Lack of sufficient understanding, participation or commitment on the part of stakeholders which can impede, or lead to inadequate results in, any, or all, of the planning, process, design, testing and implementation outcomes

• Inefficient processes

• Lack of sufficient incremental testing

• Blanket implementation without sufficient testing for problems

• Failure to adequately solve the issues that it was meant to address

• Duplicated data and processes

• Costly technology support

• Lack of agreement and adoption of a common domain model by all the market participants and regulators.

Best practice for blockchain

Just because it is a ‘blockchain’ project it doesn’t mean that it will provide the transformational results that you’re seeking. Justification at every stage is the key: will it do everything that you want? will it solve the issues you want? could an alternative solution do it better?
You should always focus on the intended result.
Part of the process should also be to ensure that all the stakeholders understand blockchain’s capabilities and limitations.
It should go without saying that you need to clearly identify and understand the problems, issues and challenges that you are seeking to solve. You need to diligently consider the possible alternative solutions and build a strong business case to justify the proof of concept and the ultimate decision that you take. Each aspect of the design, testing and implementation methodology and its progress needs to be continuously monitored.

DLT – let’s focus on distribution

In financial services, you need to decide whether the distributed ledger platform will distribute both data and functionality or just data. Most agree that data should be distributed because it increases competition and reduces the need for complex and expensive reconciliations.
There is rather more debate about whether functionality should be distributed. Doing so would avoid the need for the services of a Trusted Service Provider (TSP), but it would also result in higher technology and running costs and it can create difficulties in platform management. In smart contracts, if a TSP is involved its calculated cashflows will be accepted by all parties to the contract, but if functionality has been distributed all parties would have to use the code to calculate the cashflow, then send it to the other parties for their confirmation, or consensus, prior to the actual reconciliation. In terms of platform management, if software or calculations need to be amended, they must be updated at the same time for everyone. It can be extremely difficult to find a time that suits all parties, bearing in mind that some organisations will have specific times prior to key events when they will not allow any software changes to be made.

The key is standardisation

Never forget that it is essential to identify a common data and process model which will ensure that the most appropriate technical solution is chosen.
The aim should be to have an agreed process model, an agreed data model and a common deployment platform. To avoid wasting significant sums on developing and maintaining standards in isolation, there are real and obvious benefits in agreeing and adopting a Common Domain Model (CDM). It is essential that common standards are compatible for, and adopted by, all the permitted market participants and the regulators. The overall aim is to get the CDM used by all of them as it will dramatically improve their current processes that are reliant on information exchange, transformation, interpretation and reconciliation.

Agile implementation

Blockchain does not need to be implemented all in one go. There are significant advantages in phased implementation, with stand-alone business cases ensuring that each individual phase will add value and deliver overt incremental progress towards the desired end target.

Proceed with caution

The Deloitte findings should sound a real warning to all those considering blockchain projects. Progressing and implementing a blockchain project without sufficient consideration of all the relevant factors will likely result in costly failure. It is vital to ensure that the designed platform will deliver the real benefits required and that it will properly fit the business’ operational needs.
https://www2.deloitte.com/insights/us/en/industry/financial-services/evolution-of-blockchain-github-platform.html

Share this:

Share on linkedin
Share on twitter
Share on facebook

Related

It’s an attitude.

Have you got what it takes to join the JDX team?

Discover more.