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:
No other storage platform allows security to managed at role, entity, row and column level without having a PhD in the technology
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
Dynamics 365 is already built on CDS
Project for the Web is built on CDS
Microsoft Flow approvals are built on CDS
It is easy to use Data Flows to synchronise data into CDS
It is easy to export data from CDS to Azure Data Lake
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.