Why use the Common Data Service?

Why use the Common Data Service?

  • 05 March,2020

Last week I was asked to contribute to the introduction of a hackathon on the subject of de-mystifying the Common Data Service (CDS). As a subject, it is a fantastic area to talk about, but it is also critically important that it is understood.   

I had the honour of participating with the other hosts, all of whom have a wealth of knowledge and experience in this space, but, all of whom have primarily approached CDS from the Dynamics direction.  My contribution was my experience of coming from a SQL and SharePoint direction. 

From a SQL perspective, the process of developing a solution was based on multiple tiers of storage, business logic and presentation.  This separation in layers made a lot of sense with regards to decoupling dependencies, which is why it was used.  What it also did was multiply the number of teams of developers that were required, as to develop an enterprise level line of business solution we have needed: 

DBAs to design the relational data structure and the data security

Developers to build the business logic to interact with the database and enforce the business logic 

Front-end developer to develop a web interface 

Mobile developers to develop a native app for each mobile OS 

BI Developers to integrate data into a Data Warehouse 

Report Developers to build the reports to present the data 

From a SharePoint perspective, the battle cry has always been “SharePoint is NOT a relational database” and therefore why would you use it as one?  On the other hand, it is a great tool for storing and managing unstructured content such as documents, news articles and content pages.  SharePoint has also had tools such as Workflow and InfoPath, both of which have enabled line of business applications to be built on SharePoint, but with limited application lifecycle management.  Those people who used to build SharePoint applications share some unique skills that were not needed for any other platform, and they can tell some truly scary stories about how they overcame technical challenges. 

If you come from the Dynamics space then there are certainly the same stories to tell about complex solutions but there have been less moving parts to make up a genuine line of business solutions because that is what Dynamics has always been designed to be. 

So how does CDS fit into this story? 

CDS is what the Dynamics folks have had as a secure, robust platform to build enterprise scale applications on, and what the SharePoint folks have always hoped SharePoint could be! 

It provides so many capabilities that make it the logical go to platform for any future line of business application that to justify not using should require a business case.  Some of the key features in my view are as follows: 

Security 

No other storage platform allows security to managed at role, entity, row and column level without having a PhD in the technology 

Data Access 

CDS is core to Microsoft’s Power Platform so it is the foundation for Model-Driven Power Apps and Power Apps Portals 

CDS has APIs to allow access 

There is a connector for Power BI 

Power Automate has connectors 

Strategically important 

Dynamics 365 is already built on CDS 

Project for the Web is built on CDS 

Microsoft Flow approvals are built on CDS 

Import/Export 

It is easy to use Data Flows to synchronise data into CDS 

It is easy to export data from CDS to Azure Data Lake 

Business logic 

The CDS is where business logic can be configured 

In summary, CDS combines so many of the essential capabilities of an enterprise line of business application into one service, and enables so many other tools to be used to build presentation, integration and reporting capabilities with ease that it would be truly remarkable not to choose to use it. 

Resources:

Introduction to CDS

Learn about CDS