Blockchain and the Enterprise, Part 3

Blockchain and the Enterprise, Part 3

While I was away…

If you are one of my very few but precious readers, you would have noticed I was away for awhile as there is a gap in blog posts. What was I doing? Over the summer I  was busy with blockchain events, meetups,  online courses, in-person courses, exams, whitepapers, certifications and bad dreams. If you want to know about those send me a note.

After  a period of blockchain indigestion, resulting from an all-blockchain diet with too much fiber, I managed to somewhat sort all of that out. Or so I hope  for my sake and yours, as I am about to visit all that wisdom upon you in a three-part blog (because three-part anything sounds grand!). This is part three, which should be obvious as per the title. No, you did not miss the other parts. Yes, I am starting with part three because I am a discordian and I like reading Robert Anton Wilson. Deal with it.

 

This is my plan of action for imparting all that hard-earned wisdom: I will use a process similar to a value proposition analysis which I learned from these nice people, and which I will probably mangle beyond recognition.

• Step 1: Describe the thing, or solution, as is (the blockchain that is)
• Step 2: Describe the problem (pains and gains in value proposition lingo)
• Step 3: Describe how the solution or thing (blockchain again!) addresses those pains and gains
• Step 4: Money!.. I wish it was that easy. If I get a bitcoin account, will you give me some?

I will have some detours here and there, as per my usual style and as I see fit.

First, let’s deal with the Trekkies

Fellow Trekkies, I know I used a catchy image to do a bait-and-switch. I have a small number of readers so I do what I can to get more.  Now that I have your attention, note this blog entry has nothing to do with the Enterprise as you know it. Please forgive me and read on.

I won’t even mention there was no money in the Original Series and The Next Generation, and the future  seemed to be strangely void of currencies (crypto or otherwise). Maybe the Ferengis are the bitcoin miners of the Federation? All that talk about fearing an afterlife  spent in the “Vault of Eternal Destitution” sounds very familiar.

For the rest of you: if you are not a Trekkie, or don’t know what that is, nevermind, just keep on reading. Also, know this blog has nothing to do with Car Rentals, Aircraft Carriers, or Space Shuttles (which may have been named after the fictional spaceship, or not).

So, what is this about? This is about the legal entity made up of an association of people (natural or legal) with the purpose of doing some commercial activity (hopefully legal), and which we all affectionately call “The Enterprise”. It is also about how blockchain could help or hinder said commercial activity. Yes, that’s right! You got it! We are going to discuss Blockchain and The Enterprise! (the clouds parted when I wrote that).

The following picture illustrates the idea. Or it will confuse you. I am already confused.

Second, let’s disarm the “B” controversy

As we all know (myself and my three readers) everytime blockchain is mentioned there is controversy. Which suits me fine (didn’t I say I am a discordian!), but makes intelligible discourse impossible. I am reminded of what Iñigo Montoya said “You Keep Using That Word, I Do Not Think It Means What You Think It Means”, so for the sake of being able to continue with this blog, and for the fun of it, let’s state what “blockchain” could mean.

The term “blockchain” is ambiguous and misleading as it could refer to:

• Bitcoin or any other cryptocurrency
• The underlying data structure used by cryptocurrencies
• The underlying technology used by cryptocurrencies, including consensus algorithms
• The data structure in distributed ledgers
• The technology used in distributed ledgers
• The algorithmic incentives used to promote convergence of state in distributed systems

 

“Blockchain” has been used in numerous online forums, starting in 2009 in reference to bitcoin, and to everything else later on. Sometimes it has small “b” and sometimes a cap “B”, depending on the importance of the speaker.

So which Blockchain or blockchain am I addressing? I will discuss the technology used in distributed ledgers, also known as Distributed Ledger Technology, also known as DLT. I will do that for at least part 3 and 2, for the sake of my argument and to avoid talking about tokens and cryptocurrencies in the context of The Enterprise. If you know what Hyperledger, Corda or Quorum are, those are the ones!

 

Third, let’s get this show on the road

Now that all pertinent clarifications have been made, and I have excused myself with the Blockchain Inquisition, I have one final clarification to make (sorry!). 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 (because I can), and into four quadrants as per a second axis of profitability (now I sound like a Ferengi). It does not follow any economic model, but it suits me fine.

From that diagram above, the “Enterprise” we are about to discuss, is located on 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.

The 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”, which is a word you are going to be reading a lot moving forward.

