It’s not a stretch to say that data warehouses are maturing. Most of our clients’warehouses and marts have not only reached adulthood, many are showing their age. This has prompted some executives and business users to inquire about their retirement. Read on to see whether or not predictions of your data warehouse’s demise are premature.
In consulting with companies on their data warehouses over the past 20 years, I’ve witnessed the evolution of data warehouses from a technology proof of concept reserved for the “early adopters” to a widespread solution found, in one form or another, in most of today’s companies. Information has gone from a luxury to a must-have for these companies, and thus their IT environments have likewise evolved to support data delivery. With this evolution comes the assumption of the data warehouse as a commodity. Data warehousing is simply not as sexy as it used to be, and many arehouses and marts are showing their age. Outdated ETL processes, shaky logical data models, slipshod business requirements, and an emerging “back burner” approach to new BI needs have put many otherwise valuable data warehouses in peril.
How does your data warehouse measure up? This report introduces five signs that indicate your data warehouse or mart might need help:
1. No description of the overall role of the warehouse People assume—and we know what that means!—that the data warehouse is fulfilling a stated purpose, be it to integrate cross functional data, or to serve as the system-of-record for critical data subject areas like Customer. Although the warehouse may be operating well and providing data to a range of business users who are making powerful and differentiating business decisions, if there is no consensus around its purpose, it’s likely to be put on the chopping block when the inevitable IT budget cuts are taken up. I once sat in a meeting where an executive got no answer to the question, “What’s the EDW doing for us that it didn’t do last year?” After an uncomfortable silence, someone spoke up and added that new compliance measures were going to drive the need for data audits from the warehouse. Everyone breathed a sigh of relief, and the executive erased the data warehouse from her list. You can be sure, though, that the team convened the next day to come up with a mission statement and application inventory for the warehouse. Better late than never.
2. Lack of consistent business requirements To practitioners who have been around data warehousing since the early days, this one is what Baseline Partner Jill Dyche calls “an old standby.” We learned the hard way that a business-driven data warehouse—in which the data answers key business questions enabling end-users to take quick business action—is one of the basic enets of a sustainable data warehouse.
You’d be surprised at how few companies actually create and maintain business requirements for BI applications in a consistent and repeatable way. A formal requirements definition process enlists usually reluctant business people to become involved in defining new information capabilities for the enterprise. It also makes it easier to incrementally extend an existing environment with new requirements to add functional capabilities. In our Data Warehouse Scorecard projects, Baseline actually maps the clients’ requirements against a comprehensive set of best practices. These include a solid overall requirements definition process; differentiating between business and data requirements; and making requirements activities iterative. The exercise usually illustrates that companies aren’t doing as good a job as they think they are when gathering and documenting BI business requirements.
3. Few internal checks and balances You can usually spot a data warehouse development team that is under fire. They hoard project plans and don’t publicize successes. They aren’t user focused. They don’t really answer to anyone. Most of our clients now have some sort of a governance body in place that establishes accountability measures for a range of IT projects, including the data
warehouse. Governance committees not only sign off on new BI business cases, they approve capital expenditures and upgrades, rendering it easier for the data warehouse to deploy value to the business over time. This committee needs to understand how the data warehouse has delivered value in the past—back to the concept of internal PR!—so that it can approve its future growth. There are other checks and balances involved in the data warehouse. Data auditability, security, and control are common and often high-profile concerns. The data warehouse development team should be beholden to a Chief Security Officer or a privacy czar for the deployment and use of company-sensitive information.
4. Rigid and inflexible infrastructure You’ve probably heard about a data warehouse that can’t support end-user, ad-hoc queries, or one that can only support ten concurrent queries simultaneously. Many of these data warehouses have hit the funding wall and are thus constrained by inadequate resources. (Sorry, but I have to bring up that all-important internal PR on this one. If the value is easily perceived, funding is probably flowing.)
However, other data warehouses were simply built in an inflexible and rigid way. Bad designs, poor ETL processes, technologies that can’t scale, or standards and conventions that have become “religion” can reduce the data warehouse to a mere technology platform for discrete processing. We recently asked a Scorecard client, “If a new, high-profile business initiative required the addition of a dozen new tables and a few hundred gigabytes of data from a handful of source systems, would the work take weeks, months, or years?” The quantified answer isn’t as interesting to us as the reasons why, indicating the problem areas and the potential fixes.
5. Nothing new It doesn’t matter how valuable your actuarial reporting is, or the fact that you can match your customers with the products they’ve purchased. If the data warehouse isn’t adding business value in a regular and visible way, it will eventually be at risk. Sure, as long as you have a consistent and updated return-on-investment story, you’re probably safe for now. But the constituency will take you for granted and people’s attention will wander to the technologies or projects they perceive are adding bang for the buck. The data warehouse must be perceived to be continuously creating value, be it through the support of new business analytics, the deployment of new data, or the ability to take fresh and deliberate business decisions as a result of data inquiry. If no one has this opinion, the data warehouse is just another isolated island in a long archipelago of technologies. In a follow-up article, I’ll suggest some tips and techniques for rejuvenating an aging data warehouse. Some may need major surgery, while others may only require a simple “nip and tuck.”
SOURCE:http://www.baseline-consulting.com/uploads/BCG_pub_5SignsOfAgingDW_2009.pdf
In consulting with companies on their data warehouses over the past 20 years, I’ve witnessed the evolution of data warehouses from a technology proof of concept reserved for the “early adopters” to a widespread solution found, in one form or another, in most of today’s companies. Information has gone from a luxury to a must-have for these companies, and thus their IT environments have likewise evolved to support data delivery. With this evolution comes the assumption of the data warehouse as a commodity. Data warehousing is simply not as sexy as it used to be, and many arehouses and marts are showing their age. Outdated ETL processes, shaky logical data models, slipshod business requirements, and an emerging “back burner” approach to new BI needs have put many otherwise valuable data warehouses in peril.
How does your data warehouse measure up? This report introduces five signs that indicate your data warehouse or mart might need help:
1. No description of the overall role of the warehouse People assume—and we know what that means!—that the data warehouse is fulfilling a stated purpose, be it to integrate cross functional data, or to serve as the system-of-record for critical data subject areas like Customer. Although the warehouse may be operating well and providing data to a range of business users who are making powerful and differentiating business decisions, if there is no consensus around its purpose, it’s likely to be put on the chopping block when the inevitable IT budget cuts are taken up. I once sat in a meeting where an executive got no answer to the question, “What’s the EDW doing for us that it didn’t do last year?” After an uncomfortable silence, someone spoke up and added that new compliance measures were going to drive the need for data audits from the warehouse. Everyone breathed a sigh of relief, and the executive erased the data warehouse from her list. You can be sure, though, that the team convened the next day to come up with a mission statement and application inventory for the warehouse. Better late than never.
2. Lack of consistent business requirements To practitioners who have been around data warehousing since the early days, this one is what Baseline Partner Jill Dyche calls “an old standby.” We learned the hard way that a business-driven data warehouse—in which the data answers key business questions enabling end-users to take quick business action—is one of the basic enets of a sustainable data warehouse.
You’d be surprised at how few companies actually create and maintain business requirements for BI applications in a consistent and repeatable way. A formal requirements definition process enlists usually reluctant business people to become involved in defining new information capabilities for the enterprise. It also makes it easier to incrementally extend an existing environment with new requirements to add functional capabilities. In our Data Warehouse Scorecard projects, Baseline actually maps the clients’ requirements against a comprehensive set of best practices. These include a solid overall requirements definition process; differentiating between business and data requirements; and making requirements activities iterative. The exercise usually illustrates that companies aren’t doing as good a job as they think they are when gathering and documenting BI business requirements.
3. Few internal checks and balances You can usually spot a data warehouse development team that is under fire. They hoard project plans and don’t publicize successes. They aren’t user focused. They don’t really answer to anyone. Most of our clients now have some sort of a governance body in place that establishes accountability measures for a range of IT projects, including the data
warehouse. Governance committees not only sign off on new BI business cases, they approve capital expenditures and upgrades, rendering it easier for the data warehouse to deploy value to the business over time. This committee needs to understand how the data warehouse has delivered value in the past—back to the concept of internal PR!—so that it can approve its future growth. There are other checks and balances involved in the data warehouse. Data auditability, security, and control are common and often high-profile concerns. The data warehouse development team should be beholden to a Chief Security Officer or a privacy czar for the deployment and use of company-sensitive information.
4. Rigid and inflexible infrastructure You’ve probably heard about a data warehouse that can’t support end-user, ad-hoc queries, or one that can only support ten concurrent queries simultaneously. Many of these data warehouses have hit the funding wall and are thus constrained by inadequate resources. (Sorry, but I have to bring up that all-important internal PR on this one. If the value is easily perceived, funding is probably flowing.)
However, other data warehouses were simply built in an inflexible and rigid way. Bad designs, poor ETL processes, technologies that can’t scale, or standards and conventions that have become “religion” can reduce the data warehouse to a mere technology platform for discrete processing. We recently asked a Scorecard client, “If a new, high-profile business initiative required the addition of a dozen new tables and a few hundred gigabytes of data from a handful of source systems, would the work take weeks, months, or years?” The quantified answer isn’t as interesting to us as the reasons why, indicating the problem areas and the potential fixes.
5. Nothing new It doesn’t matter how valuable your actuarial reporting is, or the fact that you can match your customers with the products they’ve purchased. If the data warehouse isn’t adding business value in a regular and visible way, it will eventually be at risk. Sure, as long as you have a consistent and updated return-on-investment story, you’re probably safe for now. But the constituency will take you for granted and people’s attention will wander to the technologies or projects they perceive are adding bang for the buck. The data warehouse must be perceived to be continuously creating value, be it through the support of new business analytics, the deployment of new data, or the ability to take fresh and deliberate business decisions as a result of data inquiry. If no one has this opinion, the data warehouse is just another isolated island in a long archipelago of technologies. In a follow-up article, I’ll suggest some tips and techniques for rejuvenating an aging data warehouse. Some may need major surgery, while others may only require a simple “nip and tuck.”
SOURCE:http://www.baseline-consulting.com/uploads/BCG_pub_5SignsOfAgingDW_2009.pdf
0 comments:
Post a Comment