Technologies for uniting the enterprise

Technologies for uniting the enterprise

Peter M. Batty
Smallworld Systems, Inc.
5600 Greenwood Plaza Blvd.
Englewood, CO 80111

Overview
The main focus of this paper is the integration of major business systems, an area which is now commonly known as Enterprise Application Integration (EAI). The problems with a traditional point to point integration approach are examined, and an alternative approach often known as an "integration bus" is explained. The role of XML in this arena is briefly discussed. An overview is given of IEC TC57 Working Group 14, a major standards initiative in this area, focused on electric distribution. The industry trend towards merging of major systems into integrated application suites is also examined. In the latter part of the paper, a few other aspects of technology for "uniting the enterprise" are examined. While EAI is primarily focused on data flows between major systems, there is also a requirement for imbedding functionality from one application within another to streamline workflow. A brief discussion is included on how component and distributed object technologies can help to achieve this. Finally, the issue of distributing functionality throughout an organization is examined, with a particular focus on the Internet, mobile devices and wireless communications.

Enterprise Application Integration (EAI)

Problems with point to point integration
The traditional approach to integrating corporate systems has been to write direct interfaces between each pair of systems which need to be integrated. This leads to an architecture like that shown in the following diagram:

With this approach, in order to integrate n systems it may be necessary to write n * (n-1) separate interfaces. In addition to the major effort required to develop these interfaces, there are a number of other serious drawbacks to this approach. A major issue is ensuring data integrity. If one of these systems fails and has to be recovered from a backup which is not fully up to date, it may well be impossible to fully restore data integrity between this system and all the other systems it is interfaced. Another issue is the difficulty of replacing one of these major systems, since all of the interfaces it is involved with need to be rewritten.

The "integration bus" approach
There is a much better approach to this problem, which is commonly known as an "integration bus" or "publish and subscribe" approach.

n bus In this approach, all systems talk to a single "integration bus", which is a piece of software (or "middleware") which manages the passing of messages between applications. There are several companies which provide this type of software, including specialist companies such as Vitria and TIBCO, as well as some of the major hardware and software companies such as Compaq, HP, IBM and Microsoft.

Any applications can publish events onto the bus, and the bus takes care of delivering each message to all applications that have subscribed to events of that type. For example, assuming that facility updates were done in the GIS, the GIS could publish an event to indicate that a new facility had been added (or an existing one updated). This event would be passed to all the other systems which had subscribed to facility change events - which would probably at least include work and asset management, SCADA, and outage management in this example. Another example of an event might be that a feeder breaker had tripped, which would be published by the SCADA system and subscribed to by (at least) the outage management system. The application which publishes an event to the bus does so only once, and has no knowledge of which applications have subscribed to that event. Similarly, an event subscriber has no specific knowledge about the publisher.

This approach can obviously significantly reduce the amount of code which needs to be written to interface multiple interfaces. However, the integration bus middleware also generally adds a number of additional features which have significant benefits.

One of the major advantages relates to resynchronization after recovering one system from an old backup. The bus assigns a sequence number to each event and can store all events in its own backup or log. Each database will store the number of the last event it processed as part of each transaction. So when a system is recovered from a backup, it can ask the bus for all events which have occurred since the last event it processed, to bring it back up to date.

A similar approach can be used to enable the integration bus to handle disconnected systems, such as mobile data terminals which are used by field crews. When one of these systems is connected to the network, it can ask the bus for any events of interest which have occurred since it was last synchronized (for example facility updates). The mobile system could also publish events itself, based on any updates which were done in the field.

Another very useful feature which is offered by some integration bus products is the ability to manage multiple "channels" and copy or move events between them. This can be very useful for testing and simulation. For example, suppose a new outage management system was being implemented and its primary inputs were events generated by the Customer Information System (CIS) and the SCADA system. A new test channel could be set up so that all real events generated by CIS and SCADA were copied to that and could be read by the outage system, but any additional events generated on that channel would not be seen by the production systems. In addition, a separate channel might be used to play back trouble call events from a recent storm into a test system, for training or performance testing purposes. It is very difficult to manage these sort of scenarios easily with traditional point to point interfaces.

