Integrations in small numbers can be relatively straightforward to implement and maintain. You can get away with having them all built, managed, and supported independently. But when considering them at scale, especially eBonding integrations, you need to take a very different approach.
One alternative approach we frequently see is to use so called “plug-and-play” integration platforms. In our experience, there are no plug-and-play eBonding integrations. And where these platforms work very well for simpler one-way data integrations, the increased complexity of eBonding is not well supported.
Our view is that eBonding can work well at scale. You just need the right platform, and this is where Unifi takes centre stage. We have put this blog together to discuss some of the underlying reasons that make eBonding at scale difficult and the ways in which Unifi makes things much easier.
Why is eBonding at scale difficult?
A common challenge when scaling eBonding integrations is that most published APIs are not designed for them. They are usually designed for simple data synchronisation. In these types of integrations, the receiver will typically be expecting the data to be lined up perfectly.
However, published API’s typically have a very limited capability for manipulating data as it is received. The whole emphasis is then on the sender to maintain this data. This might be OK for one or two integrations, but it becomes an arduous task if you have twenty, or in some cases hundreds to manage.
Another challenge with eBonding is that everyone’s processes are slightly different. Even though most people will approach a process in a similar way there are still areas where they tend to differ; for example, when putting incidents on hold, or the automatic closing of incidents after resolution or approvals for change requests. And these differences between processes tend to be greater when the process itself is more rigid.
It is relatively easy to manage the differences if you only have one or two integrations. But many of our customers like Advania manage dozens of eBonding integrations. When you have many eBonding integrations that all require bespoke changes, how do you cater for this? It is a problem, especially in systems that are designed for rinse and repeat plug-and-play.
Typically, operational errors or issues tend to go undetected, or at best are recorded in an admin only log file. Error messages from integrations are lost in this generic log, containing every other error, warning, and info message from the system.
Analysts working on bonded tickets have no visibility that there are issues, and certainly no way to resolve them without specialist support. It becomes a time-consuming task to find and resolve integration issues, and one that also requires highly skilled developers, preferably those who built the integration in the first place.
How Unifi makes things easier
Unifi’s co-founders James Neale and Tim Attenborough spent their early careers doing this kind of integration design, development and support, battling against these challenges daily. Their authentic real-world experiences, learnings and insights are what makes Unifi an exceptional integration platform.
Our MSP customers experience many of the challenges outlined above. They must maintain different data, service catalogue items and integration structure for each customer. With dozens of different integrations, it becomes unmanageable.
Unifi can be used to map data both inbound and outbound, and by having your customers use Unifi in their own ServiceNow instances, the data mapping can be maintained locally. It has the controls and capabilities to perform detailed inbound mapping and transformation, removing the complexity of data management from the MSP. Read more about how BT used Unifi to simplify its eBonding integrations using this technique.
Unifi has been designed from the ground up to manage integrations at scale and to cater for process nuances. Integrations and scenarios can be modified and tailored independently from one another. If one customer requires a change, you do not need to regression test the others.
Within this flexibility is structure and standardisation. Integrations are grouped into processes, and scenarios are grouped by integrations, meaning they are all managed and supported in the same way, even when they have different data mapping, scenarios and even for different processes altogether!
Unifi presents the operational workings of eBonding integrations to the whole support team. People working on bonded tickets can instantly see if there is a problem with the integration and either look at it themselves or escalate to a specialist team.
With one click from any bonded ticket, you have access to all relevant transactions and logs. There is no need to hunt through large log files for the correct second something happened. Transactions coming in and out of Unifi are displayed in real time, and errors are highlighted in the instance that they happen, even raising incidents within your system to alert support automatically.
Now Platform eBonding at scale
The challenge with mainstream plug-and-play systems is their flexibility. These tools are inherently rigid and therefore do not cater for process alignment at scale. Of course, you can still achieve eBonding integrations with them, but the management and administrative overheads when dealing with lots of integrations should not be underestimated.
Unifi has been designed and built to be flexible because we know that in the real-world every integration is different. Everybody wants tools that adapt to their needs and processes and it is this inherent adaptability that allows Unifi to effectively deliver Now Platform eBonding integrations at scale.