When to kill your SOA project

There has been a decent amount of press recently about SOA projects "failing to deliver value" or indeed just plain failing. This isn't that much of a surprise really in an industry where failure has been the repeated norm for many a decade. What I'd like to know about these failures is whether they have read Mythical Man Month, Peopleware and Death March. In other words are the projects failing because of "SOA" or because the organisation wasn't able to do that sort of project using the tools that it had? Organisations that see SOA as a technology based thing will be particularly in danger to this sort of problem as they try and solve problems with technology without understanding truly what they are delivering. This "lipstick on the pig" approach to SOA tends to deliver failing projects pretty much all the time as it is an attempt to solve an underlying major problem by applying a new technology as sticking plaster.

SOA projects are not "special" and mystically better than non-SOA and you need to know when to kill them off and the three books above will give you some good indicators. But some very obvious ones are

1. Project has slipped 50% on its timescales, and you aren't even developing yet
2. You are using early access software and you don't have a link to the dev team
3. Most projects failed under the old process and it hasn't been changed
4. There was no additional time added for learning new technologies
5. The vendor cackled when selling you the product
6. You've included several brand new products, and its taking much longer to integrate than expected

All of these should help you to can the project early and do a proper post-mortem on the project so you can get it right next time.

In many ways you should be more often looking to kill of new SOA projects as they will have new technologies, new process requirements, new governance requirements and the odds are you'll get it wrong (particularly if you don't get outside help).

If you really want SOA to succeed then you have to look to fix the basics first, this means understanding the business services, the right process and governance model and putting in place the right training to make sure it all works.

SOA isn't magic pixie dust to be added to projects to make them succeed, technology based SOA in particular suffers from the challenges that any technology driven exercise does, namely it rarely delivers what the business wants.

Kill early, kill often. I've seen far to many projects fail at year 2 that had been known as failures since week 1.

Technorati Tags: SOAService Architecture