Data Models vs Visualisations in Analytics Tools: The Data Modeller and the Report Author

Pick any modern analytics tool, BI platform or data visualisation tool and read the marketing page. They nearly all promise the same journey of ingest your data, transform it, model it, visualise it and share it with the business. Many now go further with AI capabilities layered on top, natural language questions, auto-generated insights and Copilot style assistants. So on paper, the tools look interchangeable, one big box that turns raw data into decisions.

Here is the thing though, inside that box sit two very different disciplines, and treating them as one is a common source of pain I see in organisations. The data model and the visualisation are not the same job, they are not the same skill set and in some organisations (not always) they are not even the same person.

In this blog, I want to explain the difference between what I like to call the data modeller and the report author, using Power BI as the working example. Quick note before we go on, this blog deliberately focuses on those two roles only. Not implying there aren't others. Also, we have detailed blogs covering all the Power BI and Microsoft Fabric personas and how you should train each of them, so for the full picture be sure to read our thorough blog What Is Power BI Training?. To take it one step further, on training these persona types beyond the tech, which a lot of our clients love and see genuine value in, have a read of Microsoft Report Developer Training: Report Writing Skills.

Quick Definition

In analytics tools, the data model structures the data, defines how tables relate to each other and holds the business logic and calculations, while the visualisation presents that data to people through charts, tables and interactive report pages. In Power BI, the data model is the semantic model, built and owned by the data modeller, and the visualisation layer is the report, built and owned by the report author. One semantic model can, and usually should, feed many reports.

Key takeaways from this blog:

• Data models and visualisations are separate layers doing separate jobs, even when a tool bundles them into one product.
• Power BI can be seen as the bringing together of three Excel add-ins from before 2015, Power Query, Power Pivot and Power View, and that history still explains its layers today.
• The data modeller works in the data modelling layer (Power Pivot), the report author works in the reporting layer (Power View).
• The two roles need different skills, different training and different success measures.
• Getting this split right is a foundation for reuse, trust in the numbers and, increasingly, for AI features like Copilot to work at all.

Why the Tools Blur the Line

From my experience of working with many clients over the years, the confusion is understandable. When one person opens Power BI Desktop, they can connect to a source, shape the data, build relationships, write measures and drag visuals onto a canvas, all in a single file, in a single afternoon.

That is fine for a personal, one-off piece of analysis. But the moment a report matters to more than one team, or the moment a second report needs the same numbers, the two layers pull apart. Microsoft's own guidance recommends separating the semantic model and the reports into different files when the modellers and authors are different people, or when one model will feed multiple reports. In our experience, that point arrives much earlier than most organisations expect.

The Data Modeller and the Report Author

Let me define the two roles, using the same language we use in our training blog.

The data modeller (the Model Designer in our persona framework) is the data and data analytics expert who uses Power BI Desktop and actually enjoys the challenge of turning chaotic Excel sheets into structured semantic models. These users are tasked with creating and managing semantic models, usually combining data from various data sources. Their role involves ingesting data, selecting the right storage mode, transforming and shaping data, creating relationships, defining star schemas and writing DAX measures to produce accurate semantic models.

The report author is the individual that is an expert at making pie charts interesting enough to distract from last quarter's results. These users are responsible for creating visually engaging, insightful and interactive reports from existing semantic models. They focus on data visualisation, data storytelling and the implementation of advanced report features like bookmarks, drill through, tooltips and so much more. They spend the majority of their time in Power BI Desktop too, but on the canvas section.

Notice the phrase in that second definition, from existing semantic models. That is the whole relationship in four words. The modeller produces the semantic model as a product, the author consumes it as a source. Quick side note, plenty of people wear both hats, especially in smaller teams and that is perfectly fine. The point is not that you need two headcounts, it is that you should recognise you are doing two jobs, because each one deserves its own care.

Where Power BI Came From, Three Add-ins

Here is a bit of history that often makes this split click for people in the workshops I run.

Power BI can be understood as bringing together three Excel BI technologies that existed before Power BI Desktop: Power Query, Power Pivot and Power View. To all the experts: yes, I know Power Map was part of that family too. But to simplify the history and make the point, let us stick with these three.

Power Query provided the data ingestion and transformation experience: connecting to sources, cleaning data and shaping it for analysis. That same core technology lives on as the Power Query Editor in Power BI Desktop and as Power Query Online, which underpins experiences such as Dataflows Gen2 in Microsoft Fabric.

Power Pivot provided the modelling technology: tables, relationships, the in-memory analytical engine and the DAX language. This is the heritage of what I call the data modelling layer. An evolved form of the same underlying modelling technology still sits at the heart of Power BI semantic models, with import-mode models using the VertiPaq storage engine.

Power View provided the interactive visualisation experience: the canvas where users created charts and explored data visually. This is the heritage of the reporting layer. Microsoft removed Power View from Excel for Microsoft 365 and Excel 2021 starting October 2021, but Power BI Desktop was built on the same free-form reporting experience and became its natural successor for interactive report authoring.

Microsoft first introduced the Power BI Designer preview in around 2014/2015. It brought together Power Query and much of the Power View experience, with the Power Pivot in-memory engine already working behind the scenes. The product was then released as Power BI Desktop alongside the new Power BI service in 2015.

The original technologies did not simply remain unchanged inside Power BI. Their core capabilities evolved into the main layers of a single product:

• Ingest and transform: the Power Query layer.
• Model and calculate: the Power Pivot layer.
• Visualise and interact: the Power View layer.

The semantic model developer works primarily across the first two layers. The report author works primarily in the third, although modern Power BI allows some overlap between the roles.

The Actual Differences

Now, let us get practical about what sits in each layer, because this is where the "who owns what" arguments usually start.

What lives in the data modelling layer

• Connectivity and transformation: connecting to sources, shaping data in Power Query, handling data quality issues before they reach the model.
• Storage mode decisions: Import, DirectQuery, Direct Lake or Composite, a decision with performance and governance consequences that a report author should not have to think about.
• Structure: star schemas, fact and dimension tables, relationships and granularity. If you want the fundamentals, we cover them in Data Modelling in Power BI.
• Business logic: DAX measures with agreed definitions. Revenue should mean one thing, defined once, not five slightly different things across five reports.
• Security: row-level security and data protection, applied at the model so it holds no matter which report sits on top.

The modeller's output is trust. When two reports on the same model show the same number for the same question, that is the modelling layer doing its job.

What lives in the reporting layer

• Visual choice and design: picking the right visual for the question, layout, colour, accessibility and consistency with organisational standards.
• Storytelling: structuring pages so a reader moves from headline to detail naturally, rather than facing a wall of forty visuals.
• Interactivity: bookmarks, drill through, tooltips, slicers and navigation that makes exploration feel effortless.
• Requirements: engaging stakeholders, understanding the decision the report supports, and pushing back when a request is really a data extract in disguise.
• Audience fit: designing for the boardroom, the ops floor or a mobile screen, which are three different reports even off the same model.

The author's output is understanding. A technically perfect model that nobody can read is as useless as a beautiful report on numbers nobody trusts.

Different skills, different success measures

Think about it, you would not judge a data modeller on their colour palette, and you would not judge a report author on their DAX. Yet I see exactly this in interviews and appraisals more often than you would expect. The modeller is measured on accuracy, performance, reusability and security. The author is measured on clarity, adoption and whether decisions actually get made off the page. Same tool, different crafts.

This is also why the semantic model has become the centre of gravity in Power BI, a point we go deeper on in Power BI Semantic Models and why they matter more in the age of AI. Copilot and other AI features read the model, its measures, its relationships and its metadata. AI does not fix a vague model, it amplifies the consequences of one. A report author cannot design their way out of a modelling problem, and no AI feature can either.

Which Layer Is Your Problem In?

If you are reading this because something in your Power BI estate hurts, here is a quick diagnostic I run in my head when a client describes their symptoms. It is not exhaustive, but it catches most cases.

• The same KPI shows different numbers in different reports: modelling layer. Either there is no shared semantic model and everyone rebuilds the logic, or definitions were never agreed. No amount of report polish fixes this.
• Reports are slow or refreshes keep failing: usually the modelling layer too. Wide flat tables, the wrong storage mode or overloaded queries are the common culprits, even though the pain shows up on the report canvas.
• Reports are technically correct but nobody uses them: reporting layer. The classic sign is a wall of visuals answering every possible question and therefore answering none. This is a storytelling and requirements problem, not a data problem.
• Everyone exports to Excel the moment a report opens: could be either, so ask why. If they do not trust the numbers, that is the model. If they cannot get the view they need, that is the report.
• One exhausted person is the bottleneck for everything: both jobs on one head. The fix is rarely "hire another generalist", it is recognising the two roles and deciding which one to grow or bring in.

I would encourage you to run your own estate through that list before deciding what kind of help you need, because I regularly meet organisations buying report redesigns when their actual problem is three versions of revenue.

Where Metis BI Fits

The reality is that plenty of people do both jobs, especially in Power BI where one developer often takes a solution end to end. The trick is not splitting people, it is recognising the two crafts, structuring your Power BI and MS Fabric estate so models are shared products rather than per-report copies, and training each craft deliberately, even when both sit in the same person. That is one of those things we give a lot of attention to in Metis BI. We help teams split their modelling and reporting layers properly, define the personas in their organisation and deliver persona-based training so modellers become better modellers and authors become better authors. It suits organisations who have grown their Power BI estate organically and can feel the strain of everyone doing everything. Learn more about our Power BI Training approach.

Summary

Analytics tools sell one journey, but underneath they run two crafts. The data modelling layer, the Power Pivot heritage in Power BI, is where the data modeller builds structure, logic and trust into a semantic model. The reporting layer, the Power View heritage, is where the report author turns that model into something people can read, explore and act on. The tools will keep blurring the line, especially as AI features spread across every product, but the disciplines are not blurring at all. If anything, a well-built semantic model matters more now than it ever has. Know which job you are doing, respect both, and train for each one deliberately.