Indeed. Our software basically sits between customers systems (ERP/WMS etc) and some gov't systems. Even a bare-bones integration usually means getting data from ERP/WMS and sending data back to invoicing system. As you say, how orders/invoices etc are structured varies a lot.

In the more complex systems we interact with over 6 other systems, sometimes a lot more if the customer has done acquisitions but not consolidated IT systems (one potential customer had over 20 systems we'd have to integrate with, including 5-6 different WMS systems).

We found that it's usually easiest to just get the customer to tell us what their systems can provide or need, and then make the shims on our end. We've got a few customers running BizTalk and such but as far as I can figure they're mostly just an additional point of (frequent) failure.

All I do for a living is build middleware.

Don't take that away from me.

This kind of mapping and data massaging is a comparatively manageable task if the applications themselves provide reasonably standard interfaces. There's no inherent reason for it to be provided out-of-the-box by a single, monolithic "middleware" platform.

If you are a large business the assumption that all applications will have reasonably standard interfaces won't hold water.

Most ERP's or similar enterprise software will have some sort of mapping layer (e.g. mulesoft) otherwise they just won't be able to roll their software out into the real world.

It's at least no worse than "all applications will be compatible with a single, proprietary middleware platform", which is the assumption OP seems to rely on for their argument that these bespoke platforms are so crucial to enterprise IT.

The middleware platform is about applications communicating to/from salesforce.

Let's say we have the following:

- Salesforce conforms to a standard and sends sales orders in format "Generic Order Format"

- WMS receives sales orders in format "WMS Order Format"

- TMS receives sales orders in format "TMS Order Format"

- TMS will update Salesforce on shipment progress in format "TMS Order update format"

- WMS will also update shipment progress to Salesforce in "WMS Order update format"

So without some sort of mapping layer, how would this work? How does Salesforce understand the formats? How does it even know what software needs the messages at what intervals? What if they are legacy systems that require a EOD batch? Insisting the other vendors change their software to conform to "Generic Order Format" is just moving the issue, and means you will never make any sales.

> So without some sort of mapping layer, how would this work? How does Salesforce understand the formats?

There's always a mapping layer, but that layer could itself be modularized and interchangeable. What I have some trouble getting is the assumption that this has to be managed by a single-vendor platform.

> What I have some trouble getting is the assumption that this has to be managed by a single-vendor platform.

Well the article isn’t saying that the middleware looks after all of your enterprise mapping, it just looks after mapping to/from salesforce.

Salesforce have modularised it, and it is interchangeable - you don’t have to use mulesoft, but it’s another layer in their ecosystem. You want to manually integrate with web APIs? Sure, you have that option.

I don’t get the difference between what you are describing and what mulesoft is in this instance.