Forum Discussion
Approach for build a scaled solution
This is just one approach, but I like it for security/backup/ease of use. It leverages AD, the Desktop and the Service.
1) Security is managed via AD groups to simplify user management. You have control of which end users can read the model, which users can publish reports via that datasource (Enterprise Gateway), which users have access to the Power BI Groups. This also allows for row level security on the model level).
2) I use the desktop to build/update reports using my SSAS connection. This gives me backups/version control because I have the file which I can re-deploy anywhere, and I can store it in any number of locations including those like Sharepoint where I can see modified dates, etc.
3) I use Power BI Groups as the only place to pull company level reports into. This gives me the ability to have a group of people manage reports and own them, so everything isn't in one persons workspace.
4) For most end users, a shared dashboard is going to be easier to understand, so that is typically the best way I've found to intially start sharing reports. Although Content Packs are powerful, and I think are a great "Step 2" for implementing certain solutions, but only after I'm sure the owners and end users know how to use them.
This is a really high level broad strokes bullet point list, but it's typically my recommendation path for larger scalable solutions. At this point in time building business processes has to take the place of admin controls or features since those are not in the tool by default. I'm hoping more of the capabilities are added over time.
Thanks Anonymous, I refer to differents ways to deploy a scaled solution with Power BI, and based on their experiences, which could be the best approach. Since what I've seen every form of implementation has its pros and cons. For Example:
1- With Power BI Desktop you can create a very complete solution importing data from multiple sources and modeling it and all this running in memory. But the cons is when you publish in the service (Because Actually Doesn't exists an On-Premise solution) you are limited to 250MB in your dataset, so is not scalable (I think so).
2- The other alternative is create a solution using DirectQuery, with this you are not limited in the dataset and also you get always the most recent data, but the cons is DirectQuery has many limitations in the Query Editor, Modeling, DAX and lose the in-memory technology..
3- Also we can work with SSAS, but in this way you lose all the ETL capabilities of Power BI, because Power BI will act only as a presentation layer.
alexanderg My 2cents: If you have the option to use SSAS, then go that route.
The only downside, that I see, is that it requires more knowledge of different applications to build the backend etl.
The benefits:
There are no limitations to size (as you mention)
There are methods for version control (TFS) and backups
You don't have to rebuild everything if your 1 Desktop file that contains everything becomes corrupt for some unknown reason.
You get the benefits of using an in-memory model - especially in SQL 2016
You get to keep your data on-premises (matters to some, not all)
You can use your model in any visual platform that supports a connection to it
There are probably other benefits, but that's what I can think of at the moment.
Thanks Anonymous I will considerate that route, use a SSAS Tabular as a backend! So for you which is the best approach to organizing in the Power BI service the content of a solution based on SSAS. taking into consideration aspects of security, governance, access levels, collaboration, etc.?
This is just one approach, but I like it for security/backup/ease of use. It leverages AD, the Desktop and the Service.
1) Security is managed via AD groups to simplify user management. You have control of which end users can read the model, which users can publish reports via that datasource (Enterprise Gateway), which users have access to the Power BI Groups. This also allows for row level security on the model level).
2) I use the desktop to build/update reports using my SSAS connection. This gives me backups/version control because I have the file which I can re-deploy anywhere, and I can store it in any number of locations including those like Sharepoint where I can see modified dates, etc.
3) I use Power BI Groups as the only place to pull company level reports into. This gives me the ability to have a group of people manage reports and own them, so everything isn't in one persons workspace.
4) For most end users, a shared dashboard is going to be easier to understand, so that is typically the best way I've found to intially start sharing reports. Although Content Packs are powerful, and I think are a great "Step 2" for implementing certain solutions, but only after I'm sure the owners and end users know how to use them.
This is a really high level broad strokes bullet point list, but it's typically my recommendation path for larger scalable solutions. At this point in time building business processes has to take the place of admin controls or features since those are not in the tool by default. I'm hoping more of the capabilities are added over time.
Hi Anonymous,
It seems really interesting thread to have discussion. It is likely that we were in the same situation to choose approach how to integrate PowerBI in our legacy system (over 5 years old). we are currently using Qlik, and now we had decision to move on Power BI.
Eventually, we go ahead with approach:
1. Move our database from on-premise to Azure SQL. (This way we don't need to install enterprise gateway).
2. Built lots of Database Views to support PowerBI. With this way we can do lots of tweats (limit columns, aggregations, renaming, calculated columns....) under SQL instead of Dax and Data Tool on PowerBI (SQL is still more powerfull and familiar with us than DAX). The PowerBI will load data over Views, not tables directly. The con for this approach is we will loose the relationship between tables, so we have to re-add again manually on Power BI relationship.
3. We use scheduling to refresh data, not direct query. So the limitation 250M is acceptable for us, since we use Views doing tweats in oder to decrease the size.
4. The hardest part we think is security, for now PowerBI only uses AAD for authentation. Our system has its own security mechanism on premise. As my understanding we have no way to do authentication from PowerBI to external Identity Provider. So we have to sync our users from our system to AAD. This is awkward approach since the way to manage users is totally different with AAD (mutlti-tenant, roles...). How we deal with roles? We have to build each PowerBI file for each roles even they have the same Power BI UI but different data. It's not still good approach but it does work, though.
If you have any idea, it would be highly appreciated
