An Application Integration Strategy for a Mid-Market Operator: Three Decisions Before Any Connector.
Most companies do not have an application integration strategy. They have a list of connectors. Each one was bought or built to stop one specific pain: the orders that had to be re-keyed, the leads that never reached sales, the invoices that did not match the quotes. Each one worked, more or less. Together they form an estate that nobody drew, nobody owns and nobody can explain, and the sense that the list itself is now the problem is usually what brings a company to us.
A strategy is not a longer list and it is not a platform. It is three decisions, made explicitly and written down, before any connector is chosen. This post is about those three decisions, in the order they have to be made, and why an operator who makes them can run a dozen applications as one system while one who skips them cannot run three.
Decision one: which system is the record for each thing.
Every fact the business depends on, the customer, the product, the price, the order, the invoice, the ticket, the employee, has to have exactly one system that is its system of record. Not the system it was typed into first, and not the system most people look at. The system whose version wins when two systems disagree, and the only one that may be edited directly.
This sounds obvious and is almost never done. In a typical mid-market estate the customer lives in the CRM, the accounting system and the support desk, and all three are edited by hand. The product lives in the inventory system and the e-commerce platform and the quote template. When two versions differ, the person who notices picks one, and the choice is never the same twice.
The decision is a table with one row per fact and one system per row, plus the rule that every other system receives that fact and never originates it. It fits on a page. It is the most valuable page in the integration project, and it is the page nobody writes because it feels like paperwork rather than engineering. Every connector built without it moves data in a direction the company never agreed to.
Decision two: which joins matter, and in which direction.
Once the records are assigned, the joins that matter are the ones that carry a fact from its record to the places that need it, in one direction. A lead becomes a customer in the CRM and flows to the accounting system when the first order is accepted. An order is placed in the commerce platform, flows to inventory for fulfilment and to accounting for invoicing. A ticket is raised in the desk and the customer's status flows back to the CRM.
Write these down as a list of flows, each with a source, a destination, a trigger and a shape. Most companies find they have between eight and twenty that matter, and that half of the connectors they run do not correspond to any of them. Those connectors are the ones that break at 2 a.m. and that nobody misses when they are switched off.
Two rules from doing this work. First, if a flow appears to need to run in both directions, one of the two directions is almost always wrong, and the reason it looks necessary is that decision one was skipped. Our piece on why bidirectional sync is usually a design failure covers the mechanism. Second, a flow that carries a whole record when the destination needs three fields is a future outage: it couples the two systems to each other's schema, and the next edition upgrade on either side breaks it.
Decision three: who owns a failed sync.
An integration strategy without an owner for failure is a hope. Every flow will fail: a field renamed, a rate limit hit, a credential rotated, an API version retired. The question is not whether but who finds out, how fast, and what they do.
The decision is an owner per flow, a way of knowing within minutes rather than at month end, and a runbook: what a failed order sync means for fulfilment today, who re-runs it, what has to be checked afterwards. In our experience the owner question is the one that most reliably exposes a strategy as fiction. Ask who is accountable for the order-to-invoice flow and watch the CRM partner, the accounting firm and the internal admin each point at the others. Managed technical operations exists as a service line because that gap is real and somebody senior has to hold it.
Only now: the tools.
With the three decisions made, tool choice is easy and mostly boring. Native integrations where the vendor maintains them, because someone else fixes the upgrade. An integration platform for the flows that are simple, one-directional and low-volume, where the value is speed of change. Custom code on the platform's own runtime for the flows that carry money or stock, where the value is control and the failure modes have to be handled precisely. Our Zoho integration services piece walks through where each fits on a Zoho estate.
The point is that the tool follows the flow, and the flow follows the record. Companies that start with the tool end up with a platform full of flows that encode nobody's decisions, and then blame the platform.
What this has to do with the ERP question.
Everything, for a mid-market operator who is weighing whether to buy a suite. Most of the pain that drives an ERP purchase is integration pain: the three customer records, the quote that does not match the invoice, the stock count in three systems. An ERP solves it by putting everything in one database, which is a legitimate solution and a fifteen-year one. An integration strategy solves it by making the joins explicit, which is a solution of weeks and one that survives whatever ERP decision follows, because the ERP will want the same record assignments and the same flows. We have written about whether you need an ERP or an integration, and the honest answer for most operators under two hundred people is the strategy first and the suite decision after, made with the data already in shape.
The one-page version.
One system of record per fact, written down, and no other system originates it.
A list of the flows that carry facts from their record to where they are needed, one direction each, with a trigger and a shape.
An owner, a detection time and a runbook for every flow.
Then the tools, chosen per flow, native first, platform for the simple ones, code for the ones that carry money.
That page is what we produce in discovery, which you pay for only if you proceed, and it is the basis of a guaranteed estimate for the flows that need building; if we estimate low, we absorb the difference. Retainer clients see the full plan for each release before committing to it, so the estate grows by decisions rather than by connectors.
An integration strategy is the difference between an estate you run and an estate that runs you. It costs three decisions and a page, and it is the cheapest architecture work a mid-market operator will ever do.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments