Most integrations are built to a deadline. Going live is the easy part. The real work comes in the years after, when a process changes, the other side upgrades, or the person who built it moves on. Governance is what makes those moments routine rather than an emergency.
How integrations become technical debt
It rarely happens all at once. A quick fix goes into a script that other things depend on. A field mapping lives in one person’s head. A second customer’s integration is copied by hand from the first, and the two slowly drift apart. Each shortcut works on the day. Years later, nobody can say exactly what the integration does, so nobody wants to change it, and the only person who knew has left.
What good governance looks like
Mostly, it’s uneventful. When a customer changes their process, the slow part is agreeing what should change, not working out how to change it. When something fails, your team opens the integration, sees what was sent and what came back, and fixes it without calling anyone. Someone new can follow an integration in their first week, because it’s built like all the others. And nothing runs that nobody knows about: every integration has an owner and a record, not just a memory.
Knowing what crosses the edge of your platform
Governance also means being able to answer a simple question at any time: what data is coming in, and what is going out? For integrations that run both ways, that means every update sent and received. For other systems connecting to yours, it means each one and exactly what it’s allowed to touch. Our explainer on controlling access to your ServiceNow APIs covers that side in detail.
Where governance is easiest
A policy document doesn’t govern anything on its own. Governance has to live where the integrations run. Put the logic in middleware and you’re governing two systems, plus the gap between them. Hand it to an outside service and the knowledge sits with them, not your team: the same single point of failure, with a contract attached. Keep it on your ServiceNow instance and the controls you already run apply to it, and your own team can read every integration. How native apps compare with integration platforms
How we approach it
We built Unifi for integrations that have to last. You build an integration around your process once, then each new one starts as a copy, tailored from there, so they’re all built the same way. Each integration is configured in the app rather than spread across scripts, with its own settings and access, so changing one can’t break another, and every message is logged on your instance. Every integration is a record you can list and open. We test Unifi against every weekly ServiceNow patch on the oldest and newest supported releases, so it keeps pace as the platform moves on.
NTT MCIS, part of NTT Group, is one example. Over five years it extended Unifi from its eBonding integrations to its CMDB and automation platform. In the words of Fernando Caamaño: “Over time, with the help of Unifi, we have built the know-how and confidence to quickly integrate our systems with pretty much any external system.” Read the story
Easy API, coming soon, brings the same thinking to the APIs other systems use to reach your instance, with control down to each user, service and API.
