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 NickelHell yes, people are still lobbing in new technologies without worrying about the consequences so they can get it on their CV.
Antipattern: The Technology AltarAgain its a Hell yes. Some of the REST preaching out there is right out of the technology altar book.
Antipattern: Percolating ProcessAgain 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 ServicesIts 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 HairsAgain 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: IT2BNot really an SOA anti-pattern but an IT organisation pattern and its certainly still a problem.
Antipattern: DIY TransportIts 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 HomeAre 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 SOAYup still valid.
Antipattern: UBER serviceI've not seen this one for 12 months or so, but its still valid.
Antipattern: A Million Services all in a rowStill seeing this, the focus at the edge, build up the volume and "they will come". Muppetry
Antipattern: Architectural StovepipeBig 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 SOAGetting 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?