Six rules for Blockchain success - and 6 things to avoid

Main visual : Six rules for Blockchain success - and 6 things to avoid

My previous blog looked at how blockchain technology can have a potentially disruptive impact on business. Now I’d like to explain some crucial elements – as well as highlighting some things to avoid in kicking off a blockchain-related project.

Blockchain really is the start of a new business paradigm, and I’m probably the last person in the world who would want to put the brakes on an exciting new project that’s making full use of distributed ledger technology (DLT) to revolutionize an antiquated business practice.

However, there are also some crucial elements that you’ll need to keep at the forefront of any new blockchain technology. There are numerous pitfalls, as well as some significant risks that blockchain projects are started for the wrong reasons: either because the technology is perceived as a silver-bullet solution to help organizations overcome multiple issues, or to allay fears of being left behind.

Neither approach is a great basis for making real progress or for being successful.

So, let me share what we have identified at the Fujitsu Blockchain Innovation Center – through our work on projects such as InvoiceChain – as what we are calling the six golden elements that must be in place for a successful blockchain proof of business. What’s more, there is a matching set of six common pitfalls that you should avoid when considering implementing blockchain in an enterprise environment.

6 key elements for Blockchain success…

Before kicking off a project, it’s a good idea to run this checklist of six key elements to ensure that all of them are present, deliverable and meet the aspirations of all stakeholders. If not, then all may not be lost, so proceed with caution.

In fact, if some of the below elements are missing and you’re still determined to move ahead with a blockchain project, then you might want to consider trying out our recently-launched blockchain productization framework. It is focused on determining the true viability of a business concept – or helping ensure that you fail fast, so you can move on to the next big thing.

  1. Identity: for enterprise-class applications in permissioned networks, you need to know who does what. That means visibility of the enterprise and/or personal Identities of Beware that not all stakeholders will necessarily see it this way. Check first.
  2. Data/Content: the value of the application will reside in the data and how you can use that to mitigate any certain risks that are identified. Can you clearly identify what information is going to be shared?
  3. Date-stamp: who does what, when? The notion of old-to-new, sequentially, is a key factor driving trust and proof on distributed ledgers. Does this suit your needs?
  4. Immutability: records cannot be altered, nor can they be updated.
  5. Repeatable: an action in an enterprise and its ecosystem that is executed only once is not the best choice for distributed ledger technology.
  6. Automate: events and actions that can be automated are prime candidates for enhancement, via smart contracts.

And 6 pitfalls to avoid

  1. Impact: You should evaluate your use case based not on the technology per se, but on whether it has the right impact on your business model (and ‘no’ is a valid answer when searching for a use case).
  2. Realistic expectations: Don’t expect ledger technology to fix everything. Be selective and take the time to understand the real value drivers for your business: many topics can be solved without distributed ledger complexity.
  3. Due diligence: Be careful about the data you want to share – the project should be about shared control of data and not about data sharing.
  4. Go beyond the database: Consequently, don’t use your proposed application just as a database – DLTs are databases with shared control over what and how data is added with a reconciliation cycle before data is stored.
  5. Prove the business case: Avoid the risk of endless (and costly) Proof of Concepts (PoCs) – select the right use case and move to a Proof of Business (PoB) instead.
  6. Choose an experienced partner: And lastly, select a partner that isn’t there purely for the technology but understands the business modeling and enterprise ontology that comes with it.

The changes that DLT brings are going to be intense – there’s no getting away from that. But we urge you to resist the temptation to investigate this technology via a toe-in-the-water exercise.

The chances are, it won’t show any relevant benefit that energizes your stakeholders sufficiently to make meaningful progress. Alternatively, you might get locked in a cycle of endless PoCs, grappling with the technical issues raised by the previous cycle and getting bogged down by the rapidly-evolving technology components in the Blockchain and DLT ecosystems.

The key to getting a blockchain project off the ground successfully is shifting your initial focus from the technology to the business drivers and the impact of your idea, in a proof of business test. This means a fundamental assessment of how DLT could reform or transform how you do business.

If you’re still uncertain whether this is the right path for your organization, then try to answer the 10 key questions listed here. They could save you a great deal of time and resources, as well as set you on the path to something transformative, but crucially, viable.

10 key questions to ask before starting a Blockchain project

  1. Are you sure you have a real use case for Distributed Ledger Technology based on the six key elements?
  2. Is there a relevant use case that brings sufficient benefits (operational or financial) where all stakeholders buy-in?
  3. Is there a business and market case over a reasonable time including any modifications to existing systems and processes?
  4. Are all stakeholders (internal, participants, authorities, etc.) on board (in- and outside the company) and is the right governance in place?
  5. What are the standards the projects will adhere to and have you mitigated the risk of evolving standards (technical and non-technical)?
  6. Are the technical, business and operational scalability and performance requirements understood and managed?
  7. Have you sufficiently understood non-technical elements including: decision and process modelling, business (re-)engineering, use cases interaction, enterprise ontology, adoption?
  8. How will regulatory and compliance issues be addressed?
  9. Are there any fundamental legal risks that occur when conducting the project?
  10. How is security and trust handled and what protocols will be put in place to manage this?