There have been numerous articles and blog entries on SOA best practices, designing good services, and a robust supporting backbone. In fact, I have written extensively about these topics myself. But there is another side to the coin. Let's say that you've just embarked on a major SOA initiative for your (or your client's) organization. You are now faced with a myriad of questions. How will you avoid starting down the wrong path? How will you know when you are doing something that is about to get you into trouble by limiting your options in the future? How will you figure out that the SOA initiative that you have so lovingly started is about to create more problems than it can solve? Finally, and probably most importantly of all, how will you figure these things out in time to cut short this vicious cycle and get back on the right track?

Enter the World of Antipatterns

We all know what "patterns" are; a concept first introduced by Christopher Alexander in the world of civil engineering. Patterns have taken a solid hold in the software universe as well, thanks to the seminal book, 'Design Patterns: Elements of Reusable Object-Oriented Software,' published by Erich Gamma et al. This is an excellent book that talks about patterns in the context of software design. Patterns, however, can also be discussed in the context of software architecture, implementation, and deployment. Regardless of the context, each pattern documents a unique problem and a well-known solution in a way that enables the solution to be used over and over again (i.e. reusable) in a variety of different situations. Well-documented patterns provide the added benefit of creating a common lexicon that software professionals can use to communicate their software solutions succinctly and unambiguously.

Antipatterns, just as their name indicates, are the exact opposite of patterns (just like matter and antimatter for all you science buffs). While patterns are good and should be embraced as much as possible, antipatterns should be recognized as early as possible and be avoided at all costs. In short, antipatterns are those things that if not caught and fixed early on, pretty much guarantee doom and gloom for your project. Each antipattern is named and documents a set of circumstances to help identify when you are in the midst of or about to enter that antipattern. In the rest of this article, I will document a few antipatterns related to SOA that I have come across in my years of interviewing SOA professionals and implementing, assessing, and correcting SOA solutions.