Send in the Clouds: Martech Moves to Cloud Platforms

Last weekend brought the intriguing rumor that Salesforce is in late stage talks to acquire data integration vendor Informatica.   This followed the previous week’s rumor that Google-parent Alphabet is consideringan offer for Salesforce-competitor HubSpot, and came the same week as a slew of partnership announcements tied to Snowflake’s Marketing Data Cloud Forum.

You don’t need a crazy wall to see how these events are connected.  Cloud database vendors including Google and Snowflake are expanding into marketing applications.  This poses an obvious threat to customer cloud vendors like Salesforce, in good part because it expands the ability of IT and data teams to build their own solutions rather than buying them.  Viewed in this light, Informatica helps Salesforce to compete by strengthening its ties with IT and data teams.  Of course, this is the same benefit that Salesforce sought with its Tableau, Slack and Mulesoft acquisitions, although you could argue those were all primarily tools for business users while Informatica is used primarily within IT and data teams.

A stronger strategic argument is that an Informatica that is properly integrated with Salesforce Data Cloud would help those teams build more powerful databases within Salesforce.  This would make Data Cloud a more viable alternative to Google Cloud or Snowflake as the company’s primary customer data store.  In Salesforce’s wildest dreams, Data Cloud might even replace data warehouses.

Let’s put aside the question of whether Salesforce could or should become an enterprise data warehouse supplier.  The immediate question is whether it can retain its position as a primary platform for customer data and customer-facing applications, or that role will be taken over by cloud platform vendors like Google Cloud, Amazon Web Services, and Microsoft Azure and cloud database specialists like Snowflake and Databricks. 

I don’t know the answer.  But what does seem clear is that customer systems will run on platforms, whether from Google, Salesforce, Snowflake, or someone else.   

The platform approach isn’t particularly new but it’s not the way things have always been.  Remember that most customer systems – even today – are stand-alone, self-contained products that maintain their own databases.  These are the dreaded silos we keep hearing about.  The trick is to connect these silos, initially at the data level by copying their data into a central warehouse or Customer Data Platform, and ultimately at the decision and delivery levels through shared journey orchestration and messaging. 

Platforms solve the data problem, since all systems run on a common data store.  They don’t necessarily unify the decision and delivery layers, since those functions are handled by applications built on the platform.  Those boundaries are not clear: platform vendors sometimes add decision and delivery functions.  Indeed, the risk that the platform vendor will incorporate your application is one that application developers must accept as the price for accessing the platform vendor’s customers.  Data clean rooms are a good example: once independent applications, they are now offered as core platform services.  Machine learning and artificial intelligence are following the same path.

The transition from silos to platforms is far from complete, but the industry direction is clear.  The entry of cloud and cloud data platforms as alternatives to customer clouds is likely to accelerate the change.  As we’ve already seen, platforms are a mixed blessing for application developers: they gain access to a larger audience but risk of being undercut by a platform product extension.  (The good news is those extensions often involve acquiring a leading application.)  

Application vendors also benefit from the platform providing data management functions that the application vendor would otherwise have to build for themselves.  This simplifies application development, freeing resources to improve the primary application functions.  Unfortunately, it also makes it easier for other companies to build competing applications.  This lower barrier to entry (and to continued survival) is one reason the number of marketing applications has increased so sharply in the past decade. 

The only way for application developers to escape this "app trap" is to themselves become platforms.  Many aspire to this and some, including HubSpot, have had some success moving down that path.  But most are too small to support a robust app marketplace and certification program or to attract a critical mass of application vendors.  

And what does all this mean for marketers and other business users?  Since the platform model isn’t new, we can already draw on experience.  It’s a mixed bag: buyers have a greater choice of applications for any particular task, which is mostly good but does create a burden of having to choose.  Buyers are tightly bound to whichever platform they select, since switching platforms means switching the related applications as well.  This creates a quasi-monopoly situation, with the potential for higher prices and poorer service that comes with it.  Raise your hand if you’ve seen that already.  This will only become worse as platforms become more common, making it harder for independent application vendors to survive and, thus, harder for companies to assemble their own ‘best of breed’ architecture from separate point solutions.  In other words, you may miss those silos when they’re gone.

