CDM: New Data Model For The Common Good?

The first new component of the upcoming Dynamics 365 platform that has reached a stage of public preview is the Microsoft Common Data Model (CDM). Available via PowerApps, CDM can be provisioned in your Office 365 tenant with only a few clicks, so there’s little reason for not having a look an early look at it. In fact, you only need to sit back and relax while watching CRM MVP Scott Durow walk you through a first look at the Common Data Model:

So, there you have it! That’s what CDM looks like when accessed via the PowerApps web management UI. Any questions?

Yeah, I actually do have a couple.

How will this work with CRM and AX?

What we have available in the preview is pretty much the most straightforward part of the very big puzzle to put together, meaning a database on Azure with some preconfigured tables and data model management tools. We do not yet know much about how the Dynamics CRM and Dynamics AX functionality will be linked to CDM as part of the Dynamics 365 cloud platform, so there’s plenty room for speculation, which honestly is mostly what I’m about to do here. In a way I’m just continuing on the theme of my previous post about Dynamics 365 and its potential implications for XRM, to pass the time as we wait for Microsoft’s plans to be revealed in more detail.

Right now the only way to push data into CDM is a Flow. If you’ve ever played with automation tools like IFTTT or Zapier, then you’ll quickly grasp the idea of Microsoft Flow. The application itself shouldn’t be underestimated just because of its current simplistic demo scenarios that usually are along the lines of “when a new row is added to a SharePoint list, send an email to this address”. Built on top of Azure Logic Apps, there’s actually a next generation BizTalk type of cloud integration platform under the hood, which should provide plenty of future potential for advanced messaging solutions to orchestrate business processes across a number of different systems.

Once Dynamics 365 Enterprise arrives and gives us the features of CRM and AX in one seamless cloud environment, there’s naturally going to be a need for something a lot more than a “build your own” type of Flow integration. Keeping the Sales and Operations apps of D365 in sync with the customer and transaction data managed in the process of making an delivering a sale involves a fair amount of business logic. If you’ve ever designed and developed a custom integration for this type of a scenario, you’ll know the requirements can quickly grow a bit hairy. Assuming Microsoft can come along and say “we’ll take care of that hairy part, don’t you worry about it” then who could resist it?

The reason CDM exists is that there will be more than one physical database in the Dynamics 365 suite. It’s not all XRM, which means you can’t find the Operations app entities inside your CRM solution files. For the business processes to work seamlessly, someone needs to keep those database closely in sync with one another. From reading through the Common Data Model tutorials, we can see that at least as of now, Flow is not the system that can handle it:

“Today, when you use Microsoft Flow to import data or export data, it is not a full synchronization service. Whenever an object is added to one service, it will be imported into the other system. However, that means if an object is deleted from one system it will not be deleted in the other system.”

So, the sync part is still in the “To Be Implemented” bucket. So is security, since the passing of a record from CRM to CDM via Flow will not carry over any details about who should have the rights to do some CRUD work on it. Again, it may not sound like such a mission impossible to build. However, if you’ve ever faced the requirement in a Dynamics CRM project to implement SharePoint document library integration with account records that includes not just linking the folders but also enforcing the account access rights on the documents, you’ll know the struggle is real. Sure, a collaboration solution like SharePoint has very different security concepts than a system designed for structured business records management like CRM or ERP. But if Microsoft hasn’t been able to offer OoB synchronization of access rights across Dynamics CRM and SharePoint despite of the clear business demand for it, maybe we’d be foolish to expect that it will all be seamless inside the Dynamics 365 world either.

The thing here is that unless the solution provided by Microsoft is going to be fairly advanced, it might not be an actual solution. It’s like the old saying from the dawn of the internet:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

When confronted with the need to integrate processes across two different cloud business applications, there’s always the danger of someone rushing into thinking “I know, I’ll build a database in the middle to unify the process data”. So we end up with three cloud business applications… Now, I’m not saying that Microsoft wouldn’t have the type of application architecture masterminds working on the Dynamics 365 platform that can solve these complex problems when developing a new product. I’m just afraid that things may still turn out a bit more complex in reality than the marketing pitch for the new product launch might lead people to believe.

What limitations will this impose on customization?

The one reason why many of us love the capabilities of the Dynamics XRM platform is the awesome flexibility it offers us to customize the application to meet the specific needs of customers. And by “customize” I actually mean “configure”, since these days you can build such amazing features for business users without writing a single line of Javascript or C#. With Dynamics 365 now promising to deliver so many preconfigured apps for different departments’ needs, as well as making them all work together, I bet some of us are thinking about whether there’s a potential threat to the platform’s flexibility buried in the new approach Microsoft is taking.

