Revisiting the BUS matrix in a dashboard project | agileDSS

Ralph Kimball graced us with a nice artefact when he laid some of today’s data warehouse paradigms; the mighty bus matrix. This is a great tool for BI business analysts to gather requirements. It is very useful to conceptualise and understand the processes of an organisation across its business entities.

I now propose to rethink this artefact in the light of a dashboard project. I personally use this artefact in the design phase. Let me expose its use and maybe you’ll see how this gem of a concept never gets old!

Some of the examples I am referring to are especially suited for small or medium–sized enterprises (one to three dashboards) with a tactical or departmental scope having a few stakeholders. They are agile in nature and are often the new preferred tools of many mid-level managers, the envy of their pairs. You get the picture. The type of quick win, limited scope dashboard-with-a-laser-purpose that we oh so enjoy to build and show off.

The Bus Matrix to Know What we Need

When I first tackle a dashboard concept, the first things I need to understand are the key business entities we are trying to monitor/analyse/alert/etc. with the use of KPIs. These are my common dimensions and their associated hierarchies (snowflakes). I start my workshop with the product owner by trying to list the dimensions that are in the scope of the dashboard. I then list the indicators in row form which now replaces the business processes, which are sometimes facts.

Then, we start discussing the purpose and meaning of the indicators and while doing this, we try to see in which “axis” these indicators would be meaningful.

Let’s try an example with a movie company selling tickets.

We see that some views are more important than others. Each “Movie” showing has a set of indicators and they overlap a great deal with “Market” analysis. For instance, the number of tickets sold for a certain movie schedule or an average price that a certain market is paying.

Is the time missing? Yes, but we will address it later and partly in the design as well. Since at this point we do not know the quality, sourcing and grain of each element of that matrix, I prefer to wait. Rarely does a stakeholder know this information.

The Bus Matrix to Know What is Possible

At this point I can already hand over that simple matrix and have a data analyst come back with an assessment of what’s possible. Here I add a new column: the granularity.

Caveat: We can imagine a case where an indicator is sourced differently for two movie theatres, one daily and the other weekly because of different ticketing systems or resellers. We can also imagine a ticketing system giving a ticket sale by movie but not by sales channel. That would simply require more rows or some other columns. For the sake of this article, I try to use a simple case.

We can imagine the next matrix:

Another thing I did was coloring the sourcing. In this example we found that the same data source provided the ticket sales and by a little join, the occupancy rates. Next we see two surveys and a marketing data source.

Next we see that getting the customer satisfaction by movie is not possible. Maybe that data source does not have that level of detail.

Again, I want to make clear that this is a conceptual model, not the exact way the tables are declared. Remember, this is a matrix representing customer needs. It makes no pretence of illustrating the completeness of the actual data warehouse.

Talking about detail, we see the ticket sales are by transaction. This is great! It means we’ll have a lot more detailed information and possibilities! We can also see here that some of our early questions about the missing “time” column are addressed.

A little tip is having a senior data analyst present with the product owner when showing or making that matrix. Interesting discussions can ensue, but buyers beware… many stakeholders will react in shock at their data quality result and will argue with IT people, which is not the goal of the exercise.

Another addition is to add some metadata about the indicator, like benchmarking, thresholds and other important information. This can be completed in a full KPI Specification.

The Bus Matrix to Help the Design

It helps identify which combinations are not possible from a data point of view. It prevents spending too much time on a design that cannot be implemented.

It helps to see which indicators are viewed under the same axis and can be grouped under the same set of graphical elements. For instance, we could have a section display “Movie” for the four metrics.

It helps setting the prompt and sliders. Would you create a global dashboard prompt on the “Venue” if only one indicator is viewed per venue? I think not.

It helps understanding design opportunities and behaviour of analysis. Would an indicator be viewed together with another entity? For instance, showing ticket sales for all the movies and all the market on the same page or using a combo box to select a “venue” or “movie” view, one at a time? This would greatly augment the component reuse aspect, thus the ensuing performance.

So here are some of the many things we can do with this new concept. I hope you find them useful!