It doesn’t have to be this way.  The alternative to a platform architecture is a true composable architecture, where different applications are written to common standards that are not controlled by any particular platform.  The ecommerce world has managed this to some extent, with ‘headless’ solutions and standards enforced by the MACH alliance.  Standard data access languages like SQL are another example.  That the customer data world will come up with similar standards seems doubtful, although there’s always hope.   

It’s also possible that integration platforms will let different systems interoperate even without shared standards.  That’s certainly their goal but so far results are limited by the effort to accurately capture all the nuances of one system and present them to another without losing anything in translation. AI might well change things by making this translation easier.  But AI might change a lot of things, so let’s not count on any of them quite yet.

For the immediate future, then, we can expect a handful of platform vendors to control customer data at a growing number of companies.  Those companies will be captives of the platforms, but it will be a fairly enjoyable captivity, with many pleasing applications to choose from and few obstacles to working as they please.  Every so often they’ll pull back a curtain and see the bars on the windows. Some will be so unhappy that they'll escape.  But most will accept the limits of their chosen platform and get on with their work.

 

 

Salesforce Customer 360 Solution to Share Data Without a Shared Database

Salesforce has sipped the Kool-Aid: it led off the Dreamforce conference today with news of Customer 360, which aims to “help companies move beyond an app- or department-specific view of each customer by making it easier to create a single, holistic customer profile to inform every interaction”.

But they didn’t drink the whole glass. Customer 360 isn't assembling a persistent, unified customer database as described in the Customer Data Platform Institute's CDP definition.  Instead, they are building connections to data that remains its original systems – and proud of it. As Senior Vice President of Product Management Patrick Stokes says in a supporting blog post, “People talk about a ‘single’ view of the customer, which implies all of this data is stored somewhere centrally, but that's not our philosophy. We believe strongly that a graph of data about your customer combined with a standard way for each of your applications to access that data, without dumping all the data into the same repository, is the right technical approach.”

Salesforce gets lots of points for clarity.  Other things they make clear include:

• Customer 360 is in a closed pilot release today with general availability in 2019. (Okay, saying when in 2019 might be helpful, but we’ll take it.)

• Customer 360 currently unifies Salesforce’s B2C products, including Marketing, Customer Service, and Commerce. (Elsewhere, Salesforce does make the apparently conflicting assertions that “For customers of Salesforce B2B products, all information is in one place, in a single data model for marketing, sales, B2B commerce and service” and “Many Salesforce implementations on the B2B side, especially those with multi-org deployments, could be improved with Customer 360.” Still, the immediate point is clear.)

• Customer 360 will include an identity resolution layer to apply a common customer ID to data in the different Salesforce systems.  (We need details but presumably those will be forthcoming.)

• Customer 360 is only about combining data within Salesforce products, but can be extended to include API connections with other systems through Salesforce Mulesoft.  (Again, we need details.)

• Customer 360 is designed to let Salesforce admins set up connections between the related systems: it's not an IT tool (no coding is needed) and it's not for end-users (only some prebuilt packages with particular data mappings are available).

So we have a pretty good idea of what Salesforce is doing. The question is, are they doing the right thing?

I say they’re not. The premise of the Customer Data Platform approach is that customer data needs to be extracted into a shared central database. The fundamental reason is that having the data in one place makes it easier to access because you’re not querying multiple source systems and potentially doing additional real-time processing when data is needed. A central database can do all this work in advance, enabling faster and more consistent response, and place the data in structures that are most appropriate for particular business needs.  Indeed, a CDP can maintain the same data in different structures to support different purposes. It also can retain data that might be lost in operational systems, which frequently overwrite information such as customer status or location. This information can be important to understand trends, behavior patterns, or past context needed to build effective predictions. On a simpler level, a persistent database can accept batch file inputs from source systems that don’t allow an API connection or – and this is very common – from systems whose managers won’t allow direct API connections for fear of performance issues.

Obviously these arguments are familiar to the people at Salesforce, so you have to ask why they chose to ignore them – or, perhaps better stated, what arguments they felt outweighed them. I have no inside information but suspect the fundamental reason Salesforce has chosen not to support a separate CDP-style repository is the data movement required to support that would be very expensive given the designs of their current products, creating performance issues and costs their clients wouldn't accept.  It’s also worth noting that the examples Salesforce gives for using customer data mostly relate to real-time interactions such as phone agents looking up a customer record.  In those situations, access to current data is essential: providing it through real-time replication would be extremely costly while reading it directly from source systems is quite simple.  So if Salesforce feels real-time interactions are the primary use case for central customer data, it makes sense to take their approach and sacrifice the historical perspective and improved analytics that a separate database can provide.

