SOA Anti-patterns revisted - Part 1

Back in 2006 I wrote an article, with some help, at InfoQ on SOA Anti-patterns and I thought it was about time to revisit and extend them.

The format again remains the same

Each anti-pattern presented in this article will follow the following format:

• Description - What it is?
• Effect - What you see?
• Cause - What behaviours led to that effect?
• Resolution - What can be done to solve the problem?

First off I'll revisit the old patterns to see if they are still valid.

Antipattern: The Shiny Nickel

Hell yes, people are still lobbing in new technologies without worrying about the consequences so they can get it on their CV.

Antipattern: The Technology Altar

Again its a Hell yes. Some of the REST preaching out there is right out of the technology altar book.

Antipattern: Percolating Process

Again its something I see over and over again. People are still saying things like "Process on top of Services" and I still see people mapping out processes and then calling activities "services" and claiming SOA.

Antipattern: Point to Point Web Services

Its still an anti-pattern but I'll admit that its one that is happening less and less. People are doing ESBs to avoid Point to Point and the REST crowd are claiming the dynamic nature of the URIs combined with DNS.

Antipattern: Splitting Hairs

Again its about splitting process and services, some people are even going further and advising you split further into data/service/process. Its still an anti-pattern and its still being done over and over again.

Antipattern: IT2B

Not really an SOA anti-pattern but an IT organisation pattern and its certainly still a problem.

Antipattern: DIY Transport

Its an anti-pattern but I've not seen someone do this recently. The ones who did this before are now leaping on REST as their transport, I'm still not sure that its any better than the custom XML-RPC approach of before as it still gives a completely unstandardised application interface. But the problem now probably isn't at the transport level. So if you are doing this you are seriously behind the times, its beyond an anti-pattern now and into the category of reasons for commital to an asylum.

Antipattern: Nobody Home

Are people building services without thinking about how they will be used? Oh yes they are. Some people have even talked about not being concerned about the interface design and that "you should at least start somewhere". Well you shouldn't start by making up services based on a set of perceived rather than actual needs.

Antipattern: Too many Cooks in the SOA

Yup still valid.

Antipattern: UBER service

I've not seen this one for 12 months or so, but its still valid.

Antipattern: A Million Services all in a row

Still seeing this, the focus at the edge, build up the volume and "they will come". Muppetry

Antipattern: Architectural Stovepipe

Big strategic views from Enterprise Architecture that result in hard to deliver solutions... almost a best practice in some places it appears. Its still an anti-pattern.

Antipattern: Defensive SOA

Getting worse this one. More and more companies are "already doing SOA" and when you look its the same thing they did before but with a software upgrade.


So to my mind they are all still valid but some of them are less of an issue than 2 years ago. Now what are the new SOA anti-patterns?

Technorati Tags: SOA, Service Architecture