Top 5 Reasons That Integrations Fail

For a well-planned integration project, a business decides on project goals in advance. Articulating these goals is essential because so many integrations fail.

Taking time to analyze why previous integrations fail helps a company plan better for what a healthy integration solution looks like, what it will take for the next integration to thrive, and what value it will deliver for the business.

So here are the top five reasons that integrations fail. Which ones have you seen in action?

1. People Moved On

Of all industries, the technology industry has the highest turnover rate. When a company replaces an employee, it’s rarely an even replacement. Vital information failed to transfer, and the company has lost knowledge. A study on unshared knowledge by Panopto and YouGov found the following:

• 42% of needed skills for a position are known only by the employee in the position at the moment.
• 21% of the work week is spent inefficiently due to knowledge gaps.
• 60% of employees report difficulty or extreme difficulty getting information needed to do their jobs.
• Companies with 1000 employees lose $2.4 million per year because of knowledge loss.

Consider what happens when an employee who helped implement an integration leaves—or when a consultant who did the same is no longer available. The result? The integration’s days are numbered.

Here is a representative scenario. An application architect managed the details of a custom integration for the company that employed them. Then that employee leaves. Because that architect did not document all their work (very few do), it is not only difficult but impossible for the replacement to upgrade or continue managing the bespoke integration. So the integration fails.

And it is not only technical knowledge failing to transfer that causes integrations to stop working. The integration champion may also fail to transfer the business value. The integration serves a strong business purpose for the organization, but because of employee turnover, others do not see the same purpose. But more on that below (#5).

To avoid knowledge loss, companies often retain employees that would not otherwise be retained, impairing effectiveness in other areas. Or when a new employee is tasked with managing an integration that they did not implement, their frustration at being thrown into an overwhelming situation kills their morale during crucial days in a new position.

Solution: Rather than relying on employee knowledge that leaves when the employee does, partner with a stable, trusted integration provider that delivers end-to-end service for your integrations.

2. Systems Replaced or Updated

High turnover in IT does not exclude administration. When new leaders come in, they often replace systems.

A Microsoft-centric CIO is hired into a Fortune 500 enterprise company. The next year, all the systems have switched to Microsoft systems, because that’s where the CIO’s alliance and connections are. The same is true, whether it’s years of experience with Amazon Web Services, Remedy, Cherwell, or other platforms.

Whether new leadership or another factor prompts the change—and whether a system is replaced or updated—what happens to integrations that connected with that system? A change in systems means that all of the custom integrations with the old system must be replaced—an extraordinary amount of work.

Fortunately, there is a much better approach.

Solution: Integrate at the process level so that a changed or updated system does not cause the integration to fail. When you switch out or change the systems that the integration targets, it’s merely a new endpoint. The change does not require a whole team writing code and fixing problems.

With process integration, a change in a system does not require a change in the process that the integration is supporting. Making use of a common data model, an incident management process, for example, is the same whether you integrate with Remedy, ServiceNow, or another ITSM solution.

Unlike the shallow integrations via the connectors and adapters of expensive iPaaS toolkits, an integration with prebuilt mapping is a wholly thought-out process integration. To take our ITSM example, the process integration understands the representation of an incident in ServiceNow and how it’s different from the representation of an incident in Remedy.

The common data model solves the problems of systems changing or being updated. Integrations that are done at the process level are impervious to system or target-endpoint changes, because the process stays the same.

3. Unreliable Connections

You can lay a wire between a battery and a bulb, but if the current does not flow, the setup has failed.

The ability of one system to connect to another is fundamental to integration, the reliability of the networking being crucial. Connections are vulnerable to a variety of interruptions: an outage in electricity, a data-center outage, denial of service attacks, systems down for upgrades, crashed systems, and so forth.

In most point-to-point integrations where networking fails, data is normally lost. And the integration itself is a failed integration because it is not achieving its purpose.

Solution: Implement an integration solution with queuing that prevents data loss.

As a managed service provider, Virteva found that its use of web services was insufficient for maintaining data integrity during ServiceNow upgrades. According to Virteva’s VP of Delivery, Matt Miller, “If I had a customer that I was integrating with to pull their data, we had no way to queue any data that needed to be sent to them.” Missing data updates meant “working endless hours on troubleshooting.”

Needing an option that could handle upgrades more reliably, Virteva implemented an integration solution that employs a message bus, with built-in queuing. If a connection fails, the data is still saved, ready for completed delivery whenever the endpoint is back up. “That’s been a huge help for us,” says Miller.

4. New Security and Privacy Rules

Along with the arrival of GDPR and the California Consumer Privacy Act of 2018, additional states are expected to pass privacy laws of their own. These laws come as studies show elevated consumer concern over security and privacy. For example, 69% of consumers would boycott a business that fails, in their view, to take data protection seriously. The privacy movement is here.

Now that cloud services are accessible worldwide, it is clear that security is of utmost concern. For integrations, there are stricter conditions and rules such as mutual authentication and data obfuscation.

If your integration is not built with security and privacy concerns in place—as is the case with most or all integrations that have been in place for at least a year—you will have to terminate those integrations and have them rebuilt in a way that complies with security and privacy requirements. The old, non-compliant integrations have failed.

Solution: You could educate your IT teams on and then apply the regulations of GDPR, the new California law, and other privacy laws that are likely to follow. But a simpler solution is to sign on with an integration provider that stays up to speed on relevant security and privacy rules at the platform level that is repeated for all solutions and customers. With that approach, you get the compliance benefits whenever the provider updates processes to keep up with the regulations.

5. Business Value Left Unrealized

Often, when integration requirements trickle down to the team that actually builds the integration, the importance of the business value has faded. That IT team is more concerned about overcoming the technical challenge of building the integration. But if the business value is not realized, the integration hasn’t delivered what the consumer or the benefactor of the integration needs. Over time, the integration will just be forgotten and then die.

So focus on knowing what the business value is. Before starting an integration project, it is important to ask questions that prompt vision into value ramifications:

• If this integration is in place, what actions can be taken to enhance value?
• If this integration is not in place, who is going to suffer?

Without having value in mind, the integration becomes just a technical job, not a business enhancement. But it’s hard to instill the importance of business value in the technical team that builds the integrations.

Solution: Partner with a provider that runs an integration platform focused on business value. Such a provider knows not only what the process is that the integration serves but also who benefits from the process being integrated. Avoid settling for tools with connectors that are not actually built for the process that you are trying to optimize. A provider that places a priority on process integration will also be familiar with a broad range of use cases, some of which are relevant to and can inform your own integration objectives.

Maximize the Return on Your Integration Investment

Whether you build your own integrations or buy a solution, the resources that you devote toward integrations are significant. Moving forward, that spending will likely increase as competitive enterprises increasingly require secure integrations that convey visibility and preserve data quality.

With a complete, business-focused integration solution, you can stay on target with your business objectives and get maximum return on your integration investment.

Want to learn how your integrations can deliver data integrity, security compliance, and business value? Let’s get in touch.