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.
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.
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.
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.
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.
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.
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.
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:
System of Record vs Source of Truth: The Integration Decision You Make Once (article)
Shopify NetSuite Integration: Connector, iPaaS, or Custom Build? (article)
One page is enough if it holds three decisions. A table with one row per business fact, such as customer, product, price, order, invoice and ticket, and the single system that is its record. A list of the flows that carry each fact from its record to the systems that need it, each with a source, destination, trigger, shape and one direction. And for every flow, an owner, a detection time for failure and a runbook. Tool choices follow from that page, not the other way round.
Pick the system whose version wins when two disagree, and make it the only one where that fact may be edited directly. It is not necessarily the system the fact was typed into first or the one most people look at. The customer is usually issued by the sales system and received by accounting and support; the product by the inventory or catalog system; the invoice by accounting. Write the choice down, because every connector built without it moves data in a direction nobody agreed to.
If a flow seems to need to run both ways, one direction is almost always wrong, and the reason it looks necessary is that nobody decided which system is the record. Two-way sync lets both systems edit the same fact, so conflicts are resolved by timing rather than by rule, and the result is records that silently overwrite each other. The fix is to assign the record, send the fact one way, and send a different fact, such as a status, back the other way if needed.
Each connection is a small product with four costs: the decision about direction, a build of a week to a month depending on how far apart the data models are, monitoring so failures are noticed in minutes rather than at month end, and a change cost each time either application or the business changes. Native vendor connectors are cheapest to run, integration platforms suit simple one-directional flows, and custom code suits flows that carry money or stock. Most companies find eight to twenty flows actually matter.
A named person per flow, with a way of knowing within minutes and a runbook for what the failure means today. Every flow fails eventually: a renamed field, a rate limit, a rotated credential, a retired API version. The question that most often exposes a strategy as fiction is asking who is accountable for the order-to-invoice flow and watching the CRM partner, the accountant and the internal administrator each point at the others. Managed technical operations exists as a service because that gap is real.
For most operators under two hundred people, yes. Much of the pain that drives an ERP purchase is integration pain: three customer records, quotes that do not match invoices, stock counted differently in three systems. An ERP solves it with one database over fifteen years; an integration strategy solves it in weeks by making the joins explicit, and it survives whatever suite decision follows, because the ERP will want the same record assignments and flows. Make the three decisions first, then decide on the suite with the data in shape.
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
