Integration Debt, Part 1: The Debt Nobody Budgets For

In 2017, a data architecture consultant named Dave McComb noticed the software industry had named the wrong debt. Everyone was talking about technical debt, the shortcuts inside one codebase that make future changes slower and riskier. McComb pointed at something bigger and quieter: the shortcuts between systems. Every time a company adopts a new tool without deliberately planning how it talks to everything else already in place, it creates a small, unbudgeted liability. Nobody schedules the work of connecting it properly. Nobody owns the connection once it exists. The cost doesn't show up anywhere until, eventually, it does.

He called it integration debt. Almost a decade later, the term still hasn't become a formal discipline. There's no academic literature behind it the way there is for Ward Cunningham's technical debt, no standard way to measure it, no line item on a balance sheet. Vendor blogs and consultancies gesture at it constantly, each with a slightly different gloss on what it means. That looseness is itself informative. Practitioners feel this problem constantly and describe it imprecisely. That's usually a sign the underlying dynamic is real and under-examined, not imaginary.

This series asks a blunter question than most content on this topic bothers to ask: can you actually prove integration debt costs money, and can you prove consolidating your systems fixes it? This part covers the mechanism. Part 2 stress-tests it against the actual evidence, including some numbers you'll see repeated everywhere that don't hold up. Part 3 gets practical about what to do given what we can and can't prove.

How the debt actually accumulates

Most companies don't choose their integration architecture. It accretes. Marketing picks HubSpot. Sales picks Salesforce. Finance picks NetSuite. Someone in ops sets up a Zapier account to stop copying leads into a spreadsheet by hand. Each decision is locally reasonable. The team that made it solved its own problem, on its own timeline, with its own budget. None of them made a decision about the system of systems that resulted.

Three mechanisms explain why this compounds instead of just accumulating linearly.

The combinatorics get worse before anyone notices. Point-to-point connections between n systems can grow to as many as n(n-1)/2. Ten core systems can produce up to 45 direct links. Fifteen systems, up to 105. The industry has an unglamorous but accurate name for the result: spaghetti integration. Integration effort doesn't scale linearly with the number of tools a company adopts. It scales closer to quadratically, while headcount and attention scale linearly at best.

Nobody owns the connections. Every individual system has an owner. Someone in finance is responsible for NetSuite, someone in sales owns Salesforce. The link between them, built by whoever needed it that quarter, usually doesn't have one. When it breaks, there's no natural first responder, because it was never anyone's job to watch it.

The real cost mechanism is silence, not error. A broken website throws an error page. A broken integration usually throws nothing. A missing field silently propagates downstream as an empty value instead of failing. A workflow can run to completion, report success, and still have written a duplicate record or a wrong invoice amount. This is how integration debt actually costs money: not as a line item, but as a slow accumulation of bad orders and duplicate CRM entries that someone eventually notices and cleans up by hand.

The case that doesn't need the hedge

Most examples of this pattern come with caveats attached, and we'll get into why in Part 2. This one doesn't. Intuit's own QuickBooks Online API documentation states, in plain language, that a "full update" on any entity, a customer, an invoice, an estimate, clears any writable field the request omits. Not ignores. Clears. Sets it to NULL. No error, no warning, nothing that flags what happened.

Intuit's SDK docs describe the alternative directly: "The sparse update operation provides the ability to update a subset of attributes for a given object; only those specified in the request are updated. Missing attributes are left untouched... This is in contrast to the full update operation, where elements missing from the request are cleared." The next line says why it matters: "A client application often does not use all the fields of an entity, so when it sends a full update request with only fields they use, it results in an erroneous blanking out of fields that were not sent." That's Intuit, describing its own API's default behavior as a trap common enough to warn against by name.

This is what makes it a cleaner example than most. It isn't a bug waiting to get patched, and it isn't a legacy setting that has since been superseded. It's documented, current, by-design behavior, still being discussed in Intuit's own developer community. Any integration that reads a QuickBooks record, changes one field, and PATCHes the whole object back will silently null out every field it didn't carry along. That pattern is common in custom middleware and generic connectors that don't special-case QuickBooks. A CRM sync from Salesforce, HubSpot, or NetSuite that does this doesn't get an error. It gets a customer record with a missing billing address and no log entry pointing at why.

Set that example next to the others and the mechanism holds up without qualification. The combinatorics are simple arithmetic, and the ownership gap is a straightforward organizational fact. The silent-failure pattern is corroborated across independent sources, and QuickBooks' own documentation is the clearest single instance of it: a vendor stating outright, in its own reference docs, that its default write behavior destroys data nobody told it to touch.

It gets thinner still the moment you go looking for a dollar figure. The most commonly cited cost statistic in this space turns out to be untraceable, and the most commonly cited consolidation statistic doesn't fare much better. That's where Part 2 picks up.