Enterprise Application Integration: 7 Architecture Patterns for Connecting Legacy Systems, SaaS, and Cloud Platforms

A practical guide to building an integration architecture that connects modern applications, legacy systems, SaaS platforms, and cloud services without creating another layer of complexity.

No company sets out to build an integration mess.

It usually happens one reasonable decision at a time.

Sales needs customer information from the ERP, so someone creates an integration. Finance adopts a new SaaS application and needs transaction data from the CRM, so another connection is added. A customer portal needs real-time order status. A warehouse system needs product data. A cloud analytics platform needs information from several operational systems.

Each individual connection solves a real problem.

The difficulty appears later.

A change in one application suddenly affects four others. Nobody is completely sure which system owns a particular piece of data. A field added to an ERP record breaks an integration downstream. An API that seemed temporary becomes business-critical. Teams hesitate to modernize old applications because too many other systems depend on them.

At that point, the challenge is no longer simply connecting applications.

It is managing the growing web of dependencies between them.

That is the real purpose of enterprise application integration architecture.

A good integration architecture does more than move data from System A to System B. It gives applications room to change without forcing the entire technology estate to change with them.

The following seven patterns are useful ways to think about that problem.

1. API-Led Integration: Put Stable Contracts Between Systems

One of the most common integration mistakes is allowing every consuming application to understand the internal structure of the system providing the data.

Imagine a CRM exposes its customer tables directly to several applications.

A billing platform reads from them. A support portal depends on them. A reporting application uses the same structure.

Everything works until the CRM changes.

Now a relatively small change inside one application becomes a coordinated change across multiple systems.

An API layer reduces that coupling.

Instead of telling consumers how the CRM stores customers, the organization exposes a stable customer capability:

GET /customers/{customerId}

The consumer depends on the contract, not the implementation behind it.

Today, that API may obtain customer information entirely from the CRM.

Tomorrow, it might combine information from a CRM, master-data platform, billing service, and another internal database.

The consuming applications should not need to know.

This is where API-led architecture becomes valuable: it creates boundaries around business capabilities.

Customer information is a capability.

Order management is a capability.

Inventory availability is a capability.

Pricing is a capability.

Shipment tracking is a capability.

When integrations are designed around those capabilities rather than around individual applications, replacing or modernizing backend systems becomes significantly less disruptive.

The important part is not simply creating more APIs. An enterprise can have hundreds of APIs and still be tightly coupled.

The value comes from designing stable contracts that protect consumers from unnecessary backend change.

2. Integration Layers: Keep Orchestration Out of Every Application

Another pattern is to introduce a dedicated integration or middleware layer between applications.

Consider an order-processing workflow.

A customer places an order through a digital storefront. The transaction needs to validate the customer, check inventory, calculate pricing, create the order in an ERP, notify fulfillment, update a CRM, and send confirmation.

Without an integration layer, the storefront may gradually become responsible for all of those interactions.

That creates a problem.

The application that should be responsible for the customer experience now contains business orchestration logic for half the enterprise.

An integration layer provides another option.

The storefront sends the business request to an integration service. That service coordinates the required systems and returns the appropriate result.

The application remains focused on its own responsibility.

This separation is especially useful when several applications need the same orchestration.

Instead of implementing the workflow repeatedly, the organization creates a reusable integration capability.

There is a trade-off, though.

An integration layer can become a new monolith if every transformation, decision, workflow, and business rule is pushed into one central platform.

The goal should not be:

Put everything in middleware.

It should be:

Put integration responsibilities in the integration layer while leaving application and domain responsibilities where they belong.

That distinction matters as the environment grows.

3. Event-Driven Integration: Stop Making Everything Wait

APIs work well when one application needs an immediate response from another.

But not every business process requires synchronous communication.

Suppose an order is created.

Several things may need to happen afterward:

Inventory needs to be updated. The CRM may need the latest transaction. Analytics needs the event. Fulfillment needs to begin. A customer notification needs to be sent.

If the order API calls every downstream application synchronously before returning a response, the customer-facing transaction becomes dependent on every one of those systems being available.

That can turn a small downstream problem into a customer-facing outage.

An event-driven architecture changes the model.

The order system records the transaction and publishes something like:

OrderCreated

Applications interested in that event react independently.

Inventory can consume it.

Fulfillment can consume it.

Analytics can consume it.

A CRM integration can consume it.

The order service does not need to know every future consumer.

That makes the architecture more flexible.

It also introduces new engineering concerns.

Events can arrive more than once. They may arrive out of order. Consumers can be temporarily unavailable. Data becomes eventually consistent rather than immediately consistent.

So event-driven architecture is not automatically better than API-based integration.

The useful question is:

Does the calling application genuinely need an immediate response from the downstream system?

If the answer is yes, synchronous APIs may be appropriate.

If the answer is no, asynchronous events can reduce unnecessary dependencies.

Many mature enterprise environments ultimately need both.

4. Canonical Data Models: Reduce the Cost of Translation

One of the least glamorous integration problems is also one of the most expensive: different applications describing the same thing differently.

Take a customer.

An ERP might represent the customer like this:

{

“CUST_NO”: “10248”,

“CUST_NM”: “Acme Ltd”,

“REG”: “US-EAST”

}

A CRM might use:

{

“accountId”: “10248”,

“companyName”: “Acme Ltd”,

“region”: “East”

}

A SaaS billing system may expect something else entirely.

When every application transforms directly into every other application’s format, transformation logic multiplies quickly.

With three systems, this may be manageable.

With thirty systems, it becomes painful.

A canonical model introduces a common enterprise representation.

Each source translates into the shared format.

Each target translates from it.

Conceptually:

ERP ───────┐

│

CRM ───────┼──> Common Customer Model ───> Consumers

│

SaaS ──────┘

The advantage is reduced transformation complexity.

The danger is attempting to design one enormous universal model capable of representing every possible field in every system.

That often creates another kind of complexity.

A more practical approach is to design canonical models around meaningful business domains.

A customer model.

An order model.

A product model.

A shipment model.

A supplier model.

Keep them clear enough to reduce unnecessary mapping while allowing individual systems to preserve details that truly belong to them.

5. Hub-and-Spoke Integration: Useful Until the Hub Becomes the Problem

Hub-and-spoke architecture has been used in enterprise integration for a long time, and for good reason.

Rather than connecting every application directly to every other application, systems connect through a central integration hub.

Without the hub, five systems can quickly create a surprising number of direct dependencies.

With the hub, each application primarily understands how to interact with the central integration layer.

That makes transformation, routing, security, and monitoring easier to standardize.

The pattern still has weaknesses.

If all integration traffic, business logic, transformation rules, and orchestration accumulate inside one central hub, it can become difficult to change.

Every project starts competing for the same central integration team.

Deployments become risky.

The hub slowly changes from an architectural simplification into an organizational bottleneck.

Modern implementations therefore tend to use the pattern more selectively.

Centralize capabilities that genuinely benefit from common control — governance, security, discovery, shared infrastructure and platform standards — while allowing individual integration capabilities to remain modular.

The goal is centralized consistency without centralized dependency on a single team for every change.

6. Hybrid Integration: Assume Legacy and Cloud Will Coexist

Technology diagrams often make modernization look cleaner than it really is.

The old system disappears.

The new cloud platform replaces it.

Everyone moves forward.

Enterprise reality is usually different.

A core ERP may remain on-premises because replacing it is a multi-year program.

A mainframe may still process transactions extremely reliably.

A new CRM lives in the cloud.

HR runs on SaaS.

Customer-facing applications run across several cloud services.

Data platforms may span multiple environments.

For years — sometimes decades — the organization operates a mixture of old and new.

That makes hybrid integration architecture essential.

Instead of treating legacy systems as temporary problems that will disappear soon, design clear boundaries around them.

A legacy application might expose its capabilities through APIs.

Changes in an older database might be published as events.

Batch processes may remain appropriate for certain workloads.

Secure integration gateways can connect cloud applications to on-premises systems without exposing internal infrastructure unnecessarily.

The objective is not to pretend every system is modern.

It is to prevent older systems from forcing every newer application to adopt old integration patterns.

A useful integration architecture lets modernization happen gradually.

That is particularly important because integration architecture often becomes the bridge that allows a business to replace systems incrementally instead of attempting one massive transformation.

7. Domain-Oriented Integration: Let Ownership Scale With the Organization

A central integration team works well when an organization has a manageable number of systems and projects.

As the company grows, the team can become overwhelmed.

Every new API requires its involvement.

Every data mapping waits in its backlog.

Every integration change needs approval.

Eventually, the architecture may be scalable while the operating model is not.

Domain-oriented integration addresses this by distributing ownership.

A customer domain might own customer APIs and customer events.

An order domain owns order capabilities.

A product domain owns product information.

A finance domain owns financial integration interfaces.

A central platform team still has an important role, but it changes.

Instead of building every integration, it creates guardrails.

It defines security standards, API conventions, deployment patterns, observability requirements, reusable components, governance policies, and platform capabilities.

