Integrations are everywhere in today’s IT landscape. They are fundamental in supporting our businesses and allowing them to provide the services demanded by today’s consumers, both inside and outside the enterprise. Most integrations are simple data exchanges, but eBonding is all about integrating processes.
eBonding has been around for decades now, starting life in the telecommunications industry to support large customers by connecting their ticketing systems together with a much more robust protocol than email. Over time, more and more businesses have taken the same approach with their customers to provide better service and value. Today, eBonding is critical to almost every enterprise, and is even creeping into smaller organisations who might be providing managed services or other B2B technology to their customers.
To help pull back the curtain on eBonding and ticket exchange we have created this blog series to introduce and define the many different factors of a successful eBonding implementation. We want to make it easy to understand and show how each part interacts with the other elements of the process. We want to help you understand how to get the best out of your ticket exchange integration and to help you avoid some of the common pitfalls.
Why is eBonding different?
Typical integrations focus on the exchange of data and there is a misconception that eBonding is broadly the same thing: sending data between two systems. Fundamentally, that is correct, however it is very much oversimplified. eBonding integrations require much more forethought to ensure they are fit for purpose and built in such a way that they more easily adapt to process modifications demanded both internally and externally.
The real complexity from eBonding comes from the fact that you are often talking about connecting two very different systems together, neither of which follows exactly the same process. Often, eBonding is also being considered for more than just one customer, so it needs to be scalable. Typical integrations might start with data mapping, and while that is valuable, the real place to start is defining the many interactions or scenarios that take place. This means thinking about how the users of the systems on either side will have the data they need at the correct time and know what they can and cannot do with it.
It is critical to really think about how the two different systems need to interact – or how you want them to interact. And it is important to do this thinking up front. Once you have implemented your process it can be very difficult or impossible to retrofit features or functions you find out would have been useful further down the line.
Much to consider
There are many elements that go into a successful eBonding integration that relate to both how data is handled by each system and exchanged between them, and also how the processes interact together.
For example, bonding tickets together in different systems can lead to data synchronisation issues if care is not taken to control when tickets can be modified. As a result one of the key considerations in designing a ticket exchange integration is ownership. How do you bake in controls at the outset that clearly define who can update or change a ticket at any given moment?
Equally it is necessary to consider how you can deliver a shared, cross-system view of things like users, configuration items (CIs), locations, groups, and other supporting data around tickets – the ‘referential data’ - so that a user has access to the information they need to fix the issue when they need it.
What about the process by which information is shared between systems? Do you want to transfer messages and information synchronously or asynchronously? At the same time, how will these processes be managed when the system is live? The order in which data is updated and sent and received is important – so will you use a message bus or another tool?
Finally, and perhaps most importantly, how will you know if something goes wrong? How will the system alert you if data imports fail or if tickets aren’t getting through?
Getting the details right for successful eBonding
As should hopefully be clear, it is this level of detail that puts eBonding above and beyond most other types of integrations. However, this isn’t complexity for the sake of it. It is critical that all of these elements are considered individually and collectively if an implementation is to be successful.
This is just a brief overview of the challenge of eBonding however. To dig a little deeper please carry on reading the other blogs in this series where we go into each of the key elements of a ticket exchange integration in more detail.