Description
This is the anti-pattern where people making compromises to, mainly, business stakeholders in order to get things accepted. Unfortunately this leads to a bloating of the programme and a lack of clarity in its goals.
Causes
The causes for this tend to be political intransigence and gaming. Someone will object in order to get their own pet project on the agenda, a political game will

Description
This is the SOA strategy that tries to much and sets its aspirations far too high. Often it starts as a little point problem before some one suggests that "we could do this as well" before long the SOA strategy is listing solving world hunger and the middle east peace process as secondary objectives that will come from meeting the now agreed two objectives of the project,

I'm not scared, we can't go over it, we can't go under it we'll have to go through it.
Duane talk about Forensic architecture. Its a great read on the lessons that he has learnt. The only thing I'll add is that I don't think we are CSI, we are more Bones, hell its pretty much Jurassic Park out there. Documenting architecture after the fact, as Duane says, isn't so much the exception, its the

Description
This anti-pattern is all about training and learning. Its the "we don't need no education" anti-pattern. It occurs when organisations want to "do everything themselves" and develop in isolation from other efforts and experiences. There can be some reading done but the predominant theme is that it will be done "My Way".
Effect
The effect of this is that the organisation starts

Description
This anti-pattern is about delivery processes, given a major goal of SOA is to enable business flexibility its amazing how organisations still insist on having a single delivery process for every type of delivery, or a best two approaches, one for package and one for the rest.
Effect
The effect here is that there is no link between the business drivers and requirements and the type

Description
The opposite end to the percolating process anti-pattern this is the one where people assume that data is the centre of the universe.
Effect
With this anti-pattern you see data being driven as the centre of everything, services are all related to data processing and the first set of services being defined are about "key" data objects in the organisation. The actual actions and

Description
This is where the time isn't spent to get a clear business service architecture and get the business bought into the approach and where IT doesn't have the confidence, or maybe the ability, to effectively negotiate with the business.
Effect
The effect is that the service definitions are changed on a regular basis, sometimes its just about a data field, sometimes a new capability and

There is a conversation that I've had close on a hundred times now in the past 8 years about how to sell SOA to the business it goes like this
Business: Why do I want to do SOA? Isn't it just another IT acronym
Me: Do you understand how your current IT estate works?
B: No
M: Would you like it to look like the business?
B: Yes
M: Then that is what SOA is about, its about making the IT estate

Description
ADHD SOA is where, normally, a group of architects continually shift their mind about what "good" looks like from an SOA perspective.
Effect
This is all about continually "refreshing" the technology stack. On the technical side it means that rather than focusing on getting things into operations and industrialising their approach the architects instead concentrate on the upfront

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

I like a lot of the stuff that Dave Linthicum writes but I don't agree with his latest post on why people should start with the data when doing SOA.
First off lets be clear, data is important its one of a few really important things in SOA
ServicesCapabilitiesReal World EffectsDataNow I've deliberately but them in that order because that is the order I think is important. I've said before about

Okay so recently I've read a bunch of articles about how France is becoming relaxed about the rise of English. It appears however this is just a front to make us relax so we won't see the real goal.
Unfortunately I've unearthed this plot via Apple, looking at the MacPro and going through the "HOW much could I spend on a PC?" test. I saw the following
See it?
What about now? Seriously its

I haven't rolled this into the project yet but its something that I've done before to raise the sense of community. Basically you pick an unusual word, but not too unusual, that people need to get into either a conference call, document or email. The word must fit within the context of the communication, not just a random shout out, and the non-included people on the call must not notice.
Today

At the Netherlands Java Night 08 I moderated a discussion on Java futures and chatted with a bunch of people doing real, and large, Java projects. The overwhelming plea was "please stop the hype and the crap, lets make it work properly first". Now with the credit crunch this got me thinking about what a credit crunch could mean to IT spending.
Now apart from the obvious of more outsourcing

One of the problems that I have in my job is the problem of IT Hype, most especially the huge distortion field that appears to fall over Silicon Valley. When I'm working with companies who are going through a procurement phase its amazing to see this field spread across the globe via the blogosphere. Its the sort of field that tends to ignore companies like IBM or SAP because they just can't be

A number of years ago I had a period of time working at a smaller company where I found myself up against the massed ranks of the "big american consultancy" (BAC) on a number of projects. Now clearly they didn't like me as I was doing some high value delivery work and might have occasionally pointed out some minor flaws in the way that they were working. Now what this did teach me however was
