Feeling out of your element, dude? Let me explain. Photo: Ginger Williams-Cook
We’ve been blogging a lot recently about AgileBI, BEAM✲ and Modelstorming, and we use those terms somewhat interchangeably. I’ll use this post to help you through the maze of terminology.
The first thing to note is these terms are a hierarchy: each fits nicely inside the next. Modelstorming is one of the techniques used in BEAM✲, and BEAM✲ is one of the methodologies we use to deliver projects using AgileBI.

AgileBI is a framework for fast delivery of data projects

Data warehousing and business intelligence projects have predominantly been managed using a “waterfall” framework. While designing everything up front works well for construction projects, data projects are different. Not only do customer requirements change during the process (that’s standard), the raw material (data) changes too. That makes whatever you build obsolete quite quickly, unless you build it expecting change.

AgileBI manages this risk in two ways: just-enough-design-up-front so we can quickly build something of provable value, and a set of interlocking methodologies that enable faster iterations. The first of these is BEAM✲.

BEAM✲ delivers requirements for data projects through conversation

BEAM✲ stands for Business Event Analysis and Modelling, and it’s the methodology laid out in Agile Data Warehouse Design by Lawrence Corr and Jim Stagnitto.
We searched for years for a better way to gather requirements for data warehousing and business intelligence, because long descriptive documents and mocked up reports just weren’t working. In 2014 we found our saviour in BEAM✲ and converted quickly! In fact we love it so much we built a one-day training course and recently hosted Lawrence at OptimalHQ for his three-day course.
Three things distinguish BEAM✲ in our minds:

1. It’s a common language for business users, BAs, data modellers and ETL developers. Everybody’s needs are met by the same set of artefacts, reducing the risk of mistranslation across layers of the business. Business events are modelled separately, as a function of the entities participating and attributes of those entities, all starting with the simple question, “who does what?” Easy to answer.
2. It’s inherently iterative from the very beginning. We couldn’t very well become an AgileBI practice and then still gather requirements for 6-12 months, right? With AgileBI we deliver a data warehouse slice-by-slice, which means customers see value early and look good to their stakeholders. To iterate we have to get them to prioritise, and BEAM✲ provides techniques to help.
3. It’s built on a collaborative foundation. All very well to have a common language that helps you iterate, but what if interactions between the stakeholders remain document-bound and adversarial? Taking mushy user wishes and turning them in to beautiful reports requires intense creativity, which means you need a way to generate lots of ideas (like brainstorming) and pour them quickly in to a useful structure (like data modelling). BEAM✲ has just the trick: Modelstorming!

Modelstorming = Data Modelling x Brain Storming (= Fun documentation)

When I blogged about Modelstorming the first time round, I said “Modelstorming = Data Modelling + Brain Storming”, but that was before I attended Lawrence’s training. Since writing the book in 2011-12, Lawrence has spent more time developing the collaborative side of BEAM✲, and now I can safely say I was wrong.
Modelstorming isn’t just the “best of both worlds” from data modelling and brain storming added together, it’s multiplicative: the best bits of data modelling are made even better by brain storming and vice versa. Strange things start to happen: business users start saying ‘this looks like us’ and developers say ‘that looks like the data’.

Lawrence took us through many modelstorming exercises, and every time we used a whiteboard to lay out a structure (in this case the model canvas) and post-it notes to move attributes and entities around. Hopefully this makes it obvious why BEAM✲ and its Modelstorming technique is such a perfect fit for AgileBI: it’s fast, flexible and fun. And at the end you get usable documentation of a data model you built directly with the business.
So to round this all out and remind you how these Russian dolls fit together:

• AgileBI is our framework for fast delivery of data projects
• BEAM✲ delivers requirements for data projects through conversation
• Modelstorming structures conversation so business users and data people get what they need to deliver

Keep asking better questions (like “who does what?”)
Shaun
You can book your place on the next Agile Data Warehouse Design Masterclass here.