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 its OK to get strategic again?
Until now SOA has been promoted as a sort of third way. Unlike 1990s-style
reengineering, SOA doesnt 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.
Youre 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 wont be able to stop with just a couple services.
And so at some point, youve got to bite the bullet and define a new architecture
that sits atop the old.
Otherwise youll wind up with a new generation of spaghetti, one thats
a bit more standards friendly, self-documenting, and an enabler of whats
at best ad hoc reuse. As for policy, youll 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, youll 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
wont 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-