Integration Middleware Architecture: An Enterprise Guide

Integration middleware: why your business systems need a layer in between

Integration middleware is the architectural layer that keeps data flowing correctly, on time and traceably between your ERP, CRM, online store, warehouse management system (WMS), e-invoicing provider, bank APIs and, increasingly, AI services. The problem usually starts the same way everywhere: two systems get wired together directly, then a third joins, and a few years later there is a web of “nightly scripts” nobody fully understands. Orders fail to reach the ERP, invoices are issued twice, and bank reconciliation is still done by hand in a spreadsheet.

This guide is for IT managers, product owners and technical leads who have to connect several business systems and want to do it once, properly. It compares point-to-point links, API gateways, message queues (RabbitMQ), event streaming (Kafka), ESBs and iPaaS, and then gets concrete about the canonical data model, versioning, security, observability and ownership. One clarification up front: the middleware discussed here is not the request-level middleware inside a web framework; we cover that separately in what is middleware.

In short

• Integration middleware connects systems through a shared layer instead of directly, so adding a new system does not mean rewiring everything.
• Use an API gateway for synchronous needs (price lookups, stock checks) and a queue or event stream for asynchronous work (orders, invoices, reconciliation).
• A canonical data model and explicit contracts keep transformation costs under control as the number of systems grows.
• Without OAuth2, mTLS and central secrets management, the integration layer becomes the weakest security link.
• No integration is “done” without correlation ids, distributed tracing, a dead-letter queue and a written runbook.

• • •

What does an integration middleware layer actually do?

Think of it as a traffic control centre with written, observable rules that every system-to-system conversation passes through. Its work falls into four buckets: connectivity (protocols and authentication), transformation (turning one system’s data format into another’s), routing (which message goes where) and reliability (retries, ordering, error queues). When these concerns are scattered across every application, the same logic gets written again and again, and none of it is monitored the same way.

A typical system landscape

At a mid-sized manufacturer or distributor we often see the following: an ERP (orders, stock, ledger), a CRM (customers, quotes), an online store or dealer portal, a WMS or warehouse app, an e-invoicing provider, payment and statement services from one or more banks, carrier APIs and a data warehouse for reporting. Over the last two years AI services have joined the list for document classification, email summarisation or customer assistants. Each of these has its own authentication method, error codes and rate limits.

When do you need a dedicated layer?

The signals we see most often in projects: the same customer exists in three systems with three different versions of the truth; you learn that an integration failed from a customer complaint; connecting a new marketplace takes months; nobody can answer “who wrote this script?”. If two of these sound familiar, the problem is architectural rather than a matter of individual connections, and a middleware layer is one of the fastest investments to pay back.

• • •

Which integration style should you choose, and when?

There is no single right technology; the right choice is the one that matches the nature of the workflow. The options below are less alternatives to each other than layers that coexist in the same architecture.

Point-to-point

A direct API call or file transfer between two systems. For two or three systems and low volume it is quick and cheap. But every new system means a separate connection to every existing one; the number of links grows quickly with the number of systems, until you have a mesh nobody can map.

API gateway

According to Microsoft’s Azure Architecture Center, an API gateway is a reverse proxy that acts as a centralised entry point between clients and services, and can offload cross-cutting work such as authentication, SSL termination, mutual TLS and rate limiting. It is the right tool for synchronous request/response traffic, such as a dealer portal checking stock or a mobile app fetching prices, not for carrying long-running work.

Message queue (RabbitMQ)

The sender drops a message on a queue and the receiver processes it when ready. RabbitMQ’s documentation states that using consumer acknowledgements and publisher confirms gives you at-least-once delivery, while without them message loss is possible. It is ideal for commands that must be done exactly once in business terms: create an order, request an invoice, send an email.

Event streaming (Kafka)

Apache Kafka is a distributed event streaming platform that stores events durably in topics. Per the Kafka documentation, events are not deleted after consumption, retention is configured per topic, events with the same key land in the same partition, and a consumer of that partition reads them in the order they were written. It shines when the ERP, WMS, reporting and an AI service all need to react independently to the same “order confirmed” event, or when you want to replay history.

ESB (enterprise service bus)

An ESB centralises transformation, routing and orchestration on a shared bus. It is powerful, but James Lewis and Martin Fowler’s 2014 microservices article pushes back on burying business logic in the communication layer and promotes “smart endpoints and dumb pipes” instead. In practice the risk of an ESB is that every change has to go through one team and one product.

iPaaS (integration platform as a service)

IBM describes iPaaS as a suite of self-service, cloud-based tools for integrating applications and data sources across environments, with prebuilt connectors and mapping tools that deliver results fast. It makes sense if you mostly connect SaaS products; just make sure pricing per flow or per volume, where data is processed and platform lock-in are discussed during discovery.

