Data Warehousing Requirements

Industry analysts have observed publicly that large-scale decision support systems — data warehouses, data marts, and business intelligence applications — have a dangerous characteristic.

The explanation for this phenomena is straightforward, the more you give people, in terms of data and analytical functionality, the more they want. Demand, where data-driven decision-making is concerned, is insatiable.

This phenomena can be referred to as the Requirements Spiral. Seen from the perspective of the business, no matter how sophisticated, comprehensive, or useful the existing data warehouse is, users perceive it as: infrastructure. It is simply part of the assumed level of service. It’s what is already in place and nothing new.

Demand for data and analytics is relentlessly focused on the new: what decision-makers don’t have, can’t get, and therefore value the most.

Most experienced data warehousing practitioners would argue that the Requirements Spiral has been with us since the data warehousing market first emerged. We began this long and sometimes painful journey collectively from data-indifferent decision-making toward what we now call data driven decision-making. The spiral of rising user expectations has always been with us.

The difference today is the gap between what users expect, and what IT organizations are resourced and funded to provide. This has widened significantly over the past 25 years.

The relatively well-funded and autonomous IT organizations of the 1990s were, by 2000 being told by senior management that the secret to IT success lay in learning how to do more with less. That is, to lower budgets for technology, reduce IT headcount, and to focus on new applications demanded by the business. The message to IT was crystal-clear: do more with less.

Furthermore, after the global economic downturn in 2007, that mantra shifted in a subtle but potentially catastrophic way. Do more with less, do much more with much less.

So the two sides square off. The business demands more from IT than simply maintaining the status quo. IT leadership cries out that they are constrained with fewer resources and a lower budget.

Business units, coping with their own do-much more-with-much-less problems, are unfazed by IT’s dilemma. The Requirements Spiral is everyone’s conundrum.

Big Data

Against that backdrop, the 2011 McKinsey report on big data, which inaugurated the so-called Big Data Revolution, promised to add to the problem.

The report dismisses the hard-won and difficult to-maintain gains in data-based decision-making made by IT organizations over two decades as basic table-stakes in a global game of information based competition. The report identified new data sources, new analytical tools, and a new class of decision-maker — what we are now calling data scientists — as the strategic focus for forward thinking companies. In effect, an entirely new class of demand was created for volumes of data and classes of analytical tools that, prior to 2011, had not been part of most CIO’s portfolios.

In other words, the whole thing was about to get harder.

Enterprise Data Warehouse

Today, many IT organisations tell us that they are less able to respond in timely and cost effective ways to requests for change to their data warehouses and data marts than at any prior time in their organisations’ histories.

They tell us that their project backlogs are growing faster than they can be serviced or cleared. And the requests for “source extractions” — Bill Inmon’s tell-tale sign of rogue Business initiatives — are rising rapidly. More and more, business units have developed shadow IT capabilities and elect to erect data marts and analytical applications for themselves, rather than wait for requested changes to be scoped and delivered into the Enterprise Data Warehouse.

Agile Project Management

A good number of IT organizations tell us that they’ve attempted to adopt agile, iterative methods for project design and build activities, to recoup lost ground with their internal customers. In principle, this is a great idea. But many of these attempts at “getting more agile” have failed to improve the IT organization’s posture vis-a-vis the business. 

Why? Because their data warehouse design-and build platform is built for long-cycle projects. Their tools follow suit, as largely incapable of promoting a rapid development environment, with management left feeling hamstrung by complex sets of requirements that never seem to be right or delivered.

Outsourcing to SaaS Providers

Some tell us that they’re aware of business units that have gone out-of-house, to SaaS-based providers of “business intelligence solutions,” with the hope to get what they want faster than IT can supply it. The reality is that most of these organizations find themselves paying much more, for much less than they could have gotten had they waited for IT to deliver their requirements into a comprehensive centralized data warehouse.

The Role of Management

Finally, many IT organizations tell us of the arrival of new functional units, often headed by a chief data officer (CDO) or chief analytics officer (CAO). These new management roles are chartered with defining and delivering new analytical platforms and capabilities to the organization. Although it’s unstated in the organizational announcements, the implication is that the IT organisation is unable to keep up with the demand from “the business.”

All of these IT organisations are aware that their ability to deliver against perennial, insatiable business demand for new data-driven decision capability is declining. They also realize it is through no fault of their own.

IT Must Deliver at the Speed of the Business

We are doing what we have always done, the way we have always done it. Now, however, we attempt the endeavor with fewer resources, less money, and in less time. It’s no wonder our ability to deliver is declining. We have the ability and the knowledge to deliver what’s required: we just need more money, more skilled people, and time to recover.

And that is the cold, hard centre of the Requirements Spiral. As business leaders see it, time is up, budgets are fixed, and headcount is likely to decline even further unless IT organizations break through the productivity barrier and operate at the speed of the business.

Data Warehousing

This history of difficulty and distrust dates back to the very beginnings of data warehousing. In ‘Building The Data Warehouse’, published in 1991, W.H. Inmon made the observation that:

“The classical system development lifecycle (SDLC) does not work in the world of the DSS analyst. SDLC assumes that detailed requirements are known at the start of the design (or at least can be discovered). However, in the world of the DSS analyst, detailed requirements are usually the last thing to be discovered in the DSS development lifecycle.”

At that time, Inmon advocated a data-driven approach to designing data warehouses, unfortunately many organisations ignored this advice and used a methodology used successfully for ERP or CRM applications, SDLC. Thus was ushered in one of the single most painful and ultimately fruitless of IT decisions in the area of decision support. In some cases it fractured the business and IT relationship to the point of divorce, in many a feeling of distrust has prevailed since. We find organisations whose BI staff will not refer to their data warehouse as a data warehouse in front of senior management because of the experience. Fortunately the majority of today’s organisations have learned from history and have moved away from SDLC.

So why are IT organisations still finding it difficult to maintain their value in the eyes of the business? Aside from SDLC, other methods and practices adopted by IT twenty years ago to build and deliver decision support systems are still largely the same. Of these the most damaging phenomenon at work is artisan thinking.

In the early 1990s, the process of identifying and transforming data sets that were of interest to decision-makers into information that was actually useful required a great deal of ingenuity and technical sophistication.

Source systems were many, varied, and complex. Data models were difficult to understand and interrogate. Many pieces of technology had to be painstakingly assembled and tuned to produce a working data warehouse or data mart. Business Intelligence tools were similarly complex and hard to integrate.

Decision-makers, starved for information, were largely unable to articulate their needs. Requirements-gathering sessions routinely turned into stand-offs. Users answered the question “What information do you need?” with either “Everything” or “What information have you got?”

The technology supplier market was equally unhelpful, offering narrowly-scoped tools and components. They offered little or no architectural guidance in assembling those narrowly-defined components into working systems.

Data Warehouses Built from Scratch

In response, the data warehousing industry developed an approach to designing and building data warehouses that accepted the complexity of the situation as it existed at that time. That approach, which quickly became a common methodology, emphasized:

  • relatively large teams of people
  • working over relatively long periods of time
  • using a complex set of uniquely-configured tools

Data warehouses and data marts were built “from scratch” and each data warehouse or data mart produced was, quite literally, a work of art.

Data Warehouse Tools

Many tools were involved in the process of designing and building a data warehouse: data discovery, logical modelling, ETL, and database tuning. Moreover, each of these tools required dedicated specialist operators and/or developers. The tools had to be manually assembled into a “tool chain” so that each tool could do something, however approximate, with the output of the tools ahead of it in the chain. The tool chain produced little in the way of documentation or shareable metadata.

What was available had to be assembled and maintained manually. Perhaps most alarming was the fundamental goal of the tool chain. It was always assumed that the goal of the process was to take a data warehouse or data mart into production with little or no consideration for future expansion and enhancement of requirements.

Much has changed, since the early 1990s, in the data warehousing industry, but our collective emphasis on artisanal tools, methods and practices has, fundamentally, remained unchanged. We are attempting — and often failing — to solve twenty first century decision-making problems with tools, methods and practices developed a quarter century ago. Is it any wonder that all too often, we’re failing?

Data Warehouse Automation

To break out of the Requirements Spiral, an IT organization has to change its mind-set about the process of producing data warehouses. Firstly, IT must move to a process that allows the adaptive iterative freedom to change that the moving target of business demands. Completing the move to agile methodologies so many have started but so few have been able to complete. 

Secondly, IT organisations must move from an approach that emphasizes the slow and expensive process of artisan craftsmanship to one that focuses on acceleration and automation. Wherever possible, we must replace the mundane and tedious contributions of human labour with software, freeing up resources to focus on what’s important – outcomes for the business. 

