Why BEAM shrinks the model

BEAM has done more to shrink my Power BI projects than any modelling trick I could teach you. Ten minutes at the whiteboard, and the grain, the definitions and the filter panel collapse to a fraction of what the team expected. If you ask me, that is the biggest saving I can point at in the field, and almost nobody uses BEAM by name.

A fortnight ago I argued that data isn’t complicated, we made it that way: most of the complexity in a BI environment is manufactured upstream, in decisions nobody hosted. This piece is chapter two. The discipline that stops the manufacturing has a name, a book and a publication year, and it fits on one whiteboard.

What BEAM is

Lawrence Corr set BEAM (Business Event Analysis and Modelling) out in “Agile Data Warehouse Design”, written with Jim Stagnitto and published in 2011. The move is small and structural: you start a requirements session from a business event, something that happens in the operation (a shift gets staffed, an order ships, a complaint gets resolved), rather than from a report mock-up or a KPI wish list. For any event, you name the 7Ws: Who, What, When, Where, Why, hoW and hoW many.

Three of them do most of the work. Why is the decision this event should improve, Who owns that decision, and hoW many is the signal that tells you the decision actually improved. The other four make the event concrete enough to model. That is the entire method, which is precisely why it survives contact with a real meeting room.

The seven Ws, walked

On the whiteboard I walk them in this order, and each one closes a door that scope creep usually walks through:

• Who puts named people around the event: the customer who orders, the planner who staffs the shift, the manager who approves the exception. The Who that matters most downstream is the decision owner, because the filter panel will end up serving that one person.
• What names the thing the event handles: the product, the ticket, the shift. Saying it out loud flushes out the vocabulary the organisation has been using loosely for years.
• When pins the rhythm of the event. Once the room agrees a shift is staffed weekly, the refresh conversation stops being a matter of taste (“real-time, please”) and becomes a property of the event.
• Where locates it: branch, channel, region. If nobody intends to act differently per location, Where just saved you a dimension.
• Why is the decision this event should improve. It is the W almost every requirements session skips, and the one every definition downstream inherits from.
• hoW describes the way the event comes about: the route, the channel, the method. It earns its place the moment the decision owner wants to compare ways of working.
• hoW many is the measure the event moves. This is where a fourteen-KPI wish list shrinks to the one signal that tells the owner something improved.

A requirements session, replayed

I have sat in enough versions of this meeting to replay it as one composite. An operations team asks for one dashboard to see everything. Taken literally, that sentence becomes a six-week scoping loop: fourteen KPIs, three filter panels, six pages, and a refresh debate that outlives the sprint. Taken through BEAM, the same sentence collapses in ten minutes. The event is a shift getting staffed. The Why is a decision the team was already circling: do we keep running this shift pattern. The Who is the operations lead who owns the roster. The hoW many is staffed hours against planned hours.

The dashboard that serves that brief is small, and nobody misses what is not on it. The model behind it has a grain anyone in the room can say in one sentence: one row per staffed shift. That is what “collapse to a fraction” means in practice: a decision finally named before anything got built.

From whiteboard to Power BI

Once Why, Who and hoW many sit on paper, the mapping into Power BI or Fabric is close to mechanical. The grain follows the event, one row per staffed shift or shipped order, and the star schema follows the grain. The definitions inherit the Why: “flexed hours” means what the shift-pattern decision needs it to mean, written down once, owned by someone with a name. The filter panel serves the Who, scoped to the things that person can actually change. The visuals serve the hoW many, which puts the signal on the front page and makes everything else earn its place. Every downstream choice becomes a small decision instead of a political one.

DoGoDa uses BEAM in engagements for exactly that reason: efficient in delivery, effective in impact, no corporate theatre. The framework is Corr’s, not mine, and that is part of the appeal: the discipline comes from a 2011 book that has aged better than most of the tooling it predates, and adopting it costs a whiteboard and an hour of honesty.

Put three questions on the whiteboard

Read Corr’s book (“Agile Data Warehouse Design”, Lawrence Corr and Jim Stagnitto, 2011). Before the next Power BI or Fabric project opens, put three questions on the whiteboard and refuse to move on until each has a one-sentence answer: which decision should get better, who owns that decision, and how will we know it improved. From what I have seen in the field, everything teams argue about for weeks falls into place behind those three sentences, and the model that follows is smaller than anyone in the room expected.

Happy to think this through with you.