OptimalBI | We do cool sh!t with data

Brian Bradley

I recently attended a course titled “Agile Data Warehouse Design Workshop”.
Presented by Lawrence Corr and based on the book “Agile Data Warehouse Design”, written by Lawrence in collaboration with Jim Stagnitto.

Synopsis

The major differentiator of this course is a methodology titled “BEAM*” – Business Event Analysis and Modelling.
BEAM* starts from a business process or processes and teases out the Dimensions and Facts related to the process in a structured and efficient style. By the end of the process you have designed a set of Star Schemas, ready to pass on to the ETL Developers.

My Take on the Course

It is a long time since I last used a structured system design methodology, and that was for building OLTP Systems. In the interim, everything has been done on an individual basis, with no real framework. I have to say that the structured way was far more efficient, as well as repeatable across an organisation. Lawrence does not disappoint.
The BEAM* methodology has been well thought out and aligns very well with the BI star schema style.
It is also worth mentioning that Lawrence is an engaging presenter and kept my attention through the whole course, including the parts which were not new to me.

How it Works

BEAM is very language based. It is designed to collaborate over a white board, it is centred on Ralph Kimball’s Six W’s, plus an extra one to finish the job:

Who
What
When
Where
Why
How and
How Many

The trusty old journalism checklist works equally well for understanding business processes. From my perspective it is a great concept, drawing the discussion well away from technical detail. The details are captured in provided spreadsheet templates in an efficient manner, using a certain amount of shorthand. The outcome is a nicely documented star schema design.

What do I think?

The big question – would I recommend using BEAM? Would I choose to use it myself?
The answer is ‘yes’ to both.
Most organisations which I have touched on in the BI space work on a fairly ad hoc basis. They rely on the BA to do a good job. Which is fine up to a point. A good BA will work in a methodical way and get to the right answers. But not all BA’s are equal. They work in many different ways, in my experience. Requirements are often gathered by technical people who are not necessarily quite so structured. For a mere U$31.28 on Amazon, you can purchase a ready-made, well thought out and disciplined method (Agile Data Warehouse Design by Lawrence Corr with Jim Stagnitto).

Is there anything I didn’t like?

While I fully recommend BEAM*, the book and the Workshop, nothing is perfect. A small complication is that the requirements gathering templates need you to remember a fair number of short hand codes. Great for cramming a lot onto a White Board / Spreadsheet, bad if you have a memory like mine. The real elephant in the room is Kimball Conformed Dimensions. On the one hand, they satisfy “Agile” by encouraging reuse. On the other hand, they can be notoriously difficult to maintain and extend in an “Agile” fashion. There are ways around this, but not included in the book or course.

How to get started