Enterprise integration patterns: connecting ERP, CRM and your own software

An enterprise rarely runs on a single application. Finance lives in an ERP, sales in a CRM, support in a ticketing tool, and your custom software sits among them. The value of each depends on how well they exchange data.

Decide who owns what

Before choosing a technology, decide the system of record for each kind of data: customers, products, prices, orders, invoices. When two systems both believe they own the customer address, conflicts are guaranteed. Write the ownership down, including who is allowed to change what.

The main integration styles

Request-response APIs. One system calls another's API when it needs data or wants an action performed. Simple, immediate and easy to understand. The caller depends on the other system being available and fast right then.

Event-driven messaging. Systems publish events such as "order placed" to a broker or queue, and others react. This decouples systems in time, absorbs bursts and lets new consumers appear without changing the producer. The cost is eventual consistency and harder debugging.

Batch and file transfer. Scheduled exports and imports, via files or bulk endpoints. Unfashionable but still common, particularly with older platforms, and often perfectly adequate when near-real-time is not needed.

Shared database access. Reaching into another system's tables directly is tempting and risky: it couples you to internal structure and bypasses that system's rules. Avoid it where an interface exists.

Integration platforms and middleware. Dedicated tools provide connectors, mapping and monitoring. They speed up standard integrations, and at scale they need governance like any other critical system.

Pick the simplest style that meets the timing and reliability needs. Real-time everywhere is expensive.

Reliability patterns that matter

• Idempotency. Networks retry. Design operations so that receiving the same message twice produces the same result, using unique request or event identifiers.
• Retries with backoff, and a limit, so a struggling system is not hammered.
• Dead-letter queues. Messages that repeatedly fail go somewhere visible for investigation instead of disappearing or blocking everything.
• Timeouts and circuit breakers. Do not let one slow dependency stall the whole application.
• Ordering and duplicates. Do not assume messages arrive once and in order unless the platform guarantees it, and even then, verify.
• Reconciliation. Run periodic comparisons between systems to find drift, because some failures are silent.

Mapping and contracts

Systems use different names, formats and codes for the same thing. Keep transformations in one clear place, document the mapping, and version interfaces so changes do not break consumers unexpectedly. A canonical data model can reduce point-to-point mapping when many systems are involved, but it needs ownership to avoid becoming a bottleneck.

Security and access

Use least-privilege service accounts, protect credentials in a secrets manager, encrypt data in transit, and log who accessed what. Integrations are a common route into sensitive data, so they deserve the same scrutiny as user-facing features. Be aware of data-protection obligations when personal data crosses system or national boundaries.

Make it observable

Every integration should answer: did the last run succeed, how many records moved, what failed and why, and how long did it take? Dashboards and alerts for failures, lag and volume anomalies turn mysterious data discrepancies into quick diagnoses.

What to take away

Settle data ownership first, choose the simplest style that meets timing needs, and build in idempotency, retries, dead-letter handling and reconciliation. Integrations that are observable and well owned stop being the part of the system everyone fears.