Over time, companies and the systems they use have become increasingly integrated, forming specific industry distrust networks, and blockchain technology is at the heart of this evolutionary step.
CORPORATE INTEGRATION
Large organizations use a large number of applications that operate in different departments and are used to exchange data and functionality to ensure a unified and consistent way of working. The process of communication of such applications within one organization is called Corporate Application Integration (EAI).
Similarly, companies need to transfer information to each other. They need to integrate and automate the core business processes that go beyond a single 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.
Essentially, both terms describe the process of data and functional integration that systems or participants exchange with each other. And as systems and business processes evolve within organizations, so does the technology behind B2B integration.
INTEGRATION EVOLUTION
Every year some kind of integration technology becomes mainstream. The technologies are gradually evolving and building on each other. However, instead of looking at individual technologies year by year, let’s try to track their progress over the decades and understand why blockchain may become the next stage of the technology.
DATA INTEGRATION
This is one of the earliest mechanisms of access to information by different systems, the most vivid examples of which are
- Single database – used to integrate systems within organizations;
- File exchange – used for information exchange within and between organizations. The use of universal file transfer protocols like FTP provides the exchange of application data between computers and operating systems.
Both of these approaches are not implemented in real time, are packet-based and have limitations in terms of scalability and reliability.
FUNCTIONAL INTEGRATION
In contrast to data integration, the following methods provide real-time data and functionality exchange:
- Remote procedure calling has a significant advantage over socket-based integration, hiding the complexity of network configuration and data marshalling. However, this method is an early-generation two-point client-server architecture that depends on the programming language.
- An object request intermediary (with CORBA, DCOM, RMI implementations) represents 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 decoupling between applications and provides guaranteed delivery of asynchronous messages.
All of the optimizations described above are mainly focused on system integration. From packets to real-time data exchange, from two-point architecture to peer-to-peer architecture, from synchronization to asynchrony, all these methods do not control or believe what kind of data exchange they produce.
On the other hand, this early infrastructure already provided B2B integration, but did not understand the data or the business process it was part of.
SERVICE-ORIENTED ARCHITECTURE (SOA)
The main aspects of SOA related to our task are standards of web-services using XML, SOAP and WSDL formats. These standards in combination with the implementation of ESB (enterprise service bus) and BPM (business process management) make the integration focus on the semantics of business integration, while earlier technologies mainly provided system integration.
Web services allow systems to exchange data not blindly, but using contracts and interface definitions readable by computers. Such contracts allow the system to understand and validate the data before interacting with another system.
Microservice architecture can also be included in this group, as it essentially creates and improves SOA and ESB architectures.
It is at this stage that distributed systems obtain common standards and contract definitions.
BLOCKCHAIN-BASED INTEGRATION
While sharing data in common protocols and standards is a positive development, service contracts do not provide insight into the business processes behind contracts and operating in remote systems.
Sometimes participants of one business process are several parties, each of which is the owner of the process. The prospect for the good functioning of such multi-stakeholder interactions is the transparency of the overall process and its current state. All this can be provided by blockchain technology.
This model extends the use of common protocols and service contracts to a common business process. In blockchain, all participants work with a single business process in the form of smart contracts. However, in order to confirm the requests and to come to the overall result of business processes it is necessary to have a general state of affairs, and this is achieved with the help of a distributed registry.
In this regard, blockchain can be seen as the next step in the evolution of integration. Blockchain networks act as distributed concepts of ESB and BPM, not within the same organization, but between several companies.
First protocols (e.g., FTP), then API contracts (WSDL, SOAP), and now the business processes (smart contracts) and their data go outside the organization, into the common space, and become part of the integration infrastructure.
Using blockchain, shared data and business process models move to shared corporate networks. It is worth noting 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 members have the same understanding of data models and business processes. Thus, this solution can be applied only in certain industries, where processes can be standardized, for example, it can be finance, supply chains, healthcare.
