Hacker News Reader

Comment by zozbot234 | Hacker News Reader

Do we really need all the bespoke middleware stuff that OP goes on and on about, when practically all new, greenfield applications are based in some way or another on the Web and its open protocols? What middleware is still needed, other than the well-known semantic web and linked-data standards that have been developed specifically so that disparate applications from many vendors would be enabled to interoperate via a common Web platform, while allowing for user-directed extension and customization?

View on HN

The answer is 'yes, absolutely', particularly considering we are talking about Enterprise IT here.

Take for instance a common integration point for these applications - sending a sales order to a warehouse management system (WMS). Even if both systems have RESTful API's there is no fixed standard for a sales order, so you need to at least do some mapping. Then maybe actually you find out WMS needs a reference from the transport management system that has to be merged into it, and this also has to go back to ERP (which isn't part of the standard 'send order' integration). This is why middleware programs exist.

Enterprises often end up being bundles of random applications that all need to be informed about random stuff, and it's just not practical to expect the application vendors to know what applications need to be aware/informed of what.

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.

Reply on news.ycombinator.com