Is it any business of the business if IT wants to implement SOA?
There are some who think not, and I can see their point. After all, what does it matter to the business how IT structures its code and does its job? The business doesn't care if you're doing object-oriented, component-oriented or service-oriented architecture. Really, it doesn't. The business only cares if you're helping it achieve goals.
I've argued against this position previously. I appreciate the argument, but it didn't feel quite right. I sided with those who feel that, since SOA could impact delivery time and costs for projects, IT should be willing to explain why it's moving to service-oriented architecture.
Still, something wasn't quite right -- something was missing from the discussion. I wasn't sure what was missing was until I read "SOA Goverance - Long-Term SOA Implementation and Management," by Wolfgang Keller, published earlier this week on InfoQ.
After reading this, I know what's amiss. In either case, IT has already decided it wants to do SOA. In effect, whether you share your decision with the business or not, you're already committed to the idea of SOA. Once you've taken that step, you've got a technology in search of a project. You've got IT for IT's sake.
And that's where IT always gets itself in trouble.
Oh sure, IT may make some noise about business value, tossing around phrases like "flexibility" and "agility." The assumption being that, if it helps IT be more efficient -- deliver programs more quickly -- well, then there's your business value. However, since you can use that sort of justification for just about every technology under the sun, the argument gets a bit useless over time.
As this article points out, it's true business owners doesn't need you to explain SOA to them. They don't care. And it can work to start SOA as an IT initiative. But it's a dangerous practice, and in many cases, when SOA starts as an IT initiative, it often loses momentum or goes dormant.
So, what's the alternative?
The alternative is to listen to what the business wants and to solve those problems. SOA becomes not an end in itself, but a piece of the overall IT governance. It may seem like semantics to some of you, but the starting point can make all the difference. Here's how, according to the article:
You can now ask yourself, what the above has to do with SOA. Deploying a proper IT governance system means aligning IT with business. If the business side has the above-mentioned strategic demand for projects and plans that can best be implemented with a SOA, then SOA will happen automatically, so to speak. In any case it then does not have to be "forced" but instead can be introduced as a suitable means for implementing business goals in such a manner that it is created in the background -- while the business goals remain in the foreground.
Perhaps this is what those advocating against "selling" SOA to the business meant originally. (And, by the way, I never advocated "selling" SOA to the business. My post was on how you talk about SOA to the business -- I never used the term or concept of "selling SOA.") But thus far, I don't believe anyone has really made this point as clearly or precisely as Keller.
The article goes on to look at IT governance and special issues involved with SOA governance. It's a definite must-read for any executive considering or involved with SOA.