The Data Warehouse
A Practical Application
Let’s take a look at a mythical large telecommunications company called Foobar Telecom. Like
many companies in the field, Foobar is overwhelmed with data and looking for better ways to
manage that data. The company is over 100 years old, has 10 million access lines in 1,500 wire
centers, and spans 900 miles across several states. Foobar has hundreds of operations systems,
each with its own data. Decision support data is scattered across multiple systems, non-integrated,
redundant, often inaccessible, contradictory, inaccurate, and costly. Countless staff are dedicated
to compiling information in a form suitable for decision support and preparing reports for the
executives.
Foobar is also in the process of implementing an AM/FM/GIS system. They have budgeted $100
million over seven years to complete the project. The system is designed with a central data server
in each engineering district linked by local area network to the engineers’ workstations. Systems
administration and backups are managed by the Information Systems Department at company
headquarters performing nightly backups from each district over the company’s internal
broadband wide area network.
Knowing the value of enterprise data, the company has attempted to integrate the new system
with the existing systems. All attempts to link the AM/FM/GIS system to legacy systems with
simple interfaces have failed, however. Either the legacy systems don’t have a suitable open
architecture, or they are not up to the task of supporting the additional load of real-time inquiries
and updates launched by the new system. Foobar knows replacing all the legacy systems with
modem databases is impractical, interfaces are not satisfactory, and yet they still want to achieve
enterprise data.
The addition of a data warehouse (Figure 1) offers one solution. The data warehouse is
maintained centrally. It is designed around subject areas; for example, “Customers,” “Facilities,”
“Billing,” “Markets,” and so on. At designated intervals (different intervals for different sets of
data) the operations systems are polled during off hours for specific current information. The data
is aggregati and summarized as decision support information and stored in the central data
warehouse where it can be retrieved on demand by anyone in the company with the need and
proper security access.
Figure 1
The data warehouse is a read-only data store. It can only be updated by the periodic polling of
operations systems. It may not be changed by end users. It polls for operations system data only
during off hours so the operations systems’ performance will not be degraded.
Unlike the operations systems servers, the warehouse server is a database machine optimized to
manage terabytes of information in large transactions where real-time, sub-second response is not
important.
Inmon emphasizes how the data warehouse must be carefully designed to anticipate and support
the data requirements of decision support functions. It will not be a complete replication of
operations da~, that would be inefficient and impractical, perhaps even impossible. Rather, the
system should retain summarized information in the smallest form that satisfies the anticipated
need. For example, a manager may set out to learn how many poles are in a distribution area. The
decision support system, anticipating someone would ask that question one day, should keep the
summarized number of poles and not a detailed list of each and every pole, which can still be
found in the operations system if necessary.
Conclusion
The data warehouse is a useful solution for integrating AM/FM/GIS data into the enterprise. It is
not a substitute for the AM/FM./GIS system, but it can be used to make selected information
available to many more people than will be able to access it through the AM/FM/GIS application.
It is relatively easy and inexpensive to implement and it can be implemented in stages with each
stage quickly returning full benefit.
The data warehouse does not provide a linkage or interfaces to legacy systems to ensure
consistent data between systems. It does, however, act as a repository of “official” data selected
from many systems, so that users will know that if there are ambiguities between systems, the data
in the warehouse is the correct, stewarded information.
It’s possiblc+even temptin&o limit the initial design of the warehouse to only AM/FM/GIS
data to quickly gain the benefit of being able to share the data with users outside the application.
However, the warehouse should be designed with an eye toward the future and the ultimate needs
of the entire company. There should be one warehouse for all subject data areas of the company.
Thus, when considering a data warehouse in support of the AM/FM/GIS application, the system
planner should be working closely with enterprise data planners.
The successful data warehouse will be application-independent. It will provide summary
information in a form useful across the company. Users will be able to access the system and
collect needed information without extensive training or assistance. It will quickly become the first
choice of users to research decision support information. The result will be executives, managers,
and engineers making better, more informed, more consistent decisions faster with less time and
effort spent on searching for information.
Bibliography
- Donaldson, William R., 1996, Enterprise Data And Competition In Telecommunications,
AM/FM International Conference XIX Proceedings, pp. 567-575.
- Hackathorn, Richard D., 1993, Enterprise Database Connectivi~, Wiley, New York.
Hackathorn, Richard D., and Inmon, William H., 1994, Using The Data Warehouse, Wiley, New
York.
- Haderle, Don, “The Five Elements Of The Data Warehouse;’ Data Resource Management, May,
1994, p.13.
- Inmon, W.H., “Data Warehouse: Seeing Is Believing;’ All About IRM Conference, Aspen, CO
July 27, 1993.
- Inmon, W. H., 1984, Integrating Data Processing Systems: In Theory and In Practice, Prentice
Hall, Englewood Cliffs, NJ.
- Muench, William F., 1996, Apres le Deluge, C’est Moi, AM/FM hternational Conference XIX
Proceedings, pp. 333-337.
