Five Enterprise Integration Patterns and When Each One Applies

Integration requests usually arrive named after a department, such as the sales integration or the payroll integration. The design depends on something else entirely, which is how the data moves and who is waiting for it. Five patterns cover most of what companies ask for, and recognising which one you have tells you where it will break before anyone writes code.

Name the pattern before the department

Before choosing tools, write one sentence for the flow you want: what moves, from where, to where, and who waits for it. That sentence usually places the flow in one of five patterns. They are patterns, not client case studies, and the one real project cited here is described with its documented scope.

Pattern	What moves	Who waits	Where it breaks
1. Order to cash	One record, forward through a chain	The customer and accounts	A step fails halfway
2. Master data in step	The same record, kept equal in two systems	The next scheduled run	Both sides edit it
3. Combined customer view	Copies or references from several systems	A person on a screen	Customer identity
4. Unified reporting	Periodic copies into a warehouse	Managers, weekly or monthly	Copying too much
5. Partner events	Updates from suppliers or warehouses	Your planners	Duplicates and late events

The decision rule follows from the second and third columns. If a person or customer waits for the result, treat it as a chain and make failures visible. If people only read the data, keep the source systems in charge and copy what is needed. If an outside party starts the change, design for events arriving late or twice.

Order to cash, a record moving down a chain

Take a tiles manufacturer that sells through dealers across Gujarat. A confirmed order in the CRM creates an invoice in the ERP, which reserves stock, which in turn books a dispatch with the transporter. Each step starts when the previous one confirms.

The risk is partial completion. The invoice is raised, the stock is reserved, and then the transporter's API times out. Someone has to see exactly where the chain stopped and resume it from that point without raising a second invoice, because a duplicate GST invoice for the same order is a month-end problem for the accountant and an irritation for the dealer.

The one documented example here has the same shape, applied between sales and delivery. Nebula Digital Accessibility needed to turn scoping answers into consistent quotes. BizHues built a guided estimator with a rules engine that converts the answers into effort by role and three package options. The tool generates a proposal and draft statement of work, with approvals for discounts. Integrations push deals to the CRM and trigger e-signature, and after acceptance the quote becomes a delivery plan with a work breakdown and a first checklist. The Nebula project story has the details.

1. 01Estimatorrules produce options
2. 02Proposal and SOWapprovals for discounts
3. 03CRM and e-signaturedeal pushed, signature requested
4. 04Delivery planwork breakdown and checklist

Each step starts when the previous one confirms, so a failure should stop the chain where people can see it.

HR to payroll, one record kept in step

A promotion or a new joiner in the HR system has to reach payroll before the month's run on the 25th. The record does not move forward through a chain. It exists in both systems, and the two copies need to agree on the day it matters.

The usual failure is that both sides edit it. HR updates the designation, payroll corrects the bank account, and the next sync overwrites one with the other. The fix is a business decision before it is a technical one. For each field, name the system that owns it, and let the other system only read it. Then run a check a few days before the payroll cut-off that lists every record where the two disagree, so a person resolves them while there is still time.

Reading across systems without owning the data

Two patterns read data rather than pass it along. In both, the source systems stay the owners and the view holds copies or live references.

A combined customer view

An agent at an insurance broker wants to see a customer's policies, renewal reminders and open claims on one screen instead of three. The combined view pulls from the CRM, the marketing tool and the claims desk.

Combined view

• CRM
• Marketing tool
• Claims or tickets
• ERP

The source systems stay the owners. The view holds copies or live references.

It breaks on identity. Each system has its own customer ID, and the same person may be a mobile number in one, an email address in another and a policy number in the third. The view needs a matching rule before it can show anything reliable, and what counts as the same customer is a business decision, so the head of the customer team signs it off before anyone builds a screen.

Unified reporting

Unified reporting copies data from the CRM, the ERP and marketing tools into a central warehouse for dashboards. Its failure is copying everything, including data nobody reports on, which then has to be secured and explained to the auditor. Start from the reports people actually read and copy only what they need.

Supplier and warehouse updates as events

Supply chain visibility is the fifth pattern. The ERP, supplier portals and warehouse systems exchange stock levels and shipment status. An alert can trigger a reorder before a fast-moving SKU runs out in the week before Navratri, and planners can see where goods are held up between the depot and the dealer.

Of the five, this is the one most likely to be event-driven, since suppliers update at their own times and polling their portals every ten minutes wastes effort on both sides. Events bring their own problem. They can arrive late, out of order or twice, so every update needs a stable key and a timestamp, and the receiving side must be able to apply the same event twice without changing the result. Our guide to what middleware does in an integration covers the queues and brokers that usually carry these events.

Where integration plans go wrong

Most of the trouble starts with choosing the pattern by the department's name. A team asked for a "sales dashboard" builds a chain that pushes records around, when what was needed was a read-only view. Chains get built with no stop point, so a failed step is discovered when the dealer calls. Combined views get built before anyone agrees on identity, and the first demo shows the same customer three times.

Two engineering choices come up in every pattern, and they are often left too late. First, decide per flow whether the caller waits for an answer through a synchronous API call or is told later through a queue or event. Second, decide how a flow can be repeated safely. Give each record a stable key so that running it twice updates the same invoice, payroll entry or ticket instead of creating another. We ask about the key before we ask about the transport.

The last mistake is paying for speed nobody uses. A report read once a week does not need real-time updates that cost money every hour.

Choosing which flow to integrate first

1. List the flows where a person currently waits for another team to update a system.
2. Write the one sentence for each and place it in one of the five patterns.
3. For chains, decide where the stop point is and who gets told when a step fails.
4. For views, settle the identity rule and the owner of each field.
5. For partner events, agree the key and what happens to a duplicate.

Pick the flow from step one that costs the most hours each week, and bring its sentence, the systems involved and the name of each system's owner to the first conversation. Our enterprise application integration work usually starts from a list like that.