Technologies of integration of IT systems

Technologies of integration of IT systems

One of the main tasks for Enterprise architects is designing and carrying out work on the integration of various IT systems. So, a typical story is that the customer has some solutions, either interconnected or partially connected, and the architect needs to build his solution, integrating it with those solutions that the customer already has.

Next, we will consider several approaches to integration and start with the simplest case, when there is no integration between systems.

That is, let’s imagine a situation when the company uses several independent information systems: warehouse, accounting, CRM and financial. There is no information exchange between these systems.

As a result, in order to fulfill the task of shipping goods, applications are created separately in each system and, for example, sales managers after issuing invoices to customers are forced to print their copies and take them to the accounting department. In accounting, they are registered in the accounting system. Accounting registers the receipt of money to the account. Sales managers, not being able to receive payments automatically in the CRM system, are forced to check with the accounting department every day about the receipt of money from customers.

Thus, we have a certain “Paper Net”, i.e., paper data exchange between managers, accounting and warehouse, as well as double registration of actions (once in the warehouse system, the second time in the accounting system).

In addition, when applications in each system are created manually, the human factor begins to play a big role, that is, errors made by various specialists in the process of processing applications in the systems.

Well, in addition, all this paper-based document management is quite expensive for the company, since it is necessary to pay for the time spent on performing duplicate procedures in different systems and correcting the mistakes made.

I think that the problem is clear and we can move on to considering ways of integration.

Horizontal integration

Let’s start with a common approach of horizontal integration – the use of a service bus. That is, we can deploy middleware – the so-called corporate service bus.

This bus should perform the task of storing the functionality repository of those corporate applications that are connected to it. At the same time, the bus must provide the possibility of using these functions by other applications also connected to this bus. Interaction between applications can, for example, take place in the form of messaging or calling published functions in the form of a REST API. Connecting the system to the bus is done by creating a special adapter for each system. After that, the system’s “published” features become available to other connected systems.

So, for example, the warehouse system when connected to the bus must publish its functions for working with items in the warehouse. With the help of the bus, other systems, such as accounting and CRM, will be able to use these functions in their work. In turn, the warehouse system can also, if necessary, use functions from other systems.

The interaction between the target systems and the bus is carried out with the help of special adapters, and here lies the main problem that the architect may face when designing the integration. To develop an adapter, we need a good understanding of how this or that target system works, what functions it has, and what parameters must be passed to these functions in order to get the desired result. In general, the study of this process of interaction requires serious analytical work from the architect.

But horizontal integration has its advantages. We can replace end systems transparently for the bus interaction process. At the same time, no changes in other systems are required. We only need to redesign the adapter for the new system so that it can also publish its functions on the bus. That is, we can replace SAP with 1C by simply rewriting the adapter. Although it is not always really “easy” to do this.

Vertical integration

An alternative to using a bus is a vertical approach to system integration. In accordance with this approach, we select integrated systems as a set of expertise that we need to integrate with each other.

So, in the example below, we highlighted two examinations: operational accounting and accounting. At the same time, accounting is vertically higher than the warehouse system and CRM. Accordingly, lower subsystems deliver data to the accounting subsystem.

Here we can also save significantly on paper document circulation and related personnel costs. But there are also a number of disadvantages here.

The first serious drawback is the complexity of expanding the functionality. Here, unlike the bus, we can no longer limit ourselves to writing adapters. If we need, for example, to create an analytical system that will take data from the Accounting system, which is higher in our hierarchy, but at the same time, the Analytical system will use a significant amount of data from lower-level systems. As a result, in addition to the development of the analytical system itself, we will also need to finalize the accounting system so that the necessary information is transferred to the analytical system.

Well, secondly, any change within the functionality of one system will inevitably lead to changes to higher systems, because there are always opportunities for integration within the framework of one functional expertise.

Many-to-many integration

And the third, the most universal option of integration, when we connect systems to each other, as we need, without using hierarchies and a data bus. That is, within the framework of this approach, each of the systems used in the company can, if necessary, refer to the functionality of any other system, while each of them can also be used by any other system. That is, we can have a one-way connection, when only one system uses the functionality of the other, and there can be a two-way connection, when both interacting systems use each other’s functions.

Here, on the one hand, we do not have the limitations that are present in the previous two approaches. We are not tied to the bus, which is also a single point of failure, because the failure of bus components will lead to the fact that we will in principle lose the possibility of interaction between our systems, and every hour of downtime of IT systems is a direct loss for the company.

The appearance of a new system will also not be a big problem for us, because it will have to be connected only to those systems with which it is necessary to build interaction.

And in general, here the opportunities for integration are limited only by technical limitations in the target systems themselves.

But what do we pay for all these benefits? Many-to-many connections are difficult to administer. It is necessary to have a good understanding of the integration framework, because a change in one system causes the entire interaction mechanism between the systems to be reworked, since the old function calls will no longer work. In general, the costs of maintaining such an integration scheme grow exponentially when the number of integrated subsystems increases.

That is, if we have more than ten integrated systems, then maintaining such integration can be expensive.

When integration is not required

Returning logically to the beginning of the article, we will consider the option when integration is not needed in principle. This is an ideal case from the point of view of the operating IT services, but for the integrator companies this approach is not very interesting, since it is not possible to make much money from it.

If we use a modular system from one vendor for the functioning of business processes, then the process of integrating a new system is reduced to the purchase of the necessary module and its connection to the already existing ecosystem. Here, the process of connecting the module is usually already described in the vendor’s instructions, and in case of problems that arise, you can safely contact their technical support.

A typical disadvantage of this approach is dependence on one vendor. So, if the portfolio of the developer company does not have any solution necessary for our business process, then we will either have to start breeding a “zoo” with other solutions and integration, or use Paper Net. Also, an ecosystem based on solutions from one vendor is usually more expensive in terms of licenses than a “zoo” based on solutions from different vendors.

Conclusion

In this article, we have considered various options for integrating IT systems. It is important to understand that there is no silver bullet here. Each option has its advantages and disadvantages. Yes, if you have your own staff of programmers, all systems are well documented, then writing bus adapters will not be a big problem. On the other hand, if you have been using a modular solution from one vendor for a long time and you are completely satisfied with it, then in principle you do not need to be bound by integration.

I would like to invite you to the free lessons of the Enterprise Architect course on the basic concepts of modern corporate architecture, as well as the Hard Skills of a corporate architect. Register using the links, it will be interesting.

Related posts