Every enterprise integration project has a scope document. Almost none of them scope the part that lasts longest, the continuous management of integrations.
The common mistake is treating integrations as projects. Software integration management is the work that begins the day after an integration goes live and continues for as long as the integration exists: watching it, changing it, documenting it, and answering for it. It is a real discipline with real cost, and in most organisations it has no budget line and no owner until something breaks and the business pays for it.
Key takeaways
- Software integration management is the ongoing work of keeping integrations running after go-live: monitoring, recovery, change, documentation and accountability.
- The work breaks into eight activities. A platform makes some of them faster to do, and your team still performs all eight.
- Most of the cost arrives when an integration breaks and the processes, service levels and invoices that depend on it stop with it.
- Tools and a Managed Integration Service resource the same eight activities differently. The deciding question is which one brings the business risk of a failure down far enough for your situation.
- Tools fit when integration capability is something you want to build and keep, and your team is equipped and available to restore a flow at any hour. A managed service fits when either is missing.
The reference for this work. The Integration Ops book sets out how integration work is operationalised, measured and scaled under a Managed Integration Service. Download the book.
What is software integration management?
Software integration management is the coordinated planning, connection and ongoing operation of an organisation’s software systems so that they share data reliably over time. The planning and connecting are finite. The ongoing operation is not, and it covers monitoring the integrations, responding when they fail, adapting them as connected systems change, controlling who can change them, keeping documentation and ownership current, and reporting on whether they still do what the business needs.
Most published guidance on the term covers scope definition, architecture choice and connection types, and then stops at the point where the integration goes live. The decision that determines cost sits after that line.
For the underlying concepts, see what software integration is.
The Integration Ops book states the position behind this view. Integration is a lifecycle, not a task, and management is the part of that lifecycle nobody scopes because it has no delivery date.
The book separates three mindsets, and the gap between two of them is where this decision sits. A project mindset builds something once and measures success by delivery. A product mindset takes ongoing ownership and asks whether the thing still solves the right problem. A service mindset treats integrations as a continuous delivery of outcomes, measured by the reliability, visibility and adaptability of the flow itself. The book also observes where most teams land: they deliver integrations as if they are projects, but they are held accountable as if they are services.
Eight core components of integration management
The two resourcing models differ in who performs each of these activities. The Integration Ops book makes the same point from the other direction. The connection runs on its own, but the work around it does not. Mark who does each activity in your organisation as you read.
1. Monitoring and detection. Knowing that a flow has stopped, degraded or started producing wrong data, before the business tells you.
2. Incident response and recovery. Restoring the flow, then reconciling whatever accumulated or was lost while it was down. Recovery routinely runs longer than the fix.
3. Change absorption. Adapting integrations when a connected system is upgraded, an API is deprecated, a schema gains a field, a certificate expires or a partner re-platforms.
4. Onboarding. Adding a new customer, supplier or system at a predictable pace, without a bespoke build each time.
5. Testing and validation. Contract tests that verify each side still behaves as expected, and regression suites that run before a change reaches production. The Integration Ops book names this as one of the recurring activities worth designing once and automating, alongside onboarding, monitoring, and documentation. In most estates it is the activity performed least consistently and missed most expensively, because an untested change gets discovered by the business.
6. Version and access control. Knowing which version of an interface is live, who is allowed to change it, and what the rollback path is. The book is direct about this. Flows, mappings and configurations should be versioned so old and new variants can run in parallel during a transition, and so teams can roll back quickly.
7. Documentation and ownership. Keeping the data mappings and interface contracts current, with a named owner attached, so that changing an integration does not begin with an investigation.
8. Business alignment. Periodically checking that what the integrations do still matches what the organisation needs, and retiring the ones that no longer do. This is one of the book’s three measurement dimensions. The other two are lifecycle efficiency and operational health, and business alignment is the one connecting integration performance to service commitments, onboarding speed, and churn.
Why the management gap is a business risk
Nobody budgets for integration management, because nobody plans for the integration to break. The people who build it believe, reasonably, that the job was done well. So the work of keeping it running lands on whoever is available, and the cost of not doing it arrives as a surprise.
“If integrations fail, hell breaks loose.” -- Hanna, DNV
When an integration nobody is actively managing breaks, the damage reaches well beyond IT. Processes stop and people switch to manual work. Decisions are made on data that is late or wrong. Service levels are missed and penalties follow. Invoices go out wrong and turn into disputes and later payment, and orders that cannot complete are lost. We traced how far this reaches in the true cost of integration failure and the fix that holds. The engineering time spent on the fix is the smallest part of the bill.
The longer the management work stays informal, the more the estate depends on the few people who know it, and the harder it becomes to hand over to anyone else. That is what makes the position risky, and why it gets harder to leave every year.
Two ways to resource for integration management
The choice gets framed as build against buy, which obscures it. Both options involve buying something. What differs is which of the eight activities you are buying and which you are keeping.
The tooling side of this market is usually described in product categories: integration platforms as a service, API management platforms, enterprise service buses, and embedded iPaaS built into a product. Those categories describe what you can buy. None of them describes who performs the eight activities once the thing is running.
The comparison here is between two operating models rather than vendors, because the product comparison already exists. Top ITSM integration tools compares native connectors, sync engines, general-purpose iPaaS, and managed services side by side, and our comparison of 45+ integration software platforms covers the wider market. Use those to pick a product. Use this to decide who runs it.
What a platform actually does for the management problem
An integration platform improves activity 1 substantially, provides mechanisms for activities 5 and 6, and reduces the effort in activities 3 and 4 by making changes and onboarding faster to execute. It does not perform any of them. A monitoring dashboard tells you a flow has stopped. Somebody still has to be watching it, decide it matters, and act. Faster change execution is worth having, and it does not answer who notices that a change is needed, who has the context to make it, or who is available when a flow breaks outside working hours and the business is waiting.
Activities 2, 7 and 8 are essentially untouched by platform choice. They are operational and organisational, which is where the cost sits. The Integration Ops book puts the distinction plainly.
“Scripts can automate tasks. A platform automates how tasks are done, repeatedly and consistently, across many integrations and many teams.” -- Integration Ops, chapter 5
Neither decides that a failing flow needs attention now, and that decision is what keeps the business running. The book is direct about the limit. Tools alone do not guarantee stability. If an organisation lacks an operating model for how integrations are owned, monitored, maintained, and operated, the risk remains. The tooling changes and the behaviours do not. Technology makes integration work faster and more flexible. It cannot, on its own, make it accountable, observable or sustainable.
A platform is a good investment, and it gets integrations built and monitored. It does not prevent the bulk of the cost, which arrives when something breaks and somebody has to own the recovery.
What moves to a provider, and what stays
With a Managed Integration Service, you keep the integration strategy, the governance and the knowledge of your own endpoints. You decide what the business needs integrated, you own the relationships with the connected parties, and you hold the provider to the service level.
What is taken care of for you:
- Building the integrations and running them 24/7, which covers monitoring, incident response and onboarding (activities 1, 2 and 4).
- Keeping them working when a connected system goes down or changes, including the maintenance, testing, upgrades, migrations and recovery that takes (activities 3, 5 and 6).
- Keeping documentation and ownership current, with a service level on the integrations themselves and the evidence you need when an auditor asks (activity 7).
Business alignment, activity 8, is shared. And because each of your systems connects once, adding a customer or partner does not mean adding complexity to your own systems to make the integrations work.
The commercial shape follows the same logic: a subscription against an outcome, compared with the platform fees plus the internal headcount it replaces.
The accountability table
The comparison that matters most in this category is who is answerable for each activity, and whether that answerability is contractual.
The cost comparison that matters
Comparing a platform subscription to a service subscription is the wrong comparison, and it is the one most business cases run. The correct comparison is the platform fees plus the fully loaded cost of the internal capability required to perform activities 1 through 7, against the subscription. That internal cost includes salaried time spent on monitoring and change work, the on-call arrangement or its absence, and the business disruption absorbed when an integration is down and nobody was watching.
Most organisations have never calculated that second half, and the disruption is usually its largest part. That is why the in-house option looks cheaper on paper than it turns out to be. We have benchmarked the three delivery models against each other in our integration solution TCO comparison, and the build-side decision in build vs buy integrations.
Where system integrators fit
A system integrator is a third option worth naming. It is where many organisations land by default when the internal team runs out of capacity.
An SI engagement is project-shaped. It runs from requirements through delivery to handover, and then it ends. That shape suits programme work, migrations and anything that genuinely finishes. Applied to ongoing integration management it produces a specific pattern. Each change becomes a statement of work, cost scales with change requests, and the knowledge accumulates with the integrator.
System integration services compared walks through where each model earns its place. Many organisations use system integrators well and should continue to. The mismatch is narrow and specific, and it is using a project-shaped engagement to buy a service-shaped need, then being surprised that the commercial model resists continuous change.
When self-managed integration tools are the right answer
There are scenarios where you want to manage your integrations through a self-service integration tool, like an iPaaS solution.
Integration capability is strategic. If how you connect to customers or partners is part of what you sell, keep the capability, buy good tools, and fund the team properly.
The estate is stable. Few connected parties, systems that change on a predictable schedule, and no cross-organisation flows. The management burden is genuinely small and a service would be paying for capacity you do not need.
You already have the operating model. Named integration owners, current documentation, standardised patterns, and a team that is equipped and available to restore a failed flow at any hour. If activities 1 through 7 already have owners, a platform is the right investment and a service is duplication.
Little is at stake when a flow breaks. If the processes on either side can run on workarounds for a day or a week without revenue, service levels or customers being affected, paying someone to restore them faster is hard to justify.
If none of these describe your organisation, the management work is happening anyway. It is being absorbed by people who were hired to do something else, and nobody is measuring it.
Moving from one model to the other
Organisations rarely switch in a single step between integration tools and managed integration services. The phased path below is the one that works in practice.
Phase 1. Inventory. List every integration, its connected parties, its owner, and its last change. Most organisations discover the list is longer than expected and the ownership column is mostly empty.
Phase 2. Move the noisy ones first. Take the integrations generating the most incidents and change requests into the service. That is where the cost is and where the relief is felt fastest.
Phase 3. Move the boundary-crossing ones. Integrations into customers, suppliers and partners carry the accountability problem, and they benefit most from a contractual answer to it.
Phase 4. Decide about the rest. The wider version of this call is covered in which IT services should be outsourced. Stable internal integrations can reasonably stay in-house. The point of the exercise is not to move everything. It is to stop paying for the illusion that the estate is managed when nobody has been assigned to manage it.
ONEiO runs this model as a Managed Integration Service. We run your integrations, you deliver your services: activities 1 through 7 move to us under a service level, connectivity is any-to-any so adding a party does not mean adding a build, and the subscription does not move when your connected systems do.
Bottom line on software integration management
Integration management is where an integration estate spends most of its life, and it consumes real effort whether or not anyone has budgeted for it. The larger cost arrives when a flow breaks and nobody was assigned to notice.
Tools and a managed service can connect the same systems, and either can be the right choice. The choice starts to matter once your estate crosses a certain level of complexity and dynamics, with processes, customers or contracts at stake when a flow stops. From there, the question is which approach brings that risk down far enough, and whether your team is realistically equipped and available to carry it.
Decide it deliberately. The default, which is that management happens informally in the gaps between other work, is the most expensive option, and the only one nobody ever chose.
Map the eight activities against your estate. Schedule a 30-minute conversation and we will work through who owns each one today.
