November 24, 2008

Given two competing companies with equal capitalization, intellectual property, technology, who wins? The fastest-moving one, of course, but that doesn't mean the one who churns out the most widgets; it means the one that can most rapidly adapt its business model to changing conditions. The question for a CIO is how to architect IT services to support rapid innovation. At Austin Energy, Andres Carvallo faced that question five years ago and found the answer in a service-oriented architecture (SOA), which has helped put the company in the forefront of energy innovation.

Andres recently spoke to News@Cisco about the benefits of SOA and how to plan, finance, and sell it to the executive team.

How do you define service-oriented architecture (SOA)?

Andres Carvallo: I think the best way to define it is to start by describing the fundamental problem it solves. IT systems undergo evolution in much the same fashion as biological systems: most of the time, old stuff doesn't get thrown away, it just gets built on top of or re-purposed. So enterprise CIOs are prisoners of the business-process equivalent of spaghetti code, with their data, their applications, and their business processes all tangled together in complex interdependencies that make changing anything a painstaking and somewhat dangerous task. If you miss a dependency, the result is going to be the kind of phone call from the CEO you definitely don't want!

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 are available to any other service that needed them-for instance, the user authentication module would also support employee inquiries into their 401-K plans.

What do you see as the primary benefits of SOA?

Andres Carvallo: There are two well-known benefits, but the one that is top of mind with many CIOs is not really the one that matters the most. What most people think of when they hear "service-oriented architecture," is better integration of IT systems to lower operational costs, which 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. IT spends most of its time just trying to keep things running.

But 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.

That's really the primary benefit SOA delivers. Rather than carefully picking your way bottom up through layers of IT functionality to figure out how to change a business process without breaking something else, 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 into a business service.

At Austin Energy five years ago, before SOA, about 85 percent of our capital and operational expenditures went for keeping the lights on. That left only 15 percent or so for doing new things. Now the ratio is more like 50/50, and since SOA makes it much easier to build new business processes, the increased funds we have available for innovation can go even farther.

It sounds like SOA involves major changes. How do you plan such a major overhaul?

Andres Carvallo: For planning, the one thing you can't do without is good business systems analysts, people who can take a business process management tool and successfully model what's going on in your business: the inputs and outputs, the people involved, the assets involved, the time involved. For instance, at Austin Energy just to get started 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 didn't. Then, having identified about 3000 different processes, we narrowed the list down to 72 critical ones, 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.

Your plan also has to be a long-term one that can be realized one piece at a time, at least to begin with, so you can demonstrate an ROI each step of the way. Web Services can be a help here, 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.

What about financing your SOA initiative? Can the piecemeal approach deliver enough savings?

Andres Carvallo: No, you're going to find bootstrapping almost impossible. The ROI of each step I mentioned above won't be enough: at Austin Energy the process took five years as part of an overall IT transformation that cost about $50 million. But if you're operating without a service-oriented architecture, chances are pretty good there are significant inefficiencies elsewhere that you can fix without major infrastructure changes and use the savings to get your SOA effort off the ground.

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.

Finally, how do you sell such a huge effort to the executive team?

Andres Carvallo: Your discovery process with the systems analysts will supply a lot of the ammunition you need, because the picture that will emerge will be shocking, but not really a surprise. That is, parts of it will be surprises to some of the executives and not to others, and who will be surprised depends on what part of operations you're talking about. Which is why you need SOA in the first place: no one has a complete overview of company operations because of systems redundancy and lack of integration. Once you get them all on the same page-mocking up some dashboards to show them what they'll be able to do with SOA that they can't do now can help-you're most of the way there.

It's not an easy sale, and you really have to do your homework. But, at some level, any decent executive team understands on a gut level that the future belongs to companies that can master business process innovation. What you have to do is show them how a service-oriented architecture gives them the framework, the capabilities, and the tools to do that, and they're sold.