SOA in the Real World 

Selling SOA Architecture

By Tony Baer, President, onStrategies , 10/05/2006

Print this article Email this article Talk Back! Write to Editor

Want to get that IT project approved? Forget strategic vision. Over the past 5 – 6 years, conventional wisdom has been that only tactical, incremental projects promising targeted ROI are getting green lighted.

Yet, as we were listening to an IBM conference call yesterday about their latest SOA offerings, they trotted out a customer who described SOA investments as “a journey, not a one-year investment choice.” Were we imagining things? Or did this signify that it’s OK to get strategic again?

Until now SOA has been promoted as a sort of third way. Unlike 1990s-style reengineering, SOA doesn’t require you to rip things out. By wrapping the legacy in a standard container that exposes functionality as a WSDL service, you can isolate change to the new services layer, letting sleeping dogs lie.

At first blush, it sounds almost like immaculate conception. No matter what you do at the services level, nothing happens to those complex, legacy assets that took generations to build, and are frankly rather mysterious to decipher. And by relying on a standards-based integration model, heck, the new code theoretically should become easier and more transparent to maintain and repurpose.

You’re probably thinking this is sounding too good to be true.

Admittedly, if you stick to building just a few badly needed services on a one-shot basis, you can get away without worrying about building yet another new legacy. But as you know all too well, priorities change, systems change. Stuff happens. You won’t be able to stop with just a couple services.

And so at some point, you’ve got to bite the bullet and define a new architecture that sits atop the old.

Otherwise you’ll wind up with a new generation of spaghetti, one that’s a bit more standards friendly, self-documenting, and an enabler of what’s at best ad hoc reuse. As for policy, you’ll be improvising from one service to the next.

So your next challenge is selling top management on the need for yet another new architecture. Yup, you can promote agility, but that only works if the business is ready, and anyway, how are you going to quantify the benefits? When you get desperate, you’ll probably wind up cost justifying the new architecture, not as a totality, but through reuse, one service at a time.

The customer in the IBM call cited three categories of reuse, ranging from enterprise, which consisted of a select few universal building blocks, like customer management. Then there is reuse at the department or business unit level, where you have to greater potential for reuse because of a shared context. And finally there will be some services that are so unique that they probably won’t be shared. But you want them managed under the same policies and infrastructure. The customer claimed that one of the ”enterprise services” saved up to 20% of the cost of the SOA architecture and new infrastructure.

1

• Next