Publish and Protect – Event Driven Enterprise Blockchain

Have you ever wondered what happened to enterprise blockchain? Once touted as the solution to everything from tracking tomatoes to fixing finance, it has seemed to fail – a victim of misapplication, complexity, and its seeming incompatibility with evolving technologies like event-driven architecture and event-driven integration.

Its potential is real, though: enterprise blockchain can solve the problem of trust between parties by creating an immutable record of transactions. The fact that “whatever’s on the ‘chain, stays on the chain” makes fraud almost impossible, and renders disputes a thing of the past – data is protected.

To do so in real applications, though, enterprise blockchain solutions must be simple, scalable, robust, widely deployable, economical, and integrated into an organisation’s IT landscape.

There is no one single solution to all this. Enterprise blockchain’s immutability and security comes at a cost in terms of scalability and performance, so it must be judiciously applied. Since we’re dealing with both operational and transactional data, it must be carefully integrated into other operational and transactional systems – the protected data needs to be published.

That’s why atkrpyto and Solace have teamed up to create architectural principles and a reference architecture for “protect and publish” – protecting important multi-party data while publishing it to operational and transactional systems.

In this article we will outline what enterprise blockchain is, how it works, and how it should be applied. we’ll then look at how it can be integrated into enterprise IT in a scalable, decoupled manner using event-driven techniques, drawing this together to outline our architectural principles and how we created a reference architecture.

In the beginning

The reason we started this work can be summed up by a conversation we had when we first met:

“I had some transactions that I needed to share with another company that were held in SAP,” Andy Silvey, CEO of atkrypto, said, “So it seemed natural to use an enterprise blockchain. But all the solutions I could find were complex, fragmented and difficult to use. They lacked business focus and there was no easy way to integrate them with SAP and other systems I used.”

Andy found this frustrating and that was the start of our conversations. We thought that by automating the reconciliation and resolution of disputes between two or more parties, enterprise blockchain has the potential to save costs, enable new business processes and automate manual processes, and simplify existing complex IT solutions. A good example is asset tracking, where ownership can be tracked throughout the entire lifetime of the asset.

When we first met, Andy and I sat down to formulate some architectural principles underpinning any solution before we felt it would be acceptable to architects, developers and business users. It should be:

• Complete from source of data (IoT sensor, corporate database) to its destination;
• Deployable anywhere (IoT edge, on premise, in cloud);
• Flexible (allowing private, public, consortia or hybrid chains);
• Decoupled but integrated into current and future technologies and systems in use;
• Scalable and robust – hence Event Driven.

Why Publish and Protect?

On the face of it, you might perhaps understand why you’d want to protect data. In this context, protection doesn’t necessarily mean “protection from unauthorized access” (although that is very much a concern), the focus is more on “protection from unauthorized modification and/or fraud.”

But why publish and protect?  A complete enterprise blockchain solution must go all the way from source to destination, and this extends from the enterprise blockchain ledger itself right through to the enterprise systems the ledger must integrate with. The traditional way to do this was with message orientated middleware, but increasingly event-driven approaches are being used for their scalability, decoupling and agility. By combining a full enterprise blockchain ledger solution with an event-driven integration platform, data is not only protected, but it can be distributed and integrated too – hence publish and protect.

Events and Publishing

What is all this “publishing” and “events” then?  Well, there are plenty of materials online outlining the hows and whys of event-driven systems, so we’ll summarise by saying that rather than focusing on commands or processes that are executed, or units of data such as a batch, event-driven approaches take a change in something in the business and use that as the unit of processing.

It is the responsibility of the applications that need to be told about a change to register their interest in this change, and the application that has the change to tell all that care that the change has occurred – publishing the event. Those interested in the change register their interest by subscribing to it – publish/subscribe. In practice, an event broker is needed to intermediate this exchange, such as Solace’s PubSub+ Event Broker.

An example of this might be a customer placing an order. Say the customer is a manufacturer and the order is for the responsible disposal of a by-product. We can say the placing of the order is an event, and should be processed at that point.

