Why use the Common Data Service?
Last week I was asked rather late in the day (over dinner the night before actually) to contribute to the introduction to a hackathon at the Scottish Summit on the subject of de-mystifying the Common Data Service.
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, Lucy Bourne (@LucyAliceBourne), Chis Huntingford (@TattooedCRMGuy), Lee Baker (@LeeMBaker) and Nick Doelman (@ReadyXRM) 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 did also do was multiply the number of teams of developers that were needed 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: