Now that Microsoft has launched the Power Platform with Common Data Service (CDS) at its core, it’s time to evolve how we build line of business applications.

There has been a lot of confusion in recent times about which platform is best to build an application on – either on the Microsoft Power Platform or Dynamics 365. I raised a few eyebrows at eXtreme Conference in Amsterdam earlier this year when I said Dynamics 365 is Dead. The message I wanted to land for all those people out there that have been building applications on Dynamics 365 for the past 16 years is that it is time to STOP.

Don’t build on Dynamics 365 for Sales, Service, or Marketing, if you intend to butcher those apps beyond recognition. There is a workaround if you want to use the data models of those apps in case you want your apps to stay interoperable with them, but you don’t need to take a dependency on them from the get-go.

If you have traditionally built solutions on Dynamics 365, it’s time to change your thinking. Start building on the Power Platform with the same level of functionality and sophistication. To build on the Power Platform you need to start with your data model.

To architect the data model for a line for business application, you need to start with an understanding of what you want to build, or what business problem you want to solve. Ultimately you will design the user experiences, automation, integrations, and reporting.  But let’s start with the data and ask the following questions:

1. What data is needed?

2. Where is the data currently located?

3. How will data enter the application once it is build?

   •  User Interface?

   • Imported?

   • Via automation procedures?

4. Is there a relationship between the datasets?

5. Is there a hierarchy between the datasets?

6. Can the datasets be grouped?

7. What Metadata requirements exist?

As we gather this information, we can start modeling real-world entities and visually building out the model of these entities. We could also refer to this as a Database Schema (think of the word schematic or blueprint of how the relational database will work together). A visual representation of this information can also be referred to as an Entity-Relationship Diagram (ERD).  As we build out these entities, we need to understand the relationship between them. For example, we may have an entity called Hospital and an entity called Patient; we may want to show the relationship between the Patient and the Hospital that they are currently in. As you continue to design out the data model, you can also define what specific fields each entity will include.

Be careful not to design more of the data model than what is needed to create the application and solve the business problem.

At this point, you need to check if Microsoft already has a Common Data Model built that could meet your needs. As you can see, in this image, Microsoft has defined a range of Common Data Models that you can use. As the Common Data Models from Microsoft can be extended, you may find that you can use one of the existing Common Data Models as a starting point for your line of business application.

The Common Data Model (CDM) is the shared data language used by business and analytics applications to provide semantic consistency and facilitate interoperability. It is an open-sourced metadata system that includes standard entities representing commonly used concepts and activities across a variety of business and application domains. CDM provides unified data and semantics over areas including sales, service, healthcare, higher education, and more, and can be easily customized. CDM is bringing the same semantic consistency to Azure Data Lake Storage Gen2 with CDM folders, allowing organizations to leverage Artificial Intelligence and Machine Learning at a scale not previously possible.

Finally, before you jump into designing your line of business application, you should check if Microsoft has created a Common Data Model specific to your industry. So far, Microsoft has defined Industry Accelerators for the following industries, that you can use as a starting point for your application:

1. Banking

2. Healthcare

3. Education

4. Non-profit

5. Automotive

6. Media

In summary, consider the following order of modeling your application from a data perspective,

• Step 1: Design your Data Model.

• Step 2: Review Microsoft’s Common Data models to see if you can use them as a starting point. (Note: there may be licensing implications if you want to use a CDM from one of the Dynamics 365 applications for your app)

• Step 3: Check if Microsoft has created an industry accelerator than you can use.

On completion of these steps, you will be able to move forward with your design and decide what automation, integration, reporting, and experiences you will want to create.

Here are my previous blog posts about Common Data Services.

The Truth about Building PowerApps on the Power Platform – CDS vs SharePoint.

Common Data Service for Apps and Future Investments on the Platform with Ryan Jones.

If there are elements you want me to address in more detail, let me know in the comments below.