SOA and the Monkey’s Paw

One of the reasons that SOA gets so much press is that it has the potential to become the catalyst for the alignment of business and IT. In most organisations the IT folk crave recognition and they want to be seen as equals with their business counterparts. SOA can be a great way for IT to get their wish, but it could have unexpected consequences.


The Monkey’s Paw is a horror story written in the early 1900’s. The paw of a dead monkey has the power to grant the holder three wishes. Unfortunately the paw is cursed and when a wish is granted there is an unforseen and horrific side-effect.

So what’s this got to do with SOA?

IT has a wish: we want to get out of the back office and rub shoulders with the business and to be seen as equals. To achieve this wish we need better alignment between business and IT, and SOA is seen as a key plank of our alignment campaign. The theoretical benefits of SOA are so compelling that in many organisations IT may get its wish. But beware the curse of the Monkey’s Paw. With increased alignment comes increased visibility.

In days gone by, architecture was largely a back office endeavour: object oriented programming, client-server, web based applications, n-tier/distributed applications. To some extent we could learn on the job. In fact in many cases we had to learn on the job because when you’re on the cutting edge there is not a lot of ‘best practice’ guidance available. We built things and they may not have performed as well as we’d like and they may not have been as secure or elegant or maintainable as we’d like. But they worked. As we learned things new things we could ‘tweak’ individual parts of the solution. The beauty of this learning process was that we could do it in the IT department, behind closed doors. IT wasn’t visible in the business unless something went horribly wrong.

Now we have SOA. And SOA is not like previous architectural shifts because the business is interested. IT will have greater visibility so we have to change our ‘modus operandi’. We need to recognise two things in particular:

  • We can’t be seen to be learning on the job. Can you imagine going to a doctor and seeing him thumb through a textbook while he tries to diagnose you? You wouldn’t be overly confident in his abilities. IT is often criticised for not “delivering the right thing”. SOA doesn’t change that. But lets at least make sure we’re capable of “delivering the thing right.” Before you tout SOA in your organisation, you better know what you’re doing.
  • Mistakes will be costly and visible. When you delivered your first web solution it probably wasn’t great. Sure, the solution may have needed some refactoring, but I cant think of a single (sensible!) architectural decision that may have forced the whole application to be thrown away. SOA is different in three ways: a) there are many architectural decisions to be made; b) almost of then are sensible, in a certain context; c) most of them are extremely costly and time consuming to reverse. I repeat. Before you tout SOA in your organisation, you better know what you’re doing.

When your IT department steps out of the safety and anonymity of the back office into the full glare and scrutiny of business, you’d better be ready. They’ll be watching you.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: