Integration cost savings
David Lagasse
PlanGraphics, Inc.
112 E. Main Street
Frankfort, KY 40601
Introduction
Back in the 1980s and early 1990s (the distant past in terms of the evolution of
computing technology), most applications were designed and implemented to meet
specific sets of user requirements. Consequently, most of these applications, were
implemented as departmental or group solutions. As computing technology evolved and
became more embedded in everyday work, companies began to realize that many of their
computing systems and applications required some of the same data. These companies
also saw that processes within one system were predecessors to processes within another
system. Since these two systems were not interfaced with each other, the only method of
moving required data or initiating a process between systems was through the use of a
human interface. This meant that a person had to manually enter the data or initiate the
dependent process. It quickly became clear that interfacing these various systems, either
at the data or process level, could eliminate redundancy and significantly improve
productivity.
Integration today
When an organization first considers integrating two systems, it usually just looks at the
two systems in isolation. This narrow view is driven by the identified need to pass data
between these two systems, or to tie two system processes together. Once the integration
requirements are defined, a custom interface is then built and implemented. Over time,
more and more integration points are identified among more and more systems. As
interfaces are implemented to meet these integration requirements, the organization
assumes the burden of supporting numerous custom interfaces.
Within today's utility organizations, these integration points can be seen, at a high level,
in the diagram below.
For example, a custom interface would be built to pass network plant and connectivity
information from the AM/FM/GIS to the Outage Management System (OMS) as
infrastructure changes and the model within the AM/FM/GIS is updated. An interface
would also be built to pass customer data from the CIS to the OMS. Since the
AM/FM/GIS, the OMS, and the CIS are usually implemented within different
environments (such as different programming languages, operating systems, or database
management systems), if the AM/FM/GI S needs customer information, another custom
interface would need to be developed to support this requirement.
As the number of integration environments increases, so will the organization's
requirements for support and maintenance. This increase results in the "ballooning" of the
number of specialized staff who must be retained to keep the interfaces working
smoothly. Ultimately, one of the underlying systems must either be upgraded or replaced.
When this happens, all of the interfaces associated with that system must be either
modified or completely rewritten.
As the number of interfaces grew, many organizations realized that the main purpose of
these interfaces was to move data among multiple systems. The organizations also
realized that while these interfaces automated the data transfer process, they caused
duplication of data. Many companies turned to data warehousing as a solution to the dataduplication
issues. The following diagram shows a high level view of the data
warehousing concept.
This type of data integration results in a central data store, from which all applications
retrieve data and to which these applications store data. While this approach effectively
reduces, and can even eliminate, data duplication, a number of issues complicate the
implementation of a data warehouse.
The first, and usually the largest, issue is the development of a corporate data model. A
corporate view of all data, including data formats and relationships, is needed to filly
implement a non-redundant data warehouse. If a generic data format is chosen for the
corporate data model, then the organization will still need to create interfaces between
each application and the warehouse to translate data. Other issues involve data ownership
and integrity within a data warehouse. Who owns which piece of data and has the
responsibility to edit the information? If more than one system needs to edit the data, how
do you solve data integrity issues among the systems? How available is information that
is already being used by another application? Other issues to be addressed when
implementing a data warehouse are physical disk space requirements, location of the
warehouse, and network bandwidth.