The domain teams build within those boundaries.

This creates a useful balance:

centralized standards, distributed ownership.

It also makes responsibility clearer.

When an API fails, there should be an obvious team that owns it.

When a contract changes, consumers should know who is responsible.

When a new integration capability is needed, teams should not need to reverse-engineer who owns the underlying logic.

Architecture scales better when ownership scales with it.

Which Integration Pattern Should You Choose?

There is rarely one correct pattern for an entire enterprise.

Most mature environments use several.

Situation

Useful Starting Pattern

Multiple applications need the same business capability

API-led integration

Complex workflows cross several applications

Integration/middleware layer

Downstream processing does not need an immediate response

Event-driven integration

Many applications represent the same business data differently

Canonical data model

Many point-to-point integrations need centralized control

Hub-and-spoke

Cloud, SaaS and legacy/on-premises systems must coexist

Hybrid integration

Many teams need to build integrations independently

Domain-oriented integration

The mistake is not using multiple patterns.

The mistake is applying one pattern everywhere because the organization happens to own a tool that supports it.

Architecture should begin with the interaction that needs to happen.

Then choose the pattern.

Then choose the technology.

Not the other way around.

The Most Expensive Integration Problem Is Often Change

Integration architecture is frequently evaluated on runtime concerns:

How quickly does data move?

How many transactions can the platform process?

How reliable is the infrastructure?

Those metrics matter.

But there is another question that deserves equal attention:

How expensive is change?

Suppose the company replaces its CRM.

How many integrations must be rewritten?

Suppose an ERP changes an internal schema.

How many consuming applications need to change?

Suppose an acquisition introduces another set of applications.

How difficult is it to incorporate them?

Suppose an AI application needs controlled access to customer, inventory and order information.

Can existing business capabilities be reused, or must another set of direct connections be created?

The quality of the architecture becomes visible during moments like these.

Tightly coupled environments make every change ripple outward.

Well-designed integration boundaries absorb much of that change.

That is one of the strongest reasons to invest in architecture before integration complexity becomes obvious.

Avoid Choosing the Platform Before the Architecture

Enterprise teams often begin integration discussions with product names.

Should we use an iPaaS?

An API management platform?

An event broker?

A middleware platform?

A cloud integration service?

Those are valid questions, but they come too early.

A tool cannot decide whether a workflow should be synchronous or event-driven.

It cannot decide where domain ownership belongs.

It cannot decide what constitutes a stable business contract.

It cannot determine the right canonical representation of a customer.

Those are architecture decisions.

Technology should implement those decisions — not substitute for them.

A powerful integration platform applied to a poorly structured architecture can simply help an organization produce complexity faster.

A Practical Test of Your Current Integration Architecture

Pick one important business transaction.

An order is usually a good example.

Trace it from the moment the customer initiates the request until every downstream system has completed its work.

Then ask:

Can you identify every application involved?

Can you tell which system owns the authoritative data at each stage?

Could one downstream application be replaced without changing every other application?

Do systems communicate synchronously even when they do not need an immediate response?

Are transformations being repeated in several integrations?

Can you trace one transaction across the entire flow?

Is API or event ownership obvious?

Can teams determine which consumers depend on a contract before changing it?

If those questions are difficult to answer, the problem is unlikely to be one bad integration.

It is probably architectural.

Integration Should Make Modernization Easier, Not Harder

Enterprise application integration is sometimes treated as plumbing.

Connect the applications, move the data and continue with the project.

But integration becomes much more strategic as the enterprise grows.

It determines how easily systems can be replaced.

How quickly new applications can be introduced.

How safely APIs can evolve.

How independently development teams can work.

How effectively cloud and legacy technologies can coexist.

And increasingly, how easily new AI and automation capabilities can access trusted enterprise information.

The goal is therefore not to eliminate complexity.

Large enterprises will always have complex technology estates.

The goal is to contain that complexity behind clear, well-owned integration boundaries.

API-led integration can protect consumers from backend changes.

Event-driven architecture can reduce unnecessary runtime dependencies.

Canonical models can simplify data translation.

Middleware can separate orchestration from applications.

Hub-and-spoke architectures can reduce uncontrolled point-to-point connections.

Hybrid integration can allow old and new technologies to coexist.

Domain-oriented ownership can help integration scale across teams.

None of those patterns is universally correct.

Used deliberately, however, they all serve the same larger purpose:

making enterprise systems easier to connect today without making them harder to change tomorrow.

And that may be the most useful measure of a good integration architecture.