Enterprise Integrations

Overview

An enterprise integration is the plumbing that connects the systems a business runs on. When a customer order flows from the website into the order system, then to the warehouse system, then to the invoicing system — without anyone re-typing it — that flow is the work of integrations. The systems themselves do the visible work; the integration layer is the invisible part that moves the data between them.

Every business with more than a couple of systems already has integrations, whether it planned them or not. They might be manual — someone exports a spreadsheet and imports it into the next system. They might be fragile — a file dropped onto a shared drive that is read by a scheduled job that fails without warning. Or they might be invisible — a patch of code written years ago that moves data, and nobody is quite sure how, or what happens when it breaks.

The value of a properly built integration is not the technology. It is the removal of the manual, fragile work that sits between systems. When integrations are right, data moves automatically, reliably, and with a record of what moved. When they are wrong, the business pays in three currencies: time (people re-entering and reconciling), risk (data that is wrong or late), and lost opportunity (reports and decisions built on incomplete data).

The difficulty of integration is usually underestimated. Connecting two systems means agreeing on what data means in each, what happens when a record exists in both but disagrees, what happens when one system is down, what happens when the same order is updated twice, and how errors are handled without losing the data. These are not technical problems; they are data problems, and they are why integrations that "look easy" turn out to be the most fiddly work in a business's technology estate.

This page gives you the honest picture: what integrations involve, where they break, and what a reliable integration layer is made of.

What We Build

Integrations come in many shapes. These are the kinds we build most often, and what they do in practice.

System-to-system integration. Connecting two core systems so data flows between them automatically: the CRM and the accounting system, the order system and the warehouse, the ERP and the supplier portal. The integration keeps the two sides in agreement — new customers, updated orders, fulfilled lines, settled invoices — without a person in the middle.

Hub-and-spoke integration. Connecting a central system to the systems around it. The ERP or the CRM is the hub, and the spokes are the tools that feed it and read from it — the website, the e-commerce store, the warehouse system, the payment provider, the reporting tool. The hub holds the core records, and the spokes move data in and out.

Legacy-to-modern integration. Connecting an aging system that the business cannot replace yet to the modern tools it needs to work with. The old system is not a dead end; it is an active system with data and logic the business depends on, and the integration lets modern software read from it and write to it safely.

Real-time event flows. For the data that must move immediately, not on a schedule. An order placed online reaches the warehouse in seconds. A payment confirmation updates the order status at once. A shipment status change reaches the customer portal immediately. Event-driven integration moves the data the moment it happens, instead of the next time a job runs.

Batch and file-based integration. For the data that does not need to move instantly, moving in scheduled, reliable batches. The nightly feed of orders, the end-of-day stock update, the weekly product catalog. Batch integration is simpler and more forgiving, and it is right for a large part of business data.

API design and delivery. Building the interfaces that systems use to talk: the APIs that let a partner's system pull your data, that let your mobile app read from your platform, that let an external vendor push data in. A well-designed API is the difference between integrations that are easy to build and ones that fight everyone.

Data mapping and transformation. The part of integration that is really about data: translating the customer record in one system into the customer record in another, agreeing which fields map to which, converting formats, handling the fields one system has and the other does not. The transformation is where the data meaning is decided.

Integration platform maintenance. Many businesses have an integration platform or middleware already — an iPaaS, a message broker, a set of custom scripts — and it has become unreliable or undocumented. We take over, fix, document, and stabilise it, and we keep it running.

Integrations built into a bigger build. When we build a system — an ERP, a CRM, a custom application — the integrations with the surrounding systems are part of the build, not an add-on. The data flows are designed with the system, so the system starts connected rather than being connected later.

Decommissioning integrations. When a business replaces a system, its integrations must be cut over, replaced, or retired — and the old ones are often still running, still sending data somewhere. We map what is connected, migrate the flows that matter, and retire the ones that do not.

The right integration shape depends on the data, the timing, and the systems. The constant is the same: data moves reliably, with a record of what moved, and the business does not have to think about it.

When This Service Makes Sense

Integrations are not a luxury; they are a consequence of having more than one system. But investing in a proper integration layer makes sense in specific conditions, and it is worth being honest about when.

It makes sense when data is being typed in twice. The order is entered into the order system and again into the warehouse system. The customer is created in the CRM and again in accounting. Every double entry is a cost and a chance for error. An integration removes the second entry, and the savings are immediate and measurable.

