Data governance is defined as a set of policies to secure an organization's data, ensure consistent and accurate decision making, and to manage access to data. Data governance is applicable to business intelligence generally, but organizations investing in Power BI for the long term should consider their data governance strategy and policies in the context of Power BI. A central component of data governance relates to the three deployment modes described at the beginning of Chapter 1, Planning Power BI Projects, and seeks to address the following question: "How can we ensure our data is secure and accurate while still providing the business with the access and flexibility it needs?"
It's generally understood that some level of self-service BI (SSBI) is appropriate and beneficial to empower business users to explore and discover insights into data. Tools, such as Power BI Desktop, and features in the Power BI web service, such as apps, make it easier than ever for business users to independently analyze data and potentially create and distribute content. However, experience with SSBI projects has also strongly suggested that IT-owned and managed administrative controls, enterprise-grade BI tools, and data assets, such as data warehouses, are still very much necessary. In response to the strengths and weaknesses of traditional IT-led BI and business-led SSBI, Microsoft has suggested and internally implemented a managed self-service approach to data governance.
From a BI architecture standpoint, managed self-service BI aligns represents a hybrid approach of both the Corporate BI and the Self-Service Visualization modes introduced in Chapter 1, Planning Power BI Projects. As shown in the following diagram, certain projects are carried out by the BI/IT department, while business users have flexibility to analyze data and create their own reporting:
The three capabilities of Corporate BI Projects identified in the preceding screenshot address the limitations or weaknesses of self-service BI projects and tools. These limitations include data accuracy, scalability, complex data integration processes, and custom distributions of reports to groups of users. Certain projects requiring these skills and tools such as the integration of multiple source systems and the scheduled distribution of user-specific reports could be exclusively developed and managed by IT. Additionally, the business stakeholders for certain projects may prefer or insist that certain projects are wholly owned by IT. From an on-premises perspective, one example of this would include an extract-transform-load (ETL) package developed in SQL Server Integration Service (SSIS), an SQL Server Analysis Services (SSAS) data model, and a combination of paginated and Power BI reports developed for the Power BI Report Server.
However, as shown in the Business User SSBI mode of the Multi-mode Power BI deployments diagram, business users are still empowered to leverage SSBI tools, such as Power BI Desktop, to conduct their own analysis and to internally determine requirements within their business unit. Most commonly, business users can leverage an IT-owned asset, such as an Analysis Services model, thus avoiding the data preparation and modeling components while retaining flexibility on the visualization layer. This Self-Service Visualization model is very popular and particularly effective when combined with Excel report connections.
Note that continuous monitoring and data governance policies are in effect across the organization regardless of Corporate BI or Business User SSBI. This is very important to detect any anomalies in user activity and as a first step in migrating a business developed solution to a corporate BI solution. For example, monitoring of the Office 365 Audit Log data for Power BI may indicate high and growing adoption of particular reports and dashboards based on a particular Power BI dataset. Given this query workload, or possibly other future needs for the dataset, such as advanced DAX measures, it may be appropriate to migrate this dataset to an Analysis Services model maintained by IT. An example of this migration process to an Azure Analysis Services model is included in Chapter 13, Scaling with Premium and Analysis Services.