Blockchain and The Enterprise, Part 1

Lassonde Professional Development Centre

Published in

TheBlockchainHub

16 min readNov 13, 2018

This blog post was written by Carlos Dominguez, MCBB. Carlos is a professional in Enterprise Architecture and Information Security. He is also alumni and volunteer with The Blockchain Hub. To learn more about our program offerings, please check www.theblockchainhub.com/academy

To address Blockchain Enterprise adoption and use cases I will use a process similar to a value proposition analysis, simplified to three steps:

Step 1: Describe the solution (the blockchain).
Step 2: Describe the problem (pains and gains).
Step 3: Describe how the solution (blockchain again!) addresses those pains and results on gains. This is known as “the fit”.

But first, which blockchain is it?

As we all know (I am including you, my readers) everytime blockchain is mentioned there is controversy. Which is fine, but it can make intelligible discourse difficult. For the sake of being able to continue with this blog entry, let’s state what “blockchain” will mean in the context of Enterprise adoption.

There are many ways to sort out blockchains into categories and every attempt at doing so still misses something. Eventually, when ISO finishes their work, we will all agree on the types, but for now let’s keep it simple.

A practical way to differentiate which “type” of blockchain is being discussed is by looking at:

Participants’ access to the network: Permissioned or Permissionless?
Participants’ access to transactions: Public/Private, Read or Write?
Type of consensus. This is where we get into those many Proof-of-whatever, including many variations of Byzantine failure tolerances.
What sort of asset it includes: some have cryptocurrencies, or tokens, or none of that.
What sort of governance: total chaos (beloved by libertarians), governance via computed rules (like a DAO), or governance by committee (people get together and vote).
Incentives: full blown tokenization (hello Tokenomics!), or token-less (like current Enterprise ones). For now (wait for part 3 of this blog).
Type of peer-to-peer networking: Gossip, Channels, Direct… many options here.
Network topology: from the mildly decentralized to the absolute decentralization.

The type of blockchain suitable for the Enterprise is usually referred to as “Permissioned”, which refers to specific design choices for the parameters I mentioned above.

I have also seen references to “Private” as in a single-party implementation, which does not make any sense as by their nature blockchains are not meant to be used as a private database. There are also Hybrid blockchains, but I will skip these for now.

Hybrid blockchain, sometimes is called “Distributed Ledger Technology” or DLT, usually lacks a native cryptocurrency. If you know what Hyperledger , Corda or Quorum are, these are the ones!

Brief detour into decentralization

Now that all pertinent clarifications have been made, I have one final addition: when I referred to The Enterprise I hid something from you. This is what I hid: The Enterprise can actually refer to all manner of businesses.

I will sort those out along a decentralization axis, and into four quadrants as per a second axis of profitability. This does not follow any economic model, but it will help me explain some notions.

I doodled this while discussing adoption. Feel free to disagree

From that diagram above, the “Enterprise” we are about to discuss is located in the left side of the diagram. They could be existing or new.

Why do I exclude the right side? Because I want to cover businesses that are moving from left-to-right along the axis of decentralization.

That movement is the result of adopting DLT (aka Blockchain) technology for their current or new business models. We can refer to the migration as a “transformation”. The world of crypto-assets and tokens for the Enterprise will come later in another blog post (part 3).

Let me explain what a “centralized product” is:, it relies on a value chain where the Enterprise is the only player, or the dominant one. From a Technology and Infrastructure standpoint, all of the value chain participants are owners and operators, and inter-business collaboration or cooperation is done along the demarcation lines of that ownership and control.

For the sake of argument, let’s also make these assumptions about the Enterprise:

It already has some form of Information Technology to support its products or services.
It operates on an industry vertical where there are competitors (let’s exclude monopolies).
It depends on other entities such as business partners, suppliers, vendors and regulators.
It offers a centralized product (or service) as discussed above.

Now that we have set the stage let’s move to the next topic.

If your business is mostly dealing with these we are going to have some challenges

Step 1: Blockchain inherent attributes

So what is it about Blockchain (or DLT) that generates so much hype? Besides its obvious use to get people investing in ICO schemes, most blockchains do the following things to some degree for a distributed network of transacting nodes (participants), where nobody is really in control of the whole thing:

Record transactions in an immutable ledger .
The ledger is used to create trust amongst the parties.
The transaction entries are digitally signed providing non-repudiation.
Each transaction block represents the state of the network.
Each transaction is final.
Transaction blocks are ordered and timestamped.
Each block is created as per consensus from the network.
It creates a level of automation for settling accounts across the network.

