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

14
Chapter 1
Figure 1-6
Proactive DW
timeline
Proactive DW/BI
DW/BI has steadily become proactive for a number of business-led reasons:
addresses
operational
demands, avoids
interim solutions
and preempts BI
performance
DW/BI itself has become more operational. The (largely technical) distinction
between operational and analytical reporting has blurred. Increasingly, sophis-
ticated operational processes are leveraging the power of (near real-time) BI
and stakeholders want a one-stop shop for all reporting needs: the data ware-
house.
problems
Organizations (especially those that already have DW/BI success) now realize
that, sooner rather than later, each major new operational system will need its
own data mart or need to be integrated with an existing data warehouse.
BI stakeholders simply don’t want to support ‘less than perfect’ interim report-
ing solutions and suffer BI backlogs.
Benefits of Proactive Design for Data Warehousing
Proactive DW
design can
improve the data
available for BI
Proactive DW
design can
streamline ETL
change data
capture
When data warehouse design preempts detailed operational data modeling it can
help BI stakeholders set the data agenda, i.e., stipulate their ideal information
requirements whilst the new OLTP system is still in development and enhance-
ments can easily be incorporated. This is especially significant for the definition of
mandatory data. Vital BI attributes that might have been viewed as optional or
insignificant from a purely operational perspective can be specified as not null and
captured from day one — before operational users develop bad habits that might
have them (inadvertently) circumvent the same enhancements made later. Agile
OLTP development teams should welcome these ‘early arriving changes’.
ETL processes are often thought of as difficult/impossible to develop without
access to stable data sources. However, when a data source hasn’t been defined or is
still a moving target, it gives the agile ETL team the chance to define its ‘perfect’
data extraction interface specification based on the proactive data warehouse
model, and pass that on to the OLTP development team. This is a great opportu-
nity for ETL designers to ensure that adequate change data capture functionality
(e.g. consistently maintained timestamps and update reason codes) are built into
all data sources so that ETL processes can easily detect when data has changed and
for what reason: whether genuine change has occurred to previously correct values
(that must be tracked historically) or mistakes have been corrected (which need no
history).