Back to Resources
By John Noctor, Service Desk Institute
One of the advantages of spending far too much time thinking about service management is that every now and then you come across something that makes you wonder whether the way we work is starting to change. Integration Ops is one of those things.
My first reaction was probably the same as yours: do we really need another ‘Ops’? We already have DevOps, SecOps, AIOps and enough terminology in ITSM to keep us occupied for several lifetimes. But the more I’ve looked at Integration Ops, the more I think there is something important behind it, particularly for MSPs and organisations operating increasingly complex, multi-supplier environments.
The idea itself is actually quite simple. We have spent years connecting more systems, platforms, suppliers and services together, but connecting things doesn’t necessarily mean they work particularly well together. That’s the gap Integration Ops is trying to address.
Integration has become an operational issue
Think about the average enterprise technology environment today. There might be an ITSM platform sitting somewhere near the middle of it, but around that you’ll find monitoring and observability tools, security platforms, cloud services, automation, collaboration tools and specialist applications. There are likely to be external suppliers involved too, many of whom will have their own platforms and processes, while an MSP has all of that complexity and then has to accommodate the different technology environments of its customers as well.
Historically, we’ve tended to treat integration as a technical project. System A needs to talk to system B, so somebody builds an integration, tests it, puts it into production and moves on. The problem is that the story doesn’t end there.
What happens when one of those systems changes, or an integration quietly stops working properly? What happens when information moves between organisations but priorities, statuses or data don’t quite match? Who owns the integration six months after it was built, and what happens when an MSP needs to onboard another 50 customers without creating another 50 bespoke integration projects?
At that point, integration isn’t just an architecture or implementation issue. It has become an operational one, and that’s where I think Integration Ops starts to make sense.
So, what exactly is Integration Ops?
I think we should resist the temptation to make this more complicated than it needs to be. For me, Integration Ops is the discipline of making sure the connections between systems, services and providers continue to work reliably as part of the service.
The important word there is continue, because this isn’t simply about creating an integration. It’s about operating it, monitoring it, governing it, improving it and understanding what happens to the service when something changes. If an integration sits in the middle of a critical service, then surely the health of that integration is part of the health of the service itself? Yet I’m not convinced we’ve always treated it that way.
Where does it fit with ITSM, SIAM and DevOps?
This is probably the question I hear most when discussing Integration Ops. Isn’t this already ITSM? Isn’t this what SIAM does? What about DevOps?
There is certainly overlap, and I don’t think inventing artificial boundaries between these disciplines helps anyone. ITSM gives us the framework for managing and improving services, SIAM becomes particularly important where multiple internal and external providers need to be coordinated, and DevOps has changed the way many organisations build and deliver technology. Recognised standards and best practice then give us the governance, assurance and continual improvement disciplines needed to do all of this well.
Integration Ops doesn’t replace any of them; instead, it helps connect the environment in which they operate.
I’ve been using a football analogy to explain it, despite the obvious risk that somebody who actually understands football will tell me I’m wrong. If DevOps is helping the players score the goals and SecOps is helping protect the defence, Integration Ops is the midfield. It connects play, gets information, or in this case the ball, where it needs to go and allows different parts of the team to work together rather than simply being very good at their own jobs.
Without that connection, you’ve got talented people running around in isolation, which, come to think of it, describes a surprising number of IT environments I’ve seen over the years.
The service desk often knows where the problem is
There’s another reason I think this matters. When integrations don’t work properly, the architecture team isn’t necessarily the first to feel the pain; quite often, it’s the service desk.
A ticket hasn’t transferred correctly, so somebody copies it manually. An analyst checks another supplier’s portal because the status hasn’t come back, or someone sends an email because they don’t trust the automated hand-off. Different systems contain different information, so a person has to work out which one is right.
Eventually these workarounds become normal, and that’s dangerous because people are extremely good at compensating for poor technology. After a while, an organisation can have a significant integration problem without recognising it as one because it has simply become “the way we do things”.
There’s a question I’d encourage service desk managers to ask their teams: how much work do we do simply because our systems and suppliers don’t communicate properly? I suspect some of the answers would be uncomfortable.
MSPs have an even bigger reason to pay attention
This is where I think Integration Ops could become particularly significant. Every new MSP customer potentially arrives with a different ITSM platform, different monitoring tools, different processes, different suppliers and even a different idea of what an incident priority should mean, yet somehow all of that has to work with the MSP’s own operating environment.
If every new customer requires bespoke integration work, there is a fairly obvious scaling problem because more customers mean more integrations, more maintenance, more dependencies and more things that can fail. This is why the Integration Ops conversation shouldn’t simply be about whether two platforms can be connected. Of course they can; we’ve been connecting systems for decades.
The more interesting question is whether those connections can be operated at scale.
Can an MSP onboard a new customer in weeks rather than months, reuse established integration patterns and see the health of integrations across its customer base? Can changes be managed without breaking services elsewhere, and can the organisation add customers without having to add integration effort at roughly the same rate?
Those questions move Integration Ops away from being purely an integration-team concern and into conversations about margin, scalability, customer experience and growth, which is why I think MSP leaders should be paying attention.
Buyers need to look beyond the demo
We’re also likely to see more technology vendors positioning themselves in this space, which means buyers need to be clear about what they’re actually buying. A demonstration showing a ticket moving successfully between two systems is useful, but it doesn’t tell you very much about how that integration will perform as part of a live, changing service environment.
I’d want to know what happens next. How easy is it to onboard the next customer or supplier, and how much needs to be built from scratch? How do we know an integration is healthy, what happens when it fails and how are changes controlled? Can established integration patterns be reused, and what happens when the environment becomes significantly larger?
Most importantly, what operational problem is it removing?
If the result is faster customer onboarding, fewer manual hand-offs, more reliable services, lower risk or a better customer experience, then we’re having an interesting service management conversation. If the result is simply “we integrated two applications”, we’re probably still having a technology conversation, and there’s a difference.
See page 11 in the latest ITSM Tools Buyer’s Guide for more on Integration Ops.
I don’t think this should become another technology silo
This is the part I think the industry needs to get right because Integration Ops could very easily become another product category, followed inevitably by another market full of terminology and three-letter acronyms. That would be a missed opportunity.
The technology is obviously important, but the bigger question is how integration fits into the operating model for the service. Who owns it, how is it governed and how do we measure it? How does it support supplier management, how do we know it’s improving and, ultimately, what does good look like?
Those are familiar questions for anyone working in service management, and they are also the reason I think Integration Ops has a natural relationship with ITSM, SIAM, recognised standards and service desk best practice.
The customer doesn’t care how complicated it is
Ultimately, this is what it comes down to for me. We can draw wonderfully complicated diagrams showing platforms, suppliers, APIs, automation, AI, security tools and service management systems, but the customer sees none of that. They see one service.
If they report an issue, they don’t care that resolving it requires four suppliers, three platforms and six integrations, nor should they. Our complexity is our problem, not theirs.
That’s why I think the Integration Ops conversation is worth having. As our service ecosystems become more distributed, more automated and more dependent on different suppliers and technologies working together, the connections between those components become increasingly important to the quality of the service itself.
Whether Integration Ops becomes the term we’re all using five years from now, I don’t know, but I’m fairly convinced the problem it describes isn’t going anywhere.
Perhaps the simplest way of putting it is that ITSM helps us manage the service, SIAM helps us manage the ecosystem, and Integration Ops helps make that ecosystem behave like one service.
If we really want to deliver seamless service experiences in increasingly complicated environments, making all of those moving parts behave as one might be one of the most important challenges we have to solve.
Wondering what Integration Ops could mean for your organisation? Book some time with John to talk through the opportunities, challenges and where it fits within your service management strategy.
