The importance of data integration to the modern enterprise cannot be overstated. Given the fundamental role that integrations play in supporting the smooth running of businesses, IT teams must understand the finer details of what is involved in any given deployment.
Many organisations might be comfortable with their ability to handle certain types of integrations. However, there is a considerable variation in how these solutions are constructed and what they are trying to accomplish. It doesn't automatically follow that handling one type of integration enables you to build other integrations successfully.
eBonding typifies how different integrations can pose significantly different challenges. Several factors make up the differences between a typical data integration and an eBonding integration. Not having a clear understanding of these differences can cause significant issues when building and operating an eBonding solution.
IT teams need to consider a range of methods and approaches to make the integration process as smooth as possible. To help make that distinction clearer, this blog will look at five key factors that underpin the differences between these two types of integration.
1. Rates of deployment
Perhaps the most fundamental difference between data integrations and eBonding is how regularly the two techniques are used.
Data integrations are everywhere. Because of that a lot of people have built one, they are well-understood solutions, and people know how to deal with them. Conversely, eBonding deployments are a lot less common. Fewer people have that direct experience of this type of integration.
This difference is manifested in the tools available to IT teams. There tends to be native support for data integrations built into most ITSM systems. There are mechanisms within the systems themselves to support the basic import/export requirements that are more suited to simpler data integrations than eBonding.
Traditionally eBonding has not benefitted from the same ‘out of the box’ support. Creating an eBonding integration has instead required a lot of custom development to support features like queue management and error handling.
2. Integration directionality
At a more technical level, data integrations are typically ‘one-way’ systems. Data is either going in or out of a system.
In comparison, eBonding ticket integrations are bi-directional. Information has to flow both in to and out of the system.
This immediately increases the complexity of eBonding integrations compared to one-way systems.
3. Fixed versus dynamic data
Another core technical difference between the two approaches is the type of data that is being managed.
Data integrations tend to be dealing with ‘fixed’ data, for example location information, group details or cost centre data. Essentially, this is about dealing with master data sources. The data is not volatile.
Once you understand the data and where it's coming from, there is not much else to be considered. Some data will be changed over time, but these updates will only happen periodically, by the very nature of the data in question.
In contrast, eBonding integrations deal with tickets, which is a much more dynamic scenario. A range of changes can occur – a comment or an attachment is added to the ticket, or the status is altered – and these changes can happen at any time and will likely happen several times in a day.
Again, this has an impact on the complexity of the integration. The more dynamic the data, the more management is required.
4. Process complexity
Linked to the previous two points is the type of process required by the different integration techniques.
The data import process that governs data integrations tends to be simple: I will pull some data from this master source and put it into a table. The process of eBonding is much more complex.
Things have to be done in a particular order, and only specific actions can be taken at certain times. You can't close a ticket before you've assigned it, for example. As a result, message queueing and process stacking is important in eBonding scenarios, which aren't considerations in a straightforward data import use case.
With a data import, there is less importance placed on how and when the data is transferred. Generally speaking, there is no order, and there is no process. Whereas with eBonding, the order and process really matter.
5. Criticality of operation
Finally, there is the issue of criticality. Although data imports can be important, generally, if one data import doesn't work, it will not bring the whole system down with it. It's not going to affect the running of the business.
With an eBonding ticket integration, it's a different story. Not only is eBonding more complex, as highlighted above, but it is also likely to be mission-critical to the whole business.
If the organisation the eBonding integration is supporting suffers a major outage, data must be appropriately shared and tickets updated correctly. Faults in the process will cause significant issues that could stop the business in its tracks.
This risk necessitates having handover and handshake mechanisms in eBonding integrations. Messages need to be sent, and the receipts need to be acknowledged to ensure that updates and changes don’t fall through the cracks and the ticket is resolved as quickly as possible.
Getting the process right
As this blog has demonstrated, there are many different integrations goals and major differences between use cases.
There is no doubt that the complexity of eBonding presents a significant challenge. It’s why we created Unifi. Whether you are building a simple data integration or an eBonding solution, we believe you should have ‘out of the box’ support to make the process as reliable and straightforward as possible.
Whatever type of integration you’re building, Unifi makes it easier than ever to build, use, and manage the integrations businesses rely on.