What all of the above means is, a ledger (a book of records):

Which is shared by a multiple parties and of which nobody is really in control. We can call that “decentralized” and it is assumed to be a good thing (notice I said “assumed”),
Represents the collective agreement of what-is-what for all those parties (the so called network state),
And, which is almost impossible to alter without anybody noticing.

Ask yourself this question: what can you do with a thing like that? If nothing comes to mind I will add one more thing: the transactions (of the immutable type) can also include code, and that code is subjected to the same rules as everything else (consensus). That code is also another overly hyped thing: Smart Contract. If still nothing comes to mind, read on.

Step 2: Stating the Problem

Now that we have described the “solution” (Blockchain), and its attributes, I will proceed to describe some of the challenges Enterprises face, and which I think are worth addressing.

So what afflicts the modern Enterprise? To answer this I will refer to the assumptions I made somewhere earlier in the blog about business environment, which I will repeat here:

It already has some form of IT, to support its products or services.
It operates on an industry vertical where there are competitors.
It depends on other entities such as business partners, suppliers, vendors and regulators.
It offers centralized product or services.

An Enterprise operating in that setting will find itself dealing with the following:

Having to coordinate transactions across many parties (all those suppliers, business partners, vendors, etc). Sometimes re-initiating the transaction as something was missed.
Using a multiplicity of integration technologies and data formats for transactions, as each party has their own technology and data preferences (their Mac to your PC).
Spending time onboarding new parties and off-boarding old ones, while keeping the legal and compliance teams busy with contracts, and IT busy with adding and removing integrations.
Having to reconcile those transactions multiple times, as each party has its own set of “books” (ledgers), where nobody can see the whole thing and errors happen.
Not knowing whether to trust the party and the data behind those integrations. The other party may be up to no good.
Not knowing about the third-party’s third-party, and what they have to do with the transactions.
Doing painful audits to ensure all transactions are compliant with a multitude of compliance rules, and sometimes finding something is amiss and needs fixing (and paying accounting firms for the privilege).
Generally spending a great deal of effort on inter-business coordination. Also, repeating the same procedures everybody else is doing, because there is no-reusing somebody’s else process that you don’t control or trust (this is an important point).

I would summarize all of the above with this picture

Inter-business integration and coordination of processes across many parties

A bit of history: that mess above used to be the state of affairs for intra-business integration, the one that takes place inside the corporate environment. Two technologies came along and helped deal with it:

The Database, to hold all that corporate data in an organized form. Hard to believe it only came about in 1970. Before that Enterprises relied on the spaghetti data! (I am exaggerating for effect).
The Enterprise Service Bus (aka ESB ), to sort out all those pesky integrations plaguing the IT environment, and move all that data in an efficient, organized and re-usable manner.

Those two technologies are still not enough to make sense of transactions at the business level. They just fix IT messes, but something else is needed to hold the ledger so the business knows the state of its own books: The Enterprise Resource Planning systems (aka ERP).

There is an obvious question: why can’t Databases, ESBs, and ERPs systems be used to coordinate external parties? Answer: if it ever was that easy! There are some things getting in the way with the industry wide implementations: Ownership, Control, and Trust. Remember, we are talking about centralized business where those three things are the name of the game!

I am not saying the solutions don’t exist. They do, but are limited by the reliance on the centralized systems. Just think about it: someone has to own and operate the thing, and whoever does, they have a great deal of power over everyone else. They are also the greatest risk and source of failures for everybody. Like the saying goes: the bigger they are, the harder they fall.

If that strikes you as a cynical view, please revisit that link I have somewhere up there (EY’s 15th Global Fraud Survey). The paper points out something very interesting which will come up next: Digitization of Compliance.

Part 3: How the solution fits the problem

Now that I have you convinced (hopefully) of the difficulties the Enterprise faces when doing transactions in a network where there is no trust, let’s figure out how the solution (Blockchain) addresses them.

I will start with a better model of the spaghetti wiring I showed above. Something more business-like, such as this diagram that I totally made up to explain this.

Business Network 1.0 with spaghetti like integration and transaction coordination

So what do we have here? Let’s list:

