With my keen, near-superhuman sense of intuition, I'm detecting there may be some frustration with the idea of SOA.
In fact, the frustrated would probably say that they're not frustrated with the idea of SOA -- they're frustrated that there is no idea. There's only an Ideal.
And ideals can be very frustrating.
My first clue that there might be a problem came after I subscribed to a service-orientated architecture newsgroup on Yahoo a few days ago. I thought it'd be a great way to figure out the real issues IT leaders face. So, imagine my surprise when the very first -- and pretty much the only widely commented-upon thread -- was titled, "SOA is Doomed."
Now, I'm not going to tell you everything published in this newsgroup, because I don't think people join newsgroups so they can see their remarks broadcast on a public blog. So, I beg their pardon for even mentioning it -- but, man, those people are pretty darned ticked off with the whole SOA thing.
It's not that they're against the idea of services or the technologies. They just think there's too much confusion about the term SOA. Is it an architecture? Software? An ESB? Governance? Business philosophy? In short, they contend the term SOA is so undefined as to be useless.
My second clue came from a reader's blog comment, which lead to a brief e-mail exchange. The reader, John O', was also disgusted with the lack of clarity on SOA's meaning -- particularly the term, "reuse":
If someone can definitively define what 'reuse' means -- preferably with examples -- that would go a long way toward helping promote SOA among other things.
John O' pointed out it's easy to say you're going to build something for reuse, but the devil's in the details. How will you know for certain it will be reusable in various circumstances? I suppose this is what a registry is for, but that doesn't really answer the question. I mean, you can say a service will work in this or that situation, but the real question is whether it actually does work in said situations.
Can you really guarantee the code will be that generic?
And even if you can, should you? I hadn't really thought about the problem until I saw this pictorial representation, using a helicopter to represent traditional IT paradigms and a Lego-built helicopter to represent the SOA paradigm. Yes, I get the point, and yes, they look alike. But I sure would hate to depend upon the Lego helicopter in an emergency.
There are a lot of philosophical discussions about SOA, but building services correctly is a concrete, ROI-breaking challenge.
John O's point is supported by a recent piece by David Linthicum, who consults on SOA implementations. Linthicum has found that reuse of services really isn't that common or even desirable, once you start exposing them:
Don't get me wrong, this does not mean that reuse is not a core value of SOA, but its value is much less than we expected, or the "SOA hype" has been stating. The true value of SOA is the ability to create enterprise architectures that provide much better agility than the overly complex, static and fragile architectures we have around today.
This confused me, because I thought the way SOA created agility was because developers could reuse services and thus create new applications on the fly. I bet I'm not the only one who'd like to see more about that topic.
OK -- clearly, a few techies are disgruntled over SOA. But is it a trend?
I wasn't sure, until the newsgroup linked to SOA Facts, a Web site offering sardonic "facts" about SOA and an unsettling tendency to connect SOA to Chuck Norris. A few samples:
The SOA Facts Web site was the last piece of evidence I needed. If it's being made fun of it, it must be a trend.