IBM Data Warehousing and Business Intelligence
Content
TechRepublic Resource Guide
Data warehousing and business intelligence
Contents
Eight strategies for delivering business intelligence on the Web ........................................... 2 These strategies will help companies ensure they are distributing the kind of high‐quality, actionable BI necessary to make real‐time business decisions. Use analytics for strategic business information implementation ......................................... 4 Strategic business information can revolutionize business analysis and performance monitoring. Find out what you need to do to implement it in your company. Making the operational case for data warehousing............................................................... 6 A data warehouse will be a bargain and a powerful strategic tool that will give your company a competitive edge... but first you need to convince your organization's decision makers. Here's how to make your case. 10 ways to begin a data warehouse project .......................................................................... 8 IT departments typically launch data warehouse projects without input from business partners, building the business case themselves. But what steps should you take once the project gets greenlighted? These pointers will help you get off on the right foot.
Sponsored by
Page 1 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
Eight strategies for delivering business intelligence on the Web
These strategies will help companies ensure they are distributing the kind of high‐quality, actionable BI necessary to make real‐time business decisions.
Businesses have mastered using the Web as a communication tool, and with good reason. The Internet has proven to speed connectivity between disparate organizations and enable a mobile workforce. Yet leading organizations are realizing that using the Web channel to communicate business intelligence (BI) in near real‐time fashion supersedes its previous use as an information dissemination and collaboration tool. Not so long ago, paper reporting was distributed on a monthly, or less‐frequent, basis. As business users became more and more technology‐savvy, reporting became more "downloadable" on demand. A step in the right direction in terms of flexibility, yet this had each user slicing and dicing data as he saw fit to find hidden treasure in the information. Most individual employees have neither a full view of corporate objectives, nor the expert knowledge or the time to dig for critical information in raw or even summary data. When it comes to delivering BI, the goals should be accessibility and clarity—not flexibility. End users should not have to wonder how to find the information that they are looking for, and what the information they are looking at means. This focus is further heightened when new and less sophisticated delivery platforms are considered; for example, mobile devices are not equipped to handle large amounts of data manipulation, but are perfect to receive frequent updates of succinct business intelligence. To succeed in today's competitive, fast‐paced business environment, it is imperative that the right content is aggregated and delivered to the right people at the critical moment when a decision must be executed. The following eight strategies will help companies ensure they are distributing the kind of high‐quality, actionable BI necessary to make real‐time business decisions.
#1: Pick the best delivery vehicle for your audience and your data
Core metrics that users need to develop a quick and clear understanding of the organization's state of health should not exceed five to eight numbers. Typically, such information is not intended to be printed and taken to a meeting, and is therefore well suited for placement on a dashboard, mobile device or in a pagelet on a portal page. Detailed reports, on the other hand, are better looked at on paper and should be provided in document format, such as PDF or Excel. Rendered documents provide much more control over the appearance of a printed report versus HTML Web pages.
#2: Integrate the presentation layer
A BI solution is often built as an add‐on component to the transactional system that generates much of the data. Users who work with the transactional system want access to reports from where they need it— from within the application—and are much less likely to navigate to a different web site that would invariably come with a different user experience. Since the value of the reports depends directly upon a user’s ability to locate, analyze and use the information skillfully and appropriately, we recommend that the reports become part of the application’s user interface. Furthermore, providing direct links to important reports from key locations on the interface will give you tighter control over where the reports appear and to whom.
#3: Integrate the security layer
In order to effectively integrate the presentation layers of your report delivery application and your transactional application, it is necessary to integrate security layers as well. One way to accomplish this is a true integration with shared user accounts. However, this approach can be complicated if either side
Page 2 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
uses proprietary security. A simulated integration where the application authenticates with the reporting server through a service account is comparably simple and straight‐forward to implement. In this scenario, the application proxies all requests to the report server and streams the results back to the client. This has the added benefit that a user does not need to access the report server directly so that it can be hidden behind a firewall. A reference implementation of a Java proxy for SQL Server Reporting Services is described in [1].
#4: Customize the presentation for target devices and user roles
There is great appeal to the idea of making critical business information available to decision makers anywhere in the world, using current data and not depending on any additional infrastructure other than a cell phone or PDA. Yet, as previously noted, clarity and accessibility become even more important for mobile device access. Full‐scale BI reports are too ungainly to be delivered to the small screens of handheld devices, and cell phones don't come with sophisticated input devices. Therefore, BI reports for wireless devices should be limited to a set of key performance indicators or a dashboard. In addition, navigation must be cut down to what is absolutely necessary.
#5: Target reports to users
If access to reports is integrated into a transactional application, parameters can be passed to the report server that reflect the user's role selection, current navigational context, and other values that a report can use to create a targeted and customized view of the data. For instance, if the application maintains some sort of organizational tree and users can navigate from the corporate level to regional and branch office levels, the reports can show data for the currently selected node in the organization. The user does not have to navigate down to the node again in a separate report application.
#6: Use a combined push/pull model
In order to maximize the use of a BI solution, it can be helpful to push information to the users instead of depending on their ability to pull the information when needed. If your presentation layer is already integrated with a transactional application that the users rely on on a daily basis, this information push can be done on Web pages with ticklers, "advertisements" and links to reports. Alternatively, report updates can be pushed via email.
#7: Keep information timely
The closer to real‐time your enterprise BI data is, the more costly the implementation, especially in large scale enterprises. Keep in mind that information is only useful if it pertains to decisions that need to be made. Therefore, firms should be judicious about hat their information requirements truly are and plan accordingly.
#8: Take advantage of Enterprise Application Integration (EAI)
Though we recommend delivering key performance indicators (KPIs) within the proper context and application (i.e., not forcing the user to a separate application), calculating and delivering KPIs often requires information integrated from other applications. This form of EAI can be accomplished in many ways, from the database level on up to Web Services, or with simple feeds from the system of record. Be aware of the EAI requirements, especially when you consider outsourcing any portion of your critical operation (data). While the Web is a very effective distribution channel for business intelligence, Web features should only be used with a specific goal in mind or they will subtract value from a solution. Even a disciplined approach will only be successful if the potential pitfalls identified above are being managed properly. BI is most effective through the merger of EAI initiatives with relevant positioning of business intelligence. The power of EAI and BI together allows a concise focus on creating business value: disseminating easily understood information to each employee’s unique information requirements, without requiring slicing and dicing on their own—and in near real‐time (NRT) fashion.
Page 3 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
Use analytics for strategic business information implementation
Strategic business information can revolutionize business analysis and performance monitoring. Find out what you need to do to implement it in your company.
When you first became aware of the business information warehouse concept, it was probably put forth as a tool of expedience—which it certainly is. And then you probably came to appreciate it as a radical repositioning of the end user in the information processing food chain. But you may not have gone so far as to classify BI as a strategic instrument of paradigm‐shifting importance. And this it can be, if you can bring your company's management around to a new point of view. BI offers management a new strategic edge, a means of implementing business performance management—the dynamic measurement and pursuit of performance goals from nontraditional perspectives. The new breed of manager springing up in the corporate world touts this approach with increasing frequency. It's up to you to provide the tools to make it a reality. How is this achieved? It is achieved with timely, at‐their‐fingertips actionable intelligence, information that enables your management's decision support system. The business information warehouse provides this, in the form of problem‐specific, department‐specific aggregations of data called data marts, along with a processing framework called analytics.
Life in the fast lane
The idea behind the business information warehouse is to tear down the traditional information processing bridge and build a new one. Where applications used to connect users to data, now the user is the connection between the data and the application. The idea is to create a storehouse of highly accurate and useful data that a user can access rapidly, flexibly, and easily, in order to facilitate a more responsive business environment based on evermore accurate forecasting. Such a warehouse is obviously the culmination of decades of dreaming in the realm of business reporting. But why do we need such reports? We need them for analysis, of course, and for monitoring our business's performance at the moment. And it is in this area that the warehouse becomes a true strategic advantage for your company. You must cultivate analytics, and you must model your system to accommodate them. But even this is only a halfway measure. What is the analytical goal of a company that is doing performance management? It is to evaluate the performance of the company as a whole—as a dynamic, producing system—rather than as an aggregation of individual departments. To this end, we need to reconsider both our data warehouse and our approach to analytics. Many companies implementing a data warehouse and analytic applications that make use of it do so with no forethought to coordination of those applications. This is fine for analyzing and monitoring the performance of a department, but it doesn't do much for the company as a whole. By all means, have department‐specific or business area‐specific data marts and local analytics, but optimize your investment by coordinating your analytics and data marts across your entire operation. Here's how.
Modeling for companywide coordination
What you need from your BI investment is a new paradigm for the use of information. You want to leverage the data your company has accumulated to optimize performance, companywide. While the department‐by‐department improvements realized by data mart/local analytic point solutions may be thought of as tactical activity, a companywide effort is, by definition, strategic: You want to use information in ways that changes the manner in which you do business. Let's carry the use of military terms a step further and stop using the word information; instead, let's call it intelligence. In a military operation, intelligence is useless if it isn't shared. If you're a general trying to take the beach, you must coordinate the activity of amphibious troop carriers, naval support, air support, and deployed
Page 4 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
troops. Each of these individual units has information available to it that is locally useful. But that usefulness is severely curtailed if it is never shared (and, in particular, if it is never shared with you). Our first principle in strategic optimization of data warehouse intelligence, then, is: Analytical intelligence gleaned from the data warehouse at the departmental level must be shared/available throughout the company. What's the hands‐on step that makes this happen? Turn your data marts and local analytics into a business knowledge network. There are many approaches to this, and they all hinge on the software you've used to implement BI and your in‐house network infrastructure. That's detail work. Where you must put real planning is in the layer between the storage/communications technology and the data warehouse. What exactly will you be passing around? This is where your attention will go. The information that should be passed between departments/business units and made available to the highest levels of management is that which meets any or all of these criteria: • • Is it "active" information? (i.e., is it current and reliable, and do decisions hinge upon it?) Does it affect performance at the departmental level, or is it information that describes performance in such a way as to affect decisions to be made at any other level or for any other department/business unit? Does the information contribute to the performance measure or real‐time monitoring of the company's high‐level performance goals? Can the information be indicative of current or impending interruptions or degradations in either departmental or company performance? Does the information affect the timeliness of performance or the response by any department or the company in general?
• • •
Once you've determined, department‐by‐department, what information feeds decision making in this manner, you have essentially classified the core intelligence knowledge for your company's decision support system. You must now formalize the regular and timely generation of this information, using data marts and analytics, at the departmental level. This you will leave in the hands of the people who own the data (that's why you have a data warehouse, so that they can do for themselves—just make sure they do it). Your next step is to set up a notification system that will pass intelligence from department to department, making your on‐the‐fly intelligence metrics a de facto distributed system. For example, when sales determines that there's increased demand for a product in the marketplace, the system will passively notify production, warehousing, logistics, and senior management. These notifications will almost always be to multiple recipients, because most business activity, viewed from a high level, is defined not by departmental activity but by interactions between departments. Your second major initiative, then, is: Make departmental performance metrics part of a distributed, companywide system by building in means of notification to other departments when data indicates an increase or decrease in performance.
Talk to the boss
Next, you'll need a set of high‐level analytics for intelligence passing from the department level to senior management. These will generate comparative data for performance metrics defined by the company's performance as an integrated whole. In addition, you need to configure projected vs. actual metrics monitors, data displays easily understood by decision makers at high levels, to be fed by these integrated metrics.
Page 5 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
These high‐level analytics are key to your success. There are several important principles to keep in mind while they are being generated: • They are not defined by senior management. Rather, senior management tells you what must be measured in order for companywide performance to be effectively optimized, and you will seek out the functional parameters at the departmental level; to this end, you need an expert from each area helping to define these high‐level analytics at every step. No one person can tell you every factor that positively or negatively impacts company performance, yet that's what these analytics propose to capture; you must effectively bring together your mid‐level and low‐level experts and let them interact extensively in order to meaningfully define these analytics. They must be extensively tested; since they are part of a system intended for highly‐specific forecasting, it will be important to define performance evaluation for comparative purposes at the departmental and senior management levels and to assign the appropriate parties to oversee this, for the period during which the efficacy of these high‐level analytics is being determined.
•
•
Your final objective, then, is: Create high‐level analytics that will present senior management (or anyone who cares to keep track) with accurate, timely metrics for evaluating overall business performance. Of course, this is all much easier said than done. You'll probably put in as much meeting time and haggling over details as you would for a major conversion or implementation. The good news is that this isn't a major conversion or implementation; you're putting in lots of people time, to be sure, but it's time that you'll recover in business performance and you'll realize those performance gains rapidly. The happy ending to the story is that it's not going to cost you millions in new software or an overhaul of old systems: You can build such a structure on top of what you already have, using tools you already possess. You don't need to reinvent the wheel or rebuild what you've already built. Everything described above is an add‐on to what you already have in place, if you've designed a non‐centralized, highly‐granular data warehouse (as most data warehouses should be). If you've already invested in the data warehouse, you're more than halfway home. And if you haven't considered taking that investment up to this new level, consider how you'll appear to senior management when you offer a magic wand like this, and tell them they've already paid for it; it's just a matter of putting it to use.
Making the operational case for data warehousing
A data warehouse will be a bargain and a powerful strategic tool that will give your company a competitive edge...but first you need to convince your organization's decision makers. Here's how to make your case.
You know you need a data warehouse. There’s no doubt in your mind. Your competition is out‐forecasting you in anticipating market trends. Other companies are faster to respond than yours in an increasingly Web‐driven marketplace, and you aren’t getting the efficiency gains you need to catch up. Your various departments are pinging your production system to death with queries and report requests. You need a data warehouse. As you march down the hall to meet with your fellow decision‐makers, do you know what you’re going to say? How do you sell this idea? How do you convince them to spring for this shapeless, faceless thing that has no explicit price tag and no explicit benefit? Here are some pointers.
Return on investment? Forget it...
The executive mindset of ROI‐as‐decision‐driver isn’t going to work when you present the plan for implementing a data warehouse. Why not? Because the production efficiency and the increased market savvy that a data warehouse delivers are not things you’ve ever measured. You can’t offer a projected ROI.
Page 6 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
You can’t quantify the benefits because you’ve never experienced them in such a context. Indeed, the very reason you want a data warehouse in the first place is to develop the metrics to create a business intelligence capacity that would teach you how to explicitly measure “increased market savvy.” You’re asking for the time and money to develop an instrument that will measure itself. You can’t even describe what you’re ultimately going to measure, once you’ve developed the analytics and performance‐monitoring capability you’re seeking. Why is this? Because your high‐level business performance metrics can be based on finely‐detailed, lower‐level metrics, and these are the province of analysts you’re going to grow in‐house, at the departmental level. Only they know what their drivers will be, and even they won’t really know what the magic numbers are until they create them. This all sounds very mystical at face value, and it is, but it’s magic that works. Here’s what you can say with confidence, and how to say it. While there are no numbers attached, it is a logical case that has no reasonable refutation.
Many‐for‐one, among others
Here’s what you get for your money, whatever the cost turns out to be: • Multilevel trend analysis. Your financial people and sales and marketing forces will acquire the capacity to define and analyze trends at every level, from the entire market down to age‐groups‐by‐ region or any other fine level that matters. And they will ultimately control the level of precision of their forecasting, because they will control the quality of the data going in and the resolution of the measurements. Company‐wide performance monitoring. This same style of analysis can be applied at the department level, business unit level, and company‐wide. You can develop, and continually refine, metrics that will allow you to continuously evaluate your company’s performance. User‐defined, user‐controlled reporting. This one is highlighted to make sure you don’t jump over it, because it sounds mundane. But there is no overstating the incredible value of this capability—and, moreover, it’s the justification you’ve been looking for.
•
•
Making your case
Consider the operational reporting systems you have in place. You need look no further than Orders for an example. A mass of reports issue from this system, going to many different individuals in a number of departments. It's often the case that any one of these users is grabbing transactional orders, data from Order History, as well as data from different databases altogether (Customer tables, etc.) in order to assemble the information required. What’s wrong with this? Well, in the first place, since the reports are largely static, and since the information is often in different databases requiring multiple queries, it’s expensive to operate this way. And this is before we even factor in the cost of developing new reports. Your choice, then, is one‐for‐one application investment vs. many‐for‐one. That is, you need to make clear to your executive decision‐makers that the ultimate take‐home point of data warehouse implementation is that you're giving your user community a single application that yields the results of many applications. The money you’d spend implementing one major new application can be spent on a data warehouse, and a great many powerful applications will spring up. Isn’t this the kind of bargain we all shop for? This, incidentally, leads you to a fourth benefit, tailor‐made for your peers: A data warehouse enables an Executive Information System. An EIS is an application that delivers, in digest form, any information an executive needs for decision support. The philosophy behind such systems is that typical executives do not fall among the users described above: There 's no way they’re going to go to four or five sources to cobble together the data they need to do their jobs. They want whatever they can get, information‐wise, by going to as little trouble as possible to get it. For such users, a data warehouse is a dream come true.
Who gets the bill?
If you can’t sell this, then they just aren’t buying. A data warehouse is going to ultimately be a bargain and a powerful strategic tool that will give your company a competitive edge. And while you can’t offer a very
Page 7 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
solid cost figure, you can safely say it’s going to be more than $100,000 and that it is unlikely to reach seven figures. What are you buying? If you’re on an ERP platform (SAP R/3, Oracle, PeopleSoft), you can buy a development kit that will give you the tools you need to extract and load data, and to develop data mining and analytic applications. If you’re not, the principles remain the same. You’re buying storage (you already know about this), extract‐transform‐load (ETL) software for putting data into the warehouse, and software for data mining, and for analytics (Online Analytical Processing, or OLAP). Beyond this, it’s a people process: You’re going to pay for the on‐the‐job training of local users of this analytical function, and for the trial‐and‐error development of reports by many users who can make use of this new analytical vs. transactional mindset. You’ll need to bottom‐line it, and the bottom line is just what everyone wants to hear: with data warehousing, your user community will be able to do more with less.
10 ways to begin a data warehouse project
IT departments typically launch data warehouse projects without input from business partners, building the business case themselves. But what steps should you take once the project gets greenlighted? These pointers will help you get off on the right foot.
High functioning value‐added IT departments operate in a consultative mode, using the enterprise business model and strategic plan to work effectively with business partners to identify technology‐based solutions in response to requirements as articulated by the business. Projects are launched based on collaboratively deciding what's needed. A data warehouse, however, is one of the few examples of a project that's typically initiated independently by IT without input from the business. IT has to build the initial business case for the data warehouse, since few people outside the technology discipline understand what a data warehouse really is or what kind of value it can provide. What's the best way to get started? Here are some suggestions.
#1: Determine your organization's appetite for change
What makes a data warehouse different from other traditional applications? One obvious answer is the rather profound difference between transactional (OLTP) and analytic (OLAP) processing. Another is the fact that data warehouses are additive in nature, which means they don't conform to standard accounting rules for financial data and are tolerant of redundancy, a construct normal relational databases avoid at all costs. Legacy applications typically have standard interfaces and proscribed reporting packages, but data warehouses are mostly accessed via ad‐hoc single‐use queries. Dimensional cubes don't look anything like relational tables. All in all, the use of a data warehouse requires a completely different user mindset. Is your organization ready for that? If not, you have two choices: Save yourself a lot of grief and don't start the project to begin with or figure out how to use your IT professional change agent skills to move the enterprise culture into one that embraces high‐level analytics and the associated set of advanced technology tools.
#2: Identify the most likely business unit to benefit from a data warehouse and approach it proactively
Every time I've gone to my business customers and said, "I'm building a data warehouse... what would you like to do with it?", the response I've gotten is, "What's a data warehouse?" Well begun is well done, so a key initial activity is to determine which of your business customers has the greatest potential need for analytical data and tools, along with the capacity and interest to put those tools to effective use. If you work for a small organization, you'll probably want to go straight to the top. At this point, you're just trying to generate interest and excitement (and funding), so build a short but effective business case
Page 8 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
before you have any meetings. Cover the high‐level basics of data warehouse functionality in business value terms. Be scrupulously careful to avoid anything remotely resembling geek‐speak. Do not make the fatal mistake of attempting to quantify data warehouse ROI. Many people have heard that data warehouses are "sinkholes of money." Don't deny this, because it's usually true, and the worst thing you can do now is kill your credibility. The initial sale you're trying to make is based on improved decision making through advanced analytics. Financial benefits will be longer term and difficult to measure, so be honest about that. Once you get approval to proceed, you'll want to quickly get business management sponsorship. IT should be the project owners only for the shortest time possible.
#3: Determine data access controls
Your proposal has been greenlighted‐‐now what do you do? All kinds of questions need to be answered, and one good place to start is by determining inclusion parameters and security requirements. You have two main areas to think about, sources and targets. Your instinct will be to use every piece of data you can get your hands on, but not every system, database, legacy application, or information enrichment file is a potential source for your data warehouse. A lot of data derived from those sources probably isn't relevant to your identified customer group and may contain qualitative data that doesn't lend itself to analysis. You also have to consider whether your downstream data warehouse customers are even allowed to process raw data. Users who are authorized at the application level shouldn't necessarily be granted access to granular information. Likewise, the target data warehouse will need some security controls imposed on it. One of the great dangers of data warehouses is that in the hands of unskilled practitioners, they can be used to make and justify spectacularly bad business decisions. Sometimes users have to be protected from themselves.
#4: Assemble the team
Who should work on the data warehouse effort? This is a project, so you'll need a project manager, someone comfortable with nontraditional project management methods (highly iterative process, multiple short‐duration interim deliverables, toleration for change and uncertainty, etc.). You'll also need a database designer and a dedicated DBA, people who are well versed in the differences between relational tables and multidimensional cube constructs. Your DBA needs to be dedicated because a good data warehouse project involves constant revision and tuning, and in addition to unique architectural skills, your DBA can't be distracted by conflicts with other responsibilities. A development team will be necessary to build the various EAI (enterprise application interface) and ETL (extract/transform/load) interfaces, and you'll need dedicated report and query specialists. You'll want to make sure your query developers have great customer focus skills, because they'll also be the ones who'll support the data warehouse to the customer community when it goes live. Don't forget the most important members of your team‐‐a customer council.
#5: Decide on the implementation approach
How should you build your data warehouse? There are two traditional approaches: the galactic data warehouse and the architected datamart. Classic data warehouse topology consists of a source layer, which feeds into an ODS (operational data store), from there into the enterprise data warehouse, and from there into a series of datamarts. All data flows unidirectionally downstream, and the reporting layer at the bottom connects to the datamarts and the data warehouse. The entire environment is connected to a metadata repository. In the galactic data warehouse approach, you build the complete backend infrastructure from source to data warehouse, encompassing as much of the source data as you might possibly someday want, and implement datamarts fed from the data warehouse as needed. The architected datamart approach bypasses the central data warehouse altogether, sending focused subsets of data directly from the sources to the datamarts. Both approaches have merit, but typically you can get to an interim deliverable far faster with architected datamarts. The danger is that you'll never have, or take, the opportunity to go
Page 9 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
back and insert the middle, the data warehouse itself. Your decision as to which approach to use depends on your own technology and business environment and should be based on a strategic risk assessment.
#6: Identify the project scope
How broad should you make your data warehouse environment? As is the case with any project, before you start you need to define the three most fundamental components of the effort: what are the inputs, what kind of processing will be performed on them, and what comes out the other side? One of the key differences between a data warehouse project and nearly every other technology project is that it's almost always impossible to define what the data warehouse and all its various components will look like by the time you're done, so you actually want to avoid too much scope definition up front or you'll lock yourself into a rigid design and end up spending even more money to overcome limitations. You're basically trying to put up a building without working from a blueprint. Nevertheless, you must come to some agreement with your customers as to at least the first few deliverables. This is why the project manager has to be comfortable with uncertainty. You'll be going to your customer intially with a very raw product and saying, "Try this, let me know how you like it," and then moving forward iteratively from there. Definition will become clearer the more you move into implementation.
#7: Establish the success criteria
What's your customer trying to achieve? If you ask your customer at the start of the project, you'll get a blank stare and a shoulder shrug, so here's where your consultative and business skills get exercised. There's no way to make a definitive statement about the financial value of the data warehouse up front‐‐ sometimes not even after it's finished. You must understand enough about your customer's business that you can help define, in qualitative and not quantitative terms, how the project will be judged successful. What results will better decision making generate? How will having advanced analytics help to understand the business? What will some of the new techniques, like segmentation analysis, provide in terms of business intelligence? How will the data warehouse help drive strategy at the enterprise and departmental level?
#8: Conduct the "25 question" analysis
Now that you have the beginning of an overall strategy, where do you go from here? I've found the most effective way to proceed is to assemble a group of 15 users and ask them to write down the 25 questions about the business for which they'd most like to know the answers. Don't allow them to collaborate. It's critically important for each one to develop a question list independently. Make sure they don't view this as a technical assignment but phrase each question in English business terms as if they were addressing their boss or the CEO (or as if those folks were addressing them). Collect everyone's lists, which will give you 375 total questions. Now normalize the list. Eliminate all the redundancies and combine all the similar questions. You'll find you'll end up with somewhere around 50 discrete questions. Convene all 15 users and review the list with them, getting them to put the questions in priority order. Know what you have in your hand? Your spec document, not only for the data warehouse but also for the first iteration of your standard query repository. If you can build a data warehouse and the queries that answer those questions in the order the users specified, you'll be a hero.
#9: Assess current data quality and pre‐cleansing efforts
What's the surest way to doom a data warehouse project? Forget about quality. No matter how good your organization thinks the data in your source systems really is, you know better. It's highly suspect. Since a data warehouse is additive in nature, you'll never do any update transactions to it. That means garbage in is not just garbage out, it's permanent garbage. Build the effort and cost of data cleansing into your data warehouse project. Not only will you have a data warehouse that produces credible results, you'll drive an overall push that's probably long overdue to improve the quality of the data in the backend systems themselves. At the same time, you'll probably uncover a host of errors in the legacy systems that should have long since been corrected.
Page 10 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
TechRepublic Resource Guide: Data warehousing and business intelligence
#10: Don't forget the metadata
Remember last Christmas when you tried to put together your daughter's bicycle without the instructions? That's what using a data warehouse without metadata is like. Metadata, or data about your data, is the glossary that documents all the important information users need so they can understand how to correctly utilize the data. The metadata repository is generally set up as a separate database, connected passively to all components of the data warehouse‐‐the sources, the ODS, the warehouse, and the datamarts. It also drives the interfaces, providing technical information that documents the processes and transformations that operate on each data entity. Whether you construct it yourself or purchase a product, remember to build this critical component into your project plan and expect the maintenance of it to be as iterative as the data warehouse itself. As one changes, so does the other.
Page 11 Copyright ©2007 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001‐6240‐0.html
