For a while now, the world of information systems has been shaped into an architecture that can be described as the corporate information factory (or the CIF). The CIF started with the enterprise data warehouse, spread to include data marts and today hosts such structures as operational data stores, exploration warehouses, project warehouses and the like. The CIF is depicted in Figure 1.

The CIF allows detailed, transactional data to enter through the operational, transaction processing applications. From the operational applications, the detailed transactional data is converted and transformed into data fit for the enterprise data warehouse. Sitting between the operational environment and the data warehouse is a type of data called an operational data store (ODS). From the data warehouse data flows to places such as data marts, exploration warehouses and near-line storage. (For a more complete description of the CIF please refer to The Corporate Information Factory, published by John Wiley and Sons). The CIF has evolved because of pressure from a number of powerful forces such as the economics of technology, the limitations of technology, end-user demands, organizational politics and so forth.


Figure 1: The Corporate Information Factory

The ODS is perhaps the most mysterious and misunderstood structure in the CIF. The ODS, in many ways, is the never-never land of information systems because it entails the least amount of discipline and the least amount of structure. There is much misunderstanding as to what an ODS looks like and how an ODS is structured. In a word, an ODS is a place where the organization can do updates, get two-to-three-second response time and access integrated data. There are, however, very good reasons for the confusion over the ODS.

In order to understand at a deeper level what an ODS is and why it is so confusing, consider the diagram shown in Figure 2.

Figure 2 shows that an ODS is always a compromise in design. The ODS sits between two schools of thought ­ the transaction-processing school of thought and the DSS- integrated school of thought. The differences between these two schools of thought are well documented and have been discussed in our industry for a number of years. Simply because of where the ODS sits, there must be compromise of design.

In order to understand the compromise of design, consider the two extremes ­ design of the transactionprocessing environment and design of the integrated DSS environment.


Figure 2: The ODS serves multiple masters at the same time ­ a difficult task in the best of circumstances.

The transaction- processing environment is optimized for transaction response time. This characteristic of operational transaction processing shapes the entire operational universe:

  • Transactions are small, accessing a small amount of data,
  • Transactions are aimed at serving a clerical community,
  • Transactions have a well-defined set of requirements before they are constructed, and
  • Transactions can do update at will.

The objectives of DSS data warehouse design are quite different. The DSS, data warehouse objectives of design include:

  • Integration of data,
  • Support of very large queries,
  • Support of the DSS community, and
  • Creation of a granular foundation of data from which many types of analysis can be done.

When these objectives from the transaction-processing world and from the DSS data warehouse world are put together, they do not mix well. The designer must prioritize which objectives are the most important.

Enter ERP

Without knowing it, the developers of ERP technology have created the world's largest ODS. The fit is not a perfect one, but it is close to perfect.

ERP provides the basic functions of transaction processing and integration. Given the track record of ERP products, it is easy to see why a compromise in design has led to systems that are difficult to implement. In many ways, good response time is at odds with integration.

One of the interesting questions is whether the ERP vendors know what ­ architecturally ­ they have created. It seems that most ERP vendors assume that if you have their product, that is all you need for information processing. If the ERP vendors understood where they fit architecturally, they would not be making such naive statements. The ODS is certainly an important structure, but by no stretch of the imagination is an ODS a fulfillment of anyone's complete needs for information. The architectural structures such as data marts, exploration warehouses and near-line storage are not addressed even remotely by an ODS. An enterprise data warehouse is hardly addressed by an ODS.

One of the more current events with the world of ODS is the advent of class IV ODSs. (See my column in the January 2000 issue of DM Review for a disccussion of the various classes of ODSs.) A class IV ODS is one where the ODS is fed from analysis done on the data warehouse. The decision support analyst creates the analysis and synthesizes the data. Once synthesized, the data is fed into the ODS from the data warehouse.

A class IV ODS is quite useful for getting the results of the data warehouse processing close to the customer. Since online response time is not a normal function of the data warehouse but is a normal function for the ODS, the ODS serves as the perfect vehicle for taking DSS data warehouse analysis and delivering it to the customer.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access