How to Design an Integration Architecture

Every enterprise I have worked in eventually reaches the same crossroads. The business has grown, systems have multiplied, and each new integration has been bolted on wherever it was quickest at the time. One day someone asks a simple question, "if we change the customer master in the ERP, what breaks?", and nobody can answer with confidence. That moment is the symptom of an architecture that was never designed, only accumulated. Integration architecture is the discipline that prevents this. It is the deliberate arrangement of how systems talk to each other, what data flows between them, in what shape, over which channels, and under what rules. Get it right and the landscape absorbs change. Get it wrong and every new connection makes the next one harder. This guide sets out how I approach the design work, drawing on the broader picture in the enterprise system integration explained pillar.

The message up front: integration architecture is not about picking the fanciest middleware. It is about making a small number of decisions well, before you write a line of integration code. The pattern you choose, the way data is shaped, whether calls are synchronous or asynchronous, and how errors are handled will shape the landscape for a decade. Tools change. Those decisions endure.

1. Why architecture matters more than tools

The most common mistake I see is treating integration as a tooling question. A team buys an iPaaS platform or stands up an enterprise service bus, and assumes the architecture will emerge from the product. It will not. The tool executes whatever design you feed it, and if there is no design, it will faithfully execute a mess. I have audited landscapes running expensive, capable middleware where the actual topology was a spaghetti of direct calls that happened to pass through the tool. The platform was blamed. The platform was innocent.

Architecture matters more than tools because the properties that make a landscape good or bad are structural, not technological. How many connections exist between systems, whether data has a single authoritative shape or a dozen dialects, whether a failing downstream system takes its callers down with it, whether you can add a new consumer without touching the producer. These are questions of arrangement, and no product answers them for you. A well-architected landscape on modest tooling will outlast and outperform a poorly-architected one on premium tooling every time.

There is also a cost dimension that only becomes visible over years. A landscape of N systems connected directly can require up to N times N-minus-one connections. At ten systems that is potentially ninety connections, each with its own mapping, its own error handling, its own credentials and its own failure modes. Every one is a maintenance liability and a security surface. Good architecture attacks that combinatorial growth head on, which is the real subject of this guide. If you are still deciding how any single pair of systems should connect, the choosing the right integration method guide is the companion piece to this one.

2. Start with the business, not the technology

Integration exists to serve a business capability, never for its own sake. So the first artefact I produce is not a technology diagram, it is a list of the business processes that cross system boundaries. Order to cash. Procure to pay. Hire to retire. Asset acquisition to disposal. Each of these flows through several systems, and the integration exists to keep those systems consistent as the process moves. If you cannot name the business process an integration serves, you should question whether it should exist at all.

Starting with the business forces two useful disciplines. First, it surfaces the real data ownership. In a procure-to-pay flow, who owns the supplier master? Who owns the purchase order once it is approved? Who is the system of record for the invoice? These are business questions with business answers, and they determine the direction of data flow long before you choose a technology. Second, it surfaces the real timing requirements. Does the warehouse need the order the instant it is placed, or is a batch every fifteen minutes fine? Does finance need the invoice in real time, or overnight? The business process tells you, and those answers drive the synchronous-versus-asynchronous decision later.

I write these as plain-language flow statements before any diagram: "when a sales order is confirmed in the CRM, the ERP must create a corresponding order within one minute, and the CRM must reflect the resulting delivery status." That single sentence contains the source system, the target system, the trigger, the payload, the direction and the timing requirement. Twenty sentences like it describe most of a mid-sized enterprise's integration needs, and they are readable by business stakeholders who would glaze over at a technical diagram. This is also where an integration strategy comes from, which I cover in the integration strategy for enterprise applications guide.

3. Map the systems and data flows

With the business processes named, the next step is a systems and data-flow map. This is an inventory and a diagram together. The inventory lists every system in scope, its role, its owner, the data domains it masters, and the interfaces it exposes or can expose. The diagram shows the flows: which system sends what data to which other system, in which direction, triggered by what event, at what frequency. It is deliberately technology-agnostic at this stage. No middleware, no protocols, just systems and the information moving between them.

The mapping exercise almost always reveals things nobody knew. Duplicate flows where two teams built separate integrations for the same data. Hidden dependencies where an ostensibly minor system turns out to feed three others. Data that is mastered in two places with no agreement on which wins in a conflict. Undocumented direct database links that bypass every interface. I treat the discovery phase as half the value of the whole engagement, because you cannot architect a landscape you do not accurately understand, and the documented picture rarely matches reality.

A practical technique: build a data-domain matrix. List the core data domains down one axis, customer, product, supplier, order, invoice, asset, employee, and the systems across the other. In each cell, mark whether the system is the master of that domain, a consumer, or both. The moment two systems both claim to master the same domain, you have found an architectural decision that must be made explicitly, because if you do not make it, the integrations will make it for you, inconsistently. This matrix becomes the backbone of the canonical data model discussed later.

The honest limitation: the map is only as good as the access you get. Vendors are sometimes reluctant to disclose how their system really integrates, and internal teams sometimes do not know. Budget time to verify the map against live traffic, log files and actual interface catalogues rather than trusting the documentation or the org chart. The gaps you find during verification are precisely the integrations that will surprise you in production.

4. Choose the integration pattern

With the map in hand, the single most consequential architectural decision is the topology, the overall shape of how systems connect. There are four archetypes, and real landscapes usually blend them, but understanding each in its pure form is essential to choosing well.

• Point-to-point: each system connects directly to each other system it needs to talk to. Simple and fast for the first few connections, and perfectly reasonable when you have three systems and two flows. The problem is growth. Every new system multiplies the connections, mappings and failure points, and the landscape becomes the combinatorial tangle described earlier. Point-to-point is not wrong at small scale; it is a trap at large scale because it starts out feeling easy.
• Hub-and-spoke: a central integration hub sits between all systems, and every system connects only to the hub. The hub handles routing, transformation and mediation. This collapses the combinatorial growth: N systems need N connections to the hub, not N times N-minus-one to each other. The trade is that the hub becomes a critical dependency and a potential bottleneck, so it must be designed for availability and scale. Most classic enterprise integration is hub-and-spoke, often realised as an enterprise service bus.
• Enterprise service bus (bus): a refinement of hub-and-spoke where the connective tissue is a shared messaging backbone. Systems publish and subscribe to messages on the bus rather than addressing each other. The bus provides routing, transformation, protocol mediation and often guaranteed delivery. It excels at asynchronous, event-driven flows and decouples producers from consumers cleanly. Its risk is that a single heavyweight bus can become an organisational chokepoint if every change has to pass through one central team.
• Mesh (API-led and event mesh): the modern decentralised approach. Instead of one central hub, capabilities are exposed as managed APIs and events, discoverable through a catalogue, and systems compose them directly under shared governance. An API gateway and a distributed event backbone provide the control plane, but there is no single monolithic broker in the data path. A mesh scales organisationally as well as technically, because teams can build and expose integrations independently within common standards. The cost is that it demands mature governance; without it, a mesh degrades back into point-to-point wearing modern clothes.

My guidance is rarely to pick one purely. A pragmatic enterprise architecture is usually a hub or event backbone for core master-data and transactional flows, an API gateway and API-led layer for real-time request-response and external exposure, and a deliberate, documented handful of point-to-point links where the simplicity genuinely outweighs the coupling. What matters is that the topology is chosen on purpose and written down, so every future integration knows which lane it belongs in. Drifting into an accidental topology is the failure mode covered in the common integration mistakes guide.

5. The reference architecture

A reference architecture is the layered blueprint that every specific integration conforms to. It defines the tiers, what belongs in each, and how data moves through them. The value is consistency: when every integration follows the same layered shape, the landscape becomes comprehensible, and a new engineer can reason about any flow because they all look alike. The diagram below is the layered reference I use as a starting point, adapted per engagement.

Read the blueprint top to bottom. Source systems emit events and expose requests. They reach the integration layer through one of two front doors: the API gateway for synchronous request-response and external exposure, or the iPaaS / ESB message backbone for asynchronous, event-driven flows. Inside the layer, everything is normalised through the canonical data model, so no system needs to know the internal format of any other. Monitoring wraps the whole layer, giving visibility into every flow. Transformed and validated data then lands in the target systems. The point of the picture is that every integration, no matter how specific, travels this same path, which is what makes the landscape governable.

