Leadership

Who Owns Integration Reliability? The Org Chart Problem

Integrations fail in the space between two teams, and that space is on nobody's objectives. Why ownership is genuinely ambiguous here, and the three allocations that actually hold.

Why this is genuinely hard

Not organisational laziness. The ambiguity is real.

A connection between your billing platform and your CRM involves finance, revenue operations, whichever engineer built it, and two vendors. Each has a legitimate claim to not owning it: finance does not run software, revenue operations did not build it, the engineer built it as a favour two years ago, and both vendors consider the connection the customer's responsibility.

So it sits unowned, and the first time anyone asks who is responsible is during a failure, which is the worst moment to be having the conversation.

Why team ownership fails specifically here

For most systems, assigning a team is fine. For integrations it tends not to work, for a reason particular to how these fail.

Integration failures are usually partial and intermittent. Recognising one requires noticing that the thing that happened today resembles the thing that happened six weeks ago. On a rota, five different people each see one occurrence and each reasonably treats it as a one-off. Nobody sees three, so nobody sees a pattern.

This is the organisational version of the problem described in why integration failures go undetected, and it is why a named person matters more here than it does elsewhere.

Three allocations that hold

The consuming system's owner

Whoever depends on the data owns the connection that delivers it. The cleanest rule, because the owner feels the failure directly and therefore has a reason to care before anyone escalates.

Works when the consumer is technical. Awkward when it is a finance team that cannot read an API log, which the next option addresses.

A named platform engineer per connection

Each connection gets an engineer's name, independent of which team consumes it. Works where integrations are numerous and consumers are non-technical.

The risk is that it becomes a list nobody revisits. It needs the review cadence that an inventory provides, where the only question is which rows have not been verified.

A business process owner with engineering support

For connections that exist to serve a finance or operations process rather than a product capability, the process owner owns the outcome and a named engineer owns the mechanism. Two names, clearly divided.

More overhead, and appropriate for the small number of connections where failure has direct financial consequence.

What does not work

• "The data team owns all integrations." Makes them accountable for contracts they did not negotiate with vendors they did not select.
• "Whoever is on call." Guarantees nobody sees enough occurrences to recognise a pattern.
• "The vendor owns it." They own their side. Nobody owns the contract between them.
• An unmaintained wiki page. Ownership that is never verified is a record of intentions from two years ago.

Making it stick

Two mechanisms, and the rest is theatre.

First, make ownership part of the definition of done when an integration ships. Retrofitting ownership is the hard version of this problem; assigning it at creation costs nothing.

Second, review quarterly with one question: which rows have not been verified? Not a discussion of each connection, which nobody will sustain. A connection with no owner should trigger an explicit decision to adopt it or retire it.

Ownership also only functions if the owner can actually see what is happening. Naming a person and giving them no signal produces accountability without capability, which is worse than nothing. Keeping that signal and the history attached to the connection is what Traxivo maintains, so ownership survives the person changing.