Industry analysts have observed publicly that large-scale decision support systems — data warehouses, data marts, and business intelligence applications — have a pernicious characteristic. After initial deployment, the costs of extending and operating these environments scale as fast, or faster, than the growth of their user communities.
The explanation for this phenomena is straightforward, intuitive, and undoubtedly correct. 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 not only perennial. It’s insatiable.
There is another pernicious feature of this syndrome: the Success Conundrum, as we think it should be called. Seen from the perspective of the user community, any given incarnation of the decision support infrastructure is perceived, almost as soon as it is introduced, as having no value relative to those users’ as-yet-unmet needs.
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 Success Conundrum has been in effect since the early 1990s. It was in this era that the commercial 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 problem 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 has widened over the past 25 years.
The relatively well-funded and autonomous IT organizations of the 1990s were, by 2000 or so 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 entitlement, reduce IT headcount, and to focus on new applications demanded by the business. The message to IT organizations 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 became, in 2008 and after, 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 Success Conundrum is everyone’s conundrum, business units and functional groups point out.
Against that backdrop, the 2011 McKinsey report on big data, which inaugurated the so-called Big Data Revolution, added insult to IT injury.
First, 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.
Today, many IT organizations 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 organizations’ histories.
They tell us that their change backlogs are growing faster than they can be serviced or cleared. And the requests for “extractions” — Bill Inmon’s telltale sign of rogue IT initiatives — are rising rapidly. More and more, business units have developed shadow IT capabilities and elect to erect data marts and analytical applications together for themselves, rather than wait for requested changes to be rolled into production.
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 documented sets of requirements that never seem to be right.
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 against their requirements.
Finally, many IT organizations tell us that they’re disturbed by 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 IT organization is perceived as unable to keep up with the demand from “the business.”
All of these IT organizations are aware that their ability to deliver against perennial, insatiable demand, on the part of business and functional groups for new data-driven decision-capability is declining. They also realize it is through no fault of their own.
According to these groups, 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. If we were properly funded and resourced, we would be the most knowledgeable, responsive supplier that business units and functional groups could desire. 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 center of the Success Conundrum. 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.
We had been weathering budget cuts for a couple of years, and we were down to a bare minimum. We had decreasing resources against increasing demands. We were forced to spend a greater proportion of our time and resources on operations, and less time and resources on true business improvements or innovations.
Since there were no big business improvements and no major innovations coming from the IT department, the organization began believing it could cut the budget on this large “cost center”. Lower budgets meant lower capabilities. Lower capabilities meant even lower budgets. Even lower budgets meant even lower capabilities. On and on it goes. Spiraling downward.
Why are IT organizations finding it increasingly difficult to maintain their value in the eyes of the business? Because the methods and practices adopted by IT twenty years ago to build and deliver decision support systems are still largely the same.
Yet there is another phenomenon at work: 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 arcane. 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. Client-side tools were similarly complex and hard to integrate.
Decision-makers, starved for information, were largely incompetent at articulating 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 unhelpful, offering narrowly-scoped tools and components. They offered little or no architectural guidance in assembling those narrowly-defined components into working systems.
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:
Data warehouses and data marts were built “from scratch” and each data warehouse or data mart produced was, quite literally, a work of art.
Many tools were involved in the process of designing and building a data warehouse: data discovery, logical modeling, 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 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.
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?
To break out of the Success Conundrum, an IT organization has to change its mindset about the process of producing decision support infrastructure. We have to 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 labor with software reducing time and cost. In doing so, we can release the contribution of human ingenuity to its fullest potential.
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.
This change — from artistry to acceleration and automation — 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—something they are often unwilling to do. Forward-thinking IT managers, concerned about their organizational credibility and relevance, must confront this latent attitude of resistance. Informed about agile methods and aware that new tools exist in pre-integrated tool chains designed explicitly to automate previously manual IT tasks, managers must lead for change. Subordinates will attempt to argue that:
And the list goes on with similar excuses, all of which are designed to preserve the status quo. “Artists” will strive to reinforce the current artisanal methods at work in the organization as both desirable and productive. Intrinsic data, as compiled by the business, suggests otherwise.
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, 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.
Today, we believe, many senior IT leaders are trapped in the Success Conundrum.
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.
Thoughtful leaders recognize that the way out of the Conundrum 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. That is, they are 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.
According to IT leaders, the biggest impediment to making this change is not technology supply. A robust market of integrated tool chains and platforms that we call the data warehouse automation market exists today. It is one of the most rapidly growing segments of the data warehouse marketplace. No, 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.
We’re told by IT leaders, who have made this change successfully, that the secret to change is the emphasis on transformation from labor to ingenuity. Every IT organization has a finite quantity of ingenuity that should be applied to the company’s most pressing analytical problems. Ingenuity, when done well, should produce breakthrough business benefits for the organization to provide companies with comparative advantages in their markets of choice to improve their competitive position and their financial performance.
Today, that ingenuity — like the IT organization itself — is 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.
The logical consequence of this dilemma is unacceptable. IT management does not want to become the tenders of other groups’ innovations, or compromise the company’s competitive effectiveness. Like their counterparts in operations and infrastructure, data warehousing and business intelligence teams in IT are turning to automation.
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.
“Most of us are aware of business’ unending frustration with IT’s roadblocks to data. But, contrary to a current myth, the answer is not free for all, self-service access by users to every piece of data through some sexy visualization tool. That comes after the data is consolidated, blended, cleansed and certified for use. The creation of a high quality data resource has always been what data warehousing has been about. And that’s what data warehouse automation is about too — but faster, better and more flexible than traditional tools. With data warehouse automation, we can move from IT’s old need — or necessity — to control everything to empowering both business and IT people to each do what they do best. Business defines what data is needed and how it should be analyzed iteratively, with IT capturing the business needs and applying quality and production values in flight.”
The essential feature of data warehouse automation (DWA) is the realization that doing a lot more with a lot less is the new reality for IT organizations. Smart IT organizations, in response to this reality, will seek to spend their scarce human talent (i.e. collective ingenuity) building value that their internal customers within the organization actually perceive to be valuable. Value can be defined as something new, something enabling, or something differentiating for the business. Today, ingenuity is trapped because IT teams are spending most of their time performing routine internally-focused tasks. Many of these tasks are invisible to internal business constituents and therefore not perceived as valuable. But alas, most of these routine tasks are either susceptible to automation (so that no human labor is spent performing them) or acceleration (so that less human labor is spent performing them).
The first rule of data warehouse automation is: spend human resources where they add the maximum customer-perceived value. Period.
To do data warehouse automation well and reap its benefits, IT teams focused on decision-making systems and infrastructure must think differently about their mission within the organization.
Thanks to market consolidation and technological innovation, databases, BI tools, and many operational systems ship with built-in connectivity and data movement features. If you have SQL Server or Oracle database systems, you have a pre-existing collection of data management tools that can be leveraged and, indeed, automated. If you have Teradata systems, you have access to data movement capabilities, powerful parallel loading tools, and a host of automation features. In a data warehouse environment, this means exploiting in-database SQL code generation and data integration features, native scheduling capabilities, and/or third party data warehouse automation tools wherever possible. In mixed data warehouse environments, it means exploiting in-database features in combination with data warehouse automation tools. DWA exploits everything it can, in the environment in which it is employed, in the name of getting more, faster, with less.
Instead of squandering scarce resources on tasks such as spot-coding SQL, writing scripts, and manually managing metadata, strive to get the most out of your human ingenuity to improve existing BI and analytic investments. By all means, use your free resources and their ingenuity to stand up advanced analytic practices that address new paradigms and incorporate new tools such as Hadoop. Data warehouse automation is a program for intelligently automating the manual human interventions that sustain the flow of information and analytic insights that are critical to everyday business decision-making. And those tasks that cannot be, strictly speaking, automated (e.g. the tuning of SQL for performance improvement) are still very much candidates for acceleration. Tasks that once took days or weeks can be performed in hours or days by people who are less skilled than might otherwise be the case. What DWA can’t automate, it accelerates.
A data warehouse automation program requires a change in the tools and platforms an IT team uses to build data warehouses and data marts. DWA tools are integrated. They emphasize both the process of defining, designing, deploying, and managing a data warehouse or mart, and the lifecycle of the system as it undergoes change, renovation, and often migration.
The Data Warehousing Institute’s model for understanding the scope of data warehouse automation platforms helps define the scope and depth of this new platform quite well.
TDWI’s model emphasizes the components of the lifecycle of a data warehouse or data mart and the role that DWA can play. In each phase of the life cycle, one can automate traditionally artisan manual tasks, or accelerate those tasks when they cannot be fully automated.
Moreover, successful practitioners insist that DWA is not generic computer-automated software engineering (CASE), as we’ve known the term historically. DWA is a program you implement, and not a product you buy. Good data warehouse automation tools are an essential part of your DWA program, but they must be applied with strong leadership, a transparent process, and a winning attitude to reap the desired benefits.
Finally, data warehouse automation is, strategically, an acceptance of the critical important role that Big Data and its associated technologies will play in many company’s future decision support infrastructure. We must recognize that Big Data technologies require even more — not to mention more complex — manual work to configure them properly, and to write the code that makes Big Data technologies actually work.
As organizations shift their attention to Big Data and its associated technologies, responsive IT organizations will need to shift resources. This will require an even more rapid and thorough automation of conventional data warehouse tasks that would otherwise be the case. To participate in the organization’s transition to Big Data and advanced analytics, IT organizations need to free up their best, most ingenious data-driven decision-making experts. They need to work with the business units who are drawn to Big Data and its associated technologies and who will be implementing those technologies and making use of that data.
DWA practitioners also argue — correctly — that the application of automation disciplines to Big Data technologies is vital to the effective leverage of those technologies and their associated data sources. Indeed there is a need, now for “big data automation,” “data pool automation,” and “data lake automation,” just as there is for data warehouse automation. Big Data technologies are in fact less well-organized, less well-integrated, less well-provisioned with metadata, and less orchestration-ready than conventional data warehousing technologies and conventional data sources. Big data technologies require much more hand-coding than conventional data warehousing, much more documentation, and much more day to-day intervention.
The relatively clean, well-documented, and stable environments we have enjoyed in conventional data warehousing are largely absent in the Big Data world. One cannot, when all is said and done determine where particular data in the Hadoop “data pool” has come from, let alone whether that data is accurate or safe for particular analytical uses. Nor can we determine, without significant effort, what processes and groups are using a given data set for what purposes, or what impacts changes to, or loss of, that data set would have on the company’s decision-making abilities.
The market is responding with the rise of automated data integration (ADI) technology and with it, bringing the mindset and process orientation present in DWA to a larger environment in which data warehouses and data marts coexist, and are integrated into, Big Data technology infrastructure. Metadata is metadata, regardless of the technology employed to persist data. Decision-making models are decision making models whether they are embodied in dimensional schema or statistical analysis engines. The problems that plague data warehousing today (too few people, too many demands, and not enough time or money) also accrue in the Big Data world.
Data warehouse automation (DWA) is a conscious, intentional program within IT organizations to shift their teams’ focus to adding customer perceived value more quickly and effectively. They use an integrated toolset or platform to automate or accelerate the tasks associated with defining, designing, developing, deploying and operating data warehouses and data marts.
Successful DWA programs not only result in more value delivered, sooner to the business, but also enhances the IT organization’s role as a partner in identifying and constructing value-added solutions that meet the decision-making needs of groups within the business. IT organizations must play a critical role as a source of valuable insight and ingenuity in the application of technologies and data to the company’s decision-making challenges.
The DWA market today is one of the most rapidly growing segments of the data warehousing software market. Led by independent software vendors such as WhereScape, the DWA market emphasizes integrated platforms of IT tools, purpose-built to accelerate and automate the definition, design, development, deployment, operation, and renovation of data warehouses, data marts and other components of a company’s decision support infrastructure.
The chart on the following page summarizes, in each area of that life cycle model, some of the key tasks that can be either automated or accelerated through the use of DWA technologies.
In general, the implementation of data warehouse automation methods and tools allow IT teams to:
respond, in days to business requests for new or enhanced BI systems with accurate and de-risked time, cost and resource estimates. Through this process, the business units’ perceptions of IT responsiveness and mastery improve substantially. deliver completed data warehouses, data marts, and BI environments in far less time than is possible using artisan-based methods and traditional tools. Along the way, IT actively involves thought-leaders within the user community in meaningful, confidence-building ways. The improvement in speed can be substantial, up to an order of magnitude in many cases. Deliverables that enjoy the uptick in speed include dependent objects like data cubes and client tool metadata support, in addition to data warehouse objects such as tables, models, and views.
rework existing data warehouses, data marts, and BI environments, in response to business changes, in hours or days. Sometimes these changes are incremental (e.g. new data elements or BI tools). Sometimes the changes are significant and disruptive, as occurs when source systems are swapped out or business units are merged, combined, or divested.
Organizations choose their DWA platform based on a clear understanding of their current resource allocation problems. Where do they spend most of their time, money, and human talent today in the data warehouse life cycle? Rather than building feature/function comparison matrices to evaluate apparently competing DWA offerings from vendors, DWA platform selection is based on acceleration of value. The match-up to consider is between what an IT organization needs in terms of time, cost, risk reduction, and what particular DWA tools can provide that will deliver reduced cycle time, reduced cost, and improved risk management in specific areas.
The key to successful DWA implementation is: use DWA across projects, instead of in particular technical areas (like database tuning or source system discovery) alone. Accelerating an entire data warehouse or data mart project, from inception to delivery, produces a before-and-after comparison that is striking. You will also gain a perspective of the business beneficiaries that is undeniable and tangible. You will create advocates for the DWA-enabled IT teams within the business units and functional groups.
The project chosen should, of course, mesh well with the strengths of the DWA platform you have chosen for use within your organization. The single most important criterion for selecting your first DWA projects, however, is business visibility. The first few projects you choose as targets for DWA automation and acceleration should be projects about which your internal customers care a great deal — projects they believe are critical to their success, in which the time-to-value factor (your ability to deliver value rapidly) is particularly important.
The transition from artistry to automation is not confined to IT organizations’ data warehousing teams; it’s happening everywhere in successful IT organizations. The Success Conundrum is in full force in companies of all sizes and in all industries.
In your data warehousing, business intelligence, and big data teams, automation has the potential to free scarce resources for high-value tasks and to enable your teams to rebuild cordial, collegial relationships with internal customers in business units and functional groups.
Doug Johnstone, an expert in IT automation noted in early 2014 that “IT automation continues to be one of the top 5 priorities for CIOs.” Further, he remarked that when IT automation projects fail, it is for one or more of five primary reasons:
As we’ve suggested in this document, DWA is:
Successful DWA initiatives begin with IT leadership that understands the need for change and is committed to making the change stick.
There will be team members, as there always are, who resist the move to data warehouse automation and who want to preserve the status quo, but the DWA transition has to proceed at the pace of the leaders, not the naysayers. Consider overcoming a subordinate’s fear of change by introducing a new concern: the fear that they may be left behind in the organization’s aggressive shift from artistry to automation.
Success in data warehouse automation initiatives belongs ultimately to the leadership of data warehousing and business intelligence teams. We should focus on measuring the change we expect to see: more customer-perceived value, delivered faster with fewer resources and less rework. Time, cost, and risk, all reduced through data warehouse automation.
Your data warehouse automation software vendor needs to do more than provide you with robust DWA software.
As your organization makes the transition to data warehouse automation, you should expect to be able to rely on your DWA supplier both for expertise in implementing data warehouse automation (particularly during your first few, critical projects using DWA) and for advice and guidance as your DWA capabilities mature.
Big. Data. Warehouses. Right. Now. That is WhereScape’s mission.