Preserve the Data WarehouseBI capabilities embedded in transactional systems degrade confidenceby Jim Gallo Continued from Page 1 Using this example, I'll discuss the need for shared information as well as a logical architecture that incorporates multiple products and takes an integrated warehouse approach. Business units generally share a degree of commonality, and data that rolls up to the corporate level is certainly similar (see Figure 1). If each business unit were to deploy its own individual set of applications that included a self-contained BI/DW, achieving conformity would be a serious challenge. Each canned solution you deploy brings with it its own set of business rules, metadata definitions, and technology solutions. A colleague told me that the large manufacturing organization where he worked had implemented applications built around a series of BI/DW solutions embedded in other applications. The net result: The business ended up with 32 data warehouses that had to be managed separately! As expected, when the CFO asked for a consolidated set of financials for analysis, they had to start from scratch and build an integrated warehouse from which enterprisewide financial analysis could be conducted. I'm happy to report that, once the project was complete, the CFO was very satisfied with the results, and the organization is now building real warehouses across multiple domains and subject areas. Not All BadAre point solutions entirely bad? Not at all. I've seen several that certainly can deliver value to the business. However, just like dependent data marts, point solutions should be sourced from a data warehouse and, if possible, use the same set of tools that are already in use within the organization. For example, at least one ERP vendor offers a complete set of integrated tools (ETL and out-of-the-box reports and dashboards) that are products from other BI vendors. These products are attractive because the ETL conversions from the transactional database can be reused for the data warehouse. However, if you peek under the covers, you will find that these mappings and reports are also available from the BI vendors. So it probably doesn't make sense to build the data warehouse within the ERP solution when, in reality, it should be treated as just another source for a global data warehouse. It's rare to find a large organization that uses a single instance of a single ERP solution, let alone having one and only one solution that runs the entire enterprise. But an organization can accommodate both an enterprise view of information as well as self-contained application vendor BI solutions. But does this strategy mean taking the long road to get to the warehouse in a box? Perhaps, but taking the extra steps will pay dividends in the long run toward data integration and reducing total cost of ownership. We're once again in search of the perfect solution where none yet exists. But if you do the work of integrating disparate data sources, you may, unlike Diogenes, find that single version of the truth. I suppose it's better than letting your enterprise decision-making go to the dogs. Jim Gallo [jjgallo@worthingtonindustries.com] is an enterprise data architect for Worthington Industries, has more than 20 years' experience in information technology, delivering business intelligence architectures and solutions. RESOURCESAll Intelligent Enterprise data warehousing articles are indexed in the Data Warehousing Info Center.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
