Blockchain: An Enterprise Reality

This article is a follow up to a talk I presented for the Australian Computer Society (ACS) in Brisbane, Australia on May 9th 2019. It is a realistic take on what anyone thinking of using blockchain technology needs to know, outside of the hyperbole filled reports produced by major firms and proclaimed by generalised media outlets.

It provides an overview of the risks, challenges and questions one needs to ask and seriously consider as they work through the muddy waters of the globally undefined “Blockchain” technology which lacks standards, interoperability, and well defined governance mechanisms.

Note: Images within are directly from the slide deck presented on the night.

Introduction

Distributed Ledger Technology (DLT) is now so pervasive, it is near impossible to ignore. If you read articles online or even the news, you may be of the opinion every single industry vertical was about to be uplifted and disposed of in place of “Blockchain Technology”.

The articles and information online, though not incorrect in general concept, are certainly not comprehensive enough for you to make an informed decision of any kind. In fact, I am yet to read any article/report that provides a truthful comprehensive reality of integrating and considering blockchain for the enterprise. Let alone valuable metrics on how to measure the potential Return on Investment (ROI) or Total Cost of Ownership (TCO) deploying a solution may potentially render. It is fair to say, many have no idea, consultants are still selling an overly positive narrative and the rest haven’t been exposed to large scale enterprises to know better.

Even more interestingly Deloitte Insights — Global Blockchain Survey for 2019¹ that was released just 4 days ago states 83% of executives surveyed believe there is a compelling business case for blockchain. Yet 43% of the same executives state that blockchain is over-hyped. The juxtaposition amongst the fold screams education is needed to dispel the ill informed masses and straighten the arrow toward a more realistic narrative.

The way I see it is, irrespective of size and scale there is fundamentals which don’t change and considerations which must be addressed if you are to tackle the new paradigm that is exposed through this technology. The below article hopes to provide you a strong starting point before you as a technologist venture down the road of “Enterprise Blockchain”.

A Reality Check

The reality is, blockchain as a technology is not disruptive at all. It is a foundational technology which took the ingredients of long standing work (a non exhaustive list provided below) and baked it in such a way that delivers an immutable, border less, open, censorship resistant, secure and trust less platform that dis-intermediates current business monopolies.

1. Cerf & Kahn (1974) — A protocol for packet network intercommunication (TCP/IP)
2. Diffie & Hellman (1976) — New Directions in Cryptography (Public Key Cryptography)
3. Leslie Lamport (1978) — Time, Clocks, and the Ordering of Events in a Distributed System (Lamport Timestamps)
4. Ralph Merkle (1980) — Protocols for public key cryptosystems
5. Haber & Stornetta (1991) — How to time-stamp a digital document
6. Adam Back (1997) — Hashcash: DOS Counter-measure with proof-of-work
7. Satoshi Nakamoto (2008) — Bitcoin: A Peer-to-peer Electronic Cash System

The important part to understand however is that the combined properties in bold above are only true within a decentralised permissionless ecosystem such as Bitcoin or Ethereum.

Many do not realise, it is not the technology which makes Bitcoin an impressive feat. It is the game theory and economic incentivisation & dis-incentivisation which enforces global order by ensuring irrational self interested actors cannot overthrow the network without significant cost. The technology is just the vehicle to achieve such with blockchain simply being one portion of the puzzle, the data store.

Puzzle Pieces of a DLT Solution

Unfortunately due to the hyperbole and misrepresentation of the word “Blockchain” over the course of many years, permissionless (public) and permissioned (private / consortium) varieties of blockchain are seen synonymously by many. Thus leading to the mindset every vertical will be touched, transformed and replaced in one fell swoop. Which simply put, is gravely incorrect and ill informed.

Permissioned vs Permissionless

Enterprises have significantly different requirements to small medium businesses, startups and certainly the libertarian views many open source Bitcoin maximalists believe in of disintermediating big banks and restoring power to the people.

Enterprises (Corporates & Government) are continuously looking for efficiencies and cost saving mechanisms. With this, ever since the proliferation of Bitcoin (as a protocol) into main stream media they (enterprises) have been tinkering with the ingredients of the technology which makes up the life blood of Bitcoin in search of outcomes which will impress shareholders, citizens, boards and business partners.

The outcome of the experimentation is that now blockchain implementations don’t come in just one flavour, they have been adapted to suit enterprise needs where their public (permissionless) counterparts may not suit the requirements of a business or industry. It is important therefore to understand the difference between permissioned and permissionless blockchain implementations (with the lens of your business, enterprise or startup) to see where the value may lie for your potential use case.

Many are using or exploring blockchain in hope the word itself will deliver the benefits they seek, without understanding the reason why. While certainly not realising that generally speaking permissioned varieties throw away the proclaimed benefits majority of executives are using as their sales pitch to investors. Counter-intuitive no?

It works like this:

Permissionless — Don’t Trust, Don’t Know

You don’t need to trust anyone, nor care for knowing who is part of the network because the consensus algorithm (rules of the network) which is run by thousands of heterogeneous nodes (computers) worldwide enforce the state of play leaving you to “trust” the code and not worry about Bob, Dan and Dave who are trying to fudge the books.

Permissioned — Don’t Trust, Know

Whereas, this is where your private and consortium entities come into play. A network more likely built of business partners or even competitors. In turn, you don’t trust your competitors within this shared distributed network and therefore you need to know — who, when, why and what to ensure their actions are controlled on the network.

Essentially it comes down to, who is able to write data onto the ledger, and under what circumstances.

Yet, it doesn’t end there. There is serious considerations which you as a developer through to a C-suite executive must analyse prior to pulling the trigger on a full blown budget blow out. The inserted slide from the presentation below details a comparison of some key points to look at and understand.

Permissionless (Public) vs Permissioned (Private) Comparison Points

Let’s discuss some:

1. Fixed vs Modular ArchitectureEnterprises would be accustomed to defining their own architectural patterns and stacks based on skill set, partnerships or industry. Yet when we introduce the concept of open, permissionless architecture it is important to remember enterprises will need to play by global rules. These rules are not easily changed, which is what makes the system secure. Therefore our value proposition must take this into account early.
2. Security vs ScalabilityThere is a well known concept in distributed databases called the CAP Theorem which infers that you can only have 2 of 3 properties at any one time. This is also known in international economics as the Impossible Trinity. Well blockchain has one also which states you can have 2 of 3 properties selecting from Speed, Security or Decentralisation. Permissionless platforms pick Security & Decentralisation over Speed while Permissioned take Speed and Security over Decentralisation. This is important for an enterprise to realise that just because permissioned chains are faster to deploy for MVP’s doesn’t give you the same level of assurances that another implementation may based on use case.
3. Smart Contracts vs Chain CodeA same same, yet different technical challenge here is exposed whereby in a permissionless network though the libraries for languages like Solidity are Turing complete (named after Alan Turing — Computer Scientist) their implementation isn’t. The reason for this is Ethereum is a global computer which must have fault tolerant mechanisms. This requires only a certain amount of computation to be run per smart contract to ensure it fits within the block size limitations (gas limits). This means you can’t codify elaborate and extensive logic, whereas in a permissioned network you can do as you please as you may own the infrastructure or be renting is specifically for business (cloud).

There however is no simple answer as to why you pick one over the other, as it is use case driven. What I want to elude to in this piece is that though seemingly Private Permission varieties throw away what made ‘Blockchain’ famously valuable (shown below). It is the actual consideration of a use case driven, consumer or business process first approach that is required not technology.

Blockchain’s in permissioned model’s have very little real world uses that cannot be achieved with existing technology when we look at existing business models. If this is to work, we must take a design thinking approach, scrutinise the way we work now and then consider if the technology meets the brief. If it doesn’t move on.

Issues & Challenges

In order to clear the air, and start producing valuable outcomes we must have the conversations no one is having openly and that is by discussing the Issues & Challenges that experienced practitioners have faced in both Permissoned and Permissonless builds.

High level considerations which plague the industry currently include:

• Governance — Tragedy of Anti-commons & DataIn both operating models there is lack of clarity around how to ensure communication breakdowns don’t occur across a distributed network. Including regulator hurdles of Personally Identifiable Information (PII) and the General Data Protection Rules (GDPR) which influence the architecture and governance model significantly. Requiring rules covering²:

1. Joining Procedure
2. Exiting Procedure
3. Minimum Security Requirements
4. Membership Committee
5. Procedure to Change the Technical Environment (Private/Consortium)

