What is the business reason for up-to-the-second response times
Let's consider a few examples. What happens when an ATM gives poor response time (e.g., 60 to 120 seconds)? In short order, the ATM falls into disuse. People assume that the ATM is not working and cancel the transaction. Or, consider airline reservation systems. What happens when the computer starts to give 60-second response times? A long line of passengers forms - all are waiting to get on a plane, all are nervously looking at their watches and all are becoming more irritated by the second. Not a pretty picture.
In both cases, when the system does not provide up-to-the-second response times, the customer suffers. And when the customer suffers, the business suffers.
Both ATMs and airline reservation systems need detailed data that is directly related to the customer or the customer's account. The data needed is of a limited amount and is subject to change at a moment's notice.
Now let's consider some other information needs. Let's suppose an organization is planning an expansion into the Northwest U.S. What kind of information needs do they have
A normal part of such an expansion is the analysis of the demographics of the Northwest. How important is it that a demographic analysis be delivered as up-to-the-second information? Consider that people move infrequently. Given the vast amount of people and territory, the analysis is probably not going to be accurate up to the second in any case. Additionally, consider the nature of the decision being made. Is there going to be a decision to move to the Northwest if there are 253,902 citizens in Lacey, Washington, as opposed to 253,901 citizens? In this case, up-to-the-second information is nice to have, but it is almost irrelevant to the decision-making process.
And what can be said about the data needed to support this decision? The data is not at the detailed level. The data is not necessarily accurate up to the second. The data is collective. And, the data is not subject to immediate change.
However, the data is still important, and the data still needs some degree of accuracy. The data has the following characteristics: it is at the summary or aggregate level; it is not massively incorrect, but some units of data may be missing or incorrect and the final analysis will not be affected; it is collective, not relating to a single individual or product; and it is not subject to immediate change. These characteristics are very different from the characteristics of the data needed in a high performance response mode.
In terms of data usability, there is a case to be made for allowing data to "settle" before being used. When data is first entered into a system, there often is a need to make adjustments to the data. The best place to make adjustments to data that is not stable is in the operational environment, not the data warehouse environment. However, when data is rushed to the data warehouse environment, adjustments must be made in the data warehouse. This complicates the data warehouse immeasurably and unnecessarily. It is much better to allow the data to enter the operational environment, settle there until it becomes stable and then place the data in the data warehouse once it has stabilized.
The attempt to make all data and all transaction processing coming out of a computer high-performance is simply a theoretical idea taken to an extreme.
Bill Inmon is universally recognized as the father of the data warehouse. He has more than 35 years of database technology management experience and data warehouse design expertise. His books have been translated into nine languages. He is known globally for his seminars on developing data warehouses and has been a keynote speaker for many major computing associations. For more information, visit www.inmongif.com and www.inmoncif.com. Inmon may be reached at (303) 681-6772.
Be the first to comment on this post using the section below.