Integration cost savings

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.

Integration tomorrow
In response to some of the issues outlined above, a "hybrid" integration approach has recently been developed. This hybrid approach involves the implementation of a uniform environment within which to conduct data integration. The diagram below shows a high level representation of this approach.

This approach provides a single integration environment that is used throughout the corporation, but each system retains and maintains the data that it needs for its operations. While this approach may lead to data duplication, it resolves the issues of cross-system data integrity. Rather than having to develop an enterprise-wide data model, users only need to identifi the information that is required from other systems. Applications that own data needed by other systems become publishers of the data, while systems that need the data are considered subscribers. A system can be both a publisher and a subscriber of data.

This integration environment generally provides a uniform development environment within which to develop adapters for each system that will publish or subscribe to data. These adapters are the interfaces to the integration environment; they generally transform the published data into the common exchange format, as well as transforming subscribed data from the common format into the format required by the target system. In most implementations of this concept, functionality exists within the integration environment to queue the data, to verify the integrity of the data as it is being published or subscribed, and to pass triggers that allow process-to-process integration without having to write custom interfaces between systems.

Benefits and savings
The main benefit of this "hybrid" approach is that there is a uniform integration environment used throughout the corporation. This uniformity allows the implementation and maintenance of a defined set of standards. Corporations only need to invest in developing and maintaining a single skill set for the integration of their systems. This standardization will result in lower development and implementation costs, lower maintenance costs, and a reduction of the number of personnel dedicated to systems integration, as well as the ability to replace lost personnel with someone from the market who already has the required skills.

As these integration environments mature, more and more "off the shelf' adapters will be available for commercially available applications. This will result in even greater cost savings to corporations while providing for the capability of quickly incorporating a new or updated system into the corporate IT architecture. Using a commercially available integration environment and adapters will save a corporation a significant amount of development costs as there will be no need to create custom interfaces. Additionally, the environment and adapter vendors will be providing upgrades for their products, thus saving companies even more money by reducing maintenance costs.

Implementing this uniform integration environment also requires fewer upgrades to the physical computing infrastructure. Existing systems will continue to provide the storage capacity for its data. There is no need to create a multi-terabyte data warehouse. This environment only requires the addition of enough storage capacity to hold the data temporarily as it moves from one system to another. It does not dramatically increase network traffic, because systems do not have to go to a warehouse for their own data. The only additional traffic is created by the movement of data among systems over the "bus," and most of this traffic would have been present using traditional system-to-system integration. Minimizing the requirements for new hardware or hardware upgrades when implementing an integration strategy will provide the organization with significant cost savings.

As mentioned earlier, a majority of integration projects are focused on the transfer of data from one system to another as required by the defined business processes. The "hybrid' integration strategy allows users to define their business processes without worrying about the mechanism that will move the data between the processes. In fact, some integration packages on the market today allow users to model their businesses with a focus on the processes they need to implement, and the application handles the mechanics of moving the data. The result is a significant cost savings as companies can focus on running their businesses (and responding to the ever-changing business environment) without being constrained by their IT integration environment.

Conclusion
There is not one universal IT system available to companies that meets all organizations' needs. Multiple systems within an organization have dictated the need for systems integration-and will continue to do so. Timely data access is vital to survival in today's business environment. The implementation of a uniform integration environment allows organizations to respond to the rapidly changing data needs of their systems while providing a significant level of benefits and cost savings. This is especially true today where mergers and acquisitions are commonplace occurrences and the "new" company must quickly bring many diverse systems together to act as one corporation.