While the examples used so far have focused on integration between major business systems within a company, some EAI products can also work across the Internet. This allows the same basic approach to be used for e-commerce between companies.

The idea of an integration bus becomes even more useful if providers of commercial applications conform to standards for the content of events which should be written to or read from the bus. The next two sections discuss XML, which is rapidly becoming the standard of choice for encoding this type of message, and IEC Working Group 14, which is working on defining utility-specific standards for the content of these messages.

XML
XML (eXtensible Markup Language) is a format which allows structured data to be stored in a text file. It has rapidly become accepted as the format of choice for exchanging structured data on the Internet, and is also becoming popular in the EAI arena. The big reason for the success of XML is that it combines simplicity with great flexibility. Its simplicity makes it very easy for software to read and write XML files - and many standard tools are available to help with this. Its flexibility means that it can be easily used to handle more or less any type of data. XML files are self-describing, which is another important aspect of the extensibility of the format.

For more information on XML see the references below.

Working group 14
Working group 14 is a standards committee run by the IEC (International Electrotechnical Commission) Technical Committee 57 (TC57) which is working on an international standard, referred to as IEC 61968-1. This standard is focused on integration of major utility applications relating to distribution management, and it is based on an integration bus approach like the one explained earlier in this paper.

The diagram above gives an overview of the areas covered by WG14. The standard aims to cover both information exchange between applications - the "events" which should be published to the bus - and also a Common Information Model (CIM). The CIM is intended to be an abstract model that represents all the major objects in an electric utility enterprise. The CIM was originally developed by the EPRI CCAPI project and submitted to TC57 Working Group 13, which is focused on Energy Management Systems (EMS). The model is now being extended by WG14 so that it will cover generation, transmission and distribution. The work of WG14 is being closely coordinated with other relevant standards initiatives. This includes initiatives focused on utilities, such as WG13 and the Electric Power Research Institute (EPRI) Control Center Application Program Interface (CCAPI) Project, and also initiatives with a more general focus, such as the Open Applications Group (OAG) and the Object Management Group (OMG).

The standard being developed by WG14 will greatly reduce integration cost and effort for systems which conform, and will make it much easier to switch out one system and replace it with another.

The trend towards merging of major systems
Notwithstanding the improvements in technologies for integration, and standards initiatives like those mentioned so far, we continue to see a trend in the IT industry for software vendors to offer integrated suites of applications. We saw this with office products, as the integrated office software suites took over the market from independent word processing, spreadsheet and presentation software packages. Microsoft is of course the dominant vendor in this market. We have seen a similar trend with Enterprise Resource Planning (ERP) applications, with suites of software from a single vendor (SAP being the dominant one) replacing multiple systems in areas such as work and asset management, materials management, customer care, accounting, etc.

We are now seeing a similar trend in the Spatial Resource Planning (SRP) area. Whereas a utility would traditionally have bought separate systems for GIS, outage management and network management, and had to integrate these, many utilities are now choosing to buy a single SRP platform which provides functionality in all of these areas. See Batty (1998) for more detail on this topic. This trend is likely to continue and will reduce the number of interfaces which need to be implemented using an integration bus type approach, since these suites of applications have more tightly coupled behavior. SRP is complementary to, but closely integrated with, Enterprise Resource Planning (ERP). The integration bus approach, and the IEC 61968-1 standard, provide an excellent method for implementing this integration between ERP and SRP systems.

Imbedding of functionality
The focus of EAI which has been discussed so far is primarily on data flows between major business systems. There are other aspects of integration which are not really covered by this approach, which relate to direct imbedding of functionality from one system within another. One example might be integration between a GIS-based design application and a load flow analysis engine. Based on the design which has been drafted in the GIS, the user would like to run a load flow analysis and look at the results within the GIS environment. This involves exporting the network in some fashion to the analysis engine (or allowing it to directly read this from the GIS), running the analysis, and obtaining the results back so that they can be displayed. This could be done by passing all this information across an integration bus, but it is not clear that this is the best approach, since a lot of transient information may need to be passed between these two specific applications - the publish and subscribe model is not really as appropriate in this scenario.

