Metaphors for the SOA Journey

Plenty has already been written about implementing a Service Oriented Architecture, and in particular the 'journey' that an organisation has to follow to achieve this. Now, a journey may be a good description for comparison, but I was wondering about other metaphors.

First, looking at the perspective of a journey; this has the following attributes:

• The destination must be decided upon first (assuming we are interested in a journey that gets us there, and not just to enjoy the trip - this isn't to be a travelogue)
• The route should be mapped out to reach the destination
• An inventory of equipment should be included in the plan
• Other people should be brought along on the journey
• Waypoints should be identified on this journey, to reflect and recover if necessary

Problems that arise with a journey include:

• Detours along the route, due to blocked pathways or wrong directions, adding to the overall journey time
• Some of the accompanying party may get left behind, split off on different routes, stop somewhere they find more interesting/attractive, or may decide that the end destination isn't where they wanted to go after all
• Dead-ends may be followed, where the wrong route is taken or the route wasn't clearly known in the first place
• Cliffs, chasms or river crossings on the route may prove very difficult, slow or expensive to cross
• Equipment may be required for some challenges, but was not expected or allowed for in the original plans, maybe requiring that the route is re-traced and the journey restarted
• Inaccurate measuring of (a) the distance travelled so far, and (b) the overall distance for the journey
• Not knowing the look of the end destination may mean you don't know if you are ever there, or maybe you reach that place and keep on travelling aimlessly, unaware that you have indeed completed your journey and should now sit back and relax

Having entered these lists, I guess that achieving SOA is indeed a journey, but it is easy to look at the negatives here and see difficulties explaining the vision and plan to management. It does seem to be full of risks and with the focus on reaching the end of the journey, it isn't clear that there are benefits to be achieved early on in this trip.

That is where I think the 'SOA Journey' metaphor falls down somewhat - maybe it is about the process of travelling, and not the ultimate destination that is important.

Alternative metaphors, based on particular types of journeys, may help get this across. This is the harder part to explain without failing in some other way.

For instance, a simple approach may be that of a ladder:

• The ladder needs to be long enough to reach the destination (so you must know where the top is)
• The ladder must be placed securely - it is dangerous to move it once starting up it
• Scaling the ladder is performed one step at a time
• You can measure progress up the ladder, and will know when you have reached the top

However:

• Only one person at a time may go up the ladder
• There are no detours from the ladder - you don't (normally) step off the side (ok, you might do this if, say, the ladder went up some scaffolding and you use it like stairs)
• You may get to the top of the ladder and find that there is another peak, that was previously hidden from view - but you do not have the time and resources to go any higher
• The order of the rungs on a ladder cannot be moved and should not be skipped
• It is easy to fall off a ladder, and with painful consequences the higher you had gone

A further analogy could be that of mountaineering:

• The final destination will be known at the outset
• Planning should be performed in detail to map out the route and identify resources needed
• Alternative routes should be included to allow for changes in environment during the ascent
• Support is put in place for the team going up the mountain
• The team doing the climb will be chosen for their abilities to suit the trip
• A base camp and interim camps may be included for longer ascents
• The climb will involve easy stretches and intensely difficult sections
• Some parts of the climb may be unachievable, requiring return to a known point to take a different approach
• During the climb, the team will [need to] learn to work well together to scale obstacles that they meet
• Reports are provided to the support team, indicating progress made
• Along the way, it is hoped that benefits will be gained from learning new techniques and putting them into practice - there may also be some nice views to be seen
• Reaching the peak gives the team something to shout about

This seems to be a bit closer. I can still see problems with false peaks, risks of accident, difficulties in never reaching the peak, and the issue of then having to come back down the mountain again afterwards (maybe analagous to stripping out the legacy architecture - don't think I'll go into that area).

What I think is missing from these, in comparison to actual SOA implementation, is that you can pick and choose aspects of SOA and implement those in a non-linear fashion. There are very strong recommendations as to those things you should put in place early on, such as standards and governance, with the need for support from management and technical teams (and products) to achieve the implementation.

This also brings to mind a sidebar that SOA is much more than the use of Web Services. This point is not always appreciated. It is, after all, described as an Architecture and that should mean a larger scope than a design and development approach. True SOA should involve the way in which businesses use IT as 'services'. Check the many definitions of SOA and this point should come out. This does depend on the development and implementation tools, but Web Services and ESB technologies are just that - technical enablers for integration purposes. What is most important is that services and business processes are identified and defined in such a way as to support integration and to gain the benefits of flexibility and reuse.

So, any other analogies or metaphors that could apply for implementation of SOA?