• Garbage In, Garbage OutA well known construct in ICT develop is that of GI,GO whereby if you input non-validated data, your business process won’t fix it for you and in turn will lead to incorrect outputs. This concept also applies to blockchain solutions, whereby there is a terrible situation unfolding that individuals use the concept of “immutability” and “trust” to infer the blockchain will sort it all out. This assumption is wrong, you need to work it out, otherwise you will store data onto the blockchain immutability with spelling errors, rounding errors etc. without the ability to change it.
• Consortium's These are appealing to organisations to join to learn from a diverse range of industry bodies and potential partners. Yet in the context of partnering to deliver, if those consortium members are competitors such as banks using a common framework — consortium's can end in standards wars. As each actor in the network wants what is best for them not the greater good. Therefore will argue in favour of rules which support their intentions. Be careful!
• Extras below:

The list above is by no means an exhaustive list, however it touches on topics many aren’t discussing which is exactly why you should. It requires enterprises to think different, which depending on your organisation, your team, you — can be challenging. It is not a simple, “we have a problem, blockchain seems a likely solution” fix.

The solution is rarely solved by using ‘Blockchain’, and if it is given the green light. There is far more worries past deciding on DLT over DB which relate to existing:

• Business Processes
• Change and Release Management (Communications/Defects etc)
• Analytics & Monitoring
• Data Storage, Migration (Extract, Transform, Load)
• In-flight projects
• Non-functional Requirements
• Auditing, Compliance & Reporting

To break these down further I have provided some questions I want you to think about and ponder.

Final Thoughts

The above is just a taste of what you need to start looking at if you want to scratch the surface of this technology. Abstracting complexity away from users is more important than anything else. We don’t want to hear you are using blockchain, just like we don’t say we are using TCP/IP, MongoDB etc. Consumers and business partners simply do not care, they just want to be able to do A, B, C.

However we still have an incredibly long way to go related to education, and being transparent with our wins and learning opportunities (failures) to better not only the technology but global business landscape.

Don’t move to fast, use the tooling available to test the waters and remember it is just a tool in your tool box as a technologist and needs to be fit for purpose. So take the time to tease out any questions, queries or doubtful points before you take the plunge and find out the “Enterprise Reality”.

Recommendations

1. Use CaseA fundamental shift in thinking needs to happen to make a use case valuable. We need to take a business process, user driven approach not technology first as Deloitte Insights¹ suggests. If your executive is one of their statistics now asking “how we can make blockchain work for us?” you are doing it wrong, and are destined to fail. It’s a self-fulfilling prophecy which will never render the optimal results. So at a minimum your idea must have:

• A business problem to be solved that cannot be solved with more mature technologies
• An identifiable business network with participants, assets and transactions
• A need for trust (consensus, immutability, finality or provenance).

Or utilise a flow like below:

To blockchain or not?

2. Enterprise IntegrationConsider this as early as possible even if your POC/MVP is not going to be integrated. Working with monolithic mainframes and existing mid range systems across different file formats, integration touch points, and even languages will require more food for thought than anticipated.

3. Non Functional RequirementsThe ‘itlities’ normally are well integrated and catered for in existing solutions with well defined service level agreement’s. However moving to a distributed ledger architecture will require you to reconsider these:

• Accessibility
• Auditability
• Capacity
• Disaster Recovery
• Fault Tolerance
• Integrability
• Maintainability
• Realiability
• Testability et cetera…

4. Small to BigIt won’t be easy, it won’t. Even using templated solutions from Microsoft Azure BaaS — the mixture of process change, to tooling, skill sets and mind sets will require commitment and perseverance as you face a multitude of set backs. So start small, and test whether the idea even has merit.

Blockchain is a tool in your toolbox (Kris Bennett)

If you have any questions or constructive criticism let me know on a channel below.

Thanks for reading,

Benjamin Hall

HAVOK Advisory & Education

• Benjamin Hall - Assistant Director (ICT) - Australian Public Service | LinkedIn
• Crypto Catch Up
• Benjamin Hall (@crypto_catchup) | Twitter

References:

1. Deloitte Insights: Global Blockchain Survey 2019https://www2.deloitte.com/insights/us/en/topics/understanding-blockchain-potential/global-blockchain-survey.html
2. Blockchain: Riding the Rollercoaster towards a Standard — Dr. Adrian McCullaghhttps://ssrn.com/abstract=3362100

Blockchain: An Enterprise Reality was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.