Blockchain as an integration instrument

01/07/2018 00:00:00

Within this article, I will be showing a further point of view on the adoption of this technology in a different application model. I’m talking about its use as tracking and data auditing tool between heterogeneous systems.

Original article published on June 2018 on MokaByte, issue 240.

Blockchain as an integration instrument

In the previous articles we talked about the basics of the blockchain technology, implementing aspects and some potential application – as proof of concept.

I have two scenarios in mind: first, that of a single entity adopting several data acquisition systems, such as SCADA systems, or other IoT ones. The second scenario instead extends outside the single entity and involves several systems of different companies, or actors.

Is it possible to view the blockchain technology as an integration instrument of heterogeneous systems?

First scenario: single entity, multiple systems

Let’s start with the first scenario, by establishing the objective, which is the need for a tool that keeps track of surveys made by different PLC, SCADA or IoT systems.

Different systems, different manufacturers, differently organised data, which need several systems to be processed, and which are often unable to aggregate information in order to have a general view. And they may also be systems with limited memory capacity for information storage.

Why use blockchain in such a context?

The possibility to gather data from several systems into a single container such as blockchain, could give an important visibility to the collected data:

The gathered information cannot be manipulated once saved within the system;
The history of data storage would be guaranteed by the blockchain transaction history;
Data could be analysed and compared with production data (ERP);
Data could be analysed with largely available tools (such as Python scripts for instance but also more complex data processing technological infrastructures).

For what reason would a structure ask its providers to make changes so that their data are saved within a blockchain (too)? There can be various reasons, but the first ones that come to mind are quality control, or compliance with regulations such as GMP (Good Manufacturing Practices) for instance, which regulates manufacturing practices of materials and objects which are going to come into contact with food products.

Picture 1 – Blockchain Integration: timeline.

Second scenario: multiple entities

The second scenario is slightly more articulated, as it requires the involvement of multiple actors in the implementation. In the suggested scenario, every company represents a node within the blockchain network, and each company has a different ERP system (you can choose the ERP names randomly).

Within an industry with a heavily regulated supply chain – such as the pharmaceutical one, for instance –, the manufacturer of a system may want to keep the path and history of each product under control.

I can imagine the following actors in this scenario:

Manufacturer, of electronic devices for instance
Courier A
Distributor
Courier B
Retailer
Customer

We have six different actors, five of which have different management systems, with different purposes and functions.

The elements of the process

In an ideal scenario, the “manufacturer” is the only one capable of adding the product within the distributed database and will therefore add it with a number of unique characteristics, such as the SKU and the serial number (SN).

The data saved within the blockchain, distributed among all actors, will inform the whole network – therefore the whole “ecosystem” of the application – about the existence of a new product and everyone will know that it is available at the manufacturer, because the information also includes its location.

Then, “Courier A” will now get the product from the “Manufacturer”. The ERP system of the courier will be capable of verifying whether that said product (SKU/SN) is really located at the manufacturer’s and take the product. Naturally, when the courier has taken a hold of this product, its ERP will take care of writing an update within the blockchain indicating that the product is in the courier’s hands.

The process continues until the product reaches the Retailer, which will register the exit of the products once it is sold. Of course, the end customer will be able to verify product identity and guarantee at any moment thanks to the information saved within the blockchain.

Picture 2 – Blockchain Integration: multivendor.

What are the advantages?

Where is the news in this? So far, the retail process has (and will still) worked without an integration of this sort, right? Yet this solution has advantages that are not to be underestimated.

Let’s begin from traceability and verifiability, which are very important points to help reduce the risk of theft or forgery. If only the manufacturer were able to create the “digital asset”, no other element in the supply chain would accept a product that in nonexistent or with a different serial number.

Through the use of a blockchain network shared between multiple actors, the single ERP could access essential information (in the form of metadata) without having to create complex systems of data exchange or ETL with third-party systems. Plus, making different information systems in contact could be an insurmountable problem.

In the two proposed scenarios, a solution based on a read-only distributed database would strongly enhance what is called the “accountability” of the involved parties. This doesn’t necessarily represent a system that can be used to “blame” someone, but rather to identify issues within processes and making it easier to solve them.

Another advantage that should not be underestimated is the possibility to reconstruct or verify the veracity of the data in case of alterations of the single actors’ databanks. Alterations that may be consequences of data tampering – be it intentional or unintentional –, loss of the data due to ransomware for instance, as has happened in several occasions, or during data migration.

Even if a copy of the blockchain database went fully destroyed (in case of a disaster, for instance), it would be possible to recreate the lost copy by reinserting a new node within the blockhain network (disaster recovery).

Last but not least, the event history would be recorded by an outside independent mechanism, the blockchain nodes.

The challenge

The complexity of such an implementation is defining a data template to store within the blockchain database that is intelligibile and interchangeable between the various systems.

The advantage of having an instrument that is accessible through standard market calls (HTTP and JSON-RPC) makes the process of dialogue and integration a lot less expensive than the development of a technology or a proprietary protocol.

This allows software houses and system integrators to fully forget the issue of data transport and sharing and focus only on the (meta)data to save within the database. The subsystem will work out the rest.

The challenge then becomes establishing a data exchange template that can allow different companies to interchange information. How? It’s a subject we’ll talk about in a more practical way in an upcoming article.