Power Platform | A good data strategy without isolation

Maybe due to the nature of Power Platform, maybe due to easy to use connectors, such as SharePoint, SQL & Co., the moment app makers think about their application use case, they are asked to become a good data strategist.

In many customer workshops (think App-in-a-Day), app makers are overwhelmed by the various responsibilities that they weren´t thinking of, when considering building an app. To allow an easier entry level and lower the barrier, let me share with you some of the key principles, I start teaching about. First data requirements, meaning:

• Do you need structured or unstructured data, or better a combination of these two?
• Would you be able to achieve your goal with internal data only, or do you need to supplement your company data with external data (for example supplier information, weather data, etc.)?
• What about quick access to the data you need?
  • If not, what data collection method will you use?

While starting with the Power Platform and in special with Power Apps following KISS, the more use-cases and apps you´re designing and building, the more you will came across above.

Once you´re into data requirements your next bus stop is around data governance. Your key considerations should include:

• Who will be or is responsible for ensuring the data is accurate, complete and up-to-date?
• How to ensure data is stored securely?
• Accessing someone else´s data, could you lose access to it? What about a plan-B in this case?
• How to ensure an ethical use of data?
• What permissions would you need to gather and use data?
• How to minimize data where possible and meet compliancy with GDPR?

Following these two key principles in your app ideation, design and creation process, you would think about: Does low-code / no-code or in particular Power Platform could help you with this? This is the time, I am introducing a third principle, which is regarding the technology implications. Here´s where in many cases I do see questions upcoming regarding the Common Data Service compared to other data sources. Couldn´t it easily become an isolation of data or a siloed approach?

To proof this is wrong, let´s take a closer look into the Common Data Service and it´s importing and exporting options. First by diving deeper into the ways of getting data into the Common Data Service.

There´re three main options, that you could follow:

1. Using Data Flows and Power Query
2. Using Azure Data Factory or
3. Using either Azure Logic Apps or Power Automate

to import data into the Common Data Service. The beauty around all of them is the easy to learn, easy to setup and easy to maintain approach, that is shared across all three options. So, if you´re a data analyst being familiar with Power Query, you high-likely would shape or transform data, map it to Common Data Model entity definitions using the Data flow editor and import data easily on a scheduled or manual basis.

Being an Azure developer familiar with Azure Data Factory, you might be in favor of using pipelines, data sets and data flow concepts to connect SaaS, Cloud- or on-premises data and import data into the Common Data Service.

Last but not least, being a system integrator you might consider using Azure Logic Apps or Power Automate and one of its hundreds of connectors to get data imported into the Common Data Service, or if not yet existing use the Custom Connectors Framework that can connect to Open API (Swagger) to work with Services, Functions, and Code running in IaaS & Azure Kubernetes Services (AKS).

No matter of the toolset you´re using to import the data needed into Common Data Service, you should always remember the easy to publish data to Azure Data Lake from CDS. A simple to configure extension already GA´d, often not yet known.

Once configured, you would already have your first export option activated, but from an app maker perspective, you might want to know about additional services. And the beauty here is again on multiple options, such as the already mentioned

• Data Flows + Power Query
• Azure Data Factory
• Logic Apps or Power Automate

but also an additional Data Export Service that allows exporting you Common Data Service data.
You might now ask yourself: What kind of toolset to be in favor of? The answer would be, it depends. Technology implications, such as

• collecting, storing and organizing data,
• processing (analyzing) data to extract the insights
• Additional technology, such as AI Builder, Machine Learning and Algorithm being used to gather insights or
• How to communicate the insights from data and think about the its visualization?

should be your tour-guide here. And finally take a look at your Skills and Capacity and your Implementation and Change principles.

Hopefully, after reading this you´re now equipped to think of a good data strategy without isolation, and you agree that using Common Data Service is not following a siloed or isolated way of data processing. Instead the various low-code or pro-code options allow for matching your skills and capacity or implementation and change principles.

Like to discuss, leave a comment on Twitter or here on this blog.

Until then…