Blockchain: Hype or Necessity?

ICOs, tokens and cryptocurrency – you can’t help but to see those words in all technical news feeds today. The hype has enabled individuals and companies to make millions on just ideas alone. Write a paper about your coin, put it in an Initial Coin Offering and you can have all the success without producing anything. You blinked, and it’s no longer that easy. Everyone is in on it it seems. All hungry investors that want in on the action will now have their money spread across a lot of players. So what’s the real work look like if you are to have success?

At the Moment, Software Development Industry is Ill-Equipped for Blockchain

Let’s zoom in from the perspective of an interesting bit of recent history: Robert, our CTO, and I headed into the blockathon (a blockchain themed hackathon) at the University of British Columbia a few weeks ago. The problem to study was disclosed a couple of days earlier by the organizers so that people could prepare and even assemble teams ahead of time. We went in cold with no such preparation. With one exception, we had never met the other participants of the team we were assigned to.  Of the seven of us, only three were developers. And yet – we walked away with 1st prize: “… they did a really good job of addressing the use case pain points, and demonstrated in a very granular way how certain transactions could be carried out. They really gave the judges confidence that, with a little more time, they could develop a workable solution.”

How did this happen?

Most That Think They Need It Don’t

It’s easy to get distracted by blockchain technological complexities instead of focusing on building better system. In the context of blockchain, a “better system” tends to come down to having a really nice audit trail so that what you put in the chain actually makes sense. What it took to make this happen and get it done fast enough to win the hackathon was to have an architecture that made use of a stream of business events – data and behaviour immortalised in an append only data store. Whether the data store’s guarantee of not having been tampered with was provided by a central entity’s asymmetric key or distributed in blockchain was a secondary concern.

What needed to be put in the blockchain was a subset of the events in the overall event stream for the entire system. This is important as the expense of putting something on the blockchain can be high – store what needs to be verified, keep all else off-chain. This is why putting events into a blockchain in an CQRS based system can simply be a read model which subscribes to all events which need to be on the chain and puts them there when they occur. CQRS stands for  “Command Query Responsibility Segregation”, also known as “build separate systems for what you want to do vs. what you want to show”. It leads to smaller subsystems which are much easier to build in parallel without incurring coordination overhead, a crucial advantage when trying to win a hackathon. We first gathered the requirements in the form of what the business event stream must look like in order to measure success. Here you can see us (team “Consentaur”) using Event Storming to drive out requirements for a system that lets users grant consent to organisations for the use of their medical data.

What You Want to Do vs What You Want to Show

Actions leave evidence by changing state. This evidence must be captured in a separate system that must only do that and do that very well. Anything else that needs to be built to make your solution run is implemented in a separate system.

At Adaptech we have a PaaS for CQRS and Event Sourcing solutions. Part of that will be an add-on component for putting all or part of the event stream for a solution on a blockchain. The key to winning the competition was to be on the same page about what would be in the event stream and not just the block chain. This spelled out the system to build, regardless if blockchain was going to be used or not.

From the stream of events, the screens and what they would show were planned. As well, the commands that were going to end up generating the events were derived. These artefacts presented the requirements very clearly, making it possible for the business people on the team to create a great presentation, completely aligned with the code demo. That demo was a happy path implementation of the API, generated with an alpha version of the Adaptech Event Sourcing Platform tooling. Given the time pressure, lack of familiarity with the business problem at hand and the fact that the “team” had only just met, the event stream based approach truly enabled us to deliver.

Conclusion

While it would be a mistake to ignore the amount of innovation that is going on in and around blockchain technologies, it would also be unwise to start implementing a blockchain solution without first studying the problem space you are trying to solve. For most, the solution is something that the blockchain helped to uncover and not the blockchain itself – deriving the events you must save as the source of truth. Blockchain is about making history tamper proof. History is a record of events which happened in the past. It seems reasonable to conclude that the most direct way to a good blockchain application is to design it as such from the ground up.

With that – thank you all, Team “Consentaur”, that was fun!  Everything came together without a hitch, a wonderful presentation followed by a good demo, last-minute but just-so! Left to right: Poya Farighi, Adam Dymitruk, Manan Mehta, Jose Pinzon, Usman Mukaty, Robert Reppel (not pictured: Omar Aldrobi).

Comments are closed, but trackbacks and pingbacks are open.

Top