Salesforce Buys MuleSoft and Offers It as a Data Unification Solutions

4
274

Share on LinkedIn

The Customer Data Platform industry is doing very well, thank you, with new reports out recently from both Gartner  and Forrester  and the CDP Institute launching its European branch.  But the great question hovering over the industry has been why the giant marketing cloud vendors haven’t brought out their own products and what will happen when they do. Oracle sometimes acts as if their BlueKai Data Management Platform fills the CDP role, while Adobe has made clear they don’t intend to do more than create a shared ID that can link data stored in its separate marketing applications. Salesforce has generally claimed its Marketing Cloud product (formerly ExactTarget) is a CDP, a claim that anyone with experience using the Marketing Cloud finds laughable.

The flaws in all these approaches have been so obvious that the question among people who understand the issues has been why the companies haven’t addressed them: after all, the problems must be as obvious to their product strategists as everyone else and the attention gained by CDP makes the gaps in their product offerings even more glaring. My general conclusion has been that the effort needed to rework the existing components of their clouds is too great for the vendors to consider. Remember that the big cloud vendors built their suites by purchasing separate products.  The effort to rebuild those products would be massive and would discard technology those companies spent many billions of dollars to acquire. So rationalization of their existing architectures, along with some strategic obfuscation of their weaknesses, seems the lesser evil.

We got a slightly clearer answer to the question on Tuesday when Salesforce announced a $6.5 billion purchase of Mulesoft, a data integration vendor that provides connectors between separate systems. In essence, Salesforce has adopted the Adobe approach of not pulling all customer data into a single repository, but rather connecting data that sits in its system of origin. In Salesforce’s own words, “MuleSoft will power the new Salesforce Integration Cloud, which will enable all enterprises to surface any data—regardless of where it resides—to drive deep and intelligent customer experiences throughout a personalized 1:1 journey.”

This is a distinct contrast with the CDP approach, which is to load data from source systems into a separate, unified, persistent database. The separate database has some disadvantages – in particular, it can involve replicating a lot of data – but it also has major benefits. These include storing history that may be lost in source systems, using that history to build derived data elements such as trends and aggregates, and formatting the data in ways that optimized for quick access by marketing systems and other customer-focused applications.

Although the difference between these two approaches is clear, some practical compromises can narrow the distance between them. Most CDPs can access external data in place, reducing the amount of data to be moved and allowing the system to use current versions of highly volatile information such as weather, stock prices, or product inventories. Conversely, a system like Mulesoft can push data into a persistent database as easily as it can push it to any other destination, so it can build some version of a persistent database. In fact, many CDPs that started out as tag managers have taken this approach.

But pushing data into a persistent database isn’t enough. Mulesoft and similar products work with well-defined inputs and outputs, while CDPs often can accept and store data that hasn’t been mapped to a specific schema. Even more important, I’m unaware of any meaningful ability in Mulesoft to unify customer identities, even using relatively basic approaches such as identity stitching. It’s possible to build workarounds, such as calls to external identity management systems or custom-built matching processes. Again, these are solutions employed by some CDP vendors that also lack advanced identity management. But such solutions can be costly, complex, and incomplete. From a buyer’s perspective, they are compromises at best. No one – except a salesperson – would argue they’re the ideal approach.

In short, Salesforce’s purchase of Mulesoft offers a partial solution to the needs that have driven the growth of CDPs. It’s probably the best that Salesforce could do without making the impractical investment needed to rebuild its existing marketing cloud components.  Get ready for a lot more confusion about the best way to build unified customer data. To avoid getting distracted, focus on what marketers really need and let that, not theory or vendor hype, drive your evaluation of the alternatives.

Republished with author's permission from original post.

4 COMMENTS

  1. Hi David, while I agree to your points I sincerely believe that this is only part of Salesforce’s motive. Amongst other topics (chief of them the risk of getting cornered) Salesforce has a data problem The company simply doesn’t get enough to be able to compete on an AI level – a level that becomes more and more important (even with AI being mainly advanced analytics at this stage).

    Mulesoft offers a remedy here.

    As you did, I covered the acquistion: https://aheadcrm.blogspot.de/2018/03/salesforce-acquires-mulesoft-defensive.html

    My 2ct
    Thomas
    @twieberneit

  2. Hi Thomas. You post makes excellent points, including accessing data for AI, connecting Salesforce’s own systems, and supporting a ‘platform’ positioning. This also gives Salesforce something to discuss with core IT groups, which CRM and Marketing do not. And don’t forget simply being part of a fast-growing market, which boosts Salesforce’s own growth. So there were many good strategic reasons for the purchase, whether or not it gives Salesforce the equivalent of a CDP.

  3. MuleSoft and similar products have a fundamentally different approach from a CDP. MuleSoft and similar products require custom connectors for each source and target system, with explicit mapping of data elements. A CDP is designed to take any data from anywhere with little or no initial mapping. Conversely, MuleSoft and similar products can orchestrate process flows across multiple systems, which a CDP doesn’t do. Most obviously, a CDP is designed to persist data while MuleSoft does not store it internally. Almost as obvious, a CDP includes identity resolution capabilities while MuleSoft does not. So, although MuleSoft performs a somewhat similar function to CDP in that it facilitates data access, it would contribute very little to building a true CDP system.

ADD YOUR COMMENT

Please use comments to add value to the discussion. Maximum one link to an educational blog post or article. We will NOT PUBLISH brief comments like "good post," comments that mainly promote links, or comments with links to companies, products, or services.

Please enter your comment!
Please enter your name here