Monday, November 2

Choosing an Integration Platform When Your Apps Refuse to Talk

Network cables plugged into a rack, a symbol of an app integration platform
Image: Federal Bureau of Investigation / Wikimedia Commons, Public domain

A finance team exports a spreadsheet from the billing system every Friday, pastes it into another tool, and emails a summary to sales. Nobody designed this process. It grew because two applications could not exchange data and a person was cheaper than a project. Multiply that by every department and you have the reason the app integration platform category exists.

What an app integration platform really does

An app integration platform sits between your business applications and moves data or triggers actions between them. When a customer signs a contract in one tool, the platform can create an account in another, notify a team chat, and update a report. The work is done through connectors, which are prebuilt links to common software, and through a workflow builder where you define what happens and when.

App integration platform - Network cables plugged into a rack, a symbol of an app integration platform
Image: Mike Linksvayer from Oakland, California / Wikimedia Commons, CC0

The newer wave of these products adds machine learning to the mix, offering to suggest mappings between fields or to build a workflow from a plain-language description. That can speed up the first draft. It doesn’t remove the need to understand your own data.

Start with the problem, not the product

Before you compare any app integration platform, write down three real workflows that currently waste time. For each, list the systems involved, how often it runs, what happens when it fails, and who owns it. This exercise tends to reveal that some tasks need a simple trigger-and-action tool, while others need heavy data transformation or strict error handling. A tool designed for one will frustrate you with the other.

Questions to ask any app integration platform vendor

  • Connector depth. Does the connector for your key application support the specific objects and actions you need, or only the basic ones? A logo on a features page does not mean a deep integration.
  • Custom endpoints. When no connector exists, can you call an API directly without leaving the platform?
  • Error handling. What happens when a step fails at 3 a.m.? Look for retries, alerts, and a way to replay a failed run without duplicating records.
  • Logs and visibility. Can a non-developer see what ran, what data moved and why something broke?
  • Security controls. Credentials, role-based access, audit trails and data residency matter, because the platform will hold keys to many of your systems.
  • Pricing model. Some charge per task, some per connection, some per user. A workflow that runs thousands of times a day can turn a cheap plan into a surprise invoice.

The hidden costs

Licensing is only part of the bill. Integrations break when a vendor changes an API, when a field is renamed, or when someone adds a mandatory column. Somebody must monitor and maintain them. If you pick a tool so friendly that anyone can build flows, you may end up with hundreds of undocumented automations built by people who have since left. Governance, meaning naming rules, owners and a review step, costs little at the start and a great deal to add later.

Scale changes the picture too. A small company may be happy with a handful of simple automations, while a larger one needs a test environment, an approval step before changes go live, and separate permissions for who can edit what. When you shortlist an app integration platform, ask to see how it handles those controls, not only how quickly you can build a first flow.

Pricing deserves the same scrutiny. Per-task and per-user models behave very differently as usage grows, a trade-off explained well in this guide to software pricing models. It is also worth reading about the older discipline behind all of this, known as enterprise application integration, because the same problems keep returning under new names.

Data quality is the other recurring trap. Two systems may both store a customer name, but one uses full names and the other splits first and last. An integration that copies data blindly will spread inconsistencies. Spend time on matching rules, such as which system is the source of truth for each field.

Buy, build or both

Some companies write their own integration code. It gives full control and fits unusual requirements, but it ties up engineers on plumbing and tends to be poorly documented. An app integration platform shifts that burden to a vendor. The middle path is common: use a platform for the long tail of routine connections and keep custom code for the critical, high-volume or latency-sensitive paths.

Run a pilot that can fail

The best evaluation is a two-week trial on one real workflow with real data. The same logic applies when renting GPUs by the hour for a short AI project: pay for a small, bounded trial before you commit. Pick something with a clear success measure, like time saved or errors avoided. Break it on purpose: send malformed records, revoke a token, change a field name. Watch how the tool reports the failure and how long recovery takes. A product that handles the happy path beautifully and the failure path badly will cost you more than any license fee.

Also ask who will own it after launch. Even a well-built app integration platform needs a named person who watches the alerts and approves changes. If the answer is nobody, you’ve simply moved the Friday spreadsheet into a more expensive place.

Image: Federal Bureau of Investigation / Wikimedia Commons, Public domain.