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

126
Chapter 4
Sufficient Events?
Merge subject
area matrices
to provide a DW-
wide overview of
conformance
After the earlier manufacturing events in Figure 4-6 are added to the sales targets,
order processing and customer support events of Figure 4-14, the matrix should
look like Figure 4-23. If this matrix inspires you to reuse more dimensions, particu-
larly dimensions from process initiating events such as PURCHASE ORDERS or
CUSTOMER ORDERS that could be carried over to their dependent milestone
events, then the matrix is doing its job. It should encourage you to maximize
dimensional reuse to make each event as descriptive as possible. In addition, if the
similarities of the dimensions of PRODUCT SHIPMENTS and WAREHOUSE
SHIPMENTS makes you think that they might actually be the same type of event,
then the matrix is also doing its job. It may turn out that wholesale shipments to
resellers are quite different to retail shipments to consumers: These events might
be handled by completely different systems. Even so, the matrix is again doing its
job in highlighting an opportunity to conform the dimensions of both events, just
in case there is business value in doing so.
The event matrix is a great technique for upholding the agile value of working
software over comprehensive documentation. The event matrix is enough com-
prehensive documentation to help you create working software based on con-
formed dimensions but if you do need more documentation, link to it from your
event matrix spreadsheet cells; e.g., events and dimensions can be hyper-linked
to their BEAM✲ tables or star schema models.
A matrix may
never contain every
event and not every
event it does
contain will be
implemented
The role of the
matrix is to identify
the conformed
dimensions for the
next release
Although the event matrix in Figure 4-23 might be complete enough for several
DW/BI development sprints, is it the complete matrix for the Pomegranate Data
Warehouse? What about customer invoicing and payment events after orders, or
product configuration prior to shipments? What about events in other subject
areas such as HR, finance, R&D? Many of these events may be out of scope for
sometime, or will never capture sufficiently interesting additional details to be
worth measuring.
Rather than initially modeling every possible event on a matrix, agile DW design-
ers concentrate on making the matrix complete enough for the next release. When
a matrix contains enough detail to help prioritize the right events for the next
release and understand their conformed dimensions that will be used again in
future releases, its job, for now, is done.
Put a large version of the event matrix on the wall where everyone can see it.
Regardless of your preferred methods for modeling events and dimensions:
BEAM✲ tables or ER notation, flipcharts, whiteboards, or projected spreadsheets,
viewing more than a few details at once is impossible. When event and dimension
tables cover all your walls, or are buried in spreadsheets, a matrix enables stake-
holders and the DW team to see the entire design at a glance.