Earlier this month, ZapThink wrote an item called, "Who's Killing SOA." You may have to be a registered member to read it, but registration is free. The list included integration platform vendors, whom ZapThink accused of slapping "Web Services interfaces on your stuff, call it an Enterprise Service Bus (ESB), and sell it as SOA middleware."
This week, ZapThink is back with a follow-up column called, appropriately enough, "What's NOT Killing SOA?" I suggest checking it out because, really, it could've just as easily been titled, "How to Make Sure Your SOA Succeeds."
For instance, the first item is, "Proper Scoping of SOA Projects." SOA advocates often argue over whether you should implement SOA from the top down or bottom up or even middle out - but no matter which you choose, if you're biting off too big a chunk, you're making a mistake, points out ZapThink.
It's hard to argue with that. But the column goes further, contending SOA doesn't have to be implemented enterprisewide. Instead, you should consider SOA as one approach, not the only approach, to enterprise architecture. I'm seeing more of this type of cautionary advice, which is interesting because when I first started reading about SOA, everyone seemed to argue that SOA needed to be enterprisewide to achieve its full potential. Now, most people are quick to point out it's not a panacea. (For more on how it's not a panacea, check out my interview with Mark Eaton, vice president of engineering for NorthStar, which recently was accepted to IBM's Service Oriented Architecture [SOA] Specialty.)
The other supporting factors for successful implementations, according to ZapThink, are: Enterprise Architecture Teams. This is opposed to individual enterprise architects who don't really understand SOA, which made the list of "Who's Killing SOA." If you're curious about who should be involved with SOA, you might want to register at ZapThink's Web site and download a recent podcast, "A Multi-Role Approach to SOA."
Technology Best-of-Breeds. ZapThink contends one of the good guys in the SOA success stories are the best-of-breed SOA infrastructural technologies and vendors who are solving real business problems.
Lines of Business Champions vs. Tech Insiders. I found this one point interesting, because ZapThink is actually arguing that the lines of business are in some cases better prepared to determine when to use SOA than the IT division. In fact, in its first article, ZapThink identified the CIO as one of the people killing SOA. How could that possibly be, you're probably wondering?
There are two reasons, according to ZapThink. First, IT gets trapped into thinking if it has a hammer, whatever problem it's confronting must be a nail. So, when the business comes to you with a problem, and you have a SOA, it must call for a SOA. Second, ZapThink contends that business users are less likely to fall for vendor success stories or, as they put it, vendor-driven architecture.
Technologists, on the other hand, don't really understand the business problem, but do love a good technology success story - and guess what vendors have aplenty? I suspect a number of you will vehemently disagree about that point, so please remember - I'm just telling you what ZapThink said.
Though I suspect they're right.
This list shares some commonalities with the success factors identified in a recent AMR Research SOA Case Study, published on ebizQ. That study identified the following success factors: