SOA and the Potential for Cascading Failure

You’ve heard the hype and understand what web services are all about. You’ve got your developers working hard on this latest attempt at enterprise integration by developing web services that connect your vital systems into what you hope will become your company’s first generation of SOA (service orientated architecture).

But, suddenly, it hits you: your web services are out of control; calling on each other to supply vital links between your mission-critical systems and your customers, partners, suppliers and vendors and you have no idea what systems are dependant on what web services to function.

Of course, you don’t realize this until a developer somewhere makes a change to an important web service that is underpinning other web services that connect to eight, 18, 80 separate applications and, all of sudden, these applications don’t do what they are supposed to be doing.

You halt all your development work and go back to square one to rethink your approach to this newest attempt at IT/business alignment, the agile enterprise, a loosely coupled infrastructure, utility computing, etc., etc. (in this context all of these catch-phrases refer to the same thing—making IT more flexible and responsive the needs of the business).

“The advantage of (web services) is about reuse,” said Keith Swenson, Fijitsu’s CTO. “So now I can have multiple applications that all use the same component. And that’s really great until you … change that one component; you could now break three or four applications.”

Outlined here is a worst-case scenario, said Swenson, but the potential for cascading failure across many applications is very real. The applications probably won’t crash but they could stop functioning properly and, perhaps more troubling, begin returning incorrect data that goes unnoticed.

To get around this problem, Cingular’s Vice President of IT Architecture & Engineering, Victor Nilson, suggests using a service catalog and a registry/repository to keep track of all deployed web services, their interdependencies and the applications that call on each.

If this approach is taken early in the process, then the above scenario can be avoided. But this takes discipline and solid governance: something many IT shops are only now, two-years after Sarbanes-Oxley, starting to get a good handle on.

“When you have something as powerful as web services and the way they can have dependencies on each other and the rate of which teams can produce them today, I do think there are many IT shops where CIO’s probably aren’t as well organized against that as they need to be,” said Nilson.

This is where a UDDI Registry/Repository comes into its own, said Ivo Totev, Software AG’s VP Product Marketing for Crossvission. Without such a tool, trying to understand what your web services are and how and where they are being consumed, would be very hard if not impossible.

But that only takes care of the technical stuff. There are products on the market today, such as Software AG’s CentraSite web services/SOA management platform, to help with this issue. What’s more important is reigning in your developers and putting strict controls over version control and change management, said Zap Think Founder and Senior Analyst Ron Schmelzer.

“Because, until now, because systems are all artesian craft … these developers have a lot of power,” he said. “Now the developer is just sort of the cog-in-the-wheel. It’s just like their implementing a service the way the business has defined it to be and they really shouldn’t have the same kind of control of that service once it’s in production.”

In other words, this may cause you problems if you don’t have in place tight controls over who is changing what, when and why—something many IT shops struggle with everyday.

But, the news isn’t all bad. SOA and web services are among the most powerful tools for positive change to come along in a long time—if managed correctly—and should be embraced by CIOs looking to glean the most benefit and value from their operations with a minimum of effort and expense, said Nilson, who likens his experience controlling Cingular’s web services to application portfolio management, but at the next level down.

“In our view it’s the next level of portfolio management,” he said. “Historically, people have done portfolio management at the application level. We’re trying to do that at the service level as well. If you have that discipline it’s very nice because now you can inventory and manage it. You can stay on top of it and … it gives you a capability of managing it that never has historically existed in IT.”