We can also trace this backwards – the completion of a manufacturing job created the by-product, so the completion of the manufacturing job is also an event, which triggers the order for disposal event. Notice, though, that the manufacturing application generating the job complete event has no knowledge of the disposal order event or how it’s generated. The manufacturing system publishes the job complete event, which the disposal management system subscribes to and then publishes the disposal order event. This is the key to the idea of decoupling in event-driven integration – you can swap out the disposal order system for a different one without the manufacturing system even knowing.

Taking this further, you can view integration challenges as a need for a change in one application requiring action from other applications – this is event-driven integration. In our by-product disposal example, we may need to prove to an external authority or auditor that we have, in fact, correctly disposed of the by-product, so we need an audit trail of certain events relating to the disposal: we don’t particularly care about the disposal order being placed, but we do care about the manufacturing job creating the by-product and the end result of the disposal order being the disposal occurring.

We need a way to persist these events and protect them from tampering. The simplest way to do this is to have an enterprise blockchain solution store these events in its tamper proof ledger: our enterprise blockchain becomes a subscriber to business events.

Event Sorcery

A common implementation of the event source pattern is to have a distributed immutable log storing all state transitions, and to rebuild current application state by replaying the state transitions. Surely this is the solution to publish and protect?

Well, no. This approach doesn’t solve the trust issue: would you replicate your log-based event streaming solution to an untrusted third party? Thought not. Log based streaming solutions also assume that replicas are generally on-line and up to date, which is not a good assumption in cross-organisational scenarios. Lastly, the log is only immutable in log-based streaming because there is no facility within the platform to edit the logs. Anyone with a binary editor can change the data and there is no detection of this or validation of data integrity. For that, you need an enterprise blockchain.

Making a hash of it: Enterprise Blockchain Protection

We’ve mentioned enterprise blockchain protecting data, but how does this actually work? Again, there are numerous detailed descriptions online [SAP What is Blockchain Technology], so this is a very quick primer.

A ledger is simply a list of related transactions. If you store this ledger in multiple places, you get a distributed ledger. You’ll have to deal with what happens when one part of the ledger gets out of sync or disagrees with other parts – usually with consensus mechanisms and the like.

Now, you can take a batch of transactions of a fixed size (a “block”) and run a cryptographic algorithm called a hash that generates a unique number based on the contents of the block. You then place this as the first item in the next block. In this way you form a chain of blocks – hence enterprise blockchain.

The power is that you can re-calculate the hash of the blocks, and compare them to the backwards facing entries in the next block. If there are any discrepancies, know the data has been tampered with – and this is what gives enterprise blockchain its ability to protect data – once the blocks are written, there is no way to change them without breaking the chain.

Solace and atkrypto – Protect and Publish

The combination of enterprise blockchain and event-driven integration gives you the benefits of an immutable, distributed ledger while providing the mechanism to integrate with existing and future enterprise systems.

The atkrypto.io enterprise blockchain platform is unique because it is the only distributed ledger technology (DLT) where the enterprise blockchain software can run at the edge/mobile. It has a light version for edge and IoT devices, and a datacenter version for cloud and on-premises applications. This means the same enterprise blockchain can have nodes or instances of enterprise blockchain running at the edge, perhaps the source of the data, and also in the datacenter. This provides a data backbone from the edge to insights.

This enables atkrypto software to run side by side with Solace PubSub+ event brokers and consequently enables information to be stored in the enterprise blockchain as close to the source of the information as possible.

Solace, meanwhile, provides the most complete publish/subscribe event-driven integration platform, combining an event broker, event-based connectors, and an event-based design and governance platform. It’s the simplest, most reliable enterprise event-driven integration platform, enabling it to act as the glue that bonds enterprise IT to atkrypto’s enterprise blockchain.

We have created a reference architecture, using the SAP ecosystem as an example, that shows how enterprise applications can be integrated with enterprise blockchain using an event-driven integration approach:

McKinsey & Company’s view, “Enterprise blockchain is a secure database shared across a network of participants, where up-to-date information is available to all participants at the same time.”.

If you want to talk about opportunities, use cases, or are just curious about the enormous potential in general for the combination of these two technologies, just reach out to us on LinkedIn: Tom Fairbairn and Andy Silvey.