And before you start asking, 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 IT (computer stuff, not the scary clown), 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 in to the next act, to heighten the drama. I have an audience to please after all.  I will be using Blockchain and blockchain in an attempt to pacify the inquisition.

Necessary detour into blockchain taxonomy

I just realized I have not done the proper thing and introduced or referred  to a blockchain taxonomy or classification. How did I miss such a thing? I will tell you: there are many ways to sort out Blockchains into categories, and every attempt at doing so still misses something. Eventually, when the International Organization for Standardization  (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, or wait for part 1 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.

You get the idea. I can keep adding categories for ever and never come to a conclusion. ISO people, please hurry up!

Here is an example of blockchain governance via Consortium (or a Cartel if done wrong): “We Do!”

The type of blockchain I am about to describe is usually called “Permissioned” or “Enterprise”, which refers to specific design choices for the parameters I mentioned. I have seen also 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 them at this time.

Note, the Inquisition would like people to call it  “Distributed Ledger Technology”, meaning some sort of database that is all over the place, and is operated by a number of separate entities, and which together constitutes a “ledger” for the network of entities, but does not have a cryptocurrency.

I know this is all very confusing. I will write about it some other time (and abuse that confusion for all I can until ISO does away with it, if they ever do). For now just imagine a blockchain, or DLT if that’s your thing, which is suitable to The Enterprise as defined above. So go with me on this.

Act 1. Blockchain Inherent Goodness

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

• Record transactions in an immutable ledger (is hard to cook the shared books)
• The ledger is used to create trust amongst the parties (participants in the network)
• The transaction entries are digitally signed, providing non-repudiation
• Each transaction block represents the state of the network
• Each transaction is final  (meaning it is done, and cannot be undone or rewritten)
• Transactions blocks are ordered and timestamped (Chain of blocks! Do you see it now?)
• Each block is created as per consensus from the network (via collective agreement as per type of consensus)
• It creates a level of automation for settling accounts cross the network.

 

In some circles that is referred to as the “trust machine” (paywalled link), as in a machine that generates trust. I am not going to call it that, as I think is over the top and reductive. I agree with this sentiment.

I mentioned ICOs in the same context as “blockchain goodness”. Just to be on the safe side, I should mention, “goodness” does not extend to dubious schemes by clever people to separate folk from their hard earned money for the purposes of procuring themselves one of these:

This blog is not investment advice. Beware of the Lambos! Do your homework and don’t blame me for your poor life choices.

I mentioned couple of terms above which may require some explanation. If needed just check out one of my older blog posts: Little Blockchain reading list. The author of  those “gentle” blog posts I included in the list also wrote a book that may come handy (disclosure: I get nothing if you buy the book. I just like the writing style). You may want to stop here and review some of that. I will continue by assuming you already did.

Back to The Goodness: you basically have a ledger (a book of records), which:

• It is shared by a multitude of entities who don’t care much for each other (no trust here),
• of which nobody is really in control. We can call it “decentralized” and assumed to be a good thing (notice, I said “assumed”),
• and by some miracle of technology it represents the collective agreement of what-is-what for all those parties (the so called network state),
• which is almost impossible to “cook” 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 idea: the transactions (of the immutable type) can also include code, and the code is subjected to the same rules as everything else (consensus and such). This code is also another overly hyped thing: Smart Contract which at times are neither  contracts nor smart, but it is a catchy name.

If you are still drawing a blank, read on. Or maybe the clouds parted for you, the sun shined, a rainbow showed up,  and a chorus of angels sang the Sony Playstation 3 sound which is said to reflect the sense of a community coming together. If that actually happened you are probably a strange character and I don’t want to be seen with you.

Act 2.  The Enterprise pains and gains

Now that we have described the “solution” and its “attributes”, (hmm… I am starting to sound like a management consultant, wondering why), I will proceed to convince you, the modern Enterprise has some challenges worth addressing. The next step depends on me convincing you of something, so please be convinced!

So what afflicts the modern Enterprise? To answer this I will refer to the assumptions I made somewhere earlier in the blog about the businesses, which I will repeat here as to increase blog word count, and in case you already forgot about it:

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

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

1. Having to coordinate transactions across many parties (all those suppliers, business partners, vendors, etc). Sometimes re-initiating the transaction as something was missed.
2. Using a multiplicity of integration technologies and data formats for transactions, considering each party has their own technology and data preferences (their Mac to your PC).
3. 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.
4. 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.
5. Not knowing whether to trust the parties and the data behind those integrations. The other party may be up to no good.
6. Not knowing about the third-party‘s  third-party, and what they have to do with the transactions.
7. 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 the Big 4 for the privilege).
8. 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 else’s process that you don’t control or trust (this is an important point).

(I wish I could do 10 points, as stopping at 8 looks lame. Point 10 should be awesome sounding,  conclusive and definitive. A big Bam! like Chef Emeril does. All I have is 8,  which will do for now.)

If I were to represent how The Modern Enterprise conducts its business with other parties by means of IT integration (inter-business integration), it would like like this (spaghetti integration) :

This 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.

These 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 these three things are the name of the game!

I am not saying the solutions don’t exist. They do, but are crippled 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.

Let me summarize this thought for you:

If that strikes you as a cynical view, please revisit that link I have somewhere up there (EY‘s 15th Global Fraud Survey). I know, I know… that paper helps EY get more customers, but they did not make up the numbers. The paper also points out something very interesting which will come up next: Digitization of Compliance.

Conclusion: If there was a way to do the inter-business coordination, without all that backstabbing, wouldn’t it be wonderful? Yes! And with this thought let’s get to the next act.

Act 3. Transformation by Blockchain

Now that I have you convinced (hopefully) of the difficulties The Enterprise faces when doing transactions in a network where there is no trust (pains and gains) , let’s figure how the solution (Blockchain) addresses them. This is it people! We are in the home stretch!

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:

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

1. There are some interdependent businesses (for business reasons I take it).
2. Each business totally controls and commands their own environment.
3. Each business has its own processes which have nothing to do with others’ processes.
4. There are a number of integrations. A few spaghetti bowls of them. Probably all different flavours.
5. There is no overarching business process to support all that integration and transaction coordination.
6. Each business has its own version of “the truth” (the ledger), which nobody else knows about.
7. 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.
8. There is plenty of material for auditors and regulators to work on. Who knows what they will find when reconciling all that!
9. Some of those businesses may not be providing actual value, or could be adding inefficiencies. These are the types of mediators that automation would do eventually remove, but for now you need them to cook all that spaghetti.
10. Adding or removing someone from that spaghetti party does not look pleasant.

( 10! I got 10! )

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

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

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

(I am so good at this enumerating-to-10 thing!)

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 ERP system but for the whole business network! Did you get that? The same type of solution put in place to sort out the messy innards of Enterprise IT is now available at a whole meta-level. Did you get that? Enterprise Blockchain is a Meta-ERP system for business networks, but decentralized to solve trust issues created by centralization!!

Here are some good follow up questions: why didn’t 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 business networks of enterprises that may not exist.
• 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 those in the final act, and also in part 2 and 1.

Next question: when and where to use Blockchain? There are couple of ways to answer that, and the most common involves a flow chart diagram with branching decisions, that portends to clarify the validation. It is basically business case validation via a Galton Board (that looks like a pachinko machine). I don’t like them as they lack nuances, and only work for simple cases.

Instead of doing this, let’s do something else. This is the opening for Act 3!

Act 3 Use Cases for Business Network 2.0

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.  Database/ERP/ESB systems can do a much better work for a single Enterprise.

There is an exception: 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.

With clarification out of the way, the type of use cases worth considering involve a bit of “coopetition” (that is one strange word!), to solve industry wide problems and revenue drains. The uses cases best suited for the technology resemble supply chains in one way or another, and do not have to be about physical items but digital ones as well.

These are the types of challenges that impact whole industry verticals, resulting in inefficiencies and constraints for all included. 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 drudgery.
• A thriving body of mediators and middle-man with low value-adds.
• Excruciating supply chain issues which makes it hard to locate something in space and time.
• Troublesome dispute resolutions with the third parties that lack accountability or transparency.

On the flip-side, there are Gains in the new and improved business models as a result of participation in Business Network 2.0! They include products or services which benefit from a single source of truth and transaction automation. Some Gains:

• Automated settlements via parametric transactions.
• Automated provenance and authenticity tracking.
• Very lean value chains, without those troublesome mediators.
• Pinpoint accuracy for supply chain and logistics. Hello, 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 that afflict 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 bigger teams.

This is the transformation:

At the extreme end of these gains is the “Decentralized Ecosystem” (remember that chart way up in the blog?). I will  discuss this in part 1 (the last part), as it requires special considerations and additional convincing. I am slow-boiling you with blockchain.  Here is a hint: decentralized ecosystem is a gigantic lego buildup of business processes across many industries.

Now we ready for the last act where I pour some cold water, to cool down the unbound optimism by adding some badly needed realism.

Act 4. Proceed with Caution

I am going to make the wild assumption that I have managed to infect you with blockchain fever. You are all ready and set to go with some of those use cases. You are even ogling your value chain, and giving an evil eye to the transaction mediators that have plagued you for ages.

Hold it! Wait for what’s coming next: an ice bucket.

First and foremost: doing some of that Coopetition will require creating a business entity to administer all that win-win goodness. Enter The Consortium, and a myriad of challenges that comes with it. The Consortium also plays a role in defining the Business Cases that will pay for all nice use cases, so let’s stay with the Use Cases for now. I will address Consortium in part 2.

My first ice bucket is this nice SWOT analysis done by Gartner more than a year ago, and which is still in good shape.

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

Under Weaknesses:

• Lack of ledger interoperability. It was actively discussed in 2018 but there is a  lot of room for improvement.
• Poor user experience. No kidding, as I still see some out there insisting blockchain has a user experience. It does as much as a database does, which is none!
• Governance: that’s the Consortium piece I am writing next.
• Smart Contracts: there is lot to be said about code that is neither smart nor a contract.
• Skill scarcity and costs: go and try to hire a Smart Contract developer – demand by far outpaces supply!
• Immature scalability: I would say unknown at this time. The largest blockchain network is tiny when compared to other transacting networks.
• Lack of trust on technology suppliers: It is mostly open source, but it can change without notice due to rapid feature evolution. Product roadmaps are just dreams in developers heads.

Under Threats:

• Technology failures: yep, it can happen. We are building rockets with rubber bands and plastic straws. It may not work as expected.
• Institutional adoption barriers: we are back into Consortium-land.
• Divergent blockchains. This is a cousin of “lack of ledger interoperability”.

Now I am going to add some of my own, which I will summarize: the Enterprise blockchain is just another IT system, and adoption will be as good or as bad as current IT practices. What it means is, if you are really bad at IT, chances are you will be really bad at blockchain too.

Let’s break this down a bit into some categories.

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 designs, 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. Again, easier said than done.

Technology Challenges

• Underestimating the complexity of integrating a node with backend systems.
• Internal reconciliation will not go away. You still have your own ledger.
• Investing in early technology which 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 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 (i.e. blessings, curses, etc.)
• Blockchain Technology does not consider data life cycle. Transactions are hard to delete or archive, without special arrangements..

And this is why I included that pyramid thing at the beginning, as a cautionary tale of what could happen with badly solutioned and implemented blockchains: Outdated and immutable structure. Centralized. Made up of useless blocks. Exposing data for ever. Read more about the curse of immutability in one of  my previous blog posts.

And now we are ready to drop the curtain, and finish this show.

The curtain drops. General advice.

So what are we to do with all that blockchain goodness and challenges? I will leave you with some general advice:

• Understand your place and value in others’ value chains. It is possible you could be the one to be disintermediated (a bit of self-reflection and introspection required).
• 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, products, for the era of programmable economy (smart contracts that is).
• Assume technology obsolescence will happen. Fast.
• Validate legal and regulatory impacts for the chosen use cases.
• Start to digitize paper records.That will come 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 some 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 (FOMO).
• Following the herd mentality.
• Trying to increase brand value by “doing blockchain”.
• Because some management consultant told you so.
• Thinking “decentralized” is inherently better than “centralized”, without considering what these actually mean for your business model.

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

• Why ‘Coopetition’ Must Become the Principle of Blockchain Culture
• Why Blockchain’s Future Demands More Coopetition
• ‘Coopetition’ the Biggest Obstacle to Blockchain Growth, Consulting Firm Says
• Gartner: The CIO’s Guide to Blockchain
• Gartner Survey Reveals the Scarcity of Current Blockchain Deployments
• The blockchain begins finding its way in the enterprise
• Forbes: Blockchain In Enterprises
• Forbes: Blockchain in Enterprises Part 2
• SAP: Blockchain Applications and Services
• Microsoft Azure: Blockchain Technology and Applications
• Oracle: Transforming the Enterprise with Oracle Blockchain Platform
• Amazon: Blockchain on AWS
• How ERP is incorporating Blockchain
• Infosys: Integrating Blockchain with ERP for a transparent supply chain (PDF)