Another example which is even more clear cut is that a customer service representative may wish to see a map of the area immediately surrounding a customer within their customer service application. This requires not just data which is stored in the GIS, but also the functionality to render the map.

These types of situation can be handled by using component or distributed object technology. The main technologies of relevance in this area are Microsoft COM/ActiveX, CORBA and Java Beans. Both ActiveX and Java Beans provide the capability to define components which have a user interface, which can be directly imbedded within an application. So the example of a map component which can imbedded into an application could be implemented in either of these environments. An advantage of Java Beans is that they can run on many different hardware and software platforms, whereas ActiveX is really restricted to Windows platforms. As the next section discusses, the rapid growth in use of Personal Digital Assistants (PDAs) and other mobile devices, many of which do not run Microsoft operating systems, is likely to be a driver for better cross-platform solutions. CORBA does not provide the ability to plug in a component with a user interface, but it allows applications to invoke functionality in a distributed environment. CORBA is the most mature of these technologies for operating in a distributed, cross-platform environment.

Distribution of functionality
A key aspect of "Uniting the Enterprise" is providing access to functionality, and data, throughout the enterprise, wherever people are. Internet technologies provide an excellent mechanism for doing this. Both ActiveX and Java allow sophisticated applications to be run in Web browsers or other lightweight containers. The idea of three tier (or more generally, multi-tier) applications allows heavy processing to be done on applications servers, while display and user interaction can be handled on a lightweight machine. The technologies of the web, Personal Digital Assistants (PDAs) and wireless communications are coming together in a way which will revolutionize work processes for mobile or field workers. Cell phones which can act as web browsers are now available. While at the moment the bandwidth which is generally available for wireless communication is too slow for handling significant amounts of graphics, this will change over the next 2-3 years. Other technologies such as voice recognition are also reaching a level of maturity which will soon make it realistic for mobile users to run sophisticated SRP applications on a small handheld unit which directly accesses corporate databases via wireless communications. It is interesting to note that Microsoft is still not a major player in this rapidly emerging market. Nokia, Ericsson and Motorola, who currently own about 70% of the world cell phone market, have formed a group called the Symbian alliance, in conjunction with British software company Psion, which is developing an operating system called EPOC for these integrated cell phones / PDAs. In the current PDA market, the Palm OS continues to maintain a strong market share. Of course Microsoft should never be written off, but at the moment it looks as though a focus on cross-platform technologies such as Java or plain HTML may be the best choice for distributing functionality across the enterprise (and to mobile systems in particular).

Summary
As GIS evolves into SRP in the utility marketplace, integration between major business applications becomes increasingly important. This paper has summarized some of the technology and standards developments which are key to achieving a high degree of integration in a cost-effective manner. The integration bus approach is being rapidly adopted as the way to integrate major business systems, both within and between companies, and it offers major advantages over traditional point to point interfaces. XML has a major role to play, and looks like it will be the standard format for passing the data between these systems. The IEC 61968-1 standard being developed by WG14 on top of these technologies will be extremely important in simplifying the integration of systems for distribution management in electric utilities.

While the integration bus approach is excellent for many purposes, there are still integration needs for which it is not appropriate. There will continue to be a role for the major component and distributed object technologies (COM, CORBA and Java beans) in more directly imbedding functionality from one application within another. Finally, in terms of "Uniting the Enterprise", the impact of Internet technologies combined with advances in portable devices and wireless communications will have an enormous impact over the next 2-3 years. It will be possible for mobile users to access sophisticated applications and corporate databases wherever they are via lightweight handheld units and wireless communications.

Acknowledgments
I would like thank Greg Robinson of Xtensible Solutions for providing me with very useful information on Working Group 14, and Alan Clarke and Charlie Savage of Smallworld for their input on various topics including EAI, XML, CORBA and Java.

References

Batty, P.M., 1998: Beyond GIS - a new level of integration. AM/FM Conference Proceedings.
www.xml.org and www.w3.org/xml - information on XML.