Adobe, Microsoft and SAP Open Data Initiative’s Common Data Model (CDM) attempts to capture real world business concepts and their relations into a single unifying data model, which could be shared across multiple business applications. In theory, benefits should include easier integrations and data use between apps, even over organization and ecosystem boundaries.
Open Data Initiative
Adobe, Microsoft and SAP announced the Open Data Initiative on 2018 Microsoft Ignite event. The announcement contained lots of buzzwords, but the key ideas were to a) get rid of data silos and b) to have one common idea of basic business concepts (like customer) and their relations to each other. This would help bring together all your line of businesses and get better insights on both your customer and what’s happening in your organization. The common model would unify the data across your silos, applications, organizations and even ecosystems.
The search for common business data model is not of course unique on the field. All the major players – IBM, Oracle, Adobe, SAP, Microsoft, SalesForce – have long developed their proprietary data models and packaged them as business applications to their customers. The thing is, that first time now few key players are trying to harmonize their ideas into one unifying model which could in theory make life a bit easier for application development.
Common Data Model (CDM)
The CDM defines a set of business entities, their fields and object relations that appear on every major organization type. Entities and their relations may be like the following:
- Account (a company that your company does business with)
- Contact (your contact point in the customer organization)
- Activity (for example – seller sends an email, fax or letter to customer contact)
- Owner (the user or team who “owns” the Account, Task or any other entity)
- Task (something to do)
- SalesOrder and OrderProduct (= single order line for a product in SalesOrder)
- Product, ProductLiterature
- CDM contains roughly ~700 entities, major entities having +-100 fields.
The CDM entities cover the typical functions in organizations like customer relations management, sales, service(desk), supply chain management, human resources, marketing and such. The picture below shows the how entities are organized by line of business. Core objects like Account and Contact are common to all functions, while Service entities covers the entities needed to implement a service desk system.
CDM GitHub repo & model viewer
The current version of the model is published as a github repository, which contains clonable directory of the model as json definitions of the entities and their fields & relations. The model is licensed with Creative Commons Attribution 4.0 International Public License (referenced 14.4.2020).
Microsoft has also implemented a CDM model browser for easier viewing of the content.
What CDM is and isn’t
CDM doesn’t dictate, that you need to store the data on single location or database (even if it would makes certain aspects a bit easier). It only defines the schema in which the data is stored. If you wanted to build your own implementation of the model using traditional relational SQL database, the model would state which tables you have, their columns and foreign key relations between the tables.
CDM doesn’t give you the actual data store, user interface forms, dashboards or processes to follow, nor the actual machine-to-machine integrations or APIs to process the data. This is where each vendor applications step in. For example; Microsoft Dynamics 365 apps, Power Apps, Power BI provide you the user interfaces, tools and mechanisms for you to use your data stored in this common format. You can read more on how in the Common Data Model Microsoft documentation.
Benefits of the model
Unified data model aims to ease the challenges with multiple format and potentially multiple location siloed data. Imagine three separate (siloed) business apps – marketing, manufacturing and sales apps for example. Each have an entity called “Account”, but all of them have slightly different fields because they have been built by separate parties. IF you used common data model, you have built your system using common Account entity, and each of the three apps could use the same data. Each app could of course extend the basic entity if required. If you are smart, you could even use the same storage solution, analytics, user interfaces and APIs.
CDM should reduce the need for complex many-to-many integrations with data format conversions, and out-of-date data for applications. The complete view in common format would certainly enable better analytical view of customers, processes, products and sales pipelines in organizations. Having data on stored on an unified schema would build ground for standardized set of tools and processes (even AI), instead of need to rely on single ecosystem tools and methods.
As an afterthought
Ok, you now have captured your business entities and their relations in a good, common data model that you can use as base for all your applications. What if I told you that you can use that model to create a fully working application that implements the model you have created? Magic? Read on: