10 years on, #Blockchain is ready for Business use... thanks to the #Hyperledger project!

Note: This isn’t a Bitcoin hedging post. In fact, that was the last occurrence of that word in this article.

Is the Blockchain hype over?

According to this year’s Gartner Hype Cycle, Blockchain has crossed the peak of unrealistic expectations and is now heading towards the trough of disillusionment. This usually means that we’ll stop hearing about Blockchain being the cure for world hunger, and instead will start hearing about real world case studies that demonstrate its use cases.

I tend to agree with Gartner’s prediction of Blockchain reaching the plateau of profitability, and therefore wider adoption in the enterprise within the next 5 years.

Gartner Hype Cycle for Emerging Technologies - July 2017

Blockchain for Business?

Fundamentally, Blockchain emerged from business principles that has been around since humans started trading with each other.

We have incrementally digitised parts of this process over the past century. However, this digitisation process is fragmented. Over time, each participating entity digitised their organisation according to the best architecture they saw fit at the time of digitisation.

This fragmented digitisation approach results in significant, but essential systems integration costs. Why? Because in a global economy, a business can not operate in a silo. Today's businesses interact with each other to build global supply chains to enable trade that deliver products and services to ever more demanding customers.

With businesses using computing as a mean to drive efficiency, a new market emerged for integration software and integrations service providers. That’s where we are today. I’m not going to speculate that Blockchain is ready to make all software integration obsolete. However, I can see a future where today's massive costs of partner integration become less and less with the adoption of Blockchain in the enterprise.

 A short history of Ledgers ...

 Blockchain evolved leveraging a few fundamental business concepts.

1. Business Networks that connect Businesses together to help move
2. Assets that flow over these Business Networks via
3. Transactions that describe an Asset exchange between 
4. Participants in a Business Network, who must adhere to
5. Contracts that define the rules for these Transactions.
6. A Ledger maintains records of these transactions.

The most important item in the list above is the Ledger. It is the source of truth that records all transactions. This ledger is trusted by all participants, and is usually held centrally. Blockchain provided us a distributed ledger that is replicated and shared among all peers in a Business Network.

In the below video, we see a good example of how a Blockchain is being used in the real world. This particular example illustrates a Blockchain implementation by the diamond industry. This Business Network helps the industry prevent Blood Diamonds from entering the market using a distributed ledger.

What's the tipping point?

As a developer, I tend to accept technologies when I can start building prototypes with them. Because that’s the only way I can recommend these technologies to others.

The Linux Foundation announced the Hyperledger project back in December 2015. The foundation appointed Brian Behlendorf as executive director of the project in May 2016. Things were finally getting interesting… for developers.

I kept following the project through 2016 and 2017. However, there was no sign of the rapid prototyping experience I was hoping for.

Don’t get me wrong. The platform strategy was awesome. Hyperledger Fabric was shaping up to be an operating system for Blockchain implementations, abstracting out complexities involved in a blockchain software infrastructure. But there was a gap around rapid prototyping and R&D capability.

Then came Hyperledger Composer.

Hyperledger Composer

Here’s a good snapshot of Hyperledger Composer's value proposition, screen captured directly from the project’s GitHub pages at https://hyperledger.github.io/composer/index.html.

Hyperledger Composer - Project's value proposition.

With the announcement of Fabric Composer being incubated within the Hyperledger project, I finally started seeing some promising developer tools in the Hyperledger roadmap. The initial demonstrations were very promising. This was the missing piece of the puzzle in making blockchain prototyping fun and, most importantly,  Rapid.

Hyperledger Composer provided another layer of abstraction on top of Hyperledger Fabric, making sure that a developer will not have to waste time when helping the business take blockchain implementations to market.

In fast phased and Agile enterprise environments, this capability is a game changer.

Hyperledger Composer Provides a Layer of Abstraction on  Hyperledger Fabric.

What’s so special about Hyperledger Composer?

To me, the two important things that make the Hyperledger Composer framework stand out are its architecture and developer workflow model.

1. The architecture.

