Power BI Governance Part 1: Multiple environments, data source certification and documentation
This post explains three best practices for Power BI governance: multiple environments, data source certification and documentation.
Power BI is taking off, and it’s fast becoming the most popular business intelligence platform on the market. It’s easy to engage with and get professional results quickly, making it the perfect tool for organisations looking to beef up their BI prowess and make data driven decisions through-out the organisation.
In this post we’re going to look at three best practices for implementation and give you the tips you need to make sure you avoid common pitfalls so you are on the fast track to success with Power BI on your organisation.
1. Setup multiple environments
When working on a Power BI implementation project, it’s wise to have multiple environments to manage the lifecycle of your BI assets. Below we’ve listed several environments that should be considered depending on the complexity of the project and your organisation’s needs.
Development (aka Dev)
Being able to keep on top of the many reports you’re testing, and having the ability to track changes that occur, is essential as you get setup. Without a specific Dev environment, your production environment will quickly become overwhelmed with assets, making it hard to maintain and manage.
When working in the dev environment, make sure that you have data sources specifically for development. We’ve seen production data used in dev on many occasions which can lead to serious privacy and data sovereignty issues. Your dev data sources shouldn’t contain sensitive data.
These development environments can be on your local network or in cloud storage (like OneDrive for Business or GitHub). It is recommended to have separate Workspaces in Power BI Service for each environment.
Tip: The data sources of all published reports to Power BI Service must be sufficient for development use only and should avoid including confidential data.
User Acceptance Testing (aka UAT)
The people who will be using the reports daily are the ones who should be testing them – they know the business best, and will be able to identify opportunities and gaps that the development team may not be able to identify themselves. By making sure the user is brought into the process early on, it maximises the value added to the business.
User acceptance testing is the last phase of testing. The UAT environment should only be created once the solution has been fully tested in Dev and approved by senior Power BI developers.
As its name reflects, UAT helps with the overall acceptance rate of the solution and drills into the users’ mindsets. Available only to a select group of users, they will have access to published datasets, reports, and dashboards in the UAT environment for testing purposes only.
Tip: All data sources in Power BI must be switched from Dev to UAT before being published to this environment.
Production (aka Prod)
Prod is the most important environment in every organisation as it’s where the whole project comes together. The solution has been through intensive tests during development, audited by experts, peer reviewed internally several times and accepted by the end users in UAT. The iterative process to get to production means we can provide a better solution that has more trust amongst users.
This environment includes real world data and it’s very important that each Power BI report has been fully tested before being published to the “Production” environment. We’re now using live, real-world data so all data sources in the model must be switched from UAT to Prod.
It’s important to remember that despite best efforts, things can go wrong when deploying to Prod. Many organisations will have an exact replica of Prod acting as Pre-Prodenvironment for deployment testing purposes. This tends to only be cost effective in larger businesses where there are lots of projects in play. For smaller organisations, the alternative is to bring the UAT environment as close as possible to Prod (while taking into account privacy and security requirements).
Tip: Specific Workspaces should be defined for each business unit (if applicable).
2. Certify your data sources
Reports are only as good as the data that populates them, so we need to take steps to maximise the accuracy of our data. Data sources should be reviewed and certified by data professionals in your organisation and only certified data sources should be used in Power BI to ensure you can trust what you’re seeing.
After the internal review is done, you may come up with various confidence levels for your different data sources. Try to categorise your data sources with some self-explanatory names, for example, Gold, Silver, Bronze. From there you can make the decision to keep or ban certain data sources from being used in your Power BI implementation, in all Power BI projects across your organisation. For example, an organisation may ban all Bronze data sources and only use Gold and Silver in Power BI implementation.
Tip: As self-service BI becomes more common, ensuring the right processes are in place to make sure the data being used can be trustedbecomes increasingly important.
A list of certified data sources should be provided to all parties involved in a Power BI project and like everything, make sure this is documented – which is the perfect segway to our final good practice:
3. Document your setup
As we have seen – a lot of work goes into implementing Power BI so that it follows best practices and delivers value to your business. But as people change within the organisation and knowledge gets lost, you need to ensure you have the right systems in place to maintain continuity – otherwise you may end up having to go through this process again.
Documentation, like certification of data sources, is another governance process that you need to make sure you’ve considered early in the implementation process. Have a plan around how you will approach it and who will be responsible for maintaining it so you can be confident that there is a central place to turn to with information on how the implementation has been completed.
Competing short term priorities often mean that documentation is push aside as it is perceived as time consuming with a longer-term payoff. However, without it, reports can be difficult to work with, hard to handover and challenging to review – costing you significantly more down the track.
Modern documentation tools make the documentation process easy, saving you days, maybe even weeks, so it’s worth investigating smarter ways to pull it together.
Tip: Ensure that you have a way to rapidly document your reports and keep thisup-to-date as your reports change.
We hope these three best practices and tips will help you on your Power BI implementation journey. If you haven’t already, check out our recent governance webinar on Self-Service BI and its Perils which outlines a range of other best practices to consider.