Over time, companies and the systems they use become increasingly integrated, forming special industry-based trust-free networks, and the blockchain technology is at the heart of this evolutionary step.
Large organizations use a large number of applications that operate in different departments and are used to exchange data and functionality in order to ensure a unified and consistent way of working. The process of communicating such applications within the same organization is called Enterprise Application Integration (EAI).
Similarly, companies need to pass on information to each other. They need to integrate and automate core business processes that go beyond the same organization. This process is an extension of EAI and is achieved by exchanging structured messages using a common message standard called corporate or B2B integration.
In fact, both terms describe the process of data integration and functionality that systems or participants exchange among themselves. And as the systems and business processes in organizations evolve, the technology underlying the B2B associations also changes.
Every year, some kind of integration technology becomes mainstream. Technologies gradually evolve and build on each other. However, instead of examining individual technologies by year, we will try to track the progress of their development over the decades and understand why the next step in technology can be the blockchain.
Consider the main technological breakthroughs at each stage of evolution listed in the table above.
This is one of the earliest mechanisms for accessing information by different systems, the most prominent examples of which are:
- Unified database – used to integrate systems within organizations;
- File sharing – used to exchange information within and between organizations. The use of universal file transfer protocols like FTP allows application data to be exchanged between computers and operating systems.
Both of these approaches are not real-time, package-based and have limitations in terms of scalability and reliability.
Integration Of Functionality
Unlike data integration, the following methods provide for the exchange of data and functionality in real time:
- Remote procedure call has a significant advantage over socket-based integration, hiding the complexity of network configuration and data marshaling. However, this method is an early generation point-to-point client-server architecture, dependent on a programming language.
- The Object Request Broker (with CORBA, DCOM, RMI implementations) is a broker component that allows multiple applications in different languages to reuse the same infrastructure and interact with each other in a peer-to-peer manner.
- Messaging is a temporary interchange between applications and provides guaranteed delivery of asynchronous messages.
All of the above optimizations are focused mainly on system integration. From packets to real-time data exchange, from point-to-point to peer-to-peer architecture, from synchronicity to asynchrony — all of these methods do not control what type of data they produce and do not verify them. On the other hand, this early infrastructure already provided B2B integration, but it did not understand either the data or the business process of which it was a part.
Service Oriented Architecture (SOA)
The main aspects of SOA related to our task are web service standards that use XML, SOAP, and WSDL formats. These standards in combination with the implementations of the ESB (enterprise service bus) and BPM (business process management) force integration to focus on the semantics of business integration, while earlier technologies mainly ensured the integration of systems.
Web services allow systems to exchange data not blindly, but to use computer-readable contracts and interface definitions. Such contracts will allow the system to understand and confirm data before interacting with another system.
You can also include the microservice architecture in this group, since, in essence, it creates and enhances SOA and ESB architectures.
It is at this stage that distributed systems receive common standards and definitions of contracts.
Although data sharing in common protocols and standards is a positive thing, service contracts do not give an idea of business processes hiding behind contracts and operating in remote systems.
Sometimes there are several parties involved in a single business process, each of whom owns the process. The prospect for the good functioning of such multilateral interaction lies in the transparency of the overall process and its current state. All this can provide technology blockchain.
This model extends the use of common protocols and service contracts to a common business process. In the blockchain, all participants work with one business process in the form of smart contracts. However, in order to confirm requests and arrive at a common result, business processes need a common state, and this is achieved using a distributed registry.
In this regard, the blockchain can be considered as the next step in the evolution of integrations. Blockchain networks act as distributed ESB and BPM concepts, not operating within a single organization, but between several companies.
First, protocols (for example, FTP), then API contracts (WSDL, SOAP), and now the business processes themselves (smart contracts) and their data extend beyond the organizations, into a common space, and become part of the integration infrastructure.
Using the blockchain, the models of common data and business processes are moved to common corporate networks. It should be noted that this step is not suitable for all companies without exception and is unlikely to enter the mainstream. It is possible only if all network participants have the same understanding of data models and business processes. Thus, this solution can only be applied in certain industries where processes can be standardized, for example, it can be finance, supply chains, health care.
Generations Of Integrations
Let us consider in more detail the evolution of B2B integration and its main stages.
First generation: Systems integration protocols
This generation of integration technology precedes CORBA and SOA and mainly provides data exchange in common protocols, but without an understanding of data, contracts, and business processes:
- Integration model: client-server, when the server component is controlled by one participant; For example, databases, file servers, message brokers.
- Explicit common infrastructure: low-level system protocols and application programming APIs, such as FTP.
- Implicit, non-shared infrastructure: application contracts, data formats, and business processes are not part of the overall integration infrastructure.
Second generation: Application integration contracts
This generation of integration technology uses a system of protocols from previous years and allows applications to share APIs in the form of universal contracts. This is the next level of integration, when both applications understand the data, their structure, conditions for possible errors, but do not understand business processes and their current state in other systems:
- Integration model: client-server model with API, described by contracts.
- Explicit common infrastructure: protocols, application contracts and API definitions.
- Implicit, non-shared infrastructure: business processes and remote state are closed.
Third generation: Distributed business processes
The blockchain-based generation, which has yet to prove itself as a reliable corporate architect, goes one step further. It uses a peer-to-peer protocol and provides access to business processes and the state of several systems controlled by participants who do not rely on each other. If previous generations of integrations required an understanding of the protocol or API, this generation relies on a general understanding of the overall business process and its current state. Only in this case it makes sense and performs the function of a distributed network of a business process between organizations:
- Integration model: multilateral, peer-to-peer integration, based on the formation of corporate networks with distributed business processes.
- Explicit common infrastructure: business process and its desired state.
- Implicit, non-shared infrastructure: a different non-process state.
There are many blockchain projects that use different approaches to solve business integration problems. Let us take as an example a few of the most popular and interesting open source projects focused on B2B integration space …
- Hyperledger Fabric is one of the most popular and advanced blockchain projects. It was originally developed by IBM, and now belongs to the Linux Foundation.
- – Hyperledger Sawtooth is another distributed project of the Linux Foundation, developed by Intel. It is popular for its modularity and complete interchangeability of components.
- Quorum is a corporate project based on the Ethereum blockchain.
- Corda – the project was created on top of existing cross-platform JVM-based technologies (Java Virtual Machine) and allows organizations to interact with contracts and exchange rates.
At the moment, there are quite a lot of corporate networks based on the above projects, and all of them allow participating organizations to interact with each other using a new integration model.
In addition to fully blockchain-based projects, there are also hybrid solutions. For example, Unibright is a project aimed at integrating internal business processes that use familiar standards like BPMN with blockchain networks through the automatic generation of smart contracts. Smart contracts can be created for public or private blockchains, which can act as another integration framework among organizations.
Recently, we have seen a large number of blockchain experiments in various areas of life. And if public (open) blockchains attract attention, promising to change the world, then closed and trusted blockchains promise less, but they are confidently moving forward.
Corporate integration has a number of nuances. Integration problems within one organization, where all systems are controlled by one company, and participants have a certain degree of trust in relation to each other, are most often solved with the help of modern ESB, BPM and micro services architectures. However, in the case of multilateral B2B integration, additional problems arise. Such systems are controlled by several organizations, do not provide transparency and do not trust each other. In this case, we see organizations experimenting with blockchain-based technology, relying not only on the sharing of protocols and contracts, but also on business processes and state.
This trend coincides with the general direction in which integration is developing: from sharing minimal protocols to general contracts, APIs and, finally, business processes.
This collaborative integration framework offers new transparent integration models in which private business processes are transformed into a shared, consistent open source interaction model. This can motivate organizations to share business processes and form networks, taking full advantage of collaborative innovation, standardization, and deeper integration.