It’s always about the architecture, really. The Hyperledger Composer abstracts complexities of the Fabric from a developer.

While doing that, it also provides a REST API generator for a developer's Blockchain implementation. This REST endpoint can either serve as the starting point for a rich Front End application or it can be directly exposed via an API gateway to be consumed by anyone.

A typical architecture of  a web application developed with Hyperledger Composer.

2. Development workflow alignment with Continuous Delivery and DevOps. 

The modelling, access control and transaction language is simple and straightforward. A developer familiar with Javascript can pick it up easily.

Deployment is automated, while familiar Javascript testing frameworks are readily available with additional Hyperledger Composer specific libraries already present.

Exposing your business network as a REST API is expected (not an afterthought). And then there’s the Composer Playground, where you can test out the network by masquerading as different types of participant.

                       Model --> Access Control --> Deploy --> Test --> Integrate

 

Enough with the press. Prototype Please!

A prototype requires a use case, either hypothetical or real. The idea for a good prototyping project came to me while sharing the post below, on LinkedIn.

A viable use case for a Blockchain prototype.

I worked as a developer for a Loyalty Points Program here in Australia about 5 years ago. I noticed a similar use case mentioned in this LinkedIn article I was sharing with my network.  So this became the simple use case I used to prototype my Blockchain.

A Loyalty Points Business Network!

Participants, Assets and Transactions of our Loyalty Points Business Network.

I created that info-graphic to use as a good reference point throughout this post. But, before we dive into the technical aspects, let’s take a minute to look at what makes a Business Network of this nature successful. 

The participants of this network want different things from it. Members want to earn the most points possible in their transactions with the Partners. Partners want to attract the most amount of vendors to their stores. Remember? All points are a result of money spent with Partners. In this Free Market scenario, the value added to the Network by Partners, and the number of Partners in the Network will send the whole Loyalty Program to hyper-growth. 

Now comes the engineering challenge of integrating all these Partners together, and also on-boarding new Partners to feed growth. Today, every singe Partner on-boarding to the network will bring a Systems Integration challenge of its own. 

1. Systems Integration Hell - From RESTful API based integrations to SOAP to XML-RPC to (heaven forbid) Batch Files. 
2. The cost of Integration - Even if the Business Network's infrastructure provider has a decent integration strategy in place, every new Partner on-boarding will require a mini IT project.
3. Member (Customer) Experience - Based on the Partners choice of Integration interface, the Business Network’s Members will experience real-time points accumulation to - in cases where the Partner’s integration interface is a Batch File - waiting for days to see their points added to the Card. 
4. Scalability - Hyper-growth requires a rapidly scalable system. If you read and reflect on points 1 to 3, you’ll see that today’s Loyalty Rewards Network can not evolve into a hyper-growth scenario. That’s why we usually see today’s Loyalty Points Networks restricted to a small list of rewards Partners. Usually, these Partners have been with the Network for years and years. Members rarely see new Partner additions. Want to collect rewards points for your Uber journey? or your recent stay using AirBnB? Good Luck with that!!!!

The Anatomy of a Hyperledger Composer Blockchain Implementation.

The source code, and a brief walk through of my prototype is available in GitHub at https://github.com/tyrell/loyalty-points-network.

Essentially, the development workflow follows the one I mentioned earlier in this post.

                Model --> Access Control --> Deploy --> Test --> Integrate

1. Model

Hyperledger Composer comes with its own Data Modelling Language. It’s object oriented and also relational. You can study it in detail at https://hyperledger.github.io/composer/unstable/reference/cto_language.

The image below contains part of our Loyalty Business Network’s Data Model. I'm only including the Assets and Participants here for reference. The full Model Definition includes Transactions and Events as well.

You can find the full CTO file at https://github.com/tyrell/loyalty-points-network/blob/d92de024cb49b77ef7b20fcbfe231c78d674085a/models/loyalty.cto#L9-L54
 

The Data Model Definition for the Loyalty Points Network Prototype.

