An integration belongs to neither team
Most integrations end up unowned for a structural reason rather than a careless one. An order feed runs between a CRM and an ERP. The CRM team owns the CRM, the ERP team owns the ERP, and both can say honestly that the feed is not theirs. Each team is measured on the health of its own system, so the feed becomes somebody's problem only on the morning it stops.
Responsibility in a business applications organisation gets drawn around systems, because licences, budgets, release calendars and support rotas are drawn that way too. Work that sits between two systems has no home in that shape. Nobody chose to abandon the feed. It was never assigned, because the method of assigning had no slot for it.
The cost shows up during an incident. The first half hour goes on deciding whose problem this is, both teams check their logs, neither finds anything wrong on its own side, and the record is still missing from the ERP. A queue does not close that gap, which is the argument in our piece on why the queue cannot own the exception. Delivery guarantees are not decisions.
Knowing what the feed is for
The title sounds administrative and the work is something else. It starts with knowing, in business terms, what the integration exists to do. Not the field mapping, which anyone can read from the flow, but the decision on the receiving side that depends on this data arriving and being right.
That knowledge is what lets someone judge a proposed change in ten minutes instead of a fortnight. When sales operations asks to add a picklist value, an owner who knows the feed drives credit limits can say straight away whether the new value needs a rule downstream. An owner who only knows the field list has to test to find out, and usually finds out after go live.
Getting there means reading the receiving side's process, sitting with the people who work the exceptions, and writing the purpose down in two sentences a finance manager would recognise. That description does more for the next incident than any amount of connector detail.
The contract is the part you own
The second piece of the role is the contract between the two sides. The agreed shape of what moves, the meaning of each field, the identifier that ties one record to its counterpart, and what happens to something the receiver rejects. Writing that down takes an afternoon. Holding the line on it is the actual job.
Holding the line means saying no when one side wants to change the shape without telling anyone. A team that renames a status value inside its own system has broken none of its own rules. The owner is the one who knows that value appears in a downstream routing rule, asks for a new version rather than a rename, and gets a date for retiring the old one. Our case for small integration contracts describes the shape that makes that argument winnable.
Where no contract exists, the behaviour of the integration is whatever the code currently does, so every change becomes a negotiation with a codebase instead of with a person. An owner who can produce one page describing the agreement carries more weight in a design review than one who can only produce a flow diagram.
Which failures matter, and whether the two sides still agree
Knowing the failure modes well enough to rank them is the third piece. A transport error that clears itself in nine minutes deserves a different response from a business rejection that has already left a wrong number in a month end report. Alerting rarely tells those apart, and a person who has watched the feed for a year can. Our piece on partial success in integration error handling works through the failures that hide in the middle.
The fourth piece is reconciliation, meaning the ability to answer on demand whether the two sides still hold the same records. Ask around and you usually get a pause, then an offer to look into it. An owner who keeps a query, a count and an agreed tolerance answers in a minute and can say when the two sides last drifted apart.
Reconciliation is also what earns the role credibility with finance and with auditors. A number that reconciles is the only real evidence that the integration is doing its job. Everything else amounts to a report that runs green.
A seat in both change processes
The most common cause of a broken integration is a change on one side that nobody mentioned to the other. So the fifth piece of the role is a standing place in both systems' change processes, with the right to read the list before approval and to ask for a delay.
Standing does not mean a veto. It means the owner gets consulted rather than informed, and a change touching a contract field cannot be approved without a note from the person who holds it. If the board reads thirty items in forty minutes, the integration owner is the one who should be able to stop on item eleven. Our method for a change approval board that moves puts the meeting's attention where that stop belongs.
Why the role is worth more than it looks
Take this role and you gain something neither platform team has, which is working knowledge of how two systems behave together. That knowledge makes a person the one who gets consulted when either side proposes a change, and being consulted is the difference between shaping a design and receiving it.
The knowledge is also hard to replace. Deep product configuration skill is portable and crowded, and the ceiling arrives sooner than people expect, which we wrote about in the career ceiling in deep product work. How this organisation's order feed and worker feed actually behave is local knowledge, and the person holding it gets asked about decisions well above their grade.
The honest part is that the role stays chronically under-credited, because its output is an absence of incidents and nobody hands out recognition for a quiet quarter. Anyone taking it should be deliberate about visibility. Keep a record of the changes you caught before they shipped, the reconciliations you ran, and the outage that never happened because a rename got versioned. Bring it to your review, because nobody else will bring it for you.
Setting the role up so it is not decorative
If you are the one deciding, name a person rather than a team. A team-owned integration is unowned in practice, because every member can reasonably believe somebody else is watching it. The name belongs in the same place the system owners' names live, and it gets read out when the feed turns up in an incident.
Give that person real standing in both systems' change processes, or the role becomes decoration with a title attached. An owner who learns about a schema change from the failure alert has been handed the blame without the authority, and will hand the role back inside a year.
Scope it honestly. One person cannot meaningfully own forty interfaces, and pretending otherwise produces a name on a list and nothing more. Build the inventory first, then tier it. The feeds where a bad day costs money get a named owner with protected time, and the rest get a written contract and a monitoring rule. Our argument for mapping the flows before the roadmap runs along the same line.
If you suspect you already hold this role without the title, pick the feed you are quietly responsible for and spend an hour this week writing its contract on one page, with the two changes on either side that would break it. Send that page to both system owners and ask to be added to their change reviews. The title tends to follow the page.