In other words, the answer to the dilemma many IT organizations find themselves in is not “Give me more money, more people and more time, and I’ll do what I have done in the past.” The answer is to change how we produce decision support infrastructure to work effectively in a time when we have fewer people, less money and less time.

“It is not the strongest of the species that survives, nor the most intelligent, but the one that is the most responsive to change” - Charles Darwin

This change — from artistry to acceleration, automation and adaptation — is easy to understand and has obvious benefits for IT leadership, but it requires a significant shift in the way that data warehousing teams do their work. More importantly, it requires that those teams adopt new tools and new methods. Forward thinking IT managers, informed about agile methods and aware that new tools exist designed explicitly to automate previously- manual IT tasks must lead this change.

Automation, as a generic IT strategy for recovering and reapplying scarce resource, is not limited to the business intelligence and data warehousing domain. In every area of IT, from desktop and server provisioning to operations, the calls for automation are being issued by industry groups and IT leaders with increasing stridency. In many of these areas, automation promotes task-shifting: the application of scarce IT human assets to more pressing tasks.

In business intelligence and data warehousing, the automation stakes are higher. The shift from artistry to automation in data warehousing promises to provide IT teams and their leadership with a way out of the cost/resource pressure pot. 

Automation with adaptation, however, promises something greater: the opportunity for IT teams to be perceived by their partners in business units as focused, knowledgeable, responsive, and value add.

Data Warehousing


Today, we believe, many senior IT leaders are trapped in the Requirements Spiral. These leaders see that their artisan style of production has made them increasingly unable to keep up with the demands of the business for ever increasing amounts of data-driven decision making infrastructure and applications. The IT organization is falling farther and farther behind in its work and it is too often viewed as an impediment to progress or a roadblock to be circumvented by new groups led by CDOs and CAOs. In the end, IT as we know it, risks evolving into an organization that will operate the technology that other groups within the company have designed and built.

An Integrated Approach

Thoughtful leaders recognize that the way out of the Spiral is to change the IT organizations’ methods and practices and its underlying tools. They must move with a sense of urgency to an integrated approach that emphasizes the automation of otherwise-manual tasks and the acceleration of those tasks that, for whatever reason, cannot be fully automated. They must consider a larger framework that treats all data warehouses, data marts, and analytical applications, in effect, as provisional and continually subject to rework and renovation. Rather than asking the company for something it cannot provide (more time, more money and more people) the IT organization has to take time and cost out of its own production process in order to “catch up” to the business and return to a position as a trusted, valued supplier.

Change Management

The biggest impediment to making this change is not technology supply, a robust market of integrated tools and platforms known as the data warehouse automation market exists today. It is one of the most rapidly growing segments of the data warehouse marketplace. The biggest impediment to the change is the will of IT leadership to drive the change within the IT organization itself, in the face of resistance from data warehousing teams who fear that their jobs are at stake, or that their skills will not migrate effectively to the new methods and models.

Empower People to Do Higher Value Work

We’re told by IT leaders, who have made this change successfully, that the secret to change is the emphasis on transformation from labour to ingenuity. Or, put another way, moving your most valuable resource, highly skilled people, from focusing on automatable, mundane tasks, to tasks that will add more value to the business. Freeing up resources to focus on higher value tasks, when done well, should produce breakthrough business benefits for the organization. This provides companies with comparative advantages in their markets of choice to improve their competitive position and their financial performance.

Unfortunately all too often today, those highly skilled people — like the IT organization itself — are trapped, doing the same old things in the same old manual ways. There is no opportunity to be ingenious; everyone is too busy turning the cranks and walking the treadmills, while slowing down and falling farther behind.

Data Warehouse Automation is the Solution

Data warehouse automation (DWA) frees trapped ingenuity and liberates an IT organization to pursue strategies for differentiating the company through data-driven decision-making. DWA is not just a cost-reduction strategy. It’s a strategy for shifting resources from repetitive tasks to value creation and restoring data warehousing teams to the highest relevance and leadership in their organizations. By doing this DWA is also a force for change of methodology and approach, by reducing disparate toolsets down to a simple paradigm. BI teams are able to implement agile development practices as they should be, short focussed sprints delivering value to the business, rather than a hotchpotch of tools and processes designed for a bygone era of data warehousing. DWA promises to usher in a new phase of decision support infrastructure success for those who have the foresight to embrace it.