When designing a Dynamics CRM solution for a customer organization it’s pretty rare that there wouldn’t already be a number of other applications in place that also deal with the same customer information on at least some level. ERP is a good generic example of such a system to use when demonstrating the potential pitfalls in planning your integration strategy and why it can have such a big impact on the success of your CRM initiative. From my personal experience over the years, some of the worst Dynamics CRM systems I’ve seen (from the perspective of business value delivered to the end users) have been either:

• Not integrated at all with any operational business information systems
• Way too integrated with an ERP to leave any space for actual customer relationship management

Obviously if the CRM system is completely detached from the physical processes that deliver products/services to the customer or the financial transactions that deliver revenue to the company, it will become an island of its own that needs to be manually updated for every single business activity. In such cases it usually won’t take long before the system is no longer actively updated, which sharply decreases its potential value for managing business processes, which in turn makes it a future desert island.

The other extreme isn’t necessarily a pretty sight either. If the implementation of a new CRM system starts by replicating the exact customer data model of the ERP system and copying over tons of transactional data, this can severely limit the possibilities of delivering new functionality for the business in the areas where it is needed: understanding the customer relationships rather than the ship to/bill to addresses, managing the customer interactions instead of orders/invoices, and so on. Enforce enough external rules and limitations onto a new system and you’ll get a poor cousin of the original system.

It’s this latter option that somehow came to my mind when taking a first look at the contents of the Common Data Model. There’s a 87 page CDM Entity Reference document available for download, which takes you down to the very details of what entities and fields are provisioned into the CDM database by default. Now, having spent a bit over a decade working with the default data model of Dynamics CRM (oh dear lord, what have I done with my life?!?), I expected to see something that I could quickly map to the CRM database in my mind. Perhaps even a kind of V2 of the CRM data model that would address some of the challenges often encountered when attempting to represent the non-hierarchical real world with the relationships, parties and activities of Dynamics CRM.

Well, that’s not exactly what I saw in CDM. It looked all very ERP’ish, with the focus being on things like this supplier invoice ERD, as an example:

Fair enough, we are of course looking at a solution here that aims to bridge the gap between CRM and ERP, so this approach makes a lot of sense from a practical perspective. Still, I find it a little bit troubling that when I look at the contents of CDM, it feels like I’m being taken inside the database of AX. I can also imagine myself being in the role of an ISV coming from outside the Dynamics ecosystem and investigating the logic of how these applications work, so that I could plan how to integrate my own software with these Microsoft applications. Remember: this may well be how the future partners developing the new applications for Microsoft AppSource would approach Dynamics 365.

It’s still a preview of the real CDM to come, of course. It’s also a database that’s been designed to accommodate custom entities and fields, just like XRM is. Nevertheless, I wish I would see something there already at this point which I’d be excited about getting to use in future projects. Instead of a unifying “person” entity to represent the human beings that should be at the heart of any CRM, I just see a number of different entities for spreading the same person into many different database tables: “alumnus”, “employee”, “constituent”, “fan”, “contact”, “tenant”, “contractor”, “volunteer”, “donor”. Ok, great, so I can store the name, address and Twitter handle of a physical person into 11 different entities now. I don’t recall ever wishing for such a possibility to exist, but it’s what’s coming at us now when Dynamics 365 arrives.

What’s the big deal then? Why could’t we just roll our own data model like we’ve done with XRM since forever? Well, of course you could, but the question really is what will the customers want? The reality is that the stack off applications that organizations are deploying to support their information workers and enable fully automated business processes is growing taller every day. What this tends to mean is that there’s less resources available for designing and developing unique solutions to business problems – at least when they are not seen as a clear source of competitive advantage. The trend is moving towards settling for the standard application functionality with no custom code whenever possible, in part to reduce the risk of getting burned when new releases of the product are being rolled out that may not support the unique extensions you might have developed. This will most likely also be a direction we’ll see in the Dynamics 365 market, too.

I don’t predict that we will lose any technical capabilities for designing business app data models with the arrival of CDM. We’ll probably gain much better connectivity between apps from different vendors, but I also believe that some compromises will be needed in order to balance the benefits of platform extensibility and app compatibility. Digital transformation surely won’t make the business requirements more static in the future, but it will certainly make it more critical to plan ahead on how the underlying systems can support the ongoing transformation without causing the wrong type of disruption to the flow of information. Microsoft also recognizes this in the CDM Entity Reference document:

“Schema compatibility between CDM versions 0.1 and 1.0 is not guaranteed. The Common Data Model (version 1.0) will provide versioning as entities change over time. Multiple versions of an entity will be supported at the same time, however, entity versions may be deprecated and removed over time with adequate notice and upgrade guidance.”

Exactly. The only thing guaranteed over time is change. Let’s see if CDM will help us get along with it.