Bernard Wheeler's Weblog

SOA = BOA ?
We all know the potential for something of value to be lost beneath hype, hype-backlash, bandwagon-hijacking, "not invented here" syndrome and the like. This applies as much here in the UK as anywhere else world-wide and I have a growing concern that some of the key points of potential value for SOA are starting to get obscured under some of these effects.

First things first: what do I mean by SOA. Well, the best analogy I've seen (and to my mind it is superb) was put forward by a fellow Sun employee, Thomas Limanek (who, as it happens, contributed to some of the ebXML specs).

Tom's analogy in a nutshell and extended here by my own whim is this (and apologies to Tom for any misrepresentations):

• the traditional relationship between business and IT is like having a personal chef: you (the business) can dictate what you want to eat, or take menu recommendations, but your chef (the IT department) only buys supplies according to the pre-agreed menu. You play no part in how the food is bought, cooked, etc., but you pay the whole cost for the chef, cooking fuel, food and all the waste from each meal. In addition, if you suddenly change your mind about what you want to eat, there's unlikely to be an alternative meal ready in a short time - apart from re-cooked leftovers.
  
  
• using commodity-off-the-shelf (COTS) software is more like eating in a restaurant: there's typically less flexibility available to you in the actual make-up of the dishes and the more customisation you want, the more it'll cost. But you share the costs of the chef, facilities, etc. among other restaurant-goers - reaping some benefits from the 'economies of scale' of the restaurant. Furthermore, if you change your mind about what you want just before ordering (e.g. pizza vs. pasta), there's probably a reasonable alternative that can be available in an acceptable amount of time. But if you want to include a totally different culture or flavour (e.g. vegetable tempura as a starter), you may have to visit more than one 'restaurant' and figure out for yourself the logistics of how the 'meal' as a whole is going to be achieved. Also, there's nothing to stop the restaurant from suddenly hiking up their prices, radically changing their menu, or being bought out by a bigger chain who then 'trashes' your preferred meal.
  
  
• SOA is like eating at a buffet: the chef (either private or shared) prepares a range of dishes from which you build your own meal. The meal you choose does not require the whole ensemble to be put together 'in the kitchen': rather, the chef focuses solely on ensuring that there is an appropriate range of dishes provided in the buffet to keep most people happy for most of the time, based on market demand, season (and other prevailing conditions), consumer feedback/requests/suggestions, etc. And if the cost of any item changes dramatically (or there's an ingredient shortage, "food scare", or some other reason to change a menu choice), you don't have to change your whole meal, just that one piece of it (although granted, it may be the centrepiece of the meal).
  
  

Hence the title of this piece (BOA = 'Buffet Oriented Architecture'). I think this is an excellent analogy, because amongst other things it helps to illustrate that:

1. a main thrust of SOA is business agility (consumer able to make their own selections) as opposed to IT agility (ability to respond to requests more quickly).
   
   
2. IT agility is important too - business won't want to wait as long for just one new component (dish, service) to be produced as they did for the whole 'meal' before - and their impatience will only grow.
   
   
3. there is a responsibility upon IT to offer a palatable and useful range of services, including 'staple items' that will be included in almost every selection.
   
   
4. some of the initial difficulties in migrating to SOA: if you just serve up the same stuff (food, services), but in a different form (buffet vs. a la carte, SOA vs. stove-pipe), the customer will wonder why the heck you bothered with the transformation. They just get the same end result, but they have to put more effort in too.
   
   
5. if you're exposing stuff into a "public space" there are various security, hygiene, monitoring, etc. considerations that you need to consider. Otherwise you'll get someone in off the street carrying a bowl, taking all of the olive, tomato and basil pasta, sneezing on the rest of the buffet and then walking out without paying. And you can't expect the consumers to choose or enforce these as options.
   
   
6. there is a need for appropriate granularity: you want to avoid the smallest portion size being a whole roast chicken.
   
   
7. for the more popular 'dishes', you'll need more capacity not only in production quantity, but also in the ability for people to access them.
   
   
8. if you want people to always have a specific item, you'd better mix it into each menu option you give, pre-load the buffet bowls/plates, or move to a "we serve you" buffet model (a 'halfway-house model, which means that you will need to factor in the hiring of serving staff, their cost, their throughput capabilities, etc.)
   
   
9. each dish can more easily be put under scrutiny - independent of all others - to isolate the efficiencies and difficulties of provision - is the volume such that outsourcing makes sense, does it take an inordinate amount of resource for the popularity and benefit it gives?
   
   
10. you cannot implement this without participation on both sides: if the business just (metaphorically) sits at the table demanding food and refuses to step up to the buffet, you're going to have an unhappy business (and frustrated culinary staff)
    
    

I think I could spend hours extending and exploring this analogy, but I think I've covered enough of the main points for today.

So what do I think is getting obscured? Well, the main issue is that people are routinely confusing business agility and IT agility. Sure, they're coupled, but potentially loosely so: you still need IT agility to create the new services in a timely manner, but if the business decides to change its selection list and create a new 'combo-special', its ability to do so need not be restricted by IT's ability to join all the stuff together - especially if you can achieve serve-yourself as opposed to we-serve-you.

And yes, I know I'm talking about 'utopia' here, but when else other than at the start of a paradigm shift is a better time to consider ultimate possibilities?

Another aspect that gets hidden is the fact that unless something measurably beneficial for the business is planned for and delivered along with the move to SOA, they will be supremely 'underwhelmed' by the achievement. "Same food, different delivery" is not going to cut it on its own.

So is SOA for everyone? Well, if the business is only ever going to order the same menu, you'd better find some pretty good reasons for selling the idea of a buffet rather than the 'served at your table' set-up.

I think that's enough for one day of blogging. And I'm starting to get hungry...