What’s the Big Fuss About?

These days, Twitterverse is alive with discouraged blockchain consultants turned bitcoin maximalists eg Angus Champion de Crespigny and one of the originals of enterprise blockchain eg John Wolpert arguing that enterprise blockchain has very limited applicability if any and the future belongs to enterprises using public permissionless blockchains. Once you include Bitcoin maximalists and their years of “Bitcoin, not Blockchain” memes, it’s hard not to wonder if we have truly entered the trough of disillusionment when it comes to consortium networks using blockchain – or at least we have on twitter.

Delayed Gratification Is No Fun

This new wave of pessimism as arisen after about five years of people arguing that because of AML compliance, privacy, confidentiality, finality and yadi, yadi yada… public blockchains will never be used by enterprise. It turns out, public blockchains are being used by enterprise (occasionally) to issue bonds, tokenise assets and as an independent auditable third party database. Pundits are generally wrong about these things.

In some cases, the same people who believed in one or the other paradigm have crossed to the other side rather than crossing the chasm… so what does the future behold for blockchain technology? If you draw a 2 by 2, we have four possibilities – both are useful, neither is useful – or only one of the two. Which one is true?

My view is an empirical one and it depends – it always depends on what you’re trying to build and why. In some cases, a public blockchain enables the right pattern and in some cases a private/consortium blockchain does. Arguments about “why don’t you do the business case” on both sides of “private #blockchain is not useful” or “public #blockchain is not useful” are abstract, based on assumptions about the current state of the tech, theoretical and rather unprovable. In the end, we’re gonna have to build and show either way. What we do know that both types of blockchain solutions are barely 2 years old (in the enterprise) and the average exit cycle for ventures is 8yrs

So why are such smart people feeling the way they feel? I think both sides of (non) believers are arguing out of frustration with technology that’s still evolving. This is a natural consequence of expectations that are 2/5/10 years ahead of time depending on the application – rather than any basic flaws in the underlying tech or the need for the tech.

Surfing Surfing

I am kinda old – and I have always somehow ended up surfing on the leading edge of the waves in emerging tech. Before it was blockchain, for me, it was Big Data, J2EE, ESB, WS, CTM, Corba … … don’t ask.

Now what I do recall about big data is that it took 10 years for Hadoop to be made commercially useful outside Yahoo – or at least in a bank. Indeed, if Twitter was such a thing back then, Twitter debaters would have called all things big data useless too. As Jeff Garzik says, it’s the market that will decide, not thoughtleaders on crypto twitter.

Narrower and Deeper – like Always

My experience with blockchain technology is two dimensional. First, I find #blockchain becoming more and more useful i.e. the use cases are getting DEEPER. Secondly, I find it proving useful in a narrower and NARROWER set of use cases by the year. In 2015, everyone was reading Don s peak hype literature about how blockchain will feed the hungry and cure cancer – and indeed back then blockchain could be applied everywhere. In 2019 businesses are being much more selective and use cases less generic and more specialised. At the same time, budgets for the use cases that work are getting really big — and the ones that don’t — appropriately zero.

Where have I seen this before? Oh yes – we saw this with big data. In 2012 the bank I worked for wanted to replace much of Oracle, SQL Server and TeraData installs with Hadoop. By 2014 we had understood that that made absolutely no sense for structured data, that we did not have big data in most parts of the bank and there were deep killer apps in trading, risk and compliance. Exactly – the use cases had got narrower and more deep instead of “everything is big data” and “big data will make toast for you” – same as what I see with blockchain now, J2EE once upon a time, ESBs at another time, Component Transaction Monitors in a different era and so on so forth.

The Future Holds Promise, Not Guarantees

So does this mean Angus and John are all wrong and consortium blockchain will fulfil all the grand dreams laid out by thought leaders at Blockchain conferences? I surely have bet a material chunk of my tech career on it already but no, that’s not guaranteed at all.

Pattern Recognition

