My first Publication Agile-Data-Warehouse-Design-eBook | Page 127

106
Chapter 4
Time-box
modelstorming
meetings to four
hours (maximum)
Use an event matrix to
identify the most
important events and
conformed dimensions
Like most agile activity, modelstorming should be time-boxed. For an initial
modelstorm use four hours as a guideline. Reserve two hours for modeling the first
(most important?) event table and its dimensions tables. One hour for modeling
related events on a matrix, and a further hour for prioritizing events and making
sure the most important event(s) and dimensions are modeled in detail. Not
enough time? Don’t overrun. Schedule another.
So far, we have covered how to open a modelstorm, at point A, with the question
“Who does what?”, and use BEAM ✲ tables and 7W data story telling techniques to
model the answer as single event and matching dimensions in great detail. Now we
describe how you get to point B’s implementation decisions using an event matrix
to rapidly storyboard several more events, in just enough detail, to identify the most
important events and conformed dimensions for the next sprint. To show how the
matrix gets you there we shall continue modeling Pomegranate’s order processing
BI requirements.
Adding the First Event to the Matrix
Start an event matrix
by adding the main
clause and
dimensions of
your initial event
Include degenerate
dimensions: they can
be conformed too
Ask if the event
creates any new
dimension values
Start with a blank matrix — download the template from modelstorming.com — and
add the initial CUSTOMER ORDERS event along with its main clause, leaving
several rows above it for previous events and planning (importance and task
estimate). Add its dimensions as columns in BEAM ✲ sequence (who, what, where,
why, and how order), leaving blank columns between W-types for additional
dimensions. As you do so, explain to stakeholders that you are now modeling when
events occur down the page (hence no when columns), and how events are de-
scribed across the page but not how they are measured (hence no how many
columns).
Don’t forget to add any degenerate how dimensions, such as ORDER ID. Even
though these dimensions are not modeled as tables (because they have no addi-
tional descriptive attributes) they still need to be recorded on the matrix because
they can be conformed degenerate dimensions appearing in multiple events. You
will see shortly how important they are for identifying process sequences.
Tick off the dimensions referenced by the event. As you do so, ask stakeholders if
the event can create new values for any of its dimensions. For example, you might
ask:
When a customer orders a product can a new customer be created?
Mark any dimensions that can have new members created by the event (e.g. Cus-
tomer, Delivery Address and Order ID) with a * rather than a tick to record this
significant dependency. When you have finished, the matrix should look like
Figure 4-8.