Death by 1,000 Integration Tools

Unlike traditional on-premise software, the economics of Software-as-a-Service (SaaS) allow for profitable delivery of narrow, highly-specialized applications. As a result, the average SaaS application user consumes more applications than an average user of on-premise software. GetApp currently tracks over 5800 business apps and estimates that there are around 10,000 SaaS vendors, worldwide. And according to Intermedia, the average small-to-medium business uses more than 14 applications, from a variety of vendors.

Few applications, SaaS or otherwise, function as closed systems. So it’s no surprise that the explosion of SaaS applications has produced an aftershock of tools for integrating with external (cloud and on-premise) data and applications. SaaS leaders like and NetSuite support ecosystems with tens or hundreds of integration options. But even the smallest SaaS application vendors offer one or two integration options.

The vast majority of SaaS integration options are application-specific point tools. Many offer free or nearly free licenses, so no budget approval process is necessary. Most are readily accessible via the Web, so no on-premise planning or provisioning are required. And by focusing narrowly on one application and a small number of interface options, many are relatively easy to learn and use, so IT involvement may be limited or non-existent.

Point tools can be the right choice for integration, in some cases. Gartner’s PACE-layered strategy provides a useful way to put those cases in focus. Applications of short duration, which Gartner labels “systems of innovation”, are good candidates. They have short lifespans, so extensibility and maintainability don’t matter. And scalability, availability, and resiliency trade-offs are frequently acceptable.

But a “free” price tag can be a powerful incentive to use point tools in the wrong circumstances. Trade-offs that may be acceptable for systems of differentiation are rarely acceptable for longer-lived “systems of record” and “systems of differentiation”. To cite an extreme case, using a manual query-and-export point tool to integrate a cloud-based CRM with an on-premise ERP would inflict severe latency, scalability, accuracy, and reliability problems on most businesses.

But the problem with point tools runs deeper than a potential mismatch between business requirements and solution capabilities:

  • Because usage is frequently project-specific and user-driven, point tools can accumulate rapidly and uncontrollably
  • The skills investment needed to learn and use point tools is diffuse, unbudgeted, and not leverageable between tools
  • Diagnosing and fixing integration problems with point tools that lack adequate debugging features may require IT intervention
  • Inadequate or nonexistent point tool support can thwart needed changes or even halt integration altogether
  • Locating the knowledge needed to extend a point tool interface after the initial project ends can be hit-or-miss
  • Change management is usually nonexistent, so changes that introduce problems require manual recovery to a prior state
  • Interface investments may need to be discarded and replaced if a point tool lacks the extensibility needed to meet new requirements
  • Reliance on deprecated interfaces and tool functions may go unnoticed

Integration is essential to successful exploitation of SaaS applications. But the great irony is that the integration point tool ecosystems that have grown up around SaaS offerings frequently make effective integration harder, not easier to achieve.

Leave a Reply

Your email address will not be published. Required fields are marked *