Style	Best fit	Strength	Watch out for
Point-to-point	2–3 systems, low volume, short-lived need	Fast, cheap start	Maintenance multiplies as systems grow
API gateway	Synchronous lookups, externally exposed APIs	Security and traffic policy at one door	Not suited to long-running work
Message queue (RabbitMQ)	Commands, job queues, order/invoice processing	Acknowledged delivery, flexible routing, dead-lettering	Consumers must tolerate duplicates
Event streaming (Kafka)	Many consumers, high volume, replay	Durable log, per-partition ordering	Needs operational skill and schema governance
ESB	Legacy systems needing central transformation	Rich transformation and protocol support	Single-team, single-product bottleneck
iPaaS	SaaS-heavy estate, prebuilt connectors	Fast rollout, low code	Pricing model, data location, lock-in

A starting layout we often recommend: an API gateway for synchronous traffic facing portals and partners; a message queue for system-to-system workflows; and an event stream where several consumers need the same event. As volume and team maturity grow, Kafka’s share can grow too; moving everything onto an event stream on day one is usually unnecessary operational load.

• • •

How do you design the canonical data model and mappings?

Every system defines “customer”, “product” and “order” differently: the ERP keys on an account code, the CRM on an email address, the store on a member number. A canonical data model defines a shared message format that belongs to no single application and asks each system to translate only to and from that format. The example in Enterprise Integration Patterns is telling: six applications translating directly to each other need 30 translators, while a canonical model brings that down to 12.

Mapping and transformation rules

Mapping rules should not disappear into code. Keep a field-by-field mapping sheet (source field, target field, transformation, required or not, sample value) and have the business sign it off. Currency, VAT rates, unit conversions and time zones are where errors cluster. Unit-test the transformation layer with anonymised sample messages taken from the real systems.

Contracts and versioning

The middleware publishes a contract between systems. Adding a field is usually backward compatible; removing a field, changing its meaning or making it mandatory is a breaking change and belongs in a new version (for example a v2 topic or endpoint). We cover versioning strategy in detail in API contract design and backward compatibility. The payoff shows when a regulator changes a document format and the change stays inside one adapter; for a current Turkish example, see our post on the GİB UBL-TR update and e-invoice integration.

• • •

How should you secure the integration layer?

The integration layer carries a company’s most sensitive data: customer accounts, bank movements, invoice contents. It deserves stricter protection than the user interface. There is no user session in system-to-system calls, so identity has to travel as OAuth 2.0 client credentials and short-lived access tokens.

Mutual TLS (mTLS)

For banks and critical partners, mTLS, where the client proves its identity with a certificate as well as the server, is a common choice. The IETF’s RFC 8705 (2020) defines OAuth client authentication over mTLS and certificate-bound access tokens, so a stolen token cannot be replayed from another machine.

Secrets and least privilege

• API keys and certificates live in a secrets vault, not in code or config files, with a written rotation schedule.
• Each integration has its own service account; one “admin” account connecting to everything is not acceptable.
• Personal data is masked in logs, and every transfer of personal data is reflected in your data-protection inventory.
• Rate limits and IP allow-lists for exposed endpoints are enforced at the API gateway.

• • •

How do you build observability and error handling?

If the answer to “is the integration working?” isn’t visible on a dashboard, the answer is usually no. Every message and request should carry an identifier that can be followed end to end: a correlation id. The OpenTelemetry docs explain that the default propagator uses the traceparent header from the W3C TraceContext specification, which lets calls across services be stitched into a single trace. The same context should travel in message headers on your queues.

Dead-letter queue (DLQ)

Some messages will never succeed: a missing mandatory field, a closed customer account, an invalid tax number. Enterprise Integration Patterns calls the remedy a Dead Letter Channel. In RabbitMQ a message can be dead-lettered when a consumer rejects it without requeueing, when its TTL expires, when a queue length limit is exceeded, or when a quorum queue’s delivery limit is passed. A DLQ is not a bin; it is a work list with an owner and an alert.

Retries and idempotency

Network errors and brief outages are a given, so retries are essential, but uncontrolled retries mean the same invoice issued twice. We walk through exponential backoff, jitter, idempotency keys and the transactional outbox with code samples in outbox pattern, idempotency and retries. For setting up metrics, logs and traces, see observability in enterprise applications.

• • •

Ownership, runbooks and AI services

Even a technically sound integration decays without an owner. Every flow needs a business owner (say, the finance manager) and a technical owner. The runbook explains the purpose of the flow, the systems involved, likely failure types, how to inspect and replay a message from the DLQ, and who to call in which situation. At 2 a.m. the on-call engineer needs that page, not an architecture diagram.

AI services add a new dimension: latency varies, cost accrues per call and output is not always deterministic. Routing AI calls through the middleware lets you enforce quotas, cost tracking, personal-data masking and fallback models in one place. We cover the production side in taking AI agents to production.

Point-to-point links end up looking like this panel: it works, but nobody knows which cable goes where.

Invoices, reconciliation and bank movements: the finance desk is where integration errors get expensive.

Flow owners, failure scenarios and runbooks are drawn up together before go-live.

• • •

How do you plan an integration programme, and how long does it take?

Timelines are driven less by technology than by how many systems you connect and how ready they are. Does the other side have a test environment? Is the API documentation current? How many weeks does it take to get access approved? Those answers form the longest leg of the schedule. A pilot that starts with one flow, such as pushing online orders into the ERP, can go live within a few sprints; a multi-system programme should be split into phases.

1. Discovery: system inventory, flow map, volumes, failure scenarios and owners.
2. Pilot flow: the single most painful flow, end to end, including monitoring and DLQ.
3. Platform: shared authentication, canonical model, adapter templates.
4. Roll-out: migrate remaining flows in priority order and retire the old scripts.

Checklist before you start

• Are all systems, their owners and their test environments listed?
• Is each flow marked synchronous or asynchronous, with an acceptable latency written down?
• Have canonical fields and a mapping sheet for customer, product, order and invoice been approved?
• Are the authentication method (OAuth2, mTLS, API key) and the secrets store decided?
• Are correlation ids, tracing and core metrics (queue depth, error rate, latency) in the design?
• Are the retry policy, idempotency keys and the DLQ process defined?
• Are contract versioning rules and a breaking-change notice process written down?
• Does every flow have a runbook, an on-call rota and an agreed SLA?

• • •

How Aksiyon Soft can help

Through our API and integration service we bring the flows between ERP, CRM, e-commerce, WMS, e-invoicing providers, banks and AI services into a single middleware layer. When it is part of a wider transformation, we deliver the integration layer together with portals and operations screens under enterprise software solutions. You can see a reference architecture on our API and data integration platform solution page.

The delivery model is straightforward: discovery maps the systems and flows; an MVP is built around the most critical flow; working integrations are demoed at the end of every sprint; go-live is followed by a hypercare period and then SLA-backed maintenance. We are headquartered in Samsun and work remotely with teams across Türkiye, with planned on-site visits for acceptance and go-live when the project calls for it.

Frequently asked questions

Do we need Kafka for enterprise integration?

No. If volume is moderate and each message has a single consumer, a message queue such as RabbitMQ is often simpler and entirely sufficient. Kafka stands out when several systems need the same event, volume is high, or you need to replay history.

Is the ESB dead?

No; it still does useful work, especially where legacy protocols are involved. The real risk is burying business rules in the bus so that every change has to go through one team. For new projects, a lighter middleware that keeps logic at the endpoints is usually more sustainable.

iPaaS or custom-built middleware?

If most of what you connect is SaaS with ready-made connectors, iPaaS delivers quickly. If local ERPs, e-invoicing providers, domain-specific rules and data-residency requirements dominate, custom middleware is more flexible. Put the total cost of ownership of both side by side during discovery.

How is personal data protected in the integration layer?

Transferred fields are flagged in the data inventory, unnecessary personal data is never carried, logs are masked and service accounts follow least privilege. Connections use TLS, and mTLS with critical partners.

Should we switch off existing scripts all at once?

No, and we advise against it. The new middleware takes over the most critical flow first; the old script runs in shadow mode for a while so results can be compared, and is retired once consistency is confirmed. This staged approach modernises without putting live operations at risk.

How long does it take to put one integration flow live?

For a single flow, a few sprints can be enough if the other system’s test environment and access are ready. The biggest delays usually come from third-party access and test data rather than development, so the schedule is shared after discovery with written assumptions.

Let’s talk about your project

If data is still copied by hand between systems, invoice errors keep recurring, or nobody owns the scripts, let’s start with a short discovery call. Use the contact form to list the systems you need to connect and the flow that hurts most, and we will shape the right middleware architecture and first pilot flow together.

Sources

• Enterprise Integration Patterns — Canonical Data Model (Gregor Hohpe, Bobby Woolf)
• Enterprise Integration Patterns — Dead Letter Channel
• martinfowler.com — James Lewis, Martin Fowler: Microservices (25 March 2014)
• Apache Kafka — Introduction
• RabbitMQ — Reliability Guide
• RabbitMQ — Dead Letter Exchanges
• Microsoft Learn, Azure Architecture Center — API gateways
• IETF — RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (2020)
• OpenTelemetry — Context propagation
• IBM — What is iPaaS? (updated 6 April 2026)