Why eBonded Systems May Be More Hindrance Than Help

Let’s say you’re running ServiceNow in your organization and you have been given the challenge of creating a functional connection between ServiceNow and a number of smaller applications. You’ve done a bit of Googling and looked at a few bits of ServiceNow documentation, and you’ve come across eBonding as possible solution.

Alternatively, perhaps you have a Managed Service Provider who is eager to connect up your respective Service Desk/ITSM tools, and eBonding has been put forward as the integration solution for making your two tools talk to each other.

Either way, this method of integration is in the cards. However, you can see it might have limitations and you are trying to work out what can be done to mitigate the various weaknesses–then ultimately ensure that the future of your software and service ecosystem isn’t running into any major risks–just to get ahead of the issue.

eBonding is actually a pretty tired solution, but it is still leaned on a lot to get a wide range of specific integrations up and running. Businesses we see that move forward with eBonding often end up in a place where they can’t mature or grow integrations in a way that suits the goals of the business. And, within a year or so, the eBonded integration becomes more of a hindrance than a help. But, don’t worry–there are easy ways around this.

What Is eBonding?

Like many integration solutions, eBonding allows you to pass data between two pieces of software. It’s a particularly popular solution for ServiceNow users, whereby you create a bi-directional integration between ServiceNow and another application.

You can often see this used in MSP or multiple ITSM tools environments, where you might have two or more teams collaborating over service requests, and you need to ensure the data they are all working from is consistent across all systems and teams.

The main benefit of eBonded solutions is that they typically provide you with a “synchronized” exchange. This means that data is shared automatically, and you’ll always have “matching” data in both systems (in theory).

Why Would You Be Thinking about It

I often see eBonding as an MSP-led solution. They have their own version of ServiceNow or Remedy, and they don’t want to have any manual processes for managing single service requests/tickets across your service desk and theirs.

Because eBonding can usually be set up within ServiceNow’s own eBonding/integration tooling and doesn’t require much manual coding, it’s quite an attractive solution for the MSP. And, for the end customer, it cuts out any debate or negotiation around changing or sharing service desk software, which is a big issue for many early-stage MSP/customer relationships.

But eBonding is not scalable and it is not mature enough for most of the integration needs you’re going to be coming up against in the future.

Why You Should Not Do It

Modern businesses need to move, change and adapt quickly. The most competitive brands I have worked with all place their agility around technology and software at the forefront of their IT strategies. And what I am now increasingly observing is that IT leaders see integration as one of the biggest enablers of this kind of agility.

This is because the ecosystem of software and services you have in your business is now far more important than any one piece of software. The way those different software packages work together is defined by