Consortium blockchain is an Enterprise Integration Pattern (EIP – not the same as Ethereum Improvement Proposal). EIPs are techniques for integrating systems to deliver business functionality. It’s gestalt – you can do more by combining systems than any system on its own. That happens within enterprise and across enterprises. In fact it always has. Companies in the past have shared data via Enterprise Service Buses to enable complex business flows, via Trade Information Warehouses to enable compliance, via messaging to enable trading and settlement and so on so forth. Consortium blockchains (which I call enterprise chains for now) are a relatively new EIP. Some say middleware … fine.

If you ever read “Design Patterns” by the Gang of Four… patterns are applicable in contexts. Consortium blockchains are also applicable in certain contexts and in many other contexts, more established patterns apply e.g. yeah – messaging etc. When should you apply this pattern of a cryptographically secure shared ledger? The short answer is… when a shared database or messaging are not adequate or desirable for the needs of network participants. If you can achieve the same result with a shared relational database, by all means don’t use a blockchain.

Yes, Sometimes It Takes Never

Now be careful – sometimes Enterprise integration patterns don’t find use anywhere near the expectations. A good example is web services. Back in 2002, I was a lead engineer in an R&D team at a supply chain tech company. At that point, Web Services were all the rage. The idea was that using xml based “api calls” discoverable using another xml based protocol “WSDL” you could orchestrate complex business workflows/processes within and across enterprises. Indeed, web services were all the rage. In parallel, the big buzzword was “Enterprise Service Bus” – basically messaging for orchestrating a bunch of business services into a business process. The latter saw some success, the former never quite did. Why? XML based invocation was too verbose and unwieldy for developers over HTTP and then there was never a security model that justified using “SOAP” to orchestrate a business process across multiple companies.

The SNUGGLE is Real

The reason I talk about web services so often is because the problem set is largely the same – “a trustable shared business process over disjoint datasets that span trust/legal entity boundaries”. The solution is new – use cryptography to create a distributed databases with time ordered data that non trusting counter parties in a business process can trust. Once you can trust shared data, it becomes possible to trust shared workflows because workflows are made of actions that update (in this case append) the database. If no one can change the database or code without agreement from the others and authorised parties can see who did what when, trust becomes a bit more possible. Does this mean parties in a “consortium” or a “shared business process/operating model” don’t need to sign a legal agreement agreeing to rely on the “shared ledger called blockchain” – nope. They still need a legal agreement but the risk goes down dramatically – and so does the need to call your lawyer and hit the court – which is what allows people to do business in a civilised society.

The need is also real

First of all, that it’s herculean effort to build a commercially viable solution across non trusting legal entities does not invalidate the need for such solutions or technology. A lot of challenges related to enterprise #blockchain have nothing to do with technology. Collaboration is hard. I know KYC utilities built on shared RDBMS that got nowhere. I know ESBs and Messaging based solutions that didn’t get anywhere. Enterprise technology is hard within one business. It’s supposed to be harder across many but that’s not because of the database – collaboration is hard for competing entities but often the value from collaboration is way too high – e.g. it’s better to trade than cheat. Yes, I am going to annoy you now by saying “Game Theory”.

Adoption Schmadoption

Then adoption is hard. Adoption is hard even for standalone mobile apps. Blockchain isn’t supposed to solve for adoption. Utility, Strategy, marketing, UX, pricing… these are the key variables. Adoption isn’t for blockchain, adoption is for solutions built on blockchain or well, even on paper. You gotta build stuff people want and will pay for. Blockchain (or SQL server) isn’t going to do adoption for you.

Moon or REKT for Enterprise Blockchain?

So will “enterprise” or “consortium” blockchain be like messaging – i.e. ubiquitous, or will it be like Web Services – i.e. extinct? My answer is – somewhere in the middle. For some applications and business networks, it will be the only way to operate and for many it will just be easier to replace a complex distributed database with a centralised database that is operated by a market operator – which is kinda how many markets work today. I could dream up complex math that cites variables like cost of reconciliation/cost of trust but this is not one of those see the future conferences and I am not predicting the future we don’t know about.

To Chain or Not to Chain?

For an enterprise architect, I have two recommendations.

1. Explore enterprise integration patterns alongside enterprise blockchain. If you can do it with a database or message bus better, by all means do it.

2. The second part is more interesting – if you do need a time ordered, cryptographically secure, append only, shared ledger - always deploy that enterprise chain on a cloud.

What? Isn’t that Centralised?

So what has changed between Web Services and now that’d allow consortium blockchains to work?

The answer is blindingly obviuous. The answer is cloud aka Blockchain as a Service. With a SaaS deployment of a consortium #blockchain solutions, the issues we couldn’t solve with web services become solvable. In fact first, the “who did what and when” nature of enterprise chains fixes what we couldn’t with web services or ESBs like webmethods. SaaS deployments like Kaleido take care of 80% of the pain of building, deploying and managing shared infra.

Now #crypto maximalists who love the “chancellor on the brink narrative” will tell you this “who is hosting your database” is a problem. It’s centralised. First of all, so what?Secondly – well it is and it is not. There are ways in which even #bitcoin is centralised – that’s why we have hard forks and FakeToshi.

On BAAS, logically, you run your own node – physically, you run it on better and more supportable infra than you were running before.

When in enterprise, eat the cake first, look at the wrapper later

I think all these “who’s hosting” arguments arise not because people are not comfortable with blockchain, but because people aren’t up to speed or comfort with cloud. The whole point is that you don’t have to worry about where the server is sitting or if there is actually a server. You just need the same or higher level of security, resilience and privacy than you had before you went to cloud – and tell ya what, not seen one bank with the same level of IT security and resilience as AWS or Azure or Bluemix – just not seen one, nope.

Without cloud, enterprise blockchain possibly couldn’t work. If you have to poke inside multiple enterprise firewalls with their own IT staff of varied quality to maintain shared infra, such a solution is DOA. Dead on arrival for enterprise. Just don’t bother. I know at least one trade finance project on a java based ledger that’s suffering from on-prem. In some cases, on-prem hosting of a node is necessary but it must be avoided for the day when the solution could actually succeed. By that day – every enterprise would have moved to cloud anyways. The economics is way to compelling and the capabilities are at a whole other level.

#Blockchain on cloud leverages established patterns for security, business continuity and resilience. This solves the bulk of the issues we couldn’t solve with web services or webmethods style infra. Other enterprise problems still remain eg data migration, upgrades and fixes, on-prem deployment and governance. All are solvable with the right tools and patterns which have come along over the last year at pace.

With big tech rolling into the space, these tools will mature and be standardised within a year or two at best. We will see big fat books written like CCNA certification, O Reilly’s Hadoop Operations, MSFT Blockchain certification and 100s of thousands of engineers will reading, copying and pasting exactly what needs to be done – and not figuring it out as they go along.

Great Enterprise Tech is Really Boring

Enterprise is good when its boring. If it’s the play of heroic engineers, its not quite there yet. Great enterprise engineers find their deep pleasures in boring and proven – since forever. That’s why they say things like “Give me the functionals and the non functionals” rather than “I am using Blockchain or AI or … “

Blockchain will have arrived when it becomes boring and nothing newsworthy. When people fail to mention blockchain in a press release, they have probably built something great.

My dreams are made of waking up and realising its become too boring and I need to find new problems but we still have work to do to get to boring.

So I am Wright and They are Wrong?

Of course – nah, just joking. It depends – on the context. Use the right pattern for the right context. That’s the mother statement of all enterprise architecture All enterprise architects I know have preferences and comfort with what’s worked for them in the past but the good ones choose what works in the long haul.

So what’s my answer to Angus Champion and John Wolpert? It’s actually quite simple – there are many contexts where new value i.e. revenue or efficiency for enterprise customers can be created by building auditable workflows on a shared database among non trusting legal entities. This type of opportunity appears within and across industries.

If you can do that with a shared database or messaging or something else, go do it. If not leave me alone to do it with enterprise #blockchain on cloud.

What Next?

A shared, trusted distributed database across entities that do not trust each other.. now what applications can one build on that? Many… we don’t know all of these yet but I know there are many we are already building and many we and others have already built. Now give them five years to succeed or fail as platforms and businesses – then we shall talk.