Keystones and Rivets

Understanding SOA

Over the past year or so there has been a huge increase in the amount of discussion about Service Oriented Architecture (SOA), and the number of blogs and posts on the subject seems to increase daily.

So with over 25 million references to SOA discovered by Google, why bother writing another SOA blog post?

Much of the discussion amongst the SOA community is interesting to other technophiles, but only serves to confuse the majority of readers.  Bloggers like Mike Kavis try to bring the focus of SOA back to a business perspective, but the vast majority of articles concentrate on the technology debate.

In recent weeks the rise of a lightweight version of SOA, termed Web Oriented Architecture (WOA), has had the techno-bloggers tapping away at their keyboards.  OnStrategies gives us a quick digest of some of the highlights.

Rather than join the technology debate about SOA we’ll take a step back and explain simply how it works, how it can be used and, with the use of a real-world example, describe why a properly planned and implemented Service Oriented Architecture can create a flexible way of aligning business and IT.

Succession Planning

A company I worked for a while ago had a novel approach to managing “indispensible” staff.

“It’s better for them to leave on our terms rather than theirs,” one of the senior personnel managers enthused.  “You never know when they might leave, and it could be at the worst possible time for the company, so better to just let them go during a quiet spell”.

Well, every department has a lynch pin, a person who can deliver to clients with consistency and who can be relied upon when the chips are down.  Surely, sacking them can’t possibly be the answer?

Trying to cross No Man's Land

The Pebble and I work well together.

But he is an Arts graduate, so I have to humour him from time to time.

This entails having to listen every so often to one of his “stories” about history or politics. 

Today, for some reason, he decided to explain why the Red Army initially collapsed during the German invasion of Russia during 1941. 

“Barbarossa”, “Lebensraum”, “OKW”,  “Timoshenko”, “Smolensk”, “Stavka”…

The Pebble often talks about interesting things but occasionally he uses too much terminology.  As is sometimes the case, after a few minutes I felt my eyes glazing over.  My mind started to drift into that strange state where you feel conscious and unconscious at the same time.  The lights were on, but there was definitely nobody home.   

His talk about matters military must have had some impact though.  Through the haze I began asking myself - when did IT last go into battle with a genuine understanding of what the business was trying to do?

When did Business and IT last plan together strategically, agree tactics, and march together with clear objectives?

How about ten years ago...?

Rolling Rocks and Landing the Catch

A couple of years ago we were invited to visit a few companies in Silicon Valley to chat about what we were up to.  It was a great trip and one of the perks was being taken to some fantastic seafood restaurants.

During one meal there was a long discussion about the problems companies have with project prioritisation in complex environments. 

One humorous comment that stuck with me was, "I don't mind rolling the rock up the hill and getting near the top only to see it roll all the way back down again.  It's rolling the rock up the hill, getting half way and having to just hold it steady that I can't stand - an occasional change of scenery would be good."

Working in IT, we’re all rolling the rock up the hill.  It tends to be the nature of the industry to load IT staff with lots of work, all of which needs to be completed in a hurry. 

It could be that we’re involved in a couple of projects, busy with procurement, testing parts of a system, fielding user queries, fault fixing, or trying to catch up on the often neglected paperwork to keep either the change board or auditors off our backs.

When it comes to scheduling our work, we could all come up with differing priorities for new tasks depending on our current workload, or how we perceive a task’s relevance.

So if a problem or failure occurs, how can we ensure that it is given the correct priority from an enterprise perspective?  If we leave it to the individual to decide the priority we cannot guarantee that we get a consistent approach to IT delivery across the enterprise. So what can be done?