Analysis: Texas Utility Finds a BPM Silver Lining in SOA

Austin Energy isn't using a business process management (BPM) suite, but it is realizing business process improvements as part of its enterprisewide service-oriented architecture (SOA) initiative.

Two years in the making, the SOA initiative is helping the $1 billion electric utility integrate and leverage disparate legacy systems. It's also helping the business adapt in the face of deregulation and new competition thanks to new energy storage and lower cost power generation technologies.

"The energy business is rapidly changing, so the company wanted to free up capital to fund new business models," says Andres Carvallo, CIO. "That meant 'right sizing' the current IT contracts and maintenance agreements to free up dollars to build an SOA driven 100 percent by the business processes."

On its way to building the new architecture--including an enterprise service bus (ESB) and enterprise portal built on the IBM WebSphere application server and middleware--the utility decided to tackle business processes very tactically, with well-defined requirements and desired benefits. Work on the first of those improvements began last November, when the company targeted the customer-support process around power outages. Austin Energy used the WebSphere Business Modeler to spot bottlenecks and potential improvements in the existing process, which was supported by a system written in COM objects and Visual Basic. Scalability was the key problem, as the system could only handle about 4,000 calls per day. As the calls came in, the customer service reps couldn't log on fast enough, they experienced lags referencing customer information in the databases and billing systems, and they couldn't create work orders quickly enough.

To speed the process, the utility created a composite application comprising five Web services that link existing systems and databases on a robust SOA infrastructure. "The new application went live on May 3, and the very next day we had a storm and were able to process 20,000 calls," Carvallo says.

Average call times dropped to one-and-a-half minutes from the previous range of three minutes to five minutes. Adding to the savings, work orders were streamlined from a paper-based, batch-oriented system to direct integration with a workforce management and dispatching system.

"We haven't been able to quantify the savings yet, but when you can only get to 4,000 calls--instead of 20,000--you're missing a lot of outage information that can give you a better picture of the source of the problem," Carvallo says. "That means you know right where to send the repair trucks, and that's a big deal, given that every truck roll costs at least $70."

Austin Energy is currently using the Modeler to find ways to speed and automate as many as 72 processes related to turning off and turning on service for customers and dispatching service crews. "Anything that involves mobile support, because the ROIs are very measurable, the benefits are quickly realized and they have a big impact on customer satisfaction," he says.

The utility is also exploring how and whether to integrate customer information systems with an interactive voice response (IVR) system and the enterprise portal. "With personalization based on your account registration information, you could enter a PIN number or account information and see exactly when your power will be turned on or restored," Carvallo explains.

Where does an SOA initiative end and BPM begin? In Austin Energy's case, the literal point of intersection is the business process modeling tool. But from Carvallo's perspective, "if you don't have your infrastructure, data models and integrations in place, you can't do enterprisewide BPM. Maybe you could do one BPM solution at a time, but to me, SOA was the solution we wanted because we were trying to solve a corporatewide challenge."

That said, Carvallo says the crucial difference between SOA and previous architectural approaches is that business processes drive it. "You map to the business process and you rationalize the infrastructure that delivers the functionality that makes that business process possible."