Or so you think.
Now there's a forecast system that's going to be built. It will use the transaction data in your data warehouse for its baseline, and visions of happy prognosticators dance across your mind.
"You are not partitioning history correctly," intones the lead architect. "You are not conforming business descriptions across the organization. Your hierarchies are rigid, and your dimensions are snow-flaked."
Suddenly, you have a big headache.
"I've got 150 reports that are being used weekly," you counter. "It can't be that bad."
"For us to get what we need," croons the architect, "you would have to redesign your data warehouse, and we can't afford to wait."
"Here's what we'll do," he adds mournfully. "We'll take the data we need from your warehouse, add to it, and load it into ours.
"Good," you say. "I don't have to change a thing."
This scenario is not unusual. For most organizations, the first data warehouse initiative is a laborious expedition into the unknown. So much effort has gone into analyzing, extracting, transforming and loading the data, that a huge sense of accomplishment is felt when the data lands in the hands of some users.
Once users get hold of this data, they clamor for more attributes, more reports and more ways to slice and dice the information. The rush is on to deliver without upsetting what's already there.
Before long, there may be several data warehouses that use a core set of the same data, and you cannot ask a question that will easily navigate across all of them.
To prevent this hydra-like growth (or an early death), take the time to give your data warehouse a thorough checkup. This assessment is crucial. It will either validate your strategy for handling the escalating needs of your core and expanding constituencies, or it will point you in the right direction for corrective action.
The key areas to examine are: