IBM Data Warehousing and Business Intelligence

Published on November 2016 | Categories: Documents | Downloads: 65 | Comments: 0 | Views: 331
of 11
Download PDF   Embed   Report




TechRepublic Resource Guide 
Data warehousing and business intelligence 

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‐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‐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‐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‐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‐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‐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‐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‐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‐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‐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‐6240‐0.html 

Sponsor Documents

Or use your account on


Forgot your password?

Or register your new account on


Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in