Five blockchain development challenges for legacy organisations

Working on a development team delivering something innovative within a traditional, leviathan company is a special kind of hell. I know this deeply, intimately and personally from the 11 years I spent on the digital news team on one of the UK’s major newspapers.

These days, I look at the daily pile-up of press releases from the world’s largest banks and financial service companies, all professing their sudden commitment to developing this, that and the other “on the blockchain” (which may or may not be a permissioned ledger rather than an actual blockchain — but that’s another story), and my heart sinks at the sheer mismatch of culture and expectations that is about to be unleashed as products developed in the hothouse environment of corporate Innovation Labs are submitted further up the food chain for approval and sign-off.

Don’t get me wrong — there are some great examples of people within legacy companies who just “get it” and who will force through the necessary change to allow their teams to compete in a changing world, but for every one of these, there are 49 or 99 who don’t understand the technology, are divorced from the everyday activities of their development teams and — most importantly — can’t envisage software that exists and runs outside the familiar walled garden model.

For those hapless developers, project managers and product owners working on blockchain solutions within banks or finance houses, here’s a clue: if your employer or client has an Innovation Lab, what does it say about the rest of the organisation?

And, for those strategists, blue-sky thinkers, CIOs and other executives who are slapping each other on the back for having assembled your blockchain teams and sent out the press releases, here’s a short list of five overarching themes to be considered:

1. Waterfall is not an option
   The glacial pace of one-year, two-year or even five-year plans, with scheduled work packages and fixed release dates is not even a 1% possibility if you’re developing on top of a pre-existing decentralised blockchain such as Bitcoin or Ethereum. Even Agile teams working in the shortest of development cycles will be lucky to get to the end of a sprint without something happening that might change the fundamentals of what they’re doing. An Agile/Lean approach with a rapid release cycle and immediate validation is the only way to approach a challenge like this. Even if you’re developing your own private blockchain solution, the facts on the ground are changing every day, and the best-honed project plan in the world is going to come unstuck very quickly if you’re not able to flex and pivot.
2. People will dispute whether your permissioned ledger is actually a blockchain
   OK, so you’ve thought about the architecture of your slightly distributed ledger, which is either private within your organisation or else shared among a few similar companies. Your press office proudly announces to the waiting world that your blockchain development team is working on a revolutionary product. And what happens? The kind of people who are active in the community around decentralised blockchains are not grateful that you are giving their idea publicity by taking some bits of it and turning it into a not-very-good vaguely distributed ledger and calling it a blockchain. They won’t get angry about it. They’ll just laugh at you. And they will probably be right.
3. Blockchains are not magic
   Blockchain maximalists claim there is nothing in the world that can’t be put on a blockchain. This may be true in theory, but the big question should be whether anything is to be gained by doing this. What if a traditional database would do the job better? Before specifying the solution, ask yourself which problem you are trying to solve. If it is not a problem that involves trust, consensus, immutability or an intersection of the three, then you probably don’t need blockchain in the mix. Blockchains are kind of magic in that they make us think about what we should be doing, and what we should care about. But if your only aim is to keep doing all the bad or pointless things you are already doing, and expect to bolt on blockchain tech and have it solve all your problems, then you’re doing it wrong.
4. Think about compliance and data protection before you start
   I’ve heard stories of execs who are all for developing some kind of application on a pre-existing public blockchain… until the moment they realise it’s essentially an append-only ledger, and that’s when they start to panic. Once written to the blockchain, your data cannot be removed — only corrected by means of future entries — so you’d better make damn sure you and your compliance people are comfortable with this. If you’re planning to use the Bitcoin blockchain, for example, there’s no one to go crying to when and if things go wrong. Everyone within the Bitcoin community understands that the strength of a decentralised ledger derives from its lack of centralised governance — but try explaining that to your CIO when s/he is waving the risk register at you.
5. The rest of your organisation will not have a clue what you are doing
   Microsoft and IBM may be offering Blockchain As A Service, Accenture may have announced a blockchain division, but in the same way people on the newspaper I worked on were blissfully unaware the website even existed in the early days of our digital operation, there will be senior people in your organisation who still think you can only use Bitcoin to buy drugs and guns, and people in your retail division who will be busily closing the bank accounts of legitimate cryptocurrency businesses.

Disclaimer: This post comes with a healthy dose of tongue in cheek, and I’m sure it doesn’t apply to your own organisation…