By Andres Carvallo, CIO, Austin Energy
Many CIOs, when they hear the phrase "service-oriented architecture" (SOA), may think first about its potential for delivering better integration of their IT systems, and thus lowering operational costs.
And that's entirely appropriate, because integration is a major pain point for most CIOs. The information their business runs on is scattered across many different systems, built using too many programming languages and data standards, and linked by too many manual processes. Data gets tossed from one silo to another like a hot potato because critical processes are repeated rather than shared, and IT spends most of its time just trying to keep things running.
SOA and Innovation
That's where Austin Energy was five years ago:
- 85 percent of our capital and operational expenditures went for keeping the lights on.
- 15 percent of our capital was left for doing new things.
With the improvement in integration made possible by our transition to SOA, the ratio now is more like 50:50.
The improved ratio between "housekeeping" and innovation is the key to the real benefit of SOA, which is only secondarily a strategy for saving money and increasing IT efficiency. Its fundamental raison d'étre is improving business agility by increasing IT's ability to deliver business services as fast as the company needs them.
Look at the Competition
Consider two competing companies with equal:
- Capitalization
- Intellectual property
- Technology
- Etc.
It's obvious that the fastest-moving one wins. And that doesn't mean the one who churns out the most widgets or whatever; it means the one that can most rapidly adapt its business model to changing conditions. What you've got to realize is that you're not in the business of selling energy, or routers, or financial services. You're in the business of moving information, so your core competency is your ability to innovate your business processes to move it faster than your competitors.
Keep Business Processes Untangled
But without SOA, you are a prisoner of the business-process equivalent of spaghetti code, the natural result of the evolution of IT systems over the past decades. Your data, your applications, and your business processes are all tangled together, with complex interdependencies that make the process of change sort of like playing pick-up-sticks. Only what may collapse if you change the wrong piece of code isn't just a pile of sticks, but a critical business service-resulting in the kind of phone call from the CEO you definitely don't want! So, even if you could keep everything running just by waving a magic wand, your pace of innovation would still be severely limited.
By contrast, SOA groups software functionality around business services, decouples data from applications and processes, and enables applications to easily exchange data with each other to support business processes, thus untangling those interdependencies.
In a way, SOA is just a logical extension of modular programming, only with the chunks being hundreds or thousands of times bigger, and representing business processes rather than application functions. For example, a product order business service for customers might include functional modules supporting processes such as user authentication, inventory checking, pricing, order status, shipping status, etc. All of these modules would also be available to any other service that needed them-for instance, the user authentication module would also support employee inquiries into their 401-K plans.
Carefully Orchastrating SOA
So, rather than carefully picking your way bottom up through layers of IT functionality to figure out how to change a business process, you end up working top down, from process to functionality. That's why architecting a SOA-based service is called "orchestration" rather than programming. Like a conductor, you point at the various instruments you need to build a symphony of business processes: a business service.
But getting from here to there is not easy, and a "boil the ocean" approach is guaranteed to fail. At Austin Energy, it took five years as part of an overall IT transformation that cost about $50 million.
You need a long-term plan designed to be realized one piece at a time, so you can demonstrate an ROI each step of the way. Web Services can help, since you can use them as a kind of "poor man's" SOA to wrap legacy applications up in interfaces that let you start sharing data in service-like fashion without re-architecting your entire infrastructure. But you're still going to have to build a brand-new "highway" on top of your existing one in parallel with any such efforts, so that when the time comes for real SOA, you've got the infrastructure you need to do it right.
Look for other inefficiencies you can address without major infrastructure changes, fix them, and use the savings to launch your SOA effort. That's what I did at Austin Energy. I did a thorough asset management inventory and found that we had way too many vendors and contracts. By consolidating vendors we got better discounts and dramatically lowered our asset management costs. The savings in the first year amounted to about $10 million, which was more than enough to launch our SOA re-engineering effort.
Above all, remember that the real power of SOA comes from transforming business processes company-wide. That requires a huge up-front effort to discover what those processes are, who uses them, how they use them, what works and doesn't work.
At Austin Energy, I worked with a team of four business systems analysts to interview 500 people (almost a third of the company) over a period of two months to build a picture of how things worked-and, just as important, how they didnt. Which is why we needed SOA in the first place: no one had a complete overview of company operations because of the redundancy and lack of integration that I mentioned at the beginning.
Of course, we also had to decide where to focus our efforts. We had perhaps 3000 significant processes, but it would take forever to try to fix all of them, so we narrowed it down to a list of 72 critical processes that had to be part of our SOA initiative, mostly focused on customer interaction, cash management, and product delivery and service. We looked for ways to re-architect these so they weren't scattered across multiple silos as a bunch of micro-processes. What resulted was a list of about 25 web services we needed to create to support the new infrastructure
Today, Austin Energy is a more agile company, with the ability to implement new processes and services very rapidly. For example:
- Customers can access information about their service, and make payments, through an online portal.
- Our field service response time has shrunk from as much as two weeks to a matter of hours.
- One-third of our fleet is now operating on automated meters.
- We've enrolled 65,000 customers in demand-response initiatives.
- We're able to attract higher value customers such as data center operators due to our flexible services, and the fact that we're the first electric utility in the United States to receive ISO 9001 certification for its quality management, something that would have been impossible without SOA.
- And SOA has positioned us to deliver the smart grid, which is critical in dealing with the rising cost of oil and gas through increased efficiency.
The future of any company lies in mastering business process innovation, and my experience at Austin Energy has convinced me that a service-oriented architecture gives you the framework, tools, and capabilities for doing just that.
