Power BI Implementation Models for Enterprises

This article is the first of a series describing how I implement Power BI systems in enterprises. There are many ways to do this, and there is no one right or wrong way, but I'll tell you what has worked for me.

5 Minutes to Wow?

Power BI is an amazing tool that is easy to get started with. Its design team started with a target of "5 minutes to wow." You should be able to start using the product, and within five minutes be saying "wow! Look what I can do with this!"

Power BI achieved that goal.

But does that work for enterprises? There are many shortcuts in that five-minute wow period—shortcuts that are hard to take advantage of in an enterprise setting. Enterprise thinking makes things a little more challenging, and you need more planning.

Power BI appeals immediately to power users. Enterprise IT developers weren't the target. I cannot blame the team for making that decision. The product is in an amazing position in the current market. It's a long way ahead of the next rival. The team had no time to fulfil the enterprise requirements. If they did, they would have lost. With that in mind, you cannot expect to implement Power BI in an enterprise setting without some planning and setup. That's what I'm going to cover in this series.

Getting Ideas off the Ground

I review many Power BI projects. So many remind me of what I used to see with Microsoft Access years ago. There is a running joke in the data community about using Microsoft Access as a database. The joke is that it is not considered a database.

I understand why enterprises have scorned Access. In many organizations, users spread data across Access databases in an uncontrolled way. I don't view Microsoft Access like that. I'm not saying that I'm a fan of it. But many applications today only exist because of it. Access was the tool that let people get started. It was an enabling technology that let ideas get off the ground.

Power BI today has a similar potential issue. It enables so many people to get data and reporting ideas started. That's all that many people need, but not enterprises. Silos of data with varying quality and management won't ever be popular there.

The needs for enterprise users don't stop there either. They also need to worry about:

• Strong security guarantees
• Using appropriate governance for the data
• Protecting their work with source code control
• Versioning their work so that they can roll back when errors occur, and so they can work out what's been changed.

These users can't afford to have their Power BI work be scorned in the future, like Access-based work often is today.

Implementing Power BI in Enterprises

I mentioned that there is no single right or wrong way to implement Power BI in an enterprise. In this series of articles, I will tell you how I do it. I have worked on many projects, and I have a good track record for outcomes. I can't promise you that I won't prefer a different plan in the future. The evolution of these technologies never stops.

It's critical to make the project suit the client. In a few articles, I'll show you how I structure the projects for different types of clients. I'll show you how I structure data models, how I stage and process the data, and how I keep it secure. I will also show you techniques that I use to automate the process of building the data models.

Cloud Implementation Models for Power BI

The number one decision point about how to implement a project for a client is to assess their level of cloud maturity. I also look at their existing source applications. No two clients are identical, but there are groups of clients whose projects I manage in a particular way.

I always start by classifying clients into four categories: cloud-native, cloud-friendly, cloud-conservative, and cloud-unfriendly. I use a different architectural approach for each type of client.

Cloud-Native Clients

These clients are comfortable with using cloud-based Software as a Service (SaaS) applications. They accept the idea that their data will live in cloud-based storage. Often, they are already using cloud-based SaaS applications. And these application systems are often the primary source systems that we will use. They feed data for our analytic work.

These are our favorite clients.

Cloud-Friendly Clients

These clients aren't using cloud-based systems for their core work. They are happy to use cloud-based SaaS applications. They know that some of their data that's needed for analytics will need to live in cloud-based storage.

These are great clients to work with as they are much more open to the cloud-based approaches that I prefer.

Cloud-Conservative Clients

These clients don't yet use cloud-based systems for their core work. They are willing to use Power BI in the cloud for visualizing data. But they don't want to store any of their data in the cloud, not even their analytic data.

These clients aren't as open to the cloud-based approaches that I prefer. We still have good solutions for them.

Cloud-Unfriendly Clients

These clients are not into cloud-based solutions at all. They want all their data to stay on premises, and they want their analytic reporting to stay there too.

These clients are not open to the cloud-based approaches that I prefer. We have solutions for them, but they are much more limited.

Summary

To get started with enterprise Power BI projects, you need to start by deciding one thing:

What level of cloud maturity does the client have?

Everything else in the architecture will flow from that. That will include where the analytic data will live.

In this series of articles, I will describe the architecture that we use for each of these types of clients. You can read the next article in the series here.