The Power BI team has invested a lot over the past year in making datasets better discoverable in the Power BI Service. This helps on many aspects to drive a data culture within your organization, aim for a single source of truth, collaboration within the organization and much more!
In this blog post I will introduce my perspective on various aspects of having an enterprise worthy dataset in the Power BI Service. I will do that by highlighting many different features that Power BI offers that will help you to take your dataset to the next level!
Enterprise worthy datasets
Looking at a large enterprise with many decentralized initiatives, it is very likely that across different teams and departments similar initiatives are worked on. As a result of that, typical end users might get lost and might experience unclarity and raise questions like;
- Which content should I trust?
- Which solutions are managed by a central BI team?
- Do we have a single source of truth?
- How can I benefit from the work that has already been done?
- Am I allowed to build a new report on this dataset?
- etc.
All valid questions, but a hard challenge to solve! Power BI offers a great set of features that helps you to approach these challenges. In many blog posts that will follow, I will describe features associated to below topics.
- Share content most effectively
- Requesting access to content
- Dataset discoverability
- Information protection
- Content ownership and descriptions
- Content endorsement
Some topics are tailored to datasets only. Nevertheless, there are some that also apply to other artifacts in the Power BI Service. For each element I will highlight to which artifact is applies.
Local solution vs global solution
Before we deep-dive into all these different features of Power BI, let’s first get clear what the difference is between a local and a global solution. In the introduction I shortly mentioned “enterprise worthy dataset” which for me defines that the solution is setup well, supported and matches governance and best practices within the organization.
Typically, a local solution started as a small initiative driven by an individual or small team. Local solutions are obviously shared with others, who will tell about this at the coffee machine and get togethers (or nowadays in teams meetings). More and more people will request access to benefit from this solution as well, as they heard about it from others. This typical scenario is what we can describe as a bottom-up approach, where a small initiative grows into a solution used by many stakeholders over time.
Where local solutions are often built on individuals’ knowledge and are based on pilled-up creative solutions, this is likely to end up in stability risks and challenges. Also, the content creator might be forced into a role to keep the solution alive, while this is not their day-to-day job and responsibility. This is the moment to take action! It is time to let your solution grow into a more mature enterprise solution.
Typical transformations an evolving local solution has to undergo is push down logic that has been built in Power Query to a data warehouse or data platform. Many transformation that might be done with self-service data prep with dataflows can be pushed down and pre-processed in the data platform before the data will be loaded in Power BI.
So far, some technical transformation that a local solution undergoes when it grows to be a more enterprise worthy solution. But it is not only technical. It is also about governance, sharing, collaborating and much more. Think about managing access through the corporate identity access management processes. But more important also privacy and security of the solution starts to play a bigger role, although everyone in the organization should take their responsibility in this area.
| Local Solution | Global Solution | |
|---|---|---|
| Approach | Bottom-up, business creates solutions that are shared across the organization. | Top-down, central managed solutions being shared across the organization according to defined governance. |
| Typical data sources | Extracted data from various applications, saved in Excel, CSV or other flat file formats on SharePoint, file shares or saved locally. | Data automatically extracted from enterprise applications flowing through a data platform with automated scheduled jobs. |
| Data transformations | Transformations applied with self-service data prep in either Power BI dataflows or directly in the data model in Power BI desktop. | Majority of transformations applied in the data platform before data is being loaded into Power BI. Minor reporting purpose specific transformation might remain in Power BI. |
| Data model | Data model is built for the reporting purpose only, according to knowledge and expertise of individual who build the solution. | Central data model intended for multiple purposes at the same time, where (company) best practices are applied and multiple reports and initiatives benefitting from the single data model is likely to be the case. Data models will support composite models and potentially build permissions for key-users to support new initiatives. |
| Solution ownership | Solution fully owned by the content creator, who will improve and maintain the solution based on best effort. | Ownership relies within a team responsible for solution and keeps improving the solution with continuous development. |
| Access management | Access management based on direct share with individual users, potentially from a personal workspace. Users will be granted access upon request. | Identity access management tooling supports access control using enterprise roles where users will be granted access automatically when they match the enterprise role profile. |
| Security & privacy | Security and privacy are based on the users own responsibilities in this area. Typically, users will be able to see the full dataset once they have access. | Security and privacy by design. Row/object level security is implemented by default and aligned with the enterprise roles as defined in the identity access management tooling. |
| Support | As this is not the day-to-day job of the solution owner. Support based on best effort within available time. | Dedicated support is handled as part of the central team building and maintaining the solution. Support is likely to include ticketing systems, service level agreements or experience level agreements. |
Now we understand better what the difference is between both, we can start looking at specific Power BI features that support the process to grow a local solution in an enterprise global solution.
In the next blog post that is coming up, I will focus on different ways of sharing content within the Power BI ecosystem. Stay tuned for more!
Data - Marc 
Pingback: Transform a local into a global Power BI solution – Content sharing – Data – Marc
Pingback: Transform a local into a global Power BI solution – Request access to content – Data – Marc
Pingback: Transform a local into a global Power BI solution – Dataset discoverability – Data – Marc
Pingback: Transform a local into a global Power BI solution – Information protection – Data – Marc
Pingback: Transform a local into a global Power BI solution – Ownership and descriptions – Data – Marc
Pingback: Transform a local into a global Power BI solution – Content endorsement – Data – Marc