It makes sense when reports do not agree. The sales system says one figure, accounting says another, and the management report reconciles them with footnotes. The systems do not disagree because people are wrong; they disagree because the data is not shared. An integration makes the reports read from the same facts.

It makes sense when decisions depend on stale data. The stock level the team sees is from yesterday's export. The order status is only as good as the last time someone checked. If decisions are being made on data that is known to be late, an integration closes the gap between the real state and the visible state.

It makes sense when a process breaks at the seams. The workflow between systems has manual steps — an email, a phone call, a re-entry, a "please confirm you got this". The seams are where work stalls, gets lost, and takes longest. An integration removes the seams.

It makes sense when a legacy system must work with modern ones. The core system cannot be replaced yet, but the business needs it to work with modern tools. The alternative to an integration is running two parallel sets of records, which nobody wants. The integration is the bridge that keeps the old system useful.

It makes sense when the business is preparing for a platform change. Replacing an ERP, moving to a new CRM, or adding a warehouse system means the integrations around the old system must be understood, migrated, and rebuilt. Doing this deliberately, as part of the project, is far cheaper than discovering it after.

It probably does not make sense when the volume is trivial. If two systems exchange fifty records a month and a spreadsheet handles it fine, a custom integration may not earn its cost. Integration is worth it when the volume, the frequency, or the cost of error makes the manual path expensive.

It probably does not make sense as a project without an owner. Integrations fail when nobody owns the outcome. If there is no person accountable for the data flowing correctly, the integration will not be maintained, and it will decay. The business, not the technology, is the deciding factor.

It probably does not make sense when the underlying systems are about to be replaced. Connecting two systems that are both being decommissioned next quarter is waste. The integration should wait for the replacement — unless the interim connection is genuinely cheaper than the status quo.

The honest test is whether the seams between systems are costing the business time, accuracy, or decision quality. If they are, integration is not a project; it is the removal of a known cost. If they are not, there is nothing urgent to build.

Common Business Problems

The problems that lead businesses to integrations are the symptoms of systems that do not share data. These are the patterns we see most.

Manual re-entry between systems. The order is entered twice, the customer is created three times, the invoice is matched by hand. Every re-entry is wasted time and a chance for a typo that will surface somewhere, later. The double entry exists because the systems do not connect — and the fix is the connection, not more care in typing.

Reconciliation as a permanent chore. The spreadsheet that compares the order system with the warehouse system, the daily check that the invoices match the deliveries, the monthly exercise of making the reports agree. Reconciliation exists to catch the differences that integrations would prevent. It is a tax on disconnected systems.

Reports that nobody fully trusts. The management dashboard is built by hand, and the people reading it know it took a day to assemble and will be stale by Tuesday. The distrust is reasonable: a hand-assembled report is as good as the person who built it. When the data is integrated, the report reads from the same facts the operations use, and the distrust goes.

The same event handled as three separate steps. A new customer is added to the CRM, told to the warehouse, and entered in accounting — three people, three entries, three chances for the record to diverge. The event happened once; the systems should learn about it once. The integration makes the event the system's event, not three people's chore.

Silent failures between systems. The nightly file did not arrive, the sync stopped running, the mapping broke on an unexpected record — and nobody knew until the data was needed. Silent failures are the worst kind, because the damage is done before it is seen. A proper integration layer fails loudly, alerts, and preserves the data.

One system is always the source of truth, and it is the wrong one. The spreadsheet is the real record, and the systems are maintained to match it. The spreadsheet is the worst system in the estate — single point of failure, no access control, no audit — and the business runs on it because the systems do not agree. An integration replaces the spreadsheet with the systems working together.

Data that means different things in different systems. The "customer" record in one system is a person and in another is a company. "Net" in one system means after tax and in another before. The mismatches are discovered one by one, usually by the person who built the reconciliation. A proper integration defines what the data means in each place and maps it deliberately.

Slow, manual handoffs that stall the work. An order sits in the order system until someone emails the warehouse. A delivery note is filed and re-keyed into the invoicing system days later. The seams slow the work, and the delays compound. Integrations turn the handoff into an automatic flow, and the work stops waiting.

The system upgrade that broke everything. A vendor updated their system, and the file format changed, and the connection that had "worked for years" failed. The integrations that were never documented are the most fragile part of a technology estate. Documented, monitored integrations survive changes; undocumented ones break and surprise.

A new system that the rest of the estate cannot see. The business bought a great new tool, and now the data lives in a new island. The tool is used, but it is not part of the flow — data must be exported and imported by hand. The new system needs to join the estate, and the estate needs to accept it.

