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

12
Chapter 1
Leading to DW
designs that did
not met BI user
needs
Packaged apps are
especially
challenging data
sources to analyze
IT staff are
comfortable with
data-driven analysis
Unfortunately, without user input to prioritize data requirements and set a man-
ageable scope, these early data warehouse designs were time-consuming and
expensive to build. Also, being heavily influenced by the OLTP perspective of the
source data, they were difficult to query and rarely answered the most pressing
business questions. Pure data-driven analysis and design became known as the
“build it and they will come” or “field of dreams” approach, and eventually died
out to be replaced by hybrid methods that included user requirements analysis,
source data profiling, and dimensional modeling.
Data-driven analysis has benefited greatly from the use of modern data profiling
tools and methods but despite their availability, data-driven analysis has become
increasing problematic as operational data models have grown in complexity. This
is especially true where the operational systems are packaged applications, such as
Enterprise Resource Planning (ERP) systems built on highly generic data models.
In spite of its problems, data-driven analysis continues to be a major source of data
requirements for many data warehousing projects because it falls well within the
technical comfort zone of IT staff who would rather not get too involved with
business stakeholders and BI users.
Reporting-Driven Analysis
Reporting
requirements are
gathered by
interviewing
potential BI users
in small groups
User involvement
helps to create more
successful DWs
Accretive BI
reporting
requirements are
impossible to
capture in full,
in advance
Using a reporting-driven approach, data requirements are obtained by analyzing
the BI users’ reporting requirements. These requirements are gathered by inter-
viewing stakeholders one at a time or in small groups. Following rounds of meet-
ings, analyst’s interview notes and detailed report definitions (typically spreadsheet
or word processor mock-ups) are cross-referenced to produce a consolidated list of
data requirements that are verified against available data sources. The results
requirements documentation is then presented to the stakeholders for ratification.
After they have signed off the requirements, the documentation is eventually used
to drive the data modeling process and subsequent BI development.
Reporting-driven analysis focuses the data warehouse design on efficiently priori-
tizing the stakeholder’s most urgent reporting requirements and can lead to timely,
successful deployments when the scope is managed carefully.
Unfortunately, reporting-driven analysis is not without its problems. It is time-
consuming to interview enough people to gather ‘all’ the reporting requirements
needed to attain an enterprise or even a cross-departmental perspective. Getting
stakeholders to think beyond ‘the next set of reports’ and describe longer term
requirements in sufficient detail takes considerable interviewing skills. Even
experienced business analysts with generous requirement gathering budgets
struggle because detailed analytical requirements by their very nature are accretive:
they gradually build up layer upon layer. BI users find it difficult to articulate