Although Transactions and Events are defined in the Data Model, They are implemented using Javascript logic. If you are a Node.js developer familiar with Promises, there is literally no learning curve involved.

The example below is the implementation I wrote for the IssuePoints Transaction. Note line 30, where I commit the updated points balance of the card and also line 33, where I emit the issuePointsEvent to the Business Network. Listeners can subscribe to this event to carry out additional logic and/or integration calls.

Source: https://github.com/tyrell/loyalty-points-network/blob/d92de024cb49b77ef7b20fcbfe231c78d674085a/lib/logic.js#L11-L36

The IssuePoints transaction implemented using Node.js

That pretty much covers the modelling part of a Business Network. Although this is a prototype, the same workflow pattern would be what a developer will follow to implement any other Business Network when using Hyperledger Composer.

2. Access Control

We have multiple types of participants in our Loyalty Points Network, each with different levels of access and permissions. Hyperledger Composer provides an access control definition language to manage these permissions.

The image below shows a few access control definitions for Participants and the Assets in our Business Network.

Source: 

https://github.com/tyrell/loyalty-points-network/blob/d92de024cb49b77ef7b20fcbfe231c78d674085a/permissions.acl#L7-L72

Access Control Definitions for the Loyalty Points Network.

3. Deploy

The key artefact for a deployment pipeline is a BNA archive. All the logic, model and permissions files get bundles into this archive to be deployed as a Business Network. Once a deployment is successful, chain code updates across network peers is taken care of by the Hyperledger infrastructure, no developer time required.

Have a look at the README at https://github.com/tyrell/loyalty-points-network/blob/master/README.md to understand the composer cli commands, for a manual deployment of our Loyalty Rewards Network. These commands will be scripted into a CI/CD pipeline in a real world scenario.

4. Test

This brings us to one of the best components of the Hyper Ledger ecosystem. I was able to get my Loyalty Network Prototype up and running within a few hours thanks to this. It’s called the Hyper Ledger Composer Playground.

Hyper Ledger Composer Playground is a browser based testing UI that allows a developer to create Participant instances and Asset instances for a Business Network. It also allows the creation of Identities and binding these identities to Participants. This capability allows developers to test the Access Control Permission and Transaction Logic from the UI.

In order to test my prototype, I had to connect to my (now deployed) Loyalty Rewards Business Network.

Connecting to the deployed Loyalty Points Network using Hyperledger Composer Playground.

Once connected, I was able to add Members, their Cards along with Partners and their Offers to my Network. Read https://github.com/tyrell/loyalty-points-network/blob/master/README.md to find the sample JSON payloads I used to create my test data.

