Archive | ESB RSS feed for this section

It’s about umm… Services, duh!

10 Oct

<Rant>

Every now and again you see something that makes you realise that you’re on a different planet to many other people.  In this instance it was an article by Dan North aimed at demystifying SOA (http://dannorth.net/classic-soa), applauded by Joe Mckendrick for taking a technology-agnostic view of the thing.

Now don’t get me wrong – I absolutely agree; service orientation is an abstraction that allows us to consider things from the perspective of services, their providers, their consumers and the agreements that exist between them.  What freaks me out (often) is that this seemingly simple concept is ignored by most people who fly into acronym and technology land – SOA, ESB, BPM, Registry, Repository, Legacy enablement, web services, SOAP, REST etc. etc – or even worse product land – microsoft biztalk, websphere ESB, weblogic application server, Jboss, <insert whatever pointless thing you’re now in a rage that I’ve left out>.  In both cases people get in to the most heated arguments about which technology or vendors approach to any particular issue is ‘the one true way’ (a point made by Joe).  Essentially they pile into explaining and arguing about ‘how’ – in the form of immense and complex technical detail and the exponential combinatory options – rather than succinctly trying to express ‘what’ – in terms of understandable concepts, benefits and outcomes.

But why do people do this?  Why do they try to explain SOA in those terms and more importantly why does the power of the concept get swamped in pointless arguments about subtle ways in which different ways of realising some insignificant part of it are better than another way of realising that same insignificant part?  What is so hard about the concept of services?  We all consume hundreds of them every day.  Why do those who try to simplify the concepts of SOA end up taking about Lego?  What’s wrong with services – banking, retail, media – we buy services from service providers all the time, each where we desire something that they are willing to provide agreed through the medium of a contract of some sort.  Would you build and run a bank at the bottom of the garden just to keep your own money in?  How much of your time would that take and wouldn’t that time be better spent living your life?  How good an interest rate could you give yourself given the small amount of money involved and wouldn’t it be better to pool your resources with others to maximise the economies of scale?  And how risky would it be to try and guard your money yourself – how much security could you afford?  Of course this would be a ridiculous proposition.  So if using service providers makes sense in our personal lives why do our companies do their own logistics/finance/underwriting/branding/whatever when we could increase our performance and focus whilst reducing risk through using services provided by specialists in a similar way?  Even if we’re shy of co-sourcing wouldn’t it be better to increase transparency by understanding what services are being provided by capability units within the organisation and how well they manage performance, cost and risk in their specialism on behalf of the company?

To be honest if people aren’t having the sorts of conversations that Dan brings out with their business colleagues – i.e. ones about who is responsible for realising what value for whom and to what level of service – then I despair of SOA ever delivering anything – we are such an immature industry.  From  a product provider perspective of course they are going to be talking about technology and features as realistically they have their own interests at heart rather than those of the business they are talking to (bit harsh but realistic) but surely service companies such as the one that I work for or internal IT departments should be able to help their business colleagues grasp the concepts and benefits whilst becoming expert realisers of those benefits and hiding all the crap?  If people went into a garage looking for a car and a hundred people descended on them shouting about different brake pads, spark plugs and rivets and why in each case the ones that they want you to buy are better then we’d all still be walking with no idea as to what the benefits of a car actually are. 

Why does this have to be so complicated?  The concept you’re looking for to help explain service oriented architecture is.. um… services.  Your colleagues are smart people – give them a real world concept and they’ll get it.  Concentrate on helping them to understand what their business would look like as a set of services, what benefits this brings – using real world, familiar examples – and leave all the grubby technical bollocks in the shed until you actually need to do the digging so that you don’t mess up the nice clean offices of people who just want to get things done.  Any implementation of SOA needs to be based on business value and outcomes and until you can explain why it’s a good idea there’s no point even putting the usual acronym laden presentation together – everything you write will be bollocks until you make it real and understandable using – unbelievably – plain english and the simple truth.

</Rant>

 ADDENDUM:  Just also read Bobby Wolfe’s article over on developerworks about ESB-oriented architecture and it made me laugh out loud.  Different angle but similar argument about the futility of technology navel gazing.  Really appreciated IBM’s quick disclaimer about the value of ESBs, too, lol (another of my pet hates, btw, given that they are basically (nearly) all proprietary hub-and-spoke products that fly in the face of all of the lessons of the last 10 years with regard to federation).

Follow

Get every new post delivered to your Inbox.

Join 172 other followers