enterprise license renewal/true-up or an impending end-of-life event for one
of the core technologies. In these situations, it is not too difficult to make a
convincing financial case. An ROI analysis will often demonstrate the potential
reduction in total cost of ownership (TCO), as a result of annual cost savings
amounting to millions of dollars.
Deep Entrenchment
The many large teams and highly skilled people who continue to care for and
feed the data warehouse octopus have no real interest in venturing into the
unknown. Senior and mid-level management are uncomfortable with starting
an enormous undertaking termed “data warehousing modernization.” Without
diligent education, awareness and change management, it will be hard to over-
come this resistance within a company.
Fear of Disruption
For many years, the tentacles of the data warehouse octopus have reached far
and deep into the organization. Some important processes, such as the
labor-intensive, multi-week madness of generating financial reports, have
been built around the limitations of the data warehouse. Without a clear strat-
egy, merely the possibility of change and its consequent disruption makes sea-
soned IT directors weak at the knees.
Organizations which have embarked with us on such a journey first take a stra-
tegic pause and invest in building a careful roadmap that anticipates potential
challenges and mitigates risks.
A Case for Modernization: Beyond the Obvious
Gerry Fierling, a colleague from my days as a Microsoft Senior Product Man-
ager for Business Intelligence, could distill the essence of a complex situation
into a small, intriguing sentence. He used to say:
“The biggest reason behind the
failure of a data warehouse is its success.”
What Gerry meant was that as more people utilize the reports and feeds from
the data warehouse, more innovative usage requirements crop up. Many of these
new requirements can’t be supported by our unruly old octopus, because it’s
almost impossible to design a data warehouse that anticipates all possible future
access patterns. The moment you commit to a structure--a relational data
model, to be specific--you’ve planted the seed for future dissatisfied users,
whose requirements won’t be supported without sticking some amount of plas-
ter and glue onto the solution.
“Schema on Read” Rather than “Schema on Write”
The concept of “schema on write,” which means committing up front to a struc-
ture to store data, is inherently limited to a set of initial and some future use
22 | THE DOPPLER | SPRING 2017