I also associated my test Member and Partner with their own Identities. This eventually helped me test the Access Control rules I set for my Business Network earlier in my ACL file. (https://github.com/tyrell/loyalty-points-network/blob/master/permissions.acl)

Issuing an Identity to our Test Loyalty Card Member.

Issuing an Identity to our Test Rewards Partner.

Identities added to the Wallet and listed as ISSUED.

Just to cover all our bases, I would like to emphasise that automated tests can be written using Mocha. I have a Mocha compatible test file committed at https://github.com/tyrell/loyalty-points-network/blob/master/test/Points.js. Although the browser based Composer Playground is a great companion during development, it's the automated test suites that will help us scale.

5. Integrate

Once a Business Network is deployed, Hyperledger Composer provides a handy utility named composer-rest-server that generates a REST API for the new Business Network.

I will not go into too much detail about the API implementation and deployment patterns. Because API life cycling is not the focus of this article. Suffice to say that I would take this to market behind a good API Gateway. The image below is the API generated for our Loyalty Points Network.

Auto generated REST API with Documentation and Test support.

So what’s the end game?

I have illustrated a high level architecture diagram of a possible end state for our Loyalty Points Network.

This diagram contains 2 Partners working as Peers in our Business Network and each have their own Member facing applications. Each partner has access to a Partner Offer Management Application that allows them to manage their Loyalty Rewards Offers. 

Partner A uses a Cloud First deployment strategy, while Partner B has opted to deploy their Peer infrastructure on-premise. Either approach will work with Hyperledger Fabric.

High Level deployment architecture for our Loyalty Points Network.

Now that we are almost at the end of this post, let’s revisit the list of things we don’t like about today's implementation of the Loyalty Points Network. 

1. Systems Integration Hell - From RESTful API based integrations to SOAP to XML-RPC to (heaven forbid) Batch Files. 
2. The cost of Integration - Even if the Business Network's infrastructure provider has a decent integration strategy in place, every new Partner on-boarding will require a mini IT project.
3. Member (Customer) Experience - Based on the Partners choice of Integration interface, the Business Network’s Members will experience real-time points accumulation to - in cases where the Partner’s integration interface is a Batch File - waiting for days to see their points added to the Card. 
4. Scalability - Hyper-growth requires a rapidly scalable system. If you read and reflect on points 1 to 3, you’ll see that today’s Loyalty Rewards Network can not evolve into a hyper-growth scenario. That’s why we usually see today’s Loyalty Points Networks restricted to a small list of rewards Partners. Usually, these Partners have been with the Network for years and years. Members rarely see new Partner additions. Want to collect rewards points for your Uber journey? or your recent stay using Air BnB? Good Luck with that!!!!

In the new world, where the implementation is switched to our Blockchain, any existing or new Partner becomes a Peer of the Business Network. 

The composition of a Peer Node.

1. Reduced Integration Nightmares - As part of a new Partner on-boarding, a new Partner will deploy and run the Peer Infrastructure. The new Partner’s existing Applications and Systems will integrate with the Composer REST API to commit Points Issue/Redeem transactions to the Business Network (Committing Peer). This gives full control of the Integration to the Partner, who is an expert in their Systems Architecture. However, submitting these transactions to the network via the REST API, in real-time, will now be a non-functional requirement for the new Partner’s Member facing applications.
2. Reduced Cost of Integration - Costs will be largely driven by the Infrastructure deployment strategy, rather than System Integration. Although a Cloud First strategy will potentially reduce this cost significantly, even with an on-premise model, the initial CAPEX expenditure will be significantly lower in our new world.
3. Member (Customer) Experience - Thanks to distributed ledger transactions, our new Blockchain implementation will provide real-time updates to Member points. Any transaction submitted to the Hyperledger Business Network will result in Consensus being requested from all Peers and an update to the Ledger and World State.
4. Scalability - The Peer-to-Peer nature of our new Loyalty Points Network makes it massively scalable. On-boarding new Partners to the Network is fast and seamless. The new Partners  will just deploy a Peer node and register to access the Business Network. Because a Partner controls their Member facing application, they can opt to stick to their current user base and gradually scale their Applications to all Members (In consumer Application development, this is considered as a “good problem to have” anyway).

A general architectural overview of Hyperledger Fabric can be found at https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html 

Final Thoughts

The main reason I wrote this post, was to mark this point in time in the evolution of Blockchain and the Hyperledger project.

From a technology point of view, today we have a few vendor offerings of Blockchain as a Service built on Hyperledger Fabric. With increasing vendor interest in joining the foundation and contributing, the amount of offerings will also increase. This is great news for Cloud First developers.

From a business point of view, some businesses that can benefit the most from Blockchain are also ones that are most regulated. Stock Exchanges and Banks are typical examples. For these businesses, Hyperledger makes solving the technology challenge the easiest part of the journey towards adoption.

Hyperledger will help a number of other Integration use cases as well. For example, have a look at Indy (https://www.hyperledger.org/projects/hyperledger-indy), another promising Hyperledger project, specifically targeting Decentralised Identity.

Hyperledger then, is a Greenhouse providing the Kernel and an ecosystem for Blockchain Projects to thrive. Just like Linux and GNU were in the early days of FOSS.

By the way .... The source code for my Loyalty Points Network prototype, discussed throughout this post can be found in GitHub at https://github.com/tyrell/loyalty-points-network. I hope it helps you start digging into Hyperledger Composer.

Thanks for reading!