Yes, XRM Is The New Common Data Service

In November 2016 I wrote an article on LinkedIn with the title “No, Common Data Service is not the new XRM”. This was my response to the speculation that had emerged from Microsoft’s announcement of a new cloud-native platform to store, model and integrate business data with other (cloud) applications. This platform called CDS was seen as a potential replacement to XRM that had been born into the good ol’ on-premises server world already back in 2003. Given the transformative power of SaaS and PaaS, it wasn’t such an outlandish thought to imagine the days of XRM bits being numbered, with a new Azure based alternative being prepared behind the scenes to take over.

Well, today we had the public launch of the Dynamics 365 Spring Wave in the Microsoft Business Forward event, which I summarized in my previous blog post. The most significant piece of news from this announcement wasn’t perhaps articulated so clearly in official Microsoft materials, so I’ll try and clarify it here and give some perspective on the what/why/how behind this change.

XRM = CDS v2

The platform known as XRM, which has served as the foundation for Dynamics CRM and later Dynamics 365 Customer Engagement, is now reimagined as Common Data Service, CDS. Or more specifically, “CDS for Apps”, but more on that later. The key things to understand here are that A) nothing from the current XRM is being removed while B) existing CDS v1 environments are migrated onto CDS v2 that effectively is XRM.

The adoption of CDS as a component of solution architecture for live customer environments has likely not reached a very high level up until this point. Originally introduced as a concept back at the time when the whole Dynamics 365 concept was launched in 2016, the purpose of CDS has remained too fuzzy for many customers to explore it further. At the same time, the feature set offered by CDS v1 hasn’t yet covered many of the scenarios that Microsoft partners would have likely used it in. You could say that in their noble attempt to connect many of the existing boxes in the business application architecture, Microsoft ended up inventing yet another box. Which is pretty much the fear I had in my first blog post covering CDS, which back in those days was still called Common Data Model (CDM):

Being the giant corporation that Microsoft is, there’s bound to be both plenty of overlap between different products developed by different groups within the organization, as well as the occasional lack of alignment between the roadmaps to where each of their countless products is heading to. I’m sure there was a clear need for introducing a foundation for managing all that business data which the Power Suite tools (PowerApps, Flow, Power BI) had to intimately work with, instead of just relying on distant services via APIs. Viewed from this perspective, the idea of CDS must have seemed pretty awesome. When looking at the feedback coming from outside the MSFT firewall, though, it’s obvious that the V1 product didn’t quite manage to meet the mark:

This Ain’t The XRM of 2011 Anymore

A lot of work remained ahead if CDS was to be built into what the real world requirements from enterprise customers were. At the same time, the XRM cloud platform was being transitioned to run on Azure services and the new target architecture was to allow the separation of the built-in applications (Sales, Service etc.) from the core platform. The CRM “legacy” of XRM was about to become an optional component you could remove and not break things, with previously hard-coded features being re-engineered as either core platform capabilities or implemented as reusable pieces within the in-house apps’ solution packages, built with Custom Control Framework (CCF) and presented via the Unified Interface.

The people at Microsoft who actually design and build the functioning technical product were sure doing all they possibly could to prepare XRM to take a bigger role than just that boring old sales pipeline management engine with Outlook integration we’ve seen since forever. The community that had worked with Dynamics CRM and seen its potential to deliver custom business apps time & time again in actual customer projects were always asking for MS to deliver a “Pure XRM” SKU, to make it a true platform. Whether it would ever happen, though, was not for either of those groups to decide.

At the end, as we now can see with the announcement of PowerApps Spring Update, the leadership team at Microsoft ultimately came to the right conclusion. XRM was chosen as the platform that would power the further expansion of PowerApps becoming more enterprise ready with the support for building model-driven apps alongside the familiar canvas apps. From a licensing perspective, “PowerApps P2 officially becomes the new platform SKU, moving away from being a admin and maker focused plan to becoming THE plan for users of stand-alone model driven apps.” So, there we have it then: Pure XRM at last.

So Long, XRM!

A legitimate question that some of you might as at this point is:

“If the CDS v1 platform is replaced with XRM, then why is everyone talking about Common Data Service still?”

Are we seeing yet another marketing spin that tries to blur our vision from what the underlying technologies really are, like with the Dynamics 365 “it might be CRM or ERP and you’ll never figure out which one we’re  talking about” rebranding pains? Well, that was my initial though when I first learned about the plans for this platform merge, but I’ve later come to the conclusion that it is actually a fairly sensible decision to replace XRM with CDS.

For those of you who have been in the Dynamics game for long enough time to recall the first moments when Microsoft started throwing around the term XRM, you might still remember the excitement that was collectively felt around that letter “X” for describing the bold journey of going beyond the standard CRM feature set. The thrill of creating your very first custom entity via the customization GUI – man, what a rush! This truly felt like the future of business application development at the time.

Fast forward to where we are today and the excitement of data model and UI customization has been replaced by the anxiety to get as many different apps and services to talk with one another with as little effort as possible. It’s not that focused on the Relationship Management part anymore, and instead of “X” we have X^N different things we need to manage and connect with (some are even IoT enabled things). To describe what we’re actually trying to use XRM for today, the Common Data Service is a pretty fitting name in the end. We’re trying to bring some common sense into the sea of data that everyone is swimming in, and we’d of course prefer to consume it as a service like we already do with movies or transportation, for example. And as for the visible UI part of the application that user interact with – well, there just happens to be this concept called PowerApps out there already. So, “XRM Part 2” = CDS + PowerApps.

I think we’re at a point where we really should look at the road we’ve traveled with our trust ol’ XRM Swiss knife, appreciate all those countless times that we were able to find a tool from it that got the job done, but accept the fact that from this point onward we’re going to need a bigger knife. Which we might as well call CDS for the server side & PowerApps for the client side.

One More Thing…

Just so things wouldn’t be uncharacteristically clear for Microsoft’s product naming tradition, what we’re seeing here is actually a bit of a “SkyDrive moment”. By this I’m referring to the episode where after renaming SkyDrive to OneDrive due to a lawsuit from BSkyB, Microsoft then proceeded with launching another product called OneDrive for Business. So, “One Drive, many meanings”…

With CDS the scenario is that while the XRM platform has now been rebranded as Common Data Service for Apps, there’s already another product on the way, called Common Data Service for Analytics. Regardless of the word “common” in the name, these two platforms are unlikely to share many characteristics when it comes to the technology under the hood. Here’s how the MSFT Technical Fellow behind Power BI describes it:

Huge: Power BI Common Data Service For Analytics is a transformational technology that will light the industry on fire.

A self-service data lake with industry schemas, and pre-built apps.

It is to data warehousing what Excel was to programming. https://t.co/bfQb3Mmo2B

— Amir Netz (@AmirNetz) March 21, 2018

So, we’ll soon have two awesome products from Microsoft named according to the pattern “Common Data Service for X”, which we can easily distinguish from one another by using the terms CDS-A and CDS-… Oh. Right. Well, there’s always the next round of rebranding we can look forward to!