It’s interesting to contrast Salesforce’s approach with yesterday’s Open Source Initiatve announcement from Adobe, Microsoft and SAP.  That group has taken exactly the opposite tack, developing a plan to extract data from source systems and load it into an Azure database. This is a relatively new approach for Adobe, which until recently argued – as Salesforce still does – that creating a common ID and accessing data in place was enough. That they tried and abandoned this method suggests that they found it won’t meet customer needs.  It could even be cited as evidence that Salesforce will eventually reach the same conclusion. But it’s also worth noting that Adobe’s announcement focused primarily on analytical uses of the unified customer data and their strongest marketing product is Web analytics. Conversely, Salesforce’s heritage is customer interactions in CRM and email. So it may be that each vendor has chosen the approach which best supports its core products.

(An intriguing alternative explanation, offered by TechCrunch, is that Adobe, Microsoft and SAP have created a repository specifically to make it easier for clients to extract their data from Salesforce. I’m not sure I buy this but the same logic would explain why Salesforce has chosen an approach that keeps the core data locked safely within existing Salesforce systems.)

I’ll state the obvious by pointing out that companies need both analytics and interactions. We already know that many CDPs can access data in place, most commonly applied to information such as location or weather which changes constantly and is only relevant when an interaction occurs. So a hybrid approach is already common (though not universal) in the CDP world. Salesforce does say
that “Customer 360 creates and stores a customer profile”, so some persistence is already built into the product. We don’t know how much data is kept in that profile and it might only be the identifiers needed for cross-system identity resolution. (That’s what Adobe stored persistently before it changed its approach.)  You could view this as the seed of a hybrid solution already planted within Customer 360.  But while it can probably be extended to some degree, it’s not the equivalent a CDP that is designed to store most data centrally.

My guess is that Salesforce will eventually decide, as Adobe has already, that a large central repository is necessary. Customer 360 builds connections that are needed to support such a repository, so it can be viewed as a step in that direction, whether or not that's the intent.  Since a complete solution needs both central storage and direct access, we can view the challenge as finding the right balance between the two storage models, not picking one or the other exclusively. Finding a balance isn't as much fun as a having religious war over which is absolutely correct but it's ultimately the best solutions for marketers and other users.

And what does all this mean for the independent CDP market? Like Adobe yesterday, Salesforce is describing a product in its early stages – although the Salesforce approach is technically less challenging and closer to delivery. It will appeal primarily to companies that use the three Salesforce B2C systems, which I think is relatively small subset of the business world. Exactly how non-Salesforce systems are integrated through Mulesoft isn’t yet clear: in particular, I wonder how much identity resolution will be possible.

But I still feel the access-in-place approach solves only a part of the problem addressed by CDPs and  not the most important part at that. We know from research and observation that the most common CDP use cases are analytics, not interactions: although coordinated omnichannel customer experience is everyone's ultimate goal, initial CDP projects usually focus on understanding customers and analyzing their behaviors over time. In particular, artificial intelligence relies heavily on comprehensive customer data sets that need to be assembled in a persistent data store outside of the source systems. Given the central role that AI is expected to play in the future, it’s hard to imagine marketers enthusiastically embracing a Salesforce solution that they recognize won't assemble AI training sets.  They’re more likely to invest in one solution that meets both analytical (including AI) and interaction needs. For the moment, that puts them firmly back into CDP territory (including Datorama, which Salesforce bought in August).

The big question is how long this moment lasts. Salesforce and Adobe/Microsoft/SAP will all get lots of feedback from customers once they deploy their solutions. We can expect them to be fast learners and pragmatic enough to extend their architectures in whatever ways are needed to meet customer requirements. The threat of those vendors deploying truly competitive products has always hung over the CDP industry and is now more menacing than ever.  There may even be some damage before those vendors deploy effective solutions, if they scare off investors and confuse buyers or just cause buyers to defer their decisions.  CDP vendors and industry analysts, who are already struggling to help buyers understand the nuances of CDP features, will have an even harder job to explain the strengths and weaknesses of these new alternatives. But the biggest job belongs to the buyers themselves: they're the ones who will most suffer if they pick products that don't truly meet their needs.