May 2008 Archives

At a recent Butler SOA strategy seminar (where I banged on again about how to sell SOA to the business, see here), there was the normal range of vendors (IBM, Sun, Progress) and anti-vendors - analysts and consultancies having a go at the vendors (no names, but you know who you are).  Amongst the noise there was the familiar debate/slanging match about the whether an Enterprise Service Bus (ESB) was a product or a concept.

To many bearded ones, this was an important philosophical question. To most of us, it was yet another infuriating part of the whole SOA hype cycle.  Customers praying for a simple answer were disappointed - the analysts and vendors lived to fight another day.  So, for those still unclear on this semantic difference, here is my attempt.

The reason why the answer to this is fuzzy is mainly down to the vendors.  Many of them have called products ESBs, but they don't all do the same thing.  IBM has both an ESB and an Advanced ESB that do things quite differently.  Other companies try to sell you on a complete SOA framework that might include ESB functionality, but not necessarily a standalone ESB.  For example, Microsoft doesn't have an ESB per se - you add together parts of Windows Server, .NET Framework and Biztalk.

But the analysts haven't helped either.  Because most of them have been talking about ESBs for years (and before that Hubs and EAI), they are struggling to find anything interesting to say that will keep them ahead of the vendors.  So most are either talking more and more abstract (Separation of Concerns, anyone?) or producing increasingly long lists of 'must-have features' hoops for the vendors to jump through.  Some of these lists are getting absurd - how many people understand or need Complex Event Processing or Federated ESBs yet?

Which view is right?  It depends on where you currently are and where you need to go.  Most companies already have some of the key ESB functionality in their infrastructure already: Routing and transformation have been around since the world moved from SNA to TCP/IP.  Start with what you have and do a gap analysis based upon potential Service Bus requirements in the foreseeable future.  From here you can plan your journey to ESB maturity - or not, if there is no obvious benefit.

So it is not about whether to ESB or not, or which product is best, but what Service Bus Architecture (if any) will suit your journey.  That is the question.

[Exit Stage Right]

John 'The Ham' Moe

You might think it was an obvious statement to say that, in a world where there is a horror story, almost weekly, about an embarrassing high profile project failure costing millions and delivering nothing, sensible companies would have in place effective, metrics driven Project Portfolio Management (PPM) systems and processes.  I'm sure you all have.  No?  Don't worry you're not alone.

Having been responsible for my fair share of cost- or time- 'challenged' projects (overrun has such an unfortunate connotation ...), I am fully aware that knowing what is sensible and achieving sensibility are not common bedfellows.  So why have I and my fellow Project Professionals (my PRINCE2 is more Machiavellian than yours) failed to keep a tight control on these black holes?

My first observation is that Project Management and PPM are different beasts, requiring different skills and experience.  Using a PM to do PPM seems sensible, but there are an alarmingly large amount of 'gotchas'.  For instance, it is quite feasible to plan, design and manage a project using MS Project (yes, I know that real PMs use Artemis).  However, trying to prioritise and schedule 50 business-critical projects using this software would be ambitious to say the least. 

Secondly, project prioritisation requires interacting with some of the most powerful people in your organisation.  Business projects are seen by their sponsors as a test of virility and woe betide anyone who doesn't treat these symbols with the respect they feel they are due.  Senior management are only interested in their pet projects being delivered immediately.  They don't give a gnat's testicle for anyone else's projects, and normally prefer everyone else's projects to fail to make themselves look better ...

So, giving a sponsor the reasons why their project is going to be delayed, while their rival's goes ahead, might seem logical, captain, but you shouldn't be surprised to suffer a verbal (and possibly physical) roasting, probably leading to a rapid and permanent posting to the Anchorage, Alaska office of your organisation.

But what about the PPM software the vendors are pushing?  Surely, given it costs a fortune, it will solve these problems?  I get too many icy postcards to believe that.  PPM software saves some nifty Excel macros, but fundamentally only gives you one part of the answer - the depth.  By this I mean the detailed metrics about the benefits, risks, costs and implications of the projects.  These are very important, but you need two other pillars in place to succeed.

Width.  The only way to get protection from the wrath of individual sponsors is to organise the equivalent of a group hug, commonly known as a PPM steering committee.  This needs to consist of the sponsors and preferably their bosses to publicly debate and agree relative groupings, priorities and resource allocation.

Height.  Depending on your organisation, you will need the support of the main board or divisional head to protect you from unhappy executives.  Or if you are built like Martin Johnson, you are probably safe already.

So there you are, PPM solved in three dimensions.  Next week, how to make an ESB using origami ...

John Moe