With today’s changing regulatory environment, business flexibility is crucial to a utility’s survival. But it is difficult to be flexible if data cannot be easily exchanged between your own business units and with third parties. US utility Idaho Power was one company which found itself in this situation.

The company took the step of implementing a software platform known as the ActiveWorks Integration System to transform its business into an e-Business. The increased operational efficiency meant that the utility could continue to offer its customers competitive prices in the deregulating market.

Fragmented systems

Idaho Power is a US investor-owned utility based in Boise, Idaho. It serves 375 000 customers in a three-state service area that includes southern Idaho, eastern Oregon and part of north Nevada. The company owns 17 hydropower plants and is a part owner of three thermal generation facilities in Wyoming, Nevada and Oregon.

To run its business efficiently, Idaho Power has to acquire information from customers and exchange data with service suppliers. Two systems automating these functions for different business units are a payment protection insurance plan and an electronic bank payment programme.

The payment-protection plan transfers data associated with providing insurance to Idaho Power customers. When a claim is paid, the insurance company sends a remittance advice so Idaho Power can credit the appropriate account.

The bank payment system receives payment information via electronic data interchange (EDI) from the bank.

Idaho Power needed to integrate the received EDI data with its own in-house designed customer accounting system without writing custom programmes.

The EDI format that the federal government made mandatory in January 1999 was challenging since the utility was inexperienced in using EDI formats. Another requirement was to format payments from CheckFree, Norcross, GA, for loading into the customer information system (CIS).

However, its computer systems applications were connected by a number of point-to-point integrations. Analysts estimate that the development of each interface in a large organization can cost

$50 000 to $100 000. Idaho Power needed a way to increase its information exchange capabilities while keeping costs down by reducing the number of interfaces.

The company chose the ActiveWorks software to achieve this in real-time. Idaho Power explained that both projects had a payment component – the insurance company sends payments based on claims made, and the banks sends payments as a normal part of processing. In its previous approach, both systems would have been implemented with custom mainframe programmes and would duplicate the logic needed to accept payment.

“Now we have one approach, being able to manage and run that in a production environment is easier than having to deal with two or more. In the past we would have custom PL/I programmes written on the mainframe. Now there is minimum coding and interaction with the mainframe. From the server side this is much easier to deal with,” noted Rob Eamon, Systems analyst at Idaho Power

This approach saves time and money. Typically it could take three to four weeks to develop a minimal application at a cost of $40 000-50 000. A similar integration, i.e. mapped on to one which has already been done but making minor adjustments, would now take a couple of days.

Eamon added: “The insurance company was the first integration that we did. It had a payment component and the reason we did the interaction with the bank was to receive electronic payments. So we were able to leverage the work from the insurance company to get the bank up and rolling pretty quickly.”

Focus on integration

Idaho Power first began looking at integrating its business units a couple of years ago when its two main business units could not come to an agreement on a customer information system. Eamon explained: “Our general business manager said let’s not go for the big ‘one-size fits all’ application. Let them go their own way and we’ll focus on the integration.”

A team was put together to start addressing the integration. The team came down to two approaches – data integration and process integration.

The data part uses some data warehousing concepts – such as replication, transformation, movement. The process integration tried to focus at the business process level and home-in on business events.

“We did not want to be coding down at the message level, having to worry about message delivery etc. We wanted to be able to focus on the business process,” commented Eamon.

After looking at eight or nine different vendors and products, Idaho Power evaluated the top three products and opted for ActiveWorks. The evaluation lasted from August through October last year, and the company began using ActiveWorks in February this year.

ActiveWorks architecture

Idaho Power, like many companies, cannot afford the risk of unplugging proven systems – even if they are fragile and outdated. Operating departments are not going to give up their computers. The ActiveWorks integration system offers an alternative to replacing a patchwork of systems with a single new design, which would probably again become outdated before too long.

With the ActiveWorks software, both systems convert their payment orders to a common event, which is then processed through the integration platform that serves the requirements for all payments, regardless of origin.

