A fundamental aspect of Power BI as a platform rarely discussed online or in groups is how you should structure and lay out your Power BI environment. At Geordie Consulting, we have a specific way of working and recommend that to all our clients; however, because no one discusses it, we often find clients have drifted into a way of working that can then become part of the problem and prevent the long-term benefit realisation of having Power BI.
To begin with, we need to understand and consider what a Workspace is within BI and the function that they are intended to provide. The core function of a Workspace is to emulate the core Microsoft function of Folders; when you roll back to the core principles of folders, the way to use Power BI Workspaces becomes clear. A workspace has Permissions, it is an access management function. Members and Administrators of workspaces should be active in how they interact with the Workspace, Viewers (and App Users) are more passive consumers of results. We recommend splitting workspaces down to workloads. NOTE: This is something that we have seen being “altered” by Microsoft as Fabric comes through, and items are being placed together in a single workspace. We will unpack that later, but we hope you will understand where our objections to this come from.
Functions and activities that need to take place within Business Data typically involve the connection to and preparation of data, modelling and shaping of data and finally visualisation and viewing of data. This is why we recommend structuring workspaces around those tasks, as an additional benefit, typically, those required to be active in different phases can be different. It may even be in the case of some data that the raw data MUST be more secure and only specific sanitised, curated data can be accessed by a wider audience.
This structure aligns very closely with traditional data professional terminology. Data is handled by Data Engineering, Model is a mix of Data Engineering, Data Science and Data Analysis, and Visualise is then Data Science and Data Analysis (+ the business). For those of you who say, “But I’m in a small company, why would I want to split things like that?” The response is simple. Doing this helps to provide a structure to your data landscape and while it adds an administrative overhead that is not necessarily a bad thing, when you are working on a single data project this can seem like overkill, however when you have multiple data projects that have been delivered and are all being worked on, that separation makes it easy to understand what and where changes should be made, the structures become clearer as do the requirements.
The multi-source landscape is where this all makes sense whenever you start to use Power BI. It is simple to think “Well this is a single solution, so it should all just be in a single workspace”. The result is that each subsequent project then uses the same strategy, so one workspace per data project. It is important to remember what has often triggered the move to Power BI, this is often driven by the divergence of BI that is brought about by the use of multiple different platforms across your organisation, the vast majority of modern software suites include a “Reporting Tool” and the majority of them are very good and are a great addition to that tool, the challenge is that then you have reports and data spread across your organisation and have to provide Senior Management either with multiple links and instructions to access each all with no way of pulling the data together OR someone within the organisation extracts data from each tool and uses a spreadsheet to produce some charts and tables to be shared via email, PowerPoint or similar. Power BI removes that problem. So, each tool may have a different data management team or requirements, which is why we recommend that each tool has its own ingestion workspace. SAP data goes into an SAP Data Workspace (should a workspace be needed – Oracle for example as a Database structure may not require a specific ETL Workspace), this structure focuses on ensuring that the ETL and Modelling steps remain different and remembers that the result of an ETL process can be used by multiple models. Semantic Models can be controlled in two ways, completely dependent on the business. If you have a well-defined vision of what a Centre of Excellence looks like within your organisation, you may decide to place all Semantic Models in one workspace as a Data Nexus. However, if there is any doubt about that, then each model should exist in its own workspace. Remember, the goal of a great data environment is to have fewer Semantic Models. Even if each model is in its own workspace, the number of workspaces should not be significant – an organisation should aspire to a single semantic model, but accept the minimum possible. Finally, the Visualisation layer – this should be structured around business function and pull the report content together that a specific job function requires. Meaning the C-Suite should ideally have a single C-Suite workspace, with variations within that function being handled by using App Audiences. For example, a Chief People Officer may have access to a more in-depth HR report within the C-Suite app, but it is limited to a CPO (Chief People Officer – Role)
In an import environment, these are typically Dataflows and will connect to source data and then extract what is required, processing the extracts to produce one or more tables of curated data. The requirement for these to typically reach into the source system means credentials are often held here, by that Client/Secret or Username/Password or access Token; they will often be present here and potentially there is a capability to extract more data that is needed, so it is sensible to separate the function of pulling the data from the function of utilising the resultant tables. This also ensures standardised ETL, often in more traditional environments, where each person manages their own extracts, and so variations creep in. Separating each application source into its own workspace, then just makes sense.
Semantic Models are the cornerstone of a Power BI environment and can require work from multiple people to be fully built, all while also not being multi-user compatible (yes, rumour has it that is changing now, but still it is not quite there). So you need to separate these and manage who can access them or update them. In essence, governance is required. This can be accomplished by bringing all Semantic Models into a single workspace or using one workspace per model; either will work, but it must be retained as moving a Semantic Model between workspaces requires work on each connected artifact (Report, Spreadsheet etc), so should only be done if absolutely necessary.
Your visualisation strategy is a vital part to consider, and while we have our recommendation that we will take you through, you may prefer to modify it, but first let us start with our recommendation.
We start by deciding that the best thing is for our teams to have a single reporting location. We want to have a single Reporting experience for our C-Suite for example, a Single Location for our Sales Teams, a single location for our R&D function. This is accomplished by establishing a workspace per functional area, the exact split of workspaces is dependent on your business, so let us now discuss exactly what happens within a single workspace.
A workspace is managed and run by Data Analysts. Reports are created using a live connection to the relevant semantic model. Remember, a report can only be connected to a single model. Using small (less than 5 pages typically) allows them to then be linked to one or more Dashboards (think interactive menus). Each Report can only connect to a single Semantic Model, however, all reports do not have to point to the same Semantic Model, meaning that your Workspace can contain reports related to every model in the organisation and all automatically refreshed on the various schedules your models have automatically. Dashboards can place content from different Semantic Models together transparently as well. The content is then accessed by the wider audience by using the Power BI App architecture, this is where content is assigned to an App, more specifically to an audience within an App. In our opinion, these audience differences are best used where you have something subtly different, so for example, your C-Suite App may have additional reports for the CPO (Chief People Officer) and the CIO (Chief Information Officer) using an additional group membership to give them access to that second audience, respectively. Audience is not the same as Security or Role-Based Access (RBAC), however, it can imitate it extremely well.
If you have built RBAC into a Semantic Model, an App will respect it while Members or above within a workspace bypass it. Another core reason to use Apps for sharing Power BI content outside your Data Centre of Excellence.
The “Stick everything in one Workspace” that seems to be being pushed now is only a way to remove the benefits of Power BI, after all, telling our Senior Leaders “Oh we’ve replaced the 10 links you have to go to with 10 new Power BI Apps” does not feel like progress. “Hey, we took those 10 different reporting tools you had and consolidated them into a single Power BI App you can access simply and have a view across the whole organisation” is the progress they want.
Geordie Consulting has the experience and expertise of doing this with clients around the world, no business is too small and laying down the right groundwork early on makes the inevitable expansion simple, even if you decide to put everything in a single workspace that does not make you a monster, being aware of the path to get to our recommended architecture so when you get to that point you can follow the steps. Geordie Consulting will work with you to understand your challenges and plan a way forward. Our goal is to make every contact your organisation has with us productive, so we are always adding value to your data environment. Schedule an “Introduction to Geordie Consulting” with us and start making your business data more valuable.
