Expand +



Overcoming Design Dilemmas in Your BI Initiative: SAP BW Keeps the Focus on Your Analytics Requirements by Mitigating Differences over Architecture

by Glen Leslie | SAPinsider

July 1, 2003

A certain amount of “analysis paralysis” can hinder the early stages of data warehousing design and even implementation. When considering a top-down central database or a bottom-up datamart-based approach, IT teams are often looking for a "best of both" design strategy that meets the need for rapid, non-technical access to accurate, consistent information at all levels of the enterprise.

When it comes to your data warehousing design, we can all agree that if business requirements are not the driving force, “all bets are off” for a successful project. Now, especially when managing the bottom line is critical, data warehousing must offer enhanced visibility into all aspects of costs, and quick access to what’s profitable (and what’s not!), while offering this information to a wider audience than ever before.

But if your organization is like most, a certain amount of “analysis paralysis” can hinder the early stages of data warehousing design and even implementation, brought on by questions such as:

  • Should we design top-down or bottom-up?

  • Should we build quick-hit data marts, or plan for an enterprise architecture?

  • Are there technical limits to how much data we could, should, or would store because of our design choices?

These questions are enough to give any data warehouse architect a good case of “FUDD” (Fear Uncertainty Doubt and Dismay)! On a more serious note, these issues can reflect a debate typically between two camps: those who look to rapidly built, subject-focused data marts for quick ROI, and those who advocate the need for a central data warehouse that will ensure consistent data across the enterprise.1 More and more, IT teams are looking for a “best-of-both” approach that meets the need for rapid, non-technical access to accurate, consistent information at all levels of the enterprise.

For those considering SAP Business Information Warehouse (SAP BW), the good news is that you won’t necessarily have to choose between one model or the other — SAP BW is fully equipped to incorporate a hybrid approach to data warehouse design.

A Brief Overview of the Data Warehousing Debate
Although this article assumes familiarity with data warehousing design, it’s useful to highlight some of the basics of these two camps as they pertain to this discussion of SAP BW:

Corporate information factory (CIF): centralized data warehouse.
William Inmon’s concept of a corporate information factory (CIF) is most associated with a centralized data warehouse model. In this top-down enterprise-wide approach, the CIF ultimately subsumes what is typically known as a “data warehouse” (depending on your definition, of course!) and is the nexus for your legacy systems. The CIF includes the ODS (the Operational Data Store for granular, volatile, operational data), a Central Data Warehouse (subject-oriented, non-volatile, detailed data), and Data Marts, among other elements. Most large enterprise systems have traditionally favored this approach for its ability to handle large amounts of data.

Multidimensional data warehousing: architected data marts connected by an enterprise bus architecture.2 In Ralph Kimball’s approach, the architecture is divided into the Operational Source Systems, the Data Staging Area, the Data Presentation Area, and the Data Access Tools Area.3 Kimball takes a bottom-up approach to data warehousing, where the central feature is a coordinated bus architecture of star schemas that allows the data warehouse to be designed in manageable, bite-size chunks often referred to as data marts. Each new data mart is plugged into the bus. Individual stars in the overall constellation share conformed dimensions — dimensions that apply cross-functionally within the organization and therefore have applicability to multiple star schemas. In the end, an overall data warehouse is built data mart by data mart. The distinct separation of layers into a “front room” (the presentation layer) and “back room” (the staging area, generally hands-off to information consumers) is also key. Latitude is provided for ODS functionality, but is not detailed in Kimball’s architecture.

Putting It All Together with SAP BW
With SAP BW to facilitate convergence and foster compatibility, an IT team can avoid the quandary of having to select one approach over the other. In many companies, a hybrid approach combines the drive for an overall, enterprise architecture with the flexibility of an “island-hopping” campaign of coordinated data marts (thus sustaining the corporate will to fund the data warehouse!). With SAP BW, cooperative scenarios are possible where the ODS and data warehouse can play the role of the bus, backroom, or both at the discretion of the data warehouse architect.

That said, there are still gaps between the two approaches. So let’s take a closer look into how SAP BW helps bridge those to attain a “best of both worlds” approach.

As part of SAP’s larger NetWeaver solution, SAP BW 3.0B/3.1 (released in June 2002/December 2002 respectively) is tightly integrated with SAP Web Application Server and SAP Enterprise Portal to form an unmatched, scalable, extensible, and user-friendly data warehousing solution.4 While SAP BW is recognized as a CIF-compliant, comprehensive data warehousing solution (see the sidebar on page 30), SAP BW is also able to comply with the multidimensional approach — or with a complementary, hybrid approach.

In SAP BW, diagrammed in Figure 1, data first flows into the Persistent Staging Area (PSA).5 Most customers tend to leverage PSA functionality in SAP BW, even though its presence is an option, not a requirement. From here, ODS objects6 can be used to build a logical ODS or data warehouse. Since the granularity and temporality of data stored in an ODS object is customer-defined, customers are free to model a data warehouse (granular, non-volatile, integrated) or ODS (granular, volatile, operational) by forming logical collections of ODS objects. This capability allows SAP BW to adapt to the prevailing definition of “ODS” (as contrasted with the notion of the “data warehouse”), even within the same data warehousing project.

Figure 1 SAP BW Can Bridge the Gaps Between Differing Approaches to Architecture

Whether the ODS object collections form an enhanced staging area or a fully functional reporting area, SAP BW accommodates directing the data to multidimensional storage. If preferred, very granular data may be directed to multidimensional storage. Alternatively, summarized data could come off of the data warehouse and into the data mart (possibly multidimensional) storage area. In either case, conformed dimensions are supported across star schemas.

In all cases, with SAP BW there are many options for placement of system boundaries, ranging from assigning one system for each element in Figure 1 (i.e., the ODS can encompass its own system), to separating the data warehouse from multidimensional “data marts,” to housing the entire diagram on a single system.6 SAP BW also provides robust tuning and optimization tools for all aspects of the data warehouse (ETL processes, PSA, ODS, star schemas, Web and Windows queries, etc.) on platforms as divergent as Windows NT, AS/400, and Unix.

Support for the Corporate Information Factory

SAP BW provides a solution that extends beyond the enterprise data warehouse and attendant ODS/data marts. Based on feedback from customers and industry analysts, SAP has brought to market a fully realized corporate information factory (CIF).7 CIF compliance in SAP BW encompasses an unprecedented array of services within a data warehousing context, including:

  • A wide range of packaged Decision Support Systems (DSS) applications available from SAP — ranging from sophisticated Supply Chain Supply Network and Demand Planning features to complex financial consolidations, planning, and balanced scorecarding capabilities — that integrate directly with SAP BW. These hybrid (part functional, part analytical) applications build on the unique strengths of SAP BW’s open, robust architecture.

  • Support for non-SAP DSS applications via the built-in “Open Hub” service.

  • Support for e-analytics via XML interfaces, along with bundled ETL for SAP’s own e-business applications.

  • Data marting, supported in a variety of ways: physical and logical, global and local, integrated and distributed. (In a CIF, data marts are a component of the overall architecture. Their role in SAP BW can be customer-defined.)

  • An integrated data mining engine, plus integration interfaces to industry-recognized data mining tools.

  • An integrated metadata repository publishable to the Web.

  • Archiving capabilities.

  • Near line storage integration with select industry-leading near line storage solutions.

  • A comprehensive, integrated, platform-independent monitoring environment for all aspects of the data warehouse — from ETL processes to report performance.

  • Robust, packaged ETL for SAP applications.

  • Published, open interface compliance in every aspect of the data warehouse, in addition to open interfaces and access to SAP BW’s frontend for third parties.

Whatever configuration you use, SAP provides a proven Accelerated SAP (ASAP) implementation methodology for gathering business requirements for the right-sized data warehouse. What’s more, SAP BW’s ASAP methodology includes Business Content for rapid data warehouse development, and consists of preconfigured, extensible ETL processes, data elements, ODS objects, star schemas, and role-based reports integrated with SAP Enterprise Portal. SAP BW Business Content represents SAP’s years of best business practice experience, with coverage of both cross-industry functional content and vertical industry-specific content. All of this is layered on top of rock-solid, CIF-compliant technology within SAP BW.

SAP BW provides a robust, adaptable solution to your enterprise data warehousing needs. With its ability to conform to industry-recognized architectural and philosophical data warehousing tenets, you can move beyond debates about design, and focus on meeting business and user requirements for your analytic and reporting needs.

For more information on SAP BW, visit

1 This article addresses some of the key points of deliberation in what’s known as the “Inmon vs. Kimball” debate — referring to William Inmon and Ralph Kimball, two pioneers of data warehouse design. See William Inmon’s publications, including Building the Data Warehouse (Wiley, 2002), “Data Warehouse, ODS And Data Marts: The Corporate Information Factory,” and “What Is a Data Warehouse?,” and Ralph Kimball’s books The Data Warehouse Lifecycle Toolkit (Wiley, 1998) and The Data Warehouse Toolkit, Second Edition (Wiley 2002).

2 Also known as a “conformed architecture.” Note that “multidimensional” here refers to the overall architecture of the data warehouse, not the underlying physical data storage mechanism. Many debates rage over the use of Multidimensional OLAP (MOLAP), Relational OLAP (ROLAP), Hybrid OLAP (HOLAP), and a host of other (xOLAP?) related approaches to physical data storage.

3 Ralph Kimball, The Data Warehouse Toolkit, Second Edition (Wiley 2002).

4 See Gunther Rothermel’s article in this issue of SAP Insider (, along with or

5 The “persistence” of the PSA is customer-defined.

6 In SAP BW, individual Third Normal Form (3NF) building blocks are labeled “ODS objects.” These are not to be confused with the “ODS” described in Inmon’s corporate information factory (which can be “global,” “local,” or “web” ODSs), or the ODS Kimball allows for (a system between operational systems or a hot partition of the data warehouse, as two examples). In fact, collections of SAP BW ODS objects could form an “ODS” as defined by either camp, or they could comprise an “Enterprise Data Warehouse” as defined by Inmon.

7 See "SAP and the Corporate Information Factory" at

8 SAP BW even supports scenarios where the "Source Systems" are hosted in the same physical system as BW itself. See SAP's MCOD (Multiple Components in One Database) functionailty discussed at

Glen Leslie is product manager with the U.S. Business Intelligence product management group at SAP Labs. He has been involved in data warehousing design and implementation projects since 1996. He can be contacted at


An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!