“We basically exchange flat files (text only files with one-line records) with the bank and insurance company, and use ActiveWorks as the interaction between the flat file and our legacy system,” said Eamon

The system defines a standard unit for capturing, analyzing, and exchanging information. This unit, called an event, is based on business process engineering. It embraces nearly all kinds of information resource running on every kind of platform, including legacy applications, package software products, custom applications, databases, and the internet. Rather than replacing these systems, it uses ‘Adapters’ to integrate them.

ActiveWorks enables resources to exchange events and hides the complexity of distributed computing in scalable “Information Brokers”, which mediate the delivery of events. The ActiveWorks architecture is designed to be adopted incrementally.

The architecture enables IT departments to connect diverse corporate information resources to each other. It does not replace heterogeneous platforms, legacy systems or application servers but can integrate them all at whatever pace the business manager and/or IT department chooses.

The ActiveWorks architecture consists of just five kinds of elements (see Figure 2):

(1) Information resources are producers and/or consumers of corporate information. The range of potential resources is very broad; conventional databases and applications are two examples.

(2) Adapters integrate information resources to the ActiveWorks system, enabling resources to work with events. The combination of a resource and its Adapter is called a ‘Broker client’. Idaho Power made use of Active’s CICS Adapter to link to its IBM mainframe running OS/390, and the Data Transformation Agent to parse the EDI files.

(3) Events are self-describing, typed messages exchanged between Adapters and Brokers over TCP/IP networks. To send an event, a broker client publishes it; to receive events of a particular type, a Broker client subscribes to that type. Each event is typed to distinguish it from other events, and is self-describing so it can be filtered by its contents. The event definitions and semantic data about the event are stored and managed by the Information Broker.

(4) Agents are software components that embody business processes by subscribing to particular types of events, applying business rules or transformations to those events, and as a result, publishing other types of events. Like Adapter-resource pairs, Agents are also Broker clients.

(5) Information Brokers mediate the delivery of events among Broker clients, and serve as central points for administration, management and security. These are the hubs through which all events flow.

Figure 2 shows many different kinds of resources publishing and receiving subscribed events via their Adapters, symbolized by diamonds, and an Information Broker in the centre. Adapters integrate diverse information resources by enabling them to exchange a common unit of information: the event. Events constitute a common currency for information exchange and a common language to describe and discuss corporate information. Agents communicate directly with the Information Broker.

Each event type contains information particular to it, such as EmployeeNumber or InvoiceAmount. An example of an event type for OrderShipped is shown in Figure 3. Events contain all the information pertaining to a business event.

These events can be analyzed at any time without relying on other resources such as databases, which are subject to change. An event can also contain semantic data often referred to as ‘metadata’, that a Broker client can access at run-time.

In any system high volumes of data traffic can present problems. Regardless of what security and storage options are chosen, sufficient event traffic volume can swamp a Broker. Further, delivery times can be unacceptable if events published on one side of the world must pass through a Broker located on the other side.

To accommodate variations in volume, the ActiveWorks architecture supports multiple cooperating Information Brokers (see Figure 4).

Brokers can be added while other Brokers are running. Multiple Information Brokers make the architecture scalable; it can meet increasing volumes with added capacity, and provide worldwide coverage without sacrificing fast local response.

Information Brokers deliver events to each other using an asynchronous store and forward technique. When a Broker receives an event that a neighbour has subscribed to but the neighbour is unreachable, the Broker reacts as it does for any subscriber: it queues the event and delivers it when the connection to the subscribing Broker comes back.

Future integration

So far the new system has worked well. It is currently being used on a fairly small scale but Idaho Power is now in the process of replacing its customer information system and plans to use ActiveWorks for several of the integrations that are necessary for this.

Other integration projects will also probably follow. “The overall goal of our integration projects is to increase our adaptability and become even more efficient through e-Business,” said Eamon. The ActiveWorks Integration System will provide Idaho Power with this capability and will become more valuable as its e-Business capabilities and integration needs continue to grow.