I've come across a few clients now with some internal debate as to whether SOA is a good idea. Sometimes of course it isn't. But when part of an organization buys into the value proposition and another doesn't, there can be serious conflict. A couple clients I've had have been in the throws of this debate but the interesting part was that the management and business analysts had bought into idea, but the IT department was dead set against it.
As it turns out, I've noticed 2 common reasons why IT departments resist adopting SOA architecture. The first reason is, they have deadlines. This is where the IT department understands the value proposition and may even be enthusiastic about its possibilities, but they are either understaffed or overcommitted to current, immediate concerns. In short, its hard to think about a better house when the one you have is on fire. The only progress that can be made here is baby steps at best.
The second reason I've found that IT departments resist SOA is that they see it as "just another rearchitecting". These folks are long timers and have heard many pitches about new technologies that will make their lives better. They are experienced and jaded enough to view SOA as just another one of these fads. What is even more interesting is that sometimes they are using SOA-like thinking but are just not calling it SOA. For example, focusing on discrete services they offer to clients. Enforcing good best practices (governance) of those service architectures. Using standardized data models. All of these are good SOA features. Because SOA did not invent these features, some people use them but don't call it SOA.
In my book, I often avoid the term SOA when talking to clients, because it can bring up assumptions or opinions on the term rather than get to what it means in terms of practices. So I don't care if you call it SOA, if it works for your use case, just use it.
9:42:00 AM 
|
