On May 3, Andres Carvallo, CIO at Austin Energy in Texas, joked that a spring storm was needed to test the first, newly installed application to run on the electricity utility’s service-oriented architecture (SOA).
At 9pm the next day, Carvallo got his wish as a severe rain and hail storm rumbled through Austin, leaving 52,000 customers without electricity and putting the new AECall application into action only a day after going into production.
AECall, which links Austin Energy’s outage management system and call centre application, processed more than 20,000 calls per day for three days during the storm, whereas the previous call-processing system would have been overloaded at 4,000 calls per day.
“Lo and behold,” Carvallo says, “we tested the system” and it worked.
The application was the first to emerge from a plan initiated more than two years ago to build and use a SOA to integrate applications that span the utility’s five divisions, he says. At the same time, the new system will eliminate redundant legacy systems, he says.
After a first stab at building a SOA failed, Austin Energy started using IBM’s Rational development tools to re-engineer all of its 72 major business processes to be tied into a SOA. The company is also using IBM Rational tools to help model and build new business processes to be linked to the SOA. IBM’s WebSphere middleware is used to run the services.
“The SOA is driving everything we do,” Carvallo says. “It touches every major enterprise application.”
The new AECall application, for example, uses five different web services to query the multiple databases, where data about customers is housed, and to reconcile that information for the outage restoration application, he says.
The utility is now building its second SOA application, which will use web services to link geographic information system maps to the application its 600 mobile crews use to respond to customer calls.
Before working with IBM, Carvallo says, the company made “some unfortunate mistakes” working with another vendor on the earlier failed effort to build a SOA. He won’t name the other vendor.
Carvallo blames the early failure on the lack of an initial hard-and-fast focus on business processes, and a lack of adequate support and services.
In addition, Austin Energy’s previous integration strategies were driven by IT rather than the business, he says.
“This one is business-driven,” he says. “This time around, when the business process is at the heart of the integration, change management happens much more easily because the business user wants it to happen. It is not really a SOA if it doesn’t involve business process innovation.”
Carvallo won’t disclose the cost of installing the SOA, but says it won’t be more than the cost of maintaining the legacy systems that the SOA will eventually replace.
Ken Vollmer, an analyst at Forrester Research, says companies interested in boosting the efficiency of business processes with a SOA shouldn’t mention the term to its business users.
He says IT should work with business users on a “business process management improvement effort, [which] will be the impetus for a SOA.”
Vollmer also notes that Austin Energy started its latest SOA effort with the outage application, which could show a quick and visible improvement in call processes. “Even if you have a huge effort in total,” he says, “you need to pick off a small piece that can show value.”