Worst Practices in SOA Implementation

In a September 2003 HBR article, Why Hard-Nosed Executives Should Care About Management Theory, Clayton Christensen and Michael Raynor state that many managers accept generic business advise which they expect to work in all circumstances. Similarly, many IT managers accept the advise that application of SOA will solve their problems.

Christensen and Raynor, go on however, to state that all theories have their flaws, and that a theory becomes more powerful as these flaws are uncovered and resolved. This insight can be applied to the theory of SOA as well.

In this context, I came across a white paper from iWay Software named Worst Practices in SOA Implementation. In it, the author identifies the practices that lead to SOA failures:

• Overemphasizing low-level code
• Centralizing design and development
• Ripping and replacing legacy software
• Buying software without support

The paper goes on to explain why these practices are bad, and how to resolve them. The author makes several good points. One is that companies need to abandon an EAI mindset, and not use SOA to create EAI workflows. This just leads to low level code which is both too complex and not reusable. Another good point is that service creation and maintenance should be distributed to local domain experts, not a central design group. This is consistent with my view that SOA is primarily an architecture for dealing with distributed, independent systems.

Although an interesting list, the paper includes some typical vendor bias, and is incomplete. A more complete list might include:

• Data is not organized and managed on an enterprise basis
• Service governance is not duly considered
• Unnecessary technology such as an ESB
• Technical rather than business focus
• Service design consistent with process rather than service workflows

The idea of exploring failure in order to understand where and how SOA should be used, seems to me to be a valuable approach and worth exploring in more detail.

See also Steve Jones excellent article on SOA anti-patterns.