The problem in plain language
System A has an owner. System B has an owner. The integration platform has a technical team. Yet when a business transaction fails between them, responsibility moves from one team to another because nobody is accountable for the end-to-end flow.
The pattern is familiar to anyone who has sat on an incident call about a broken interface. The CRM team confirms that the record was saved. The finance application team confirms that nothing arrived. The integration team confirms that the platform is running. A supplier confirms that its API is available. Every statement is accurate, and the customer's order, invoice or account change is still incomplete. The call ends with a promise to investigate further, and the transaction waits while each party looks only at its own component.
The difficulty is not a lack of competent people. It is that the organisation has assigned ownership to systems and suppliers, while the thing that actually matters to the business, the completed transaction, has no owner at all.
What the buyer is actually trying to solve
The buyer needs clear operational accountability for the connected service: who monitors completion, coordinates incidents, owns service expectations, approves changes that affect the interface and ensures dependencies remain documented.
Search language tends to reflect the frustration rather than the structure: “who owns integrations”, “integration ownership model”, “integration incidents bounce between teams”, “RACI for system integrations” or “nobody responsible when interface fails”. Behind these phrases is a practical aim. The buyer wants one place to go when a connected process breaks, and confidence that someone is watching that process before it breaks.
Evidence and system mechanism
The NIST Cybersecurity Framework 2.0, published in February 2024, frames its outcomes around six functions, including a new Govern function. Two parts of it are directly relevant here.
Within Identify, the Asset Management category describes assets, including data, systems, services and people, being identified and managed in line with their importance to organisational objectives. Its subcategories include maintaining inventories of software, services and systems; maintaining representations of internal and external network data flows; maintaining inventories of services provided by suppliers; and managing systems and services throughout their life cycles. Within Govern, the Roles, Responsibilities and Authorities category calls for roles and responsibilities to be established, communicated, understood and enforced, so that accountability is clear.
CSF 2.0 more broadly frames cybersecurity outcomes around governance and risk management across organisational systems. Taken together, those outcomes describe an integration as more than code between two applications. It is a data flow, often involving a supplier service, that supports a business outcome and therefore needs to be inventoried, prioritised and assigned.
AWS's Well-Architected Framework makes the operational side explicit. Its operational-excellence guidance states that resources should have identified owners for change control, troubleshooting and other functions, recorded in a central register or in metadata. Among the anti-patterns it lists is two teams having overlapping ownership of a critical piece of infrastructure, and it rates the risk of not establishing ownership as high. It also suggests defining what ownership means: who oversees changes, who supports troubleshooting and who is financially accountable.
The practical reading is that ownership has to be defined at the level where failure is experienced. For most businesses, that level is the end-to-end flow rather than any single component.
Problem owner and why now
The integration service owner and business process owner share the operational outcome. Urgency rises during application modernisation, vendor changes, mergers, API growth or recurring incidents where technical teams each confirm their own component is healthy while the business transaction remains incomplete.
Budget usually sits with the CIO, the COO or the owner of the application portfolio. Other common triggers include:
- a long or repeated incident in which the time spent finding the right team exceeded the time spent fixing the fault;
- an interface change in one system that broke a process owned elsewhere;
- the exit of the individual who historically understood a critical connection; and
- a supplier replacement that exposed undocumented dependencies.
Adjacent problems are covered in why integration incidents require several vendors to diagnose and why undocumented interface mappings make change risky, and the underlying principle is discussed in why every important integration needs an owner.
Economic consequence
Unowned integrations create longer incident resolution, duplicated diagnosis, change risk and fragile dependence on individuals who understand the history. Useful measures include mean time to identify the accountable team, failed transaction age, incident handoffs, undocumented dependencies and interfaces without a service owner.
- Delay in resolution: time is lost establishing who should act before anyone acts.
- Duplicated effort: several teams investigate in parallel, each proving its own innocence.
- Change risk: a modification approved within one system's governance can break a flow nobody assessed.
- Key-person exposure: knowledge of how the flow works lives with individuals rather than in a service record.
- Supplier friction: without a single coordinating owner, vendor escalations are slower and less precise.
These effects should be measured from the organisation's own incident records and integration inventory rather than estimated with borrowed figures.
Root cause
The root cause is often component ownership without service ownership. Governance is organised around applications and vendors, while the business flow crosses those boundaries.
Integrations are frequently built as project deliverables. The project team understands the flow, the project closes, and the interface passes into a support model that assigns each end to a different application team. Monitoring follows the same split: each team watches its own uptime, and no one measures whether the transaction completed. The symptom is incident ping-pong. The cause is an organisational design that never created a role for the flow itself.
Practical intervention
- Inventory integrations that support important customer, finance or operational flows.
- Map the business outcome, source, destination and intermediate dependencies.
- Assign one named operational owner for end-to-end service health.
- Define supporting application/vendor responsibilities without fragmenting accountability.
- Establish monitoring, incident, change and lifecycle expectations.
- Review ownership whenever systems, suppliers or organisational roles change.
The named owner need not fix every fault personally. The role is to be accountable for completion: to see whether transactions are flowing, to coordinate the teams and suppliers that support the flow, and to be consulted when a change could affect it. Recording the owner as a team or role, with a named lead, helps the arrangement survive individual departures.
Diagnostic questions
- Who is accountable when the end-to-end transaction fails?
- Is that person or team named in the service record?
- Can they see business completion rather than only component uptime?
- Do interface changes have a coordinated change owner?
- Are supplier responsibilities for each critical flow written down?
- Does ownership survive vendor and staff changes?
What good looks like
Every critical integration has one accountable operational owner, documented supporting responsibilities and visibility of the complete business outcome across system boundaries.
When a flow fails, the first question, “who owns this?”, already has an answer. The owner can see where the transaction stopped, contact the right supporting team or supplier, and confirm recovery against the business record. Changes that touch the interface are reviewed with the owner, and the integration inventory is kept current as part of normal change rather than rebuilt after an incident.
Where Mellorca fits
Mellorca can inventory integration estates, map business dependencies, define service ownership, improve observability and establish operating models for critical system connections. The work combines organisational design with technical monitoring, because accountability without visibility, or visibility without accountability, leaves the original gap in place.
Commercial next step
Discovery article → integration ownership diagnostic → critical flow inventory → ownership and responsibility model → monitoring and change integration → managed operations.
Method note
NIST and AWS material supports the dependency, flow, ownership and governance principles. The operational-owner model described here is an applied business-design interpretation and should be adapted to actual organisational accountabilities.
Sources and further reading
- CSWP 29, The NIST Cybersecurity Framework (CSF) 2.0 - CSRC (last verified 10 October 2026)
- OPS02-BP01 Resources have identified owners - Operational Excellence Pillar (last verified 10 October 2026)