“Power BI is a Data Visualization Tool”

A New Episode of the Series Bad Practices In Power BI

The Root of all Bad Practices: “Power BI is a Data Visualization Tool”

I have been in this situation a hundred times. A client meeting. I am invited as the Power BI expert to discuss the client’s needs and explain how Power BI is the right tool. And it’s always the same.

“Meet Gil, our data visualization expert and Microsoft MVP”, announces my colleague, who owns the relationship with the client and oversights a dozen of other non-analytic projects with this account. I don’t expect him to recognize the subtle nuances here. But then the client speaks. “We really like Power BI as a visualization tool and would like to replace our current XYZ tools”. The discussion goes on, but the misconception is almost always the same. Power BI is still considered as a front-end data visualization tool. As a result, depending on the phase of the project, it may already be too late to use Power BI beyond the front end visualization gig. How can you harness Power BI’s true powers when an entire organization already has developed a data warehouse with complex ETL and DevOps processes to provide the data for a visualization layer?

When so much time and money are already invested in the traditional development of backend business logic, how can you fight the cognitive dissonance and tell your client or project lead that Power BI can be better utilized? Do you know that Power BI can pave the way in any analytics project, reducing ETL development time, increasing data integrity, improving QA effectiveness and enabling an agile development culture where your end-users can provide feedback from the first sprint and continuously after each sprint?

So, today as a new episode of “Bad Practices in Power BI” we will focus on one of the worst bad practices in Power BI – when we treat it as a visualization tool.

As a project lead or data architect that gets to decide how to implement a new BI solution, your bad practice starts during the planning phase when you choose to involve the Power BI guys at the end of the project. Your Power BI experts should start on day 1.

Bad Practice: Power BI developers are only involved in the later stages of the project.

IT Architects, decision-makers and many Power BI practitioners are completely unaware of the data transformation (Power Query, dataflows, M) and modeling (Tabular, DAX) capabilities of Power BI and their key roles in creating a game-changer data culture that can truly combine self-service and enterprise analytics. For most of them, Power BI is a Tableau-compete tool, with very attractive interactive visualizations and Pie Charts that can be presented to their executives. As a result, they approach Power BI practitioners in the later stages of the project, and in many cases, they hire Power BI practitioners that lack skills in data preparations and modeling.

Bad Practice: Power BI developers are hired for a project based on their visualization skills only.

But we cannot blame IT and data architects for the lack of awareness. The lack of awareness starts with Power BI practitioners. Unaware of the potential of Power BI to turn them into full-stack BI demigods, these practitioners keep doing what they know the best: Manual data crunching and development of mesmerizing pixel-perfect visualizations.

Are you such a practitioner? You almost always rely on others to provide you the data in the desired format. You may have stumbled upon Power Query Editor and know how to remove columns and perform basic transformations, but nothing beyond it.

You focus on real relationships with your stakeholders and ignore model relationships. “Bring me the data in a single flat table”, you often say to your data pal. “Don’t you need it in a Star Schema?”, he may ask (and you are lucky to have him if he knows that Star Schema can help you), but you will probably reply back “A Star Wars schema? I prefer my lightsaber visualizations”.

You may know that there is a DAX language with Excel-like functions such as SUM and AVERAGE, but you always prefer to drag and drop numerical columns to the values section of your visuals (When you do it you create implicit measures – and this is a bad practice by itself – but you may not be ready to appreciate this nuance in your journey with Power BI. Instead, you will frown and redirect me to the beautiful and colorful reports you have made.

You are proud of the visualizations you have created. Your boss is also very proud. As you read these words, he may be showing off your visuals to his boss and stakeholders and may even take credit for your work, but you don’t care. Your job is secured for a decade. Life is beautiful. So are your reports.

Bad Practice: As a Power BI developer, you focus on visualizations and don’t learn Power Query, modeling or DAX.

I agree that Power Query and modeling may be perceived as topics that should be practiced by data engineers and not by data visualizations experts. It is not meant for everyone. So, if you are a data visualization expert, it is OK that you will decide to keep your focus on visualizations and avoid learning these tools. But know this – without having a strong data modeler in your team, your success may be short-lived.

Bad Practice: As a Power BI visualization developer, you don’t insist on having a strong Power BI modeler in your team.

Do you know what are the most important traits of a good modeler? I suspect that perseverance and humility are these traits. Why? Because unlike other software programming languages, the syntax of DAX and M are always sufficient to master these techniques. It takes practice and a long time of trials and errors. During this journey, many practitioners, reach a certain level and are not aware of the new pitfalls that await them. As they make a bigger impact in their organization, they become mission-critical in their projects. Filled with a sense of accomplishment, they may stop their learning journey. Knowing nothing about the opportunities that await them.

Bad Practice: You consider yourself a full-stack Power BI developer, but you don’t know what you don’t know.

This is where we start seeing Power BI reports that are overly complicated. At the start, the heroes behind these reports are admirable by their team members and managers. With so many sophisticated calculated columns and measures in DAX that are barely readable, the authors of these reports become the envy of their peers. But over-time, these Power BI reports fail to keep up with their promise and eventually they become unsustainable. If you are a developer of an overly complicated report and you refuse to know what you don’t know, your short-term success will be defined by how fast you move to a new project. If you are never assessed by the sustainability or performance of your work, you will never realize you are applying the next bad practice.

Bad Practice: You don’t keep it simple. You over-engineer it. You don’t care about long-term sustainability. You do anything to reach the desired visualizations.

You can see that there is a repetitive theme here – The lack of awareness that Power BI is a full-stack BI platform and the short-term focus on the visualization requirements as the only driver for success. This is, in my mind, the root cause of many bad practices in Power BI.

So, how did we get here? I think that it’s all related to one important element in Power BI – Its ability to enable any user to start fast. Power BI was initially designed to be a self-service analytics tool with a very low-barrier for beginners. If you have experience with PowerPoint and PivotTables in Excel, you will find it easy to drag and drop fields in visuals and start delivering amazing reports. If you know Excel formulas, you may think you know enough in DAX to create calculated columns and simple measures. So, why to bother to do more.

Another source for the lack of awareness of the data preparation and modeling’s true capabilities in Power BI lies in the fact that other BI tools simply lack such capabilities. Yes, as a BI developer in IT you may be able to do some ETL and modeling in other tools. But in Power BI you can do it using a unique technology that will allow your reports to easily be migrated across different products such as Excel, Power BI, Power BI dataflows, SQL Server Analysis Services, PowerApps, Azure Data Factory, and SSIS.

Now, if you would ask me what is the single missing behavior in Power BI that can prevent the bad practice by users to treat Power BI as a data visualizations tool, I will tell you a simple answer. It is the default Load button that should be replaced by Transform Data to expose new users to the data preparation elements of Power BI.

Microsoft recently changed the name of the button from Edit to Transform Data to help new users discover the opportunity they have, and launch the Power Query Editor to enable them to start preparing their data with few clicks of the UI. I hope this change will increase the use of Power Query, but I would go beyond such change and be more aggressive here. I would place the Transform Data as the default key and place the Load as a second key. I would even change the Transform Data to Transform now, my data is messy and change Load to Skip data transformation.

Please share your experience in the comments below. Did you encounter difficult situations following the misconception of Power BI as a data visualization tool? Do you think Power Query Editor should be more visible in the UI?

In the next episode of “Bad Practices in Power BI”, we will demonstrate the over-arching bad practice of “not knowing what you don’t know” through a sequence of badly implemented import steps of a simple Excel workbook. Stay tuned.

18 comments

  1. Alaeddin Reply

    Thanks Gil for sharing this.

    Just curios to hear your thoughts on why you would consider this a bad practice:
    “but you always prefer to drag and drop numerical columns to the values section of your visuals (When you do it you create implicit measures – and this is a bad practice by itself –”

    Cheers

    • Gil Raviv Post authorReply

      Thank you Alaeddin. The main reasons for having it as a bad practice is that your DAX becomes better sustainable with explicit measures that are reusable. In addition the Analyze in Excel add-in cannot detect implicit measures. So, you end up with textual columns that cannot be dragged and dropped to values in PivotTables.

  2. Steve Pike Reply

    What an inspirational piece! I have some up against the same problems in a job search in the UK where Power BI is not enough. Recruiters want the whole DW/SQL/SSRS/SSIS/SSAS stack when this is all taken care of within the Power BI M Query engine! Having spent consderable doing the ETL processes all in Power BI I have not had the need to develop skills in these areas. My datalake is SQL, SharePoint, Excel files, Dynamics 365, my Data Marts are Power BI datasets. One sets of skills, one place to look when debugging and one set of ‘curated data models’! Connectivity to other data and Power BI is all I have needed!

  3. MF Reply

    Excellent post! Can’t agree more. I have been waiting for a post like this for long.
    Indeed i think many people from I.T. have no idea what Power BI is capable of (at least the case in my company). Normally they are the ones keep saying Power BI is a visualization tool. ?
    I saw a Power BI report created by an internal SQL specialist, I couldn’t have expected the FAT table behind the scene instead of a star schema… ??‍♂️
    One other thing I try to / want to change is the term “report”. I intentionally state Tool instead of Report in most cases. Come on, are we still expecting a deck of static reports using Power BI? But you know, it’s not about the tool. It’s about the people. It’s behavioral change. It’s a long road. Keep fighting!
    Looking forward to your next post. ?

  4. Anonymous Reply

    Good article! I also don’t like when someone thinks that I mostly create visualizations as a Power BI developer. I like to call it a data modeling tool to implicate the complexity.

  5. Mehdi HAMMADI Reply

    Thank you Gil for this very interesting and inspiring post. I totally agree with you that Power BI was designed to be a self-service analytics tool for non BI practitioners. One of the features, that totaly illustrates that, is the “Auto Date/Time” that was set, by default, to “Enable” and in my opinion, if one of us has not disabled this feature is that he still have a long way to do

  6. Chris Healey Reply

    Really great article and highlights that emphasis is on good data modelling in Power BI foremost; unlike Tableau which has front-end capabilities to overcome lack of a sound data structure.

  7. Gudmundur Asmundsson (@Gudmas70) Reply

    For me Power BI is first and foremost a modeling tool.  With great model you can allow your clients to create the report themselves, but it starts with a well structured model, where all your measures are kept in a separate folder, not within the fact tables them selves.

  8. Ahmed Oyelowo Reply

    You have said it all Gil. I always say there are two levels of Power in Power BI. The first one being the ability for anyone to start off and create some beautiful (but always wrong) visualizations. And the second power for me is the real one, the ability to Transform, Model and using DAX to create advanced reports.

  9. Koen Verbeeck (@Ko_Ver) Reply

    (Copy paste from my reply on Twitter)

    I do not agree at all with the sentence “…when an entire organization already has developed a data warehouse with complex ETL and DevOps processes …”. What’s wrong with that?
    1. Power BI doesn’t have DevOps (currently).
    2. Power BI can’t track history. A DWH can.
    3. Complex ETL doesn’t belong in Power Query (maybe in data flows, but not in PBI Desktop).
    My advice is still building a DWH. I’d say every time, but that might not be realistic. Almost every time 🙂 Okay, rant over 🙂

    The rest of the article is spot on. I’ve seen numerous occasions where as strong model saved a lot of headaches, especially in the DAX.

    • Gil Raviv Post authorReply

      Thank you Koen for sharing. Nothing wrong in building a modern data warehouse, but there were two implicit points to make here. 1- Power BI developers could help build that data warehouse by using Power BI as a prototyping tool. You start with it and then replace relevant elements.
      2- In some projects, you already have a data warehouse, but an additional data and ETL layers are developed to serve the new Analytics scenarios. This is where you can have more options for what should be developed in Power BI and what should be developed outside. But I always prefer you start with Power BI to be agile and replace the elements that are necessary overtime.

  10. Angus Reply

    Excellent article Gil. I have just returned from delivering a 3 day Power BI and DAX course to finance and IT professionals at a very large international NGO. We only delivered the training after spending nearly 6 months getting their data model right.

    If you make the model right for Power BI, then you don’t need complex DAX formulae. 80% of your work should be modelling, 20% visualisations.

    Within the modelling time you should spend time and effort on governance, which is critical to the successful roll-out of Power BI in a large organisation. The allocation of roles and responsibilities is so important. You can’t just have anyone preparing and publishing data without proper training, oversight and management control.

    Thanks again for a great article!

    Angus
    Oxford Power BI

  11. wynhopkins Reply

    Good stuff Gil, you should set up a powerbi ideas entry “power query default should be transform not load” – if there isn’t one already

  12. Anderson O Reply

    One of the better articles on Power BI in a long time.
    It’s never the visualisation but always the underlying data.
    Sooner or later visuals are debunked if the data is not optimum. Modelling and transformation are truly the heros of power bi.
    Good read

Leave a Reply