Technical SOA - The IT Departments drug of choice

After reading yet more articles about the wonders of technology without thinking, you know the sort that say "Web Services = SOA" or "its easy then just to reconfigure your global supply chain using the Web Interface changing process and rules without requiring re-testing or re-deployment". Also DanC declared SOA doomed with which I disagreed . Well all of this got me thinking about technologists and how we become obsessed with a given technology or approach and just can't help using it everywhere. Sort of like addiction, so here it is, how to recognise if your organisation is suffering from Technical SOA addiction (thanks to this link for the basics on addiction)

1 - Use - The use of web-services or other SOA technologies within a project. It helps you do some things and you don't suffer from the consequences, in fact it makes you feel better because it speeded things up.

2 - Misuse - In a desire to use SOA technologies you decide to use BPEL for basic page flow in an application or you lob a Web Services on something just because you can. The server crashes or the project over runs and the business shouts at you to clean it up.

3 - Abuse - SOA Addition is kicking in, despite the warning from above and the over-run you decide to try BPEL for page flows again, or you create yet more Web Services and deploy a global UDDI "just because you can". More failures start occurring and governance starts going out the window

4 - Dependency/Addiction - Everything has to be SOA and use SOA technologies, large bulk uploads and ETL work is done using BPEL and Web Services, project rules dictate that Web Services must be created on all elements that could theoretically be re-used elsewhere. SOA technologies are compulsively used regardless of the impacts on projects. The IT department starts trying to tell the business how to operate and prioritizes SOA technologies over delivering anything to the business. The aim of IT is to consume and create as many web services as possible with an almost macho desire to boast about where SOA technologies were used where they had never been used before.

Do you recognise your organisation? If you are currently at stage 1 or 2 there is no reason for you to be moving towards 3 or 4, but you need to start making sure you see Technical SOA as just implementation so it doesn't become an emotional crutch that you need every hour of the day.

If you, or an organisation close to you are misusing technical SOA or slipping into dependency it isn't too late, there is a simple 7 step process to help you and them get over it

1) Admit you have a problem - face up to the fact that you've become dependent on technical SOA, talk to your software vendors about the issue and tell them that you'll need to talk to them differently from now on.

2) Start cleaning up your act - get rid of those Web Services you know were just created to give you another hit, refactor out those badly deployed technologies

3) Ask the business to help them - admit your problem to them and ask for help, they can work with your problem if they understand it

4) Read the Mythical Man Month - understand that your aren't the first, and won't be the last, to think that technology is a silver bullet and do things badly.

5) Focus totally on project delivery for a while, get your head down and don't think about IT strategy

6) Get some help, go and speak to other people who have either had similar problems and got over them, or managed to avoid your destiny and created something more balanced and beneficial.

7) Get a life - if you became that obsessed with technology you need another hobby.

Technical SOA - its okay in the right social occasion and when you've got responsible adults making sure it doesn't get out of control.

Remember - Web Service responsibly.

(NB The same addiction approach should be used for people who try and use PHP, Perl and similar languages, sometimes its okay, but when it becomes an addiction you become a danger to yourself and to those around you)