There are some interdependent businesses.
Each business totally controls and commands their own environment.
Each business has its own processes which have nothing to do with others’ processes.
There are a number of integrations. A few spaghetti bowls of them. Probably all different flavours.
There is no overarching business process to support integration and transaction coordination.
Each business has its own version of “the truth” (the ledger), which nobody else knows about.
Despite being similar, there is a lot of duplication, as each business is responsible for their own stuff and has no control over the quality of what others do.
There is plenty of material for auditors and regulators to work on. Who knows what they will find when reconciling!
Some of those businesses may not be providing actual value, or could be adding inefficiencies. Those are the types of mediators that automation would do eventually remove, but for now you need them to cook all that spaghetti.
Adding or removing someone from the spaghetti party does not look pleasant.

The obvious question is: what can Blockchain do about the spaghetti? It turns out it can do a whole lot. I will illustrate that with a another diagram, just as made-up as the previous one, but with permissioned blockchain sauce added.

Business Network 2.0 and Blockchain as the decentralized ERP in the sky

Notice, nothing changed about the intra-business coordination, we just changed how the businesses integrated with each other to support the overarching business process. That’s the transformation I mentioned above. Let’s describe that Business Network 2.0 (no spaghetti) by pointing what changed from v 1.0.

There is a new source of truth, in the form of the distributed ledger.
Nobody owns the network (or better said: they all do, but nobody “holds” it).
There is a standard for integration, courtesy of a standardized blockchain node.
There is a standard for transaction data, to support the network transactions.
Adding and removing participants is easier (courtesy of standardization of access).
Transactions are final (no back and forth to get something done).
There is a new type of application that works at the blockchain level (hello, smart contracts!).
There is transparency and accountability (everything signed, validated, and consented).
No need for manual meddlesome reconciliation/facilitators (disintermediated!).
Very resilient over-arching business process, supported by a distributed network with no single point of failure.

At this point I hope it is obvious what blockchain did. No? Ok, here it is: The blockchain (or DLT) is working as Service Bus, Database and/or ERP system but for the whole business network! The same type of solutions put in place to sort out the messy innards of Enterprise IT is now available at a meta-level. Enterprise Blockchain is a Meta-ERP/Meta-ESB system for business networks, but decentralized to solve trust issues created by centralization.

Here are some good follow up questions: why didn't any of the current software power houses create this type of technology? Those business network challenges have been around for some time, so why not build something to solve them?

These are my answers:

Software houses sell to specific clients, usually enterprises. They don't sell to unspecified networks of enterprises.
Enterprises tend to prefer and buy software that is deployed and owned by centralized entities, which is in their nature to do.
The type of problem solved by Bitcoin, and the expanded blockchain technology is better suited for Open Source development without a defined business model (investments, sales, etc.), and rely instead on the effort of a dedicated community of technical experts.
Software houses have taken notice of Blockchain and have adjusted already. Some are even launching products that will enable integration between enterprise blockchains, ERP and other enterprise systems (see links below).

You are probably wondering about the catch. Yes, there is a catch. Actually, there is a whole slew of them. I will cover some of these furter down.

Next question: when and where to use Blockchain? I think you are ready for the next part.

Enterprise use cases conclusion

Let’s get something clear: as far as I have understood the value of Blockchain technology, all the uses cases involve business networks not private deployments. A Database/ERP/ESB system can do a much better work for a single Enterprise.

There is an exception to this rule: if the Enterprise is so large that it behaves like a collection of independent business units, maybe and just maybe blockchain would work. We are talking about organizations with tens of thousands of people and hundreds of business units.

Generally the type of use cases worth considering involve a bit of “coopetition”, to solve industry wide problems and revenue drains. The use cases best suited for the technology resemble supply chain in one way or another, and do not have to be about physical items but digital ones as well.

This is the transformation for an ecosystem (team effort is needed for Coopetition)

These are the types of challenges impacting whole industry verticals, resulting on inefficiencies and constraints for all parties. It is mostly created by lack of trust, standardization, and automation. The symptoms are:

Long running transactions which are hard to settle and require manual intervention.
Identical processes repeated by many parties, and which are not a competitive advantage but just Enterprise level non-core functions.
A thriving body of mediators with low value adds.
Supply chain issues which makes it hard to locate something in space and time.
Troublesome dispute resolution with third parties lacking accountability or transparency.

When Blockchain gets added to the network you get the following Gains as per new and improved business models, and as a result of participation in Business Network 2.0:

Automated settlements via parametric transactions
Automated provenance and authenticity tracking
Very lean value chains, without troublesome mediators
Pinpoint accuracy for supply chain and logistics (e.g. surgical precision recalls).
Automated compliance for all: transparency and accountability as a business model.
Product stacking: automation and standardization with products as reusable building blocks.

In summary: the use cases are those with a win-win outcome for whole industry groups, and for challenges afflicting all. And, I repeat, are not for use cases involving competitive advantages. Blockchain is a team sport! The best use case is the one that works better with larger teams.

At the extreme end of those gains is the “Decentralized Ecosystem” (remember that chart way up in the blog?). I will discuss this in part 3, as it requires some additional considerations.

Now we ready to discuss the catch (i.e. adoption challenges).

Proceed with caution!

First and foremost: Coopetition will require creating a business entity to manage the adoption and on-going operations. Enter The Consortium, and a myriad of challenges which comes with it. The Consortium also plays a role in defining the business cases that will pay for all those nice use cases, so let’s stay with the use cases for now.

Here is the SWOT analysis done by Gartner more than a year ago, and which is still relevant.

Practical Blockchain: A Gartner Trend Insight Report

We discussed a lot of the Strengths and Opportunities in the Fit analysis, so is time to open the book on Weaknesses and Threats. You would think that by now some of them would have been resolved. No, they have not and this is where the use cases can fall apart. Granted, some of these challenges don’t apply to Enterprise Blockchain but many do.

I am going to add some challenges of my own, categorized for convenience:

Security challenges:

Key management is a core functionality supporting the Permissioned access model. It will be as good or as bad as current practices.
Need to consider transaction privacy carefully, as per specific platform features.
Tight integration with competitors could lead do disclosures of sensitive business plans.
There could be impacts to Audit and Compliance practices. You may not be able to afford disrupting those.

Business challenges

There may not be a clear business case for the use cases.
Use cases may require to adopt a common data and transaction model. Easier said than done.
Collaboration with competitors (Coopetition) requires some alignment in product and service design, as well as market approach.
Creating or participating in a consortium requires an agreement to a constitution, and abiding by it.
May need to re-imagine business models. Also challenging.

Technology Challenges

Underestimating the complexity of integrating a node with backend systems. Redundant nodes will add complexity.
Internal reconciliation will not go away. You still have your own ledger.
Investing in early technology that may be exposed to rapid changes and fast obsolescence.
Finding qualified personnel will be difficult (and expensive).

Data Governance Challenges

You need to be “Digital”. Starting with paper records to in one jump will mess up the use case, inflate budgets, and result in massive scope creep. Digitize first, and do blockchain later.
Need clear line of sight for ownership of data in the shared ledger (Consortium again).
Immutability: recorded erroneous information is not easily corrected.
Blockchain Technology does not consider data life cycle. Transactions are hard to delete or archive, without special arrangements.

Conclusion

So what are we to do when evaluating a business case? I will leave you with some general advice:

Understand your place and value in others’ value chain. It is possible you could be the one to be disintermediated.
Validate use cases carefully, and consider the impacts to your business network. You may end up upsetting some parties.
For now, think strategically and act tactically, until more use cases are validated and implemented.
Undertake proofs-of-concepts to understand technology and decentralization.
Understand the difference between a proof-of-concept (simulated network) and the actual implementation (real coopetition network).
Limit the scope of the use cases to quick wins (the easier ones to do, go first).
Learn from the early attempts to reimagine business models, processes, markets, and products for the era of programmable economy (smart contracts).
Assume technology obsolescence will happen. Fast.
Validate legal and regulatory impact for the chosen use cases.
Start to digitize paper records. This will come in handy.
Be part of the ecosystem by participating in the industry (blockchain industry), to track developments and learn from others’ attempts. Build some competence.
Start taking inventory of your business network, the participants, and their roles. Do value chain analysis with an eye on disintermediation. That may come handy too.
Initiate some of that “coopetition”, as it is possible that businesses in your vertical are already looking at industry wide challenges.

Bad reasons for using blockchain:

Fear of missing out.
Following the herd mentality.
Trying to increase brand value by “doing blockchain”.
Because some management consultant told you so.
Thinking that “decentralized” is inherently better than “centralized”, without considering what this actually means for your business model.

Here are some links to help the thinking on Enterprise Use Cases

The Blockchain Hub is an inclusive education and innovation hub, with a strong network of diverse alumni from many industry verticals. Would you like to add your voice to ours, and have your articles featured in The Blockchain Hub? Just send us a note at content@theblockchainhub.com

Disclaimer: The views and opinions expressed in this article are those of the author. They do not purport to reflect the policies, views, opinions or positions of The Blockchain Hub, any other agency, entity, organization, employer or company.