Building, managing and supporting multiple platform integrations at scale is a challenge for any organization. But bidirectional ticket exchange integrations, also known as eBonding, add an often-overlooked layer of extra complexity.
Take the example of a large MSP. On an ongoing basis, the MSP’s team could manage many hundreds of systems, triggering thousands of events and incidents every day. In this environment, lots of custom integrations can put a considerable strain on the service desk.
Anyone who has got under the hood of eBonding will know that there are many facets to tackle. However, these facets are often not considered early enough in the process or dealt with adequately in the integration.
Yet ironically, despite eBonding’s added complexity, there’s often an oversimplification in the integration approach. People assume eBonding is similar to a data import and, in doing so, cause themselves a host of problems.
Part of the problem is that, while data integrations are everywhere, eBonding is much less common. There are plenty of developers who have built lots of data integrations. Far fewer have that same level of direct experience of eBonding; therefore, they can’t be expected to know all the deeper nuances and complexities at play.
As someone who has worked with eBonding integrations for the last decade, I’ve made all the mistakes and earned the battle scars. Despite eBonding’s complexity, it doesn’t have to be a ‘dark art’; it simply requires proper consideration for how you want it to work in your organization.
Here is how to set yourself up for success.
Have a clearly defined strategy and process
The most fundamental mistakes happen when eBonding is an afterthought. Often a lack of communication and understanding between different lines of the business will lead to development times getting squeezed and teams being pushed to get eBonding integrations out quickly.
The effort and complexity involved in properly building eBonding integrations are underestimated and developers aren’t given the time they need to think through the essential considerations: what’s my strategy for doing this? What is the overall view? How am I doing it? Am I going to build all my integrations the same way? What system am I using?
Not thinking these questions through or leaving enough time in the process is problematic because your process is king in eBonding. You can have a poor platform, but if your process is excellent you can still make it work.
Think of your process as the architectural drawing that everyone can come back to — from the people building the process to the people operating it to anyone that’s trying to connect into it.
In my experience, many people don’t have that process well defined or haven’t thought it through in enough detail. In those cases, when inevitable questions or problems crop up, it sets off a spiral that ultimately leads to cutting corners and compromising the integrations because the time and/or budget isn’t there to do it ‘right’.
Some examples of things that frequently get overlooked in the process include:
Auto closure: Many people implement auto closure in their ITSM systems. It’s a fundamental part of the process of how we close tickets, but often not considered because people are used to thinking about their system in isolation.
When you try to integrate with other systems, how you approach auto closure can make a big difference. You’ll often get situations where there’s a conflict, e.g. one side has an auto-close of say three days while the other side is six days. You have to proactively decide how to do the auto-close. If one system closes the ticket in three days, you don’t want somebody to reopen it in the other system.
Having a process agreed up front means you’re always starting from a place of “this is how we do it”. It avoids having the same conversation with every supplier or building each integration in isolation, with decisions left to the developers involved (who may not be around the next time a similar integration is needed).
Breaking down messages: Many people will try to apply a traditional integration development CRUD (create, read, update, delete) approach to eBonding. By that, the thought process is once the ticket is created it’s integrated into the other system, then when that ticket is updated, the old system is updated, and that’s where it stops. But that’s not how processes work.
If you think about your process strategically from the start, you realize there are many more scenarios taking place that directly translate to messages and other actions that go on within your process. As well as ‘create’ and ‘update’ you’ve got ‘assignment’. Here you’re telling the other system you’ve sent a ticket to it, so the other system probably needs to be able to acknowledge the ticket was accepted. The other system also needs to have a reject mechanism to say this has nothing to do with me. Then there is a resolution message, suspends and all sorts of other things. What starts as two messages very quickly gets into multiple figures. Failure to deal with this means you’re overloading the update, and it’s not clear from a process or debug point of view what’s happening.
Questions of ownership: In eBonding integrations, it’s vital to ensure all of the systems that rely on the ticket exchange mechanism are in sync. Where you have two systems working on an incident simultaneously, you can run the risk that updates on one system could overwrite those on the other, destroying clarity and precision in the data and bringing down the whole process.
Permissions and access control must be appropriately implemented throughout the process. It is fundamental and can’t be retrofitted, so must be done as part of the upfront implementation to avoid problems like limbo tickets. Baking the ownership controls into the process at the outset is the only way to stop users from initiating something they shouldn’t or updating a ticket they don’t own.
With a robust, well-defined process, you’re forewarned and can pre-empt all these issues instead of having to shoehorn a workaround in three weeks before going live.
Next, be sure about what you’re buying
As I already mentioned, data integrations are everywhere and eBonding is a lot less common. Because of this difference, there has been more native support for data integrations built into ITSM systems; eBonding has not received out-of-the-box support and has involved a lot of custom development.
That said, many of the major ITSM systems have started to market themselves as supporting eBonding but approach with caution. What ‘support’ often means is that they’ll support the basics and specific, limited scenarios. When you want to do something more complex, you’ll quickly realize that significant custom development effort is still required to make it happen.
Ultimately, doing eBonding right as a custom build project is always going to be cost-prohibitive. Look for tools that go beyond the basics and allow you to achieve that goal in a fraction of the time.
Finally, remember that the value of a good integration far outweighs the cost of propping up a bad one
The most impactful way of illustrating this point is to share the example of Nordic MSP Advania.
Advania’s eBonding integrations were typically custom processes that required a significant investment of time — approximately 300–400 hours per customer — amounting to a couple of months of work.
With Advania looking to scale, it realized that this time-consuming and complex process was unsustainable. Consequently, it embarked on a strategy to simplify and standardize eBonding integrations.
Advania has now successfully created a ‘golden image’ or standard integration that is now used internally and for all its customers. Thanks to this simplification, the setup time of new integrations has fallen from 400 hours to an average of 35–40 hours. These new efficiencies driven by the standardized eBonding integration process have resulted in savings of several million Swedish krona (1 million SEK = $120,000).
So, do you want pain or an easier life?
As I hope I’ve illustrated, by really making an effort to think about your eBonding process upfront, taking the time to develop a robust strategy and making sure you have the right tools for the job, you can put yourself on the path to successful ticket exchange integrations at scale.
Tim Attenborough, Co-founder, ShareLogic
