How can you tell if your efforts at service-oriented architecture are headed down the wrong path? It's a tough question, and I've seen a lot of complex answers, many of which actually serve more as morality tales than actual indicators you can use.
Vijay Narayanan takes a different approach in a recent eBizQ article, offering a list of 10 design assumptions that might hurt your SOA.
Narayanan is a software professional who runs a blog dedicated to software reuse. He's worked on a range of systems and platforms. And, as far as I can tell, his list isn't written around a specific vendor's concept of SOA, which we all know is an all-too-common occurance in pieces about SOA or any tech initiative.
The list includes both practical and ideological symptoms of trouble ahead. For instance, a practical symptom he mentions is if your service capabilities are always Web services or if services only need to support one data format, such as SOAP. The ideological symptoms are less obvious at a glance. These include assumptions such as, "Service consumers will all migrate to new versions simultaneously. No need to support multiple versions," or "Service capabilities from vendor solutions can be consumed out of the box without mediation."
Although he doesn't say it outright, he does imply that many of these 10 design problems happen in organizations where SOA is approached as a bottom-up, IT initiative, rather than a business initiative or a top-down strategy overseen by the CIO. While bottom-up, or guerilla SOA, has its advocates and advantages, Narayanan's list speaks indirectly to the disadvantages of this approach.
Unless things have changed significantly in the past year, CIOs aren't taking the reins on SOA, which makes me wonder just how many of SOA initiatives are, in fact, bottom-up implementations.