Salesforce buying MuleSoft hints at a seismic shift in enterprise integration

Last week's revelation that cloud applications giant Salesforce is spending $6.5 billion to buy API integration platform MuleSoft in its biggest-ever acquisition was unexpected. As someone who has pretty much always thought of integration as a form of mediation between loosely-coupled component services*, I've always seen it as a platform-neutral activity. But once I'd got past my initial surprise, I began to realize that this transaction merely reflects a seismic shift that's already rippling through the enterprise integration landscape.

There are some other factors in play which I'll come to in a moment, but the root cause of this tectonic rearrangement is the shift from old-school point-to-point integration to an API-centric architecture. This is MuleSoft's forte, as I've discussed in numerous conversations over the years with company founder Ross Mason. We last met in January, when Mason spoke about the notion of 'APIfying' enterprise infrastructure. MuleSoft provides tools and a framework that allows enterprises to build APIs at three layers.

System-level APIs expose IT resources such as data stores and core systems — there's an instructive Unilever case study where moving to MuleSoft meant the IT team could decommission 95% of its pre-existing middleware tools. Process-level APIs expose application functions in the second of these three tiers. Finally, experience-level APIs are the domain of user interactions.

Three-tier API model

Adopting this three-tier API model allows an IT team to gradually package up resources, functions and interactions as self-service components that the business can harness as needed. Flexible composability is the goal, says Mason:

[E]verything should be an API, and what we’re really doing is stitching APIs together to perform different activities.

This composability — the ability to compose and recompose something based on any kind of new input or new application that sits on top — should be like the Holy Grail for many enterprises.

By buying MuleSoft, Salesforce not only acquires 1,200 customers who are already APIfying their infrastructure — and therefore will find it easier to compose Salesforce resources into that infrastructure — but more importantly, it acquires a toolset that will help its own customers who may currently be struggling with this APIfication challenge. MuleSoft focuses on offering CIOs what is effectively a means of replacing EAI with an API-centric architecture, which for most established enterprises is not a bad idea as they try to work out how to move towards a more flexible, cloud-centered IT landscape.

Workflow automation layer

But there's another dimension that's much more significant not just for Salesforce and its customers but for any enterprise looking to harness modern connected digital technology. This is the emergence of a new integration trend at the workflow automation layer — actually, I prefer to call it connection rather than integration, because it's more fluid than the fixed integrations of old. Once there's an API-centric infrastructure in place, connection moves up into the experience layer, where it joins up workflow to deliver results. It's a more flexible reinvention of what used to be called business process management (BPM), as I recently explained:

What I find intriguing here is the rebirth of what used to be called BPM — business process management — as enterprises discover new ways to stitch together and automate complex end-to-end business processes. This isn’t your father’s BPM though. Built on top of a flexible, API-driven cloud platform, and enriched by artifical intelligence, it’s a completely new way of automating business operations.

Many of the emerging workflow automation tools that work with a modern API infrastructure use a low-code model that means you don't have to be a technology expert to compose a new automated process. Interestingly, MuleSoft was not getting into this field as avidly as its rival Dell Boomi, which has more of a longstanding partner relationship with Salesforce. Boomi recently introduced a low-code workflow automation tool based on an acquisition it made last year. Another vendor that's making interesting strides in this space is Workato, which surfaces workflow automation in the conversational layer in Slack and similar applications, part of an emerging trend towards headless applications. Perhaps Salesforce plans to elaborate its Quip collaborative platform as a workflow automation tool on top of the MuleSoft API infrastructure.

Salesforce is catching up

So let's say that nowadays the innovation in integration and connection is moving into workflow automation at the experience layer, and the prerequisite for making that work is a robust and flexible API infrastructure of the type that MuleSoft enables. You can start to see that the functionality MuleSoft offers becomes something you want built into one of your core application stacks. Your priority in enterprise IT is joining up your systems of record so that you can expose their data and functions in a robust API infrastructure that your workflow automation layer can then consume.

Having come to the conclusion that enterprise stacks need to include the ability to build and manage an API infrastructure, what's interesting is when you realize that Salesforce is a laggard in catching on to this rather than a trailblazer. Workday, as I mentioned in another post earlier, acquired integration capabilities a decade ago when it bought Cape Clear. Oracle acquired middleware leader BEA Systems the same year. Infor has its Ion middleware. Salesforce will want to argue it will leapfrog some of these rivals once it has brought MuleSoft onboard — there may be some merit in that point of view.

My take

Overall then, I think this unexpected acquisition does make strategic sense both for Salesforce and for enterprise technology buyers because of three interconnected shifts in the integration market:

• The focus of the integration/connection market is shifting up-stack.
• Integration at the systems/EAI layer doesn't have to be vendor neutral any more.
• Vendors that don't include that lower-level integration capability in their stack are left at a disadvantage.

I think this shift also has repercussions for how we think about traditional enterprise application stacks, but I'm going to save those thoughts for another day.

* As I posted to my Loosely Coupled blog in August 2005, "it's only by having a distributed web (or mesh, or fabric) of intermediaries that you get the kind of redundancy and scalability that's required to operate an enterprise infrastructure of multiple autonomous service consumers and providers."