The Integration That Wasn't

Why "integrates with your existing systems" is almost never true

Somewhere in every vendor presentation is a slide about integration. Icons of different systems connected by arrows. Your ERP, your MES, your quality system, the new equipment, all talking to each other seamlessly. The word "seamless" appears more than once. The reality will be anything but.

Integration is where technology projects actually get expensive. Not the equipment, not the software licenses, not the installation — the glue code. The months of work figuring out how to get System A to talk to System B when they were designed by different companies, in different decades, with different assumptions about how data should be structured.

"Integrates with" usually means "has an API" or "supports standard protocols." This is technically true and practically meaningless. Having an API is the starting point, not the destination. The work is in mapping your data to their data, handling the exceptions that occur when mappings don't fit, building the error handling for when connections fail, and maintaining all of this as both systems evolve independently.

I've watched integration projects double and triple their budgets. Not because anyone was incompetent, but because nobody understood the scope at the start. The complexity isn't visible until you're deep in the details: this field that's mandatory in one system but optional in another, that status code that means different things in different contexts, the timestamp format that almost matches but doesn't quite. Each discrepancy is a decision, a piece of code, a test case, a potential failure mode.

The vendors on both sides point at each other. Your existing system vendor says the new equipment should conform to your standards. The new equipment vendor says their API is well-documented and integration is your responsibility. Both are technically right. Neither will build the bridge for free.

Standard protocols are supposed to solve this problem. OPC-UA for industrial equipment, REST APIs for software systems, standard file formats for data exchange. Standards help, but they don't eliminate the work. They standardize the transport layer, not the meaning layer. Two systems can communicate perfectly over OPC-UA while completely misunderstanding each other because they model the same concept differently.

There's a specific meeting where integration scope gets underestimated. Someone asks how hard it will be to connect the new system to the existing infrastructure. The vendor says "we have connectors for that" or "it supports industry standards." Everyone nods and moves on. Nobody asks what happens when the connector doesn't cover your specific ERP version, or when the standard protocol is supported but the data model isn't compatible, or when real-time requirements exceed what the integration layer can handle.

The honest answer to "how hard is integration?" is "it depends on details we don't know yet." That answer doesn't fit in a project proposal. So the proposal contains an estimate based on best-case assumptions, and the project burns through the estimate in the first month of integration work.

Companies that handle this well do two things. First, they budget integration as a separate line item, usually 30–50% of the technology cost, rather than burying it in installation. Second, they involve the people who maintain their existing systems early — not to approve, but to identify where the bodies are buried. The IT team that manages the ERP knows which integrations have failed before. The maintenance team knows which protocols the existing equipment actually supports versus which it claims to support on the datasheet.

The arrows on the integration slide are lies. Not intentional lies, but lies of omission. They show connection without showing the effort required to make connection meaningful. Every arrow is a project unto itself.