Middleware Is Not an Architecture. It's a Maintenance Contract.

Zapier, MuleSoft, Boomi, and their siblings have a legitimate role in software infrastructure. That role is not “the connective tissue of your financial system.” When middleware becomes the thing holding your business data together, you’ve transferred risk without reducing it — and you’ve added a dependency that will require maintenance forever.

Middleware is a category of software that connects other software. At its best, it’s an elegant solution to a real problem: two systems that weren’t designed to work together, made to share data through a managed integration layer. Integration Platform as a Service (iPaaS) products like MuleSoft, Boomi, Workato, and the more accessible end of the market in Zapier and Make have made this connectivity dramatically easier than it was a decade ago.

The problem isn’t the tools. The problem is the architectural decision to depend on them for financial data integrity.

What middleware does and doesn’t do

Middleware passes data between systems. It can transform the data format, filter records, trigger actions based on conditions, and manage the timing and retry logic for transfers. It is, essentially, a managed message bus — a system for moving information from point A to point B with some control over how that happens.

What middleware doesn’t do is create a shared source of truth. When a payment is recorded in your billing system and middleware pushes a corresponding entry to your GL, you now have two records of one event in two systems. If the middleware job completes successfully, the two records should agree. If it doesn’t — if the job fails, if there’s a transformation error, if the destination system rejects the record for a validation reason — the two systems now disagree, and something or someone needs to detect and resolve that disagreement.

The probability of middleware jobs completing perfectly, forever, for every record, is not 100%. MuleSoft’s own research suggests that integration downtime and failure costs enterprises billions annually.¹ The lower end of the market, tools like Zapier, are explicit about the fact that they don’t guarantee delivery — tasks can fail silently, and the responsibility for monitoring and error handling lies with the user.

The operational overhead

Running middleware at any meaningful scale is an operational discipline, not a set-and-forget configuration. Integration flows need to be monitored. Error queues need to be reviewed. Schema changes in source or destination systems break mappings and require updates. New business processes require new integration flows. And when something breaks — when the Chargebee-to-NetSuite sync hasn’t run since Tuesday and nobody noticed until Friday — the investigation and remediation are not simple.

This overhead is permanent. Unlike implementation cost, which eventually ends, middleware maintenance is an ongoing operational burden that scales with the number of integrations and the frequency of change in the underlying systems. A company with ten active integration flows is managing ten points of potential failure, each of which requires monitoring and ongoing attention.²

The right use case for middleware

None of this means middleware is the wrong tool for every job. There are genuine use cases where middleware is the right answer: connecting systems that will never share a data model and don’t need to, synchronizing data between a legacy on-premise system and a cloud application, moving data between partner organizations who maintain separate systems by design. These are real problems and middleware solves them well.

The wrong use case is using middleware to create the appearance of a unified financial system from components that are architecturally separate. When a company’s accounts receivable balance is authoritative only if a middleware job has run correctly in the past 15 minutes, the integrity of the financial data is dependent on the reliability of a connectivity layer — not on the architecture of the financial system.

The alternative question

Before adding another middleware connection, the question worth asking is: what would we need to change about our architecture to not need this connection? Sometimes the answer is that the systems genuinely can’t be unified and the middleware is the right compromise. More often, the answer reveals that the root cause is running multiple systems where one would serve, and the middleware is a workaround for an architectural choice that was made earlier.

Middleware is most valuable when it’s connecting systems that are intentionally separate. It’s a warning sign when it’s connecting systems that are supposed to be unified.

Sources