Typical Features

The features below are what make an integration layer reliable. They are the difference between data that moves and data that moves correctly.

Agreed data definitions. Before anything is connected, the meaning of the data is agreed: what a customer is, what an order status means, which fields are the identifiers, which are optional, which are authoritative. The definition is written down, because the data means something in each system and the integration must preserve that.

One source of truth for each fact. Each piece of data has one authoritative home. The customer record lives in the CRM and updates flow out; the financial transaction lives in accounting and flows in. The integration is built around the truth of each fact, not around whichever system happens to touch it first.

Validation at the boundary. Every record that crosses the integration is checked before it is accepted: does it have the required fields, does the reference exist, is the value within the allowed range? Invalid records are quarantined, not silently dropped, so the data quality problem is visible and fixable rather than hidden.

Retries and recovery. The integration assumes things will fail — a system will be down, a service will time out, a file will arrive late — and it is built to survive it. Failed deliveries are retried, the backlog is processed when the target returns, and nothing is lost because a service had a bad minute.

Error handling that is visible. When something cannot be delivered, the failure is visible: an alert, a queue, a report. The error is preserved with the data and the reason, so a person can see what failed and why, and fix it. Silent failure is designed out.

Idempotency. The same event delivered twice does not create two records. If a message is retried and a record is processed twice, the system recognises it and applies it once. Idempotency is what makes retries safe — and retries are what make integrations reliable.

Ordering and dependency. Where the sequence matters, it is preserved. The customer is created before the order that references them. The delivery is recorded before the invoice is generated. The integration respects the dependencies between records, so the receiving system never sees a record whose context does not exist yet.

Monitoring and alerting. The integration is watched: what is moving, what is waiting, what has failed, how old the oldest queue item is. Problems are caught by alerts, not by the business noticing the data is wrong. An unmonitored integration is not reliable; it is merely optimistic.

An audit trail. There is a record of what moved, when, and what happened to it. When a question arises about a record — where did this value come from, why did this order not reach the warehouse — the trail answers it. The audit trail turns hindsight into a lookup.

Graceful degradation. When a downstream system is down, the integration keeps the business running: the upstream keeps accepting work, the queue holds it, and delivery resumes when the system returns. The integration absorbs the failure of its parts without failing the whole.

Testability. The integration can be tested: a safe environment where records can be run through without affecting real data, and test records that exercise the edge cases. A reliable integration is one that can be proven, before and after every change.

Documented, owned, and maintainable. The integration is documented — what it does, how it works, what the failure modes are — and it has an owner. A business that inherits documented, owned integrations is not hostage to the people who built them.

These features are not exotic. They are what reliable data movement requires, and they are why a proper integration layer is different from a script that happens to work most of the time.

Our Approach

We treat integrations as the infrastructure of the business, because that is what they are. The data that moves between systems is the business's operational record, and it is handled accordingly.

Map the estate before touching it. We start by finding out what is actually connected: the systems, the flows, the files, the scripts, the handoffs. Most businesses discover connections they forgot existed and manual steps they did not realise were manual. The map comes before the change.

Agree what the data means. We agree, with the people who own the data in each system, what the records mean, which facts are authoritative, and what must stay consistent. This is done in conversation, not in a technical spec, because the knowledge lives in the people who work with the data.

Design around reliability, not just connectivity. We build the integration to survive failure: retries, validation, quarantine, idempotency, monitoring. The goal is not that data moves most of the time; it is that the business never loses data and always knows its state.

Move the data in defined, verifiable steps. Each integration is delivered in steps, each one tested and verified before the next. The data flows in a controlled way, with checks at each boundary. There are no big-bang switches that change everything at once.

Bring the legacy along safely. Where a legacy system is involved, we connect to it in a way that does not disturb it — the integration works with the old system on its own terms. The legacy system is treated with respect: it carries data and logic the business depends on, and the integration preserves that while making the data useful elsewhere.

Keep a person accountable. We design the integration so the business can own it: documented, monitored, and observable. The business knows what is moving, what has failed, and what needs attention. Ownership is handed over with the integration, not left to luck.

Measure the seams as they close. We agree before we build how the benefit will be seen — the double entry removed, the reconciliation retired, the delay eliminated — and we report against it. The integration is judged by the work it removes, not by the elegance of its wiring.

Run and improve it. After the integration is live, we stay with it through the first period of real use, we fix what surfaces, and we improve what the monitoring shows. Integration work is never really "done"; it is maintained, like the rest of the infrastructure.