Integration Patterns Explained for Non-Technical Managers

When vendors talk about APIs, webhooks and middleware, managers are often left nodding along. This guide explains the main integration patterns and the questions worth asking.

6 November 20266 min read

Integration Patterns Explained for Non-Technical Managers - Kemlat Insights

Every growing organisation ends up with several systems that need to share data: an ERP (enterprise resource planning) system, a CRM (customer relationship management) tool, a website, a payroll package, a courier’s portal. How those systems are connected decides whether data moves reliably or whether someone spends every afternoon copying it. Yet the conversation about integration usually happens in technical language that leaves managers unable to judge what they are agreeing to.

Why managers should care how systems connect

Integration choices have business consequences. They decide how quickly an order placed on the website appears in the warehouse, whether a price change reaches every channel the same day, and what happens when one system goes down. They also decide how much you will pay every time something changes.

Take a medical supplies distributor in Amman that sells to hospitals and pharmacies. Its ERP handles stock and invoicing, a CRM tracks sales visits and tenders, hospitals order through a small customer portal, and deliveries are booked with a courier. Four systems, and several connections between them. If each connection is built differently by a different vendor, the distributor ends up with a fragile web that nobody fully understands. Understanding the basic system integration patterns lets the operations manager ask the right questions before that happens.

The main integration patterns, in plain language

Manual export and import

Someone exports a file from one system and imports it into another. This is where most companies start, and it is not always wrong. For data that changes rarely, or moves once a month, it can be perfectly sensible. The problems are that it depends on a person remembering, it introduces errors when files are edited in between, and it does not scale.

Scheduled file transfer

The same idea, automated. One system writes a file to an agreed location at a fixed time, such as every night at midnight, and the other system picks it up. It is simple, cheap and well understood. The limitation is timing: data is only as fresh as the last transfer, so an order placed at 9 am might not appear in the other system until the next morning.

Direct API connections

An API (application programming interface) is a defined way for one system to ask another for data or send it data, in real time. Think of it as a service counter with clear rules: you hand over a request in the agreed format and get a response. When the customer portal sends a new order directly to the ERP the moment it is placed, that is an API integration. It is fast and precise, but each connection has to be built and maintained, and if one system changes its API, the connection may break.

Webhooks and events

With a webhook, a system announces that something has happened, for example “order shipped”, and any system that has subscribed receives the message straight away. Instead of the ERP asking the courier system every few minutes whether a delivery is done, the courier system tells the ERP when it happens. This is efficient and quick, but you need a way to handle messages that fail to arrive.

Middleware or an integration platform

Instead of connecting every system to every other system, each one connects to a central integration layer, which routes and transforms data between them. This can be a dedicated integration platform or a workflow tool such as Power Automate or n8n for simpler cases. It costs more to set up, but changes become easier: replacing the CRM means changing its one connection to the central layer, rather than every link the old CRM had. It also gives you one place to see what moved, what failed and why.

Warning sign: If a vendor proposes connecting two systems by letting one write directly into the other’s database, ask hard questions. It may work today, but it usually breaks with upgrades and can bypass the receiving system’s own validation rules.

Comparing the patterns side by side

Pattern	Speed	Setup effort	Good for
Manual export and import	Whenever someone does it	Very low	Rare, low-volume transfers
Scheduled file transfer	Hourly or daily	Low	Reporting, nightly stock updates, bank files
Direct API	Real time	Medium per connection	Orders, prices, customer data that must be current
Webhooks and events	Real time	Medium	Status updates such as shipped, paid, approved
Integration platform	Real time or scheduled	Higher at first	Several systems, frequent changes, need for monitoring

Most organisations use a mix. The distributor above might send bank statements by scheduled file, push portal orders into the ERP by API, receive delivery updates by webhook, and run the whole thing through a small integration layer so the IT lead can see failures in one place.

Questions to ask before approving an integration

You do not need to design the integration yourself. You do need to ask questions that reveal whether it has been thought through.

Which system owns each piece of data? If customer addresses can be edited in both the CRM and the ERP, which one wins when they differ? Every shared data item needs a single owner.
How fresh does the data need to be? Real-time integration costs more. If daily is good enough for a particular flow, say so.
What happens when it fails? Who is told, how quickly, and does the data retry automatically or wait for someone to resend it?
Where can we see what moved? A log showing what was sent, when and whether it succeeded is essential for resolving disputes and errors.
Who maintains it after go-live? If the vendor who built it disappears, can someone else understand and fix it? Ask for documentation.
What happens when one system is upgraded or replaced? The answer tells you how tightly the systems are tied together.

Starting from the business flow, not the technology

The right integration design starts with a simple picture of how data should flow through the business: where an order begins, which systems it passes through, who needs to see it and when. Once that picture exists, choosing patterns for each connection becomes straightforward. Without it, integration decisions are made one vendor at a time, and the result is the fragile web nobody wants.

A one-page diagram of your systems and the data flowing between them, labelled with the pattern used for each connection, is one of the most useful documents an IT lead can keep. It also makes conversations with new vendors much shorter.

Connecting systems around how the business works

Integration is where many system projects quietly succeed or fail. Clear data ownership, sensible patterns and visible monitoring make the difference between systems that support each other and systems that need constant manual repair.

Our Enterprise Systems service includes data architecture and legacy system integration, starting from the business flow and choosing the simplest pattern that meets each need. Simpler flows, such as a nightly file transfer or an approval message, can often be built and monitored as automated workflows by our Intelligent Automation team.