As an IT service leader, you are probably familiar with two common ways to maintain integrations across your IT systems and software:
- You can buy an iPaaS licence and operate integrations yourself.
- You can hire a system integrator and get them to build integrations as a project.
The third, and increasingly popular, option is to buy the outcome and let somebody else run the operation. That third option now has a name: Managed Integration Services.
Key takeaways
- A Managed Integration Service delivers integration as an operated service: the provider owns the platform, the operational management and the accountability for keeping integrations running.
- It is not the same thing as an iPaaS. An iPaaS is a platform you operate. It is not a system integration project either. A project ends, and integrations do not.
- The commercial shape is a subscription against a service level rather than a licence plus internal headcount, which makes cost forecastable as change accelerates.
- The model fits environments with high complexity, constant change and low tolerance for failure. It is a poor fit for small, stable estates and for organisations whose integration capability is itself a differentiator.
- The buyer question that separates the three options is not which tool is best for configuring integrations. It is who is accountable when something breaks.
Discover the discipline behind the service. The Integration Ops book sets out how the integration lifecycle is planned, operated and measured. Download the book.
What is a Managed Integration Service?
A Managed Integration Service is an operating model, popularized by ONEiO, in which an external provider takes ownership of an organisation's integrations end to end: the integration platform and connectivity, the continuous operational management of every integration running on it, and the expert work of adapting those integrations as connected systems change.
The integration provider is accountable for outcomes under a service level. Three components make up that service, and a provider missing any one of them is offering something else:
- Integration infrastructure. The platform and the connectivity, plus the environments they run in. This is the part that most resembles an iPaaS, and it is the least distinguishing part of the service.
- Operational management. Continuous monitoring, incident detection and response, change work as connected systems evolve, and upkeep of the integration estate as a live thing.
- Expert support. A named team that handles new connections, changes to existing ones and the alignment between what the integrations do and what the business currently needs.
The Integration Ops book states the underlying position directly. Integration is a lifecycle, not a task, and a Managed Integration Service is what it looks like when an organisation acts on that.
How is it different from an iPaaS tool?
An integration platform as a service gives you the tools. You configure the flows, you monitor them, you respond when they break, and you rebuild them when a connected system changes. The vendor is accountable for platform availability. You are accountable for integration availability. Those are different things, and the gap between them is where most integration cost lives, along with what breaks in the business when integrations fail.
A Managed Integration Service closes that gap by moving the operational work and the accountability to the provider. The same underlying capabilities exist. The question of who runs them has a different answer.
You can describe this as managed iPaaS, which is a reasonable bridge term for buyers arriving from an iPaaS evaluation, and we unpack that term in what managed iPaaS is and how it works. The outcomes are the ones an iPaaS promises, delivered through a different operating model. The same boundary from the other direction is covered in iPaaS vs integration as a service.
How is it different from a system integrator?
A system integrator delivers integrations as a project. Requirements, design, build, test, handover. The engagement has a defined end, and at that end the integration becomes the customer's responsibility to operate.
That model works when the thing being delivered is stable after delivery. Integrations are not. They sit between systems that release, re-platform, get acquired and change their data models, often outside your control. Each of those events is a maintenance obligation. When the SI leaves, the obligation stays.
Many organisations use system integrators well, for programmes and migrations that genuinely finish. The mismatch is specific to ongoing integration operations, where a project-shaped engagement is being used to buy a service-shaped need. ONEiO's popular system integration services compared guide walks the same three models through a procurement lens.
The three options, compared
What you really buy with a Managed Integration Service
The platform and the people running it are what the provider delivers. What your organisation buys is a set of abilities it did not have before:
- The ability to say yes to every integration demand, without each new connection becoming a project.
- The ability to handle complexity others can't, because one integration connects multiple endpoints regardless of platform.
- The ability to stay operational when others go down, with failures caught before the business feels them.
- The ability to guarantee outcomes others won't, and to make commitments to your own customers that differentiate you.
- A reputation for quality and flexibility, which is what turns a service provider into a partner for demanding businesses.
For service providers the last two are the commercial point. Michael at MHP described what it changes in a sales situation:
"Making commitments that differentiate you... that helps me, especially in pitches between other managed service providers, because we can promise them we can connect your system to our system." -- Michael, MHP
What the service actually covers
The list below is what a complete Managed Integration Service takes on. It is also a usable evaluation checklist, because providers vary considerably in how much of it they accept.
- Design and build of new integrations, including the data mapping and the negotiation of interface contracts with third parties.
- Connectivity to any endpoint, regardless of platform, without a bespoke point-to-point build for each pair. This is the difference between an estate that scales and one that compounds.
- 24/7 monitoring with proactive escalation, meaning the provider notices before the business does.
- Incident response to a defined service level, including data recovery and reconciliation after an outage, not just restoration of the flow.
- Change management, absorbing upgrades, API version changes, schema changes and re-authentication across the connected systems.
- Security and compliance of the integrations themselves, not only of the platform they run on. A compliant platform does not make what you built on it compliant.
- Onboarding of new parties, customers, suppliers and partners, at a predictable pace.
- Documentation and ownership, maintained as a live artefact so that no integration depends on one person's memory.
A fuller picture of what sits inside each of these is in IT integration services and integration service providers explained. Items three, four and five are the ones that separate a Managed Integration Service from a hosted platform with a support contract. Items six and eight are the ones organisations discover they needed after an audit.
How are Managed Integration Services priced?
A Managed Integration Service is normally priced as a subscription with the scope of the estate as the main variable: the number of integrations, the number of connected parties, and the volume moving through them. There are two reasons why this model is a better fit for smoothly run IT service management:
- It is forecastable. The cost does not spike when a connected system announces a major version upgrade, because absorbing that upgrade is part of what the subscription buys. Finance can plan against it.
- Pricing does not follow volume. Per-transaction pricing has a structural problem in an integration context. It charges you more precisely when your business is busiest, and it charges you for volume that a well-run integration would have prevented from being generated at all. Predictable subscription pricing removes that tension.
Key point: when you compare alternatives, do not stop at licence or project costs. Put the licence plus the fully loaded cost of the internal capability required to operate the estate against the predictable subscription. That is the integration total cost of ownership calculation most business cases omit.
What does SLA-backed mean here?
Service levels in this category should cover four things. A provider that commits to fewer is committing to less than the label implies. Here is what the answer to each should be, and how ONEiO answers it.
1. Does the commitment cover the integrations or the platform underneath them?
Both. Platform uptime with a broken flow running on it still fails the business, so the service level has to cover the integrations as well as the platform they run on. This is the most clarifying question in the category, and the one where published terms differ most.
2. Who notices a failure, and how?
The provider, proactively. In ONEiO's case the Operations Team monitors the service 24/7/365 and notifies the customer's subscription owner immediately when there is an issue, as set out in the ONEiO service description. If a provider's answer is that you raise a ticket, the monitoring is a reporting feature.
3. What happens to the data during an incident?
Nothing gets lost. Persistent queuing holds messages while a connected system is down and delivers them when it returns, processed in the order they were received. Without that, restoring the flow is only half the job, and the reconciliation project lands on your team.
4. What is written into the contract, and how is it measured?
Specific targets, in writing. Typical examples are integration availability per month, time from failure to detection, time from detection to a restored flow, and message delivery through an incident. Numeric targets in this category are commercial terms, set per agreement and varying with scope and tier; at ONEiO they sit in the service level commitment of the master agreement. Compare like for like on what is being measured and when the clock starts, and ask what happens when a target is missed.
When you evaluate integration service providers, ask every one of them to state all four in writing. The set of integration vendors willing to do so is considerably smaller than the set that uses the word managed.
"They are promising, and they are not just promising, they are really showing that they're going to hold or stay to their promise: connecting whatever kind of system out in the world with whatever kind of system you are using." -- Michael, MHP
When you should not choose managed integrations
The managed integration model is not your best pick in three situations:
- Your estate is small and stable. A handful of integrations between systems that rarely change does not justify an operated service. Buy or build a platform and leave it alone.
- Integration is your product. If the way you connect to customers is a differentiator you sell on, keep the capability in-house.
- You need a one-time migration, not an operation. Moving from one platform to another with a defined end state is project work. Commission a project. Hire an SI. Move on.
The managed integration model earns its cost where complexity is high, where the systems on both sides change constantly, and where a failed integration has a business consequence somebody will have to explain.
How to evaluate a provider
Six questions, in the order that surfaces the most. Ask them of every provider on the shortlist, including the incumbent.
- Who is accountable when an integration fails at a boundary between two vendors? If the answer involves working it out at the time, the recovery clock starts with a negotiation.
- How do you detect a failure, and how long until we hear about it and the flow runs again? Look for the mechanism, not the adjective.
- What happens when a connected system announces a breaking change? A service absorbs it. A platform sends you a release note.
- Is your service level about the platform or about my integrations? This is the single most clarifying question in the category.
- How does the price move when we double the number of connected parties? Scaling behaviour tells you what kind of operation is underneath.
- Who owns the documentation and the data mappings, and can I have them? A provider confident in the service will not use the mappings as a lock.
How different provider types answer these six is set out in integration service providers compared. ONEiO operates on this model. We run your integrations, you deliver your services: the platform and its 24/7 operation, together with an expert team, delivered as a Managed Integration Service under a service level, at a subscription price that does not move when your connected systems do. Any provider in the category should be willing to answer the six questions above as directly.
Bottom line on Managed Integration Services
The category exists because the project model and the platform model both leave the ongoing operation of an integration estate unassigned, in an environment that will not stop changing. A Managed Integration Service assigns it, and that is the whole idea.
Integration is not a project you survive. It is a capability somebody has to run. The only decision is who.
Test the model against your estate. Schedule a 30-minute conversation and walk through the six evaluation questions with your own integrations.
