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

Modeling Business Events
Customer orders a quantity of products, on order date, for delivery on delivery due
date, from salesperson at sales location, for delivery to delivery address, for revenue,
on promotion with discount using order ID.
57
The generic
customer orders
story
The Next Event?
Having fully described the details of your initial event, you should model the
dimensions they represent before moving on to other events. This is exactly what
stakeholders will want you to do because although they may find the details dis-
covered so far to be fascinating, they will want to know that they can analyze events
using many more descriptive attributes. If stakeholders provide you with lots of
detail about detail this is a sure sign that they are keen to define the dimensional
attributes they will need to aggregate and filter the atomic-level business events to
produce interesting reports — and that is exactly what you learn how to do in
Chapter 3. Having modeled the
In subsequent modelstorming iterations, when you have established a library of
dimensions, stakeholders will want to move directly from event to event, rapidly
telling event stories by reusing common details (dimensions) and examples. This is
a habit that you want to encourage early on by using the event matrix techniques,
described in Chapter 4. When you already
When you and your stakeholders get the hang of telling event stories, BEAM ✲ can
proceed at a storming pace, describing many events in quick succession but you
should be careful not to model too many events at the story level. It is a balancing
act. Stakeholders need to model multiple events, to describe their cross-process
analytical requirements and be able to prioritize the most important event(s) for
the next release — not necessarily the first event(s) you discover when modelstorm-
ing. However, telling many more detailed event stories than can be implemented in
the next sprint is unnecessarily time consuming and can create unrealistic expecta-
tions of what will soon be available. It can also lead to the dreaded BDUF (Big
Design Up Front) that does not reflect the business realties, changed requirements
and available knowledge when it is eventually implemented.
You should reserve event stories for just-in-time (JIT) modeling of the detailed
data requirements for your next sprint/iteration/release depending on your agile
development schedule. Look to Chapter 4’s JEDUF (Just Enough Design Up Front)
techniques for modeling ahead to (even more rapidly) create higher-level models of
the events in future releases. These models provide just enough information to help
stakeholders decide the best events to model in detail now, and help you design
more flexible versions of those events: ones that will require less rework in future
DW iterations.
first event you
should model its
matching
dimensions next
have a library of
common dimensions
you can quickly move
to the next event