INTEGRATION Quick Tips TechTalk

SAP CPI vs. MuleSoft vs. Boomi vs. ….. revisited

Comparisons are dished out to us every day, everywhere. We hardly make a buy without comparing. Comparisons like Android vs iPhone, Xbox vs PS, Pepsi vs Coke are perpetual sources of debate. Just yesterday, I spent nearly three hours deciding on the right Bluetooth 5, IPX7 complaint, USB-C, noise cancelling in-ear earphones. Courtesy choices and hence comparison on Amazon!

So, it’s uncommon not to compare SAP Cloud Platform Integration (CPI from now on) with a myriad of other middlewares out there. It’s 2020 and the debate is back again.

  • Is CPI better than MuleSoft or Vice Versa?
  • Is CPI better than Boomi or Vice Versa?
  • Is Boomi better than MuleSoft? Or is Informatica better than all of them?

The „Best-of-breed“ Enterprise

While this could be a matter of debate for consultants and technology aficionados, enterprises and by that extension CIOs hardly have the luxury to make this choice. This is especially so with large enterprise customers or for that matter any enterprise that has experienced inorganic growth. Their landscape isn’t a homogeneous hue of blue or orange or red or what so ever. It’s more like a rainbow. Different systems, cloud, on-premise alike, from different vendors all coming in unison to deliver the best possible value for their business – this is usually the case.

For them, the middleware that comes along with a product like CPI with SAP, MuleSoft with Salesforce is often an extension of the product itself. ERP data – I get it from CPI, Sales Data from Mule and so on. This data is then consolidated and delivered to other systems via an ESB(could be MuleSoft as well), a message queue or similar contrivance.

A bespoke architecture for a LE client that INTEGRTR was involved in – CPI is not the only middleware at play

A bespoke architecture for an LE client that INTEGRTR was involved in.
A bespoke architecture for an LE client that INTEGRTR was involved in.

Process v/s Data Integration

Process v/s data integration plays a big role as well. If a middleware plays an active role in process integration, e.g. SuccessFactors to S4HANA/HCM, where the hire to pay process is literally facilitated by CPI, it makes no sense to just knock it off simply because there’s Mulesoft or Talend plying elsewhere in the landscape. At the same time, if you’re taking your SuccessFactors Employee Data into a cloud BW like Amazon Redshift (typical of data integration), it makes little sense to do it over CPI. The question here is not whether CPI can be used to connect SF to redshift – I’m sure you can. Should you do that in your specific context where there is a pre-eminent, well defined, centrally governed data delivery mechanism to Redshift albeit running on say Talend or Matillion? That’s the real question – the answer is a no. 

Skill sets of IT teams

A large part of decision making also has got to do with skills of the IT teams at an enterprise. Let’s say, a company has largely been a Mule client and a new middleware comes up – e.g. SAP CPI along with SuccessFactors – long term maintenance, upgrades, security flows and monitoring (often done via preset APMs) would be concerns. In such cases, it’s often prudent to recreate content packages that come with the said new middleware on the pre-eminent middleware. Last year, we did exactly the same at a „Mule heavy“ client. Instead of using CPI to connect Employee Central to SAP HCM, we built a Mule flow.

No alt text provided for this image

With this, did I just contradict what I had established in the previous point? Yes. That’s what I’m getting at – these decisions are contextual.

Point to Point Integrations

Finally, built-in connectors/content. New age apps come with their own built-in connectors relevant data directly from the source. This is possible because of the secure API level interoperability. An identity solution that a customer chose nearly eliminated the very need for integration over CPI or other wise, because it read data directly from SuccessFactors. SF with its open, public OData APIs allowed this possibility. But, this is hardly possible if the HR system was an on-premise one deep within layers of firewalls. See there I just started another comparison, the cloud vs on-premise debate. Didn’t I?

To conclude

The choice of middleware in an enterprise is purely contextual and largely value driven. Eventually, the debate always steers towards the value that a middleware brings on to the table. Going on a limb here – that value is primarily delivered by content and out of the box connectivity; everything else, including technical maturity of a middleware and therefore its developer friendliness, takes the second row.

As integration consultants, versatility is the key. You can be a Mule consultant; should that stop you from being a CPI Consultant or a Boomi consultant? I will leave that to you.