The term ODS is confusing. Is it a data warehouse, part of a data warehouse, or something else? ODS has several academic definitions in the data warehouse industry. However, the definition varies based on usage.
In Building the Operations Data Store, (see Appendix A), William H. Inmon, Claudia Imhoff, and Greg Battas define ODS as a
subject oriented, integrated, volatile, current valued data store containing only corporate detailed data
to support tactical decisions. At a conceptual level, just about everyone agrees with this definition. However, many differ in defining usage boundaries of ODS and implementation.
Initially, the ODS was introduced to integrate legacy and transactional applications to increase customer satisfaction, not to make tactical decisions. It had a customer focus in mind. For example, in the banking industry, customers want to see one view of all their accounts, regardless of the individual systems in which they are stored. Here, the role of ODS is to keep an up-to-date summary of all such accounts in the ODS to provide consolidated accounts information to support transactional applications as well as customers outside the company boundaries.
Here, one can value-add the account information from a partnering advertising company to promote a product, hence merging corporate and non-corporate information. Merging company and non-company information in ODS contradicts the definition previously stated.
There are three classes of ODS layers, most commonly known as Class I, Class II, and Class II. The ODS Objects in each class have special characteristics, as listed in Table 17-1.
Functionality | Class I | Class II | Class III |
---|---|---|---|
Data refresh rate from its data sources | Synchronous; almost in real time | Asynchronous; Near real time-few minutes to an hour | Asynchronous; Based on analytical application usage and the infrastructure operational requirements |
Data volume | Packets | Small-medium | Large |
Data Content | Transaction-centric | Business Event-Centric-a mix of transaction and supporting workflow information | Very much; Subject-centric at the atomic level detail |
Persistence | Low | Medium | High |
Data Transformations | Very little just to conform to data interchange format | Moderate-compose data structures by combining transaction and value-added information for DSS | Extensive-Cleansing, extraction, and transformation to construct atomic level data sets |
Availability | High | Medium | Low |
Performance | High-at the speed of intra-application interconnect requirements | Medium-at the speed of business work flow rules requirement | Medium-Low, based on business value and operation costs requirements |
Intended usage | Customer facing; Staff; Intra-application interconnect services | Customers; Customer facing and operations staff | Operations management; Data analysis; Customer problem resolution and operations |
Technical Infrastructure | Fast and reliable data interchange and data storage technologies-hardware, software-OLTP-centric | Mostly application or database specific store and forward data management technologies | Mostly batch, database, or large data handling technologies to optimize infrastructure resources |
Operations Staff | OLTP operations staff-highly visible | OLTP operations staff-less visible | OLTP and data warehouse staff |
Business Sponsors | Corporate senior business management | Division or line of business management team | Operations management team |
Example | Airline reservation; Critical care medical records | Bank accounts management; supply-chain management | Call center; Manufacturing shop floor operations |
The Class I ODS serves mostly as a real-time intra-application interconnect bus. Classes II and III are mostly to support near-real-time business operations. Due to specific time-critical ODS object-usage requirements, use robust flexible technologies to implement ODS objects. The question is then how one can deploy such a diverse ODS environment and the data warehouses under one framework to support e-business and business intelligence. This is where SAP BW technical framework plays a critical role in constructing, delivering, and managing all information objects, including ODS, OLAP, data marts, data warehouse, document warehouse, and extraprise data warehouse to support CIF under one umbrella.
In BW, 2.0 you can implement an enterprise data warehouse using the ODS objects. This extended ODS capability in SAP BW completely goes against the ODS definition. Imhoff, an authority on the Operation Data Store, states ("Understanding the Role of Operations Data Store, DCI conference, June 28, 1998") that:
The ODS is not the lowest level of detail in the data warehouse architecture.
The ODS is not a staging area for the data warehouse.
The ODS is not a department-specific application.
The SAP BW ODS implementation is quite the opposite of these three points. Most customers will store the lowest level of detail in the ODS objects, blurring the ODS and data warehouse boundaries. In doing so, one has to stage data in the ODS objects to construct non-multidimensional department-specific applications. Though SAP calls this new functionality the ODS, in reality, it is a framework to build traditional ODS and data warehouse objects along with its ROLAP implementation to complete the CIF. For this reason, I call SAP BW ODS eODS-extended ODS.
Several examples-each providing a different concept of ODS primarily based on its usage and implementation architecture-can be cited. Today, due to heavy use of ERP applications and intense focus on customer satisfaction, the lines between ODS and traditional data warehouse are blurring. A new vision for ODS is warranted. This bring us to the SAP view of ODS-how it has evolved and what it really means.
Let's look at ERP packaged applications and the scope of traditional ODS. The ERP applications provide an integrated suite of business applications, such as SAP R/3. Here, information is already integrated among several individual applications. Data from all such applications is easily available. Because the fundamental role of an ODS in a corporation is to provide almost real-time data interconnects for an integrated view of information among business applications, the role of ODS as previously defined is very limited. For an ERP environment, the role of ODS still has to be defined where ODS plays an active role in the corporate information supply chain.
After the release of SAP BW 1.2A, customers found that the ODS implementation was not what they thought an ODS ought to be. It only housed the incoming data. American SAP User Group (ASUG) members worked with SAP to form a subcommittee to define an ODS architecture in the SAP BW product. This subcommittee consisted of ASUG members representing a broad range of industries (Dan Spaulding, Halliburton; Charlene Mathias, Eli Lilly; Naeem Hashmi, Compaq; Ryan Uda, Hewlett-Packard; Marilyn Jones, Dow Corning; Mary Heaner, Intel; Dave Smith, Phillips Petroleum; Kay Black, Sabre; and Xuan Pham, Equistar).
After long and intense discussions among team members and Laurie Nolan and Dr. Heinz Haefner, both of SAP AG, a white paper on SAP BW ODS was published. This white paper became the foundation of ODS architecture in SAP BW 2.0. This team focused its analysis of ODS requirements on the eight key areas: diverse data source, environment management, extraction-transform-load, metadata management, data management, archival management, data access, and data requestors.
The proposed ODS functionality is planned for partial implementation in SAP BW 2.0A for the pilot customers, Hewlett-Packard and Eli Lilly, and in SAP BW 2.0B for general availability. The ODS pilot was launched from December 1999 to February 2000. The SAP BW ODS pilot results were presented at the BW Congress in February 2000 in San Francisco, California.
Team-Fly |