How to choose how to integrate enterprise systems

Three questions for choosing how to integrate systems

The way to integrate two systems is chosen by answering three questions: how up to date the information has to be, whether the system using it needs to work even when the other is unavailable, and which access and recording rules apply to the data. Depending on the answers, information can be queried at the source, synchronised between the two systems or transferred from one to the other.

In practice, this decision is usually made by default. The tool already comes with a ready-made synchronisation, the supplier proposes a default connection, or someone exports a file to solve the week's problem. Each of these solutions works, but each has different consequences for data consistency and for maintenance work. As we explained in the article on why integrating enterprise systems is not enough, connecting platforms without a defined logic can spread inconsistencies instead of resolving them.

What each approach solves and what it requires

With querying, the system that needs the information obtains it directly from the source system at the moment it uses it, without keeping a permanent copy. This reduces the need to keep copies up to date across platforms and the number of copies to protect, although how current the information is depends on the source and on how the integration is implemented. It requires the source to be available when the query is made and permissions to be well defined at that source.

With synchronisation, the information exists in both systems and a rule keeps them aligned. Each system can keep working with its own copy for a while even without a connection to the other, but dependencies arise around updating and data consistency. It requires deciding which is the reference information, in which direction updates flow, how often, and what happens when the two versions diverge.

With transfer, data moves from one system to another at a defined moment, for example when a process changes phase, when a platform is replaced or when information is archived, with or without a change of responsibility for the process. It requires defining what happens to the original and how what was transferred is recorded.

These approaches are not rigid categories and are often combined: the same integration may query some fields and synchronise others.

Criteria for deciding

The first criterion is how fast the information changes and how up to date the user needs it to be. Data that changes several times a day and has to be correct at the moment of decision, such as the status of an order, favours querying or very frequent synchronisation. Data that rarely changes, such as a customer's billing address, can be synchronised less often.

The second criterion is autonomy. If the invoicing system has to issue invoices even when the CRM is under maintenance, it needs its own copy of the customer data, and synchronisation is the natural option. If the system can wait for the source without harming the work, querying avoids duplicating information.

The third criterion is access and recording rules. The more sensitive the information, the more important it is to limit the places where it exists and the people who access it, which tends to favour querying with well-defined permissions. Whatever the approach, it should be possible to know which data moved, when and on whose initiative, with a level of detail proportionate to the risk of the process. In sectors with specific requirements, this choice should be made with those who know the applicable obligations, as we explained in the article on digital transformation in regulated sectors.

The criteria rarely all point to the same approach. A company may need very up-to-date data and, at the same time, need a system to keep working when the source is unavailable. In that case, the choice is not simply between querying and synchronising: it may involve querying the source whenever possible and keeping a frequently updated copy for periods of failure, with rules on how often it is updated and on what the system does when the copy may be out of date. The solution comes from balancing operational needs against the technical limitations of the systems.

An example: three decisions in the same company

Imagine a company with a CRM, an invoicing system and a warehouse management system. A customer's billing address is corrected in the CRM, which is the reference information for customer data. The invoicing system has to issue invoices in any circumstances, so it receives a synchronised copy, updated in one direction only, from the CRM to invoicing. The update applies to customer data and to future documents, not to invoices already issued, which may be subject to their own retention and amendment rules.

The available stock, which the sales team sees when preparing a proposal, changes several times a day. Here it makes more sense to query the warehouse system than to keep a copy that quickly becomes outdated. When an order is completed, the data moves from the management system to the archive at a defined moment, and the original is archived according to the company's retention rules.

Three connections, three different approaches, all resting on a reference for each type of data, a topic we explained in the article on how to build a single source of truth in company systems.

Common mistakes in the choice

The most common mistakes are synchronising everything by default, which multiplies copies and conflicts; querying everything, which makes each system dependent on all the others; and relying on manual exports and imports with no record of what was moved, which create uncontrolled copies. In any of these cases, the absence of a defined reference turns a good technical connection into a source of inconsistency.

Where InovaDigital can help

InovaDigital develops system integration solutions and custom software, taking into account business processes and the characteristics of the platforms involved. The aim is to let information flow according to the needs of each operation, reducing manual tasks and avoiding inconsistent data between systems.

Deciding connection by connection

A practical starting point is to list the connections between the company's two or three most important systems and answer, for each one, the three initial questions: how up to date the information has to be, whether the system needs to work without the source and which access and recording rules apply. The answers often show that the same company needs more than one approach, and that the essential thing is for each connection to have a clear rule, a reference system and a record of what moves.