In the summer of 1969, the United States landed two men on the moon and returned them safely home. The Apollo 11 flight was the culmination of the efforts of over 400,000 workers and the manifestation of an investment that reached a peak of over 50 cents per week for every man, woman and child in the country.

NASA had a long series of Apollo flights laid out, 18 in all. These were to be quickly followed by the space station and then a manned flight to Mars. The future seemed endlessly bright and infinitely promising for NASA and for every boy who dreamed of growing up to be an astronaut.

But soon, all too soon for the space enthusiasts and the entire aerospace industry, the bloom came off the rose. Within a few more moon landings, Congress was pondering the unponderable: "Just why are we funding this project, anyway?" The Apollo program soon fell victim to the budget ax, well short of achieving the lofty, elegant, scientific goals set out for it. Although there was no technical reason for ending the program (in fact, new discoveries were being made on each flight), the program became politically untenable and, thus, unsustainable.

Fast forward to the mid-nineties. A five billion-dollar manufacturing company spends a couple of years and over four million dollars on the initial stages of a data warehouse. The IT-driven project is unveiled with great fanfare. For the first time, users have access to integrated information from disparate operational systems. The data is reasonably clean, but terribly hard to get to. The normalized design forces users to intimately know the contents of scores of tables. The views used to hide the joins between tables leave the users with wildly varying performance for seemingly very similar queries. Beyond that, it slowly dawns on the user community that the "generalist" data set, while impressive in breadth, doesn't really solve 100 percent of anybody's problem. The business is still relying on a few columns from a handful of mainframe reports and the usual mix of stand-alone data islands and spreadsheets to run the business.

After a few years, a new management regime comes on board and reviews all ongoing expenses and programs. It discovers the still uncompleted data warehouse, costing hundreds of thousands of dollars annually to maintain with a user base of about a dozen hard-core analysts. It doesn't take any advanced math to do the amortization calculation on that size user base, and the project is quietly suffocated in its sleep.

Lesson? Don't build Apollos. If you want to have a sustainable data warehouse or data mart system, you must build specific solutions to specific business pain. The initial euphoria of the user community in response to finally getting access to some data is not sufficient to sustain a maintenance-hungry data warehouse or data mart system. Just as the attention of the U.S. public and elected officials was quickly diverted by the turmoil of the late sixties and early seventies, your business and its leaders will soon be drawn to battle by the day-to-day challenges of typical business life. Only if you are providing a 100 percent solution to life-threatening pain will your system achieve "mission critical" status and continue to survive and thrive.

How do you achieve this goal? Here are some quick pointers:

Build to pain. Do not build any data mart or data warehouse system except in response to specific, definable, discrete pain that can be 100 percent solved by tabular data.

Scope small. Start with very, very small scope and build iteratively from there. Don't try to build the entire finance data mart as your first or even second step. Completely solve a critical and discrete piece of the grand problem first and then expand in small, measured steps from there.

Make someone a hero. Identify life-threatening pain, build a 100 percent solution and save someone's life. Sit next to them for as long as it takes to solve the problem and relieve the pain, thus making them a hero to the business.

Leverage that success across the business. Use the hero's example of how the data mart/data warehouse system can solve specific problems for the business to build and leverage support for ongoing efforts. Market relentlessly.

Manage expectations. Do not let the business get on a runaway expectation binge. If you leave them to their own devices, they'll have the data warehouse curing the common cold long before you even pilot your first data set. Continually drive home the message of specific relief to specific pain.

Build measurable solutions. You can't leverage the success of a solution that is unmeasurable. Build only solutions for which you can measure the success or failure with discrete metrics. For instance, don't build a solution to "customer satisfaction" problems if your business doesn't have a widely respected way to measure that metric. Stick to dollars and cents for your first few iterations. You must be able to return to the business with a solid example of success using measures the business understands.

If your only goal is to deliver an integrated source of read only, clean, detailed, historical data with varying levels of aggregation, you will quickly find yourself with little left but a mylar flag hanging over a lifeless lunar landscape. Today's world demands specific solutions to specific problems. Note the deliverables of NASA's current efforts: specific goals for specific research. Make sure you are emulating their approach. Don't build Apollos.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access