6. The key design decisions

Beneath the topology and the reference blueprint sits a set of decisions that recur on every integration. I make them once, at the architecture level, document the default, and allow deviation only with justification. Making them centrally is what stops each integration reinventing its own answer and drifting the landscape apart. The table below sets out the decisions I insist on nailing down before build begins, the default choice I usually recommend, and why each one matters.

The two decisions organisations most often get wrong are synchronous-versus-asynchronous and error handling. The default reflex is synchronous, because it is conceptually simple: call the other system, wait, get an answer. But synchronous coupling means that when the downstream system is slow or down, the caller is slow or down too, and outages cascade. Asynchronous messaging, where the producer drops a message and moves on and the consumer processes it when able, is more work to design but far more resilient. I bias every non-interactive flow toward asynchronous for exactly this reason.

Error handling deserves special attention because it is where most integrations are quietly deficient. The happy path is easy and gets all the attention. What happens when the target rejects the message, the network drops, or the same event arrives twice? A well-architected integration answers all three: retries with exponential backoff for transient failures, idempotent operations so a duplicate delivery does no harm, and a dead-letter queue for messages that cannot be processed after retries, with an alert so a human intervenes rather than data vanishing. Skimping here is the root cause of the mysterious "we lost a batch of orders" incident that eventually surfaces in every under-designed landscape.

7. The canonical data model

Of all the architectural devices, the canonical data model earns its keep most quietly and most powerfully. The idea is simple: instead of every system learning to speak every other system's data format, you define one neutral, enterprise-owned representation of each core domain, and every system maps only to and from that shared shape. The ERP does not need to know the CRM's customer format; both map to the canonical Customer. The CMMS does not need to know the finance system's asset format; both map to the canonical Asset.

The payoff is structural. Without a canonical model, connecting N systems that each have their own format requires, in the worst case, mapping every format to every other, which is the same combinatorial explosion that plagues point-to-point topology, just at the data level. With a canonical model, each system needs only two mappings, into the canonical shape and out of it, so the mapping effort grows linearly rather than combinatorially. Add a new system and you write one pair of mappings, not one mapping per existing system. That single property is often the difference between a landscape that can grow and one that has calcified.

Designing the canonical model is genuine work and it is where the data-domain matrix from the mapping phase pays off. For each core domain you define the neutral fields, the authoritative source, the identity strategy for reconciling keys across systems, and the versioning approach for when the shape must evolve. It is deliberately not any one system's model; it is the enterprise's model, which is why ownership must sit with an architecture or data-governance function rather than any single application team. Business Central integrations, for instance, benefit enormously from mapping to a canonical model rather than exposing the ERP's internal entities directly, a point I develop in the Business Central APIs and integrations guide.

A caution on over-engineering: a canonical model can be taken too far. Trying to model every attribute of every domain up front produces a bloated, slow-moving schema that becomes its own bottleneck. Model the fields that actually flow between systems, version the model deliberately, and let it grow with real need. The goal is a shared vocabulary for the data that crosses boundaries, not a universal enterprise ontology that no one can finish.

8. Non-functionals: security, scale, resilience

Functionality gets an integration into production. Non-functional properties decide whether it survives there. Three deserve architectural attention from day one, because retrofitting them later is painful and sometimes impossible.

Security must be uniform across the landscape, not improvised per integration. Every integration is a doorway between systems and therefore an attack surface, and the landscape is only as strong as its weakest connection. The architectural stance I hold to: authenticate every call with a modern mechanism such as OAuth 2.0 or mutual TLS, never static shared secrets in code; grant least-privilege scopes so an integration can touch only the data it needs; encrypt everything in transit; and hold credentials in a secrets vault, rotated, never in configuration files or source control. When security is an architectural standard rather than a per-project afterthought, a new integration inherits it by default.

Scale means the architecture accommodates growth in volume without redesign. This is where the synchronous-versus-asynchronous choice returns: an asynchronous, queue-based backbone naturally absorbs bursts, because the queue buffers load the consumer cannot yet handle, whereas a synchronous chain fails under the same burst. Designing for scale also means avoiding single choke points, sizing the message backbone and gateway for peak plus headroom, and ensuring the canonical transformation layer can be scaled horizontally. You do not need to build for ten times today's load on day one, but the architecture must not forbid it.

Resilience is the property that the landscape keeps functioning when parts of it fail, because parts of it will fail. Asynchronous decoupling is the foundation: if a consumer is down, messages wait in the queue rather than being lost, and processing resumes when it recovers. On top of that, circuit breakers stop a failing downstream from dragging its callers down, timeouts prevent indefinite hangs, and the dead-letter-plus-alert pattern ensures nothing disappears silently. The test of a resilient architecture is simple: take any single system offline and ask what happens to the rest. In a well-designed landscape the answer is "flows queue and resume," not "the business stops."

9. Governance and standards

The most technically elegant architecture will still degrade into a tangle without governance, because architecture is not a one-time act but a continuous discipline. Governance is what keeps every future integration inside the design instead of quietly working around it. It does not have to be heavy, and heavy governance that slows delivery to a crawl is its own failure mode, but it must exist and it must have teeth.

The governance elements I put in place are modest but non-negotiable. A published set of integration standards: the approved patterns, the canonical models, the security requirements, the error-handling expectations, written down where every team can find them. An API and interface catalogue, so integrations are discoverable and reuse is possible rather than teams rebuilding what already exists. A lightweight design review for new integrations, checking they conform to the standards before build, which catches drift at the cheapest possible moment. And clear ownership: someone accountable for the canonical model, someone accountable for the integration platform, someone who can say no to a point-to-point shortcut that would undermine the topology.

The reason governance matters so much is that architecture erodes at the margins. No single integration destroys a good design. It is the tenth expedient shortcut, each individually defensible under deadline pressure, that collectively returns the landscape to spaghetti. Governance is the mechanism that makes the right way the easy way, so that conforming to the architecture is less effort than circumventing it. When that balance holds, the architecture sustains itself. When it does not, no diagram survives contact with the delivery schedule. This is the through-line of a real integration strategy, developed further in the integration strategy guide.

10. References

The single most valuable reference for anyone designing integration architecture is Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf. It catalogues the messaging patterns, the message channels, routers, translators, and endpoints, that underpin every serious integration platform, and it gives a shared vocabulary that lets architects communicate precisely. Much of the pattern language used in this guide, and in the enterprise service bus and message-backbone products themselves, traces directly to that work. If you design integrations for a living, it belongs on your desk.

Beyond that foundational text, the practical references worth knowing are the standards bodies and specifications that govern the mechanics: the OAuth 2.0 and OpenID Connect specifications for authorisation and identity, the OpenAPI specification for describing REST interfaces, and the AsyncAPI specification for describing event-driven ones. These are living standards maintained by their respective communities, and they are the common ground on which interoperable integrations are built. I deliberately avoid pointing at deep, volatile URLs here, because specifications move; the names above are stable and easily found.

Final thoughts

Integration architecture is not glamorous work, and it rarely gets the credit it deserves, because a well-architected landscape is invisible. Nothing breaks, changes absorb cleanly, new systems slot in without drama, and everyone assumes it was always going to be that way. The tangled landscapes get all the attention, precisely because they were never designed. The whole point of the discipline is to be boring in production, and that boredom is earned entirely in the design phase.

The method holds regardless of which tools you eventually buy. Start with the business processes that cross system boundaries. Map the systems and the data honestly, verifying against reality rather than documentation. Choose a topology on purpose and control the combinatorial growth. Normalise through a canonical data model so mapping effort grows linearly. Make the recurring decisions, synchronous versus asynchronous, error handling, security, monitoring, once and centrally. Design the non-functionals in from the start. And govern the whole thing so it does not erode at the margins. Do that, and you will have built the kind of architecture that scales gracefully instead of the tangle nobody dares touch. For the wider context this sits within, return to the enterprise system integration pillar.

Related reading: Enterprise system integration explained, How to choose the right integration method, Integration strategy for enterprise applications, Common integration mistakes, Business Central APIs and integrations.