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

I've just come back from a successful two days at the Project Challenge Conference and Exhibition, at the NEC Birmingham.  Alphacourt had a stand in the Process Performance Zone and my feet can attest to the fact that we were busy for just about the whole time.  Aside from the normal quota of freebie thieves, there were a large number of project and process professionals asking the same old questions:

• How can I manage all my projects effectively? 
• How can I get my users to give me the right requirements?
• Can I have a job please?

Obviously we provided some great answers: Project Portfolio Management, Process Modelling, and No, respectively.  I'll discuss PPM in the next blog.
 
My main disappointment was the variable quality of presenters speaking in the conference seminars.  They covered the whole spectrum, from nervous techies mumbling from a script with their heads down, to brash salesmen pumping the features of their new vapourware solution.  Having been guilty of both these styles in the past, I'd like to think my presentation avoided these pitfalls and gave a practical insight into "Gathering the Real User Requirements using Process Modelling".  You can find a copy of this presentation here.

Another highlight was Mark McGregor's interactive lecture about "Mapping and Modelling for the 21st Century".  Insightful and leading edge as ever - I was amazed how he smoothly incorporated the Beijing Olympics, giving up smoking and globalisation into the talk and brought it all together at the end with a clear focus on people and process.

The BPM vendors are now desperately trying to avoid the 'me too' tag and are coming up with more arcane positioning statements to make themselves stand out from the crowds.  This to me signals that the market is maturing and that the features of the products have effectively converged and the only differentiator is how you use the tools.  So the message for Process Professionals now is to skill up in the methods and techniques of process improvement.  The tools all have four wheels now and a steering wheel - you just have to learn to drive and work out whether you are Lewis Hamilton or Mr Bean ...

John Moe

In the battle of the TLAs (Three Letter Acronyms to you non-geeks), there seems to a sharp change in the fortunes of the old warhorse BPM (normally Business Process Management) against the upstart SOA (Service Oriented Architecture).

Over the last five years, SOA has been thrusting its way up the agenda of the chattering IT classes as being the Next Big Thing (or NBT in TLA-speak) for IT analysts and vendors to sell to hard pressed CIOs and IT Directors.  The fact that none of the previous NBTs have made a significant difference to their organisations (except additional cost) hasn't deterred people from trumpeting SOA as the latest snake oil.

So it may come as a surprise to some (not me, obviously - see previous blogs) to read Gartner's 2008 CIO Business and Technical Priority lists.  Top of the Business priorities is BPM.   However, SOA comes a distant 10th (and last) in the Technical priorities list, down 4 places from last year.  Oh dear.  What has happened?  Just as all the IT vendors have finished rebranding their existing products as SOA compliant/enabling/focussed, etc., their customers have binned that part of their IT strategy in favour of two old favourites - BPM and BI (that annoyingly Two Letter Acronym, Business Intelligence), which came top of the Technical Priorities.

My reading of this is that IT has spectacularly failed to articulate the benefits of SOA to their business sponsors.  I also think that a sizeable minority of CIOs were never seduced by SOA, or never fully believed the hype.  The resurgence of BPM and BI seems to be an indication that the business has become impatient with IT and are looking for tangible and quicker returns on their investments.  Given that the second and third Business Priorities are Customer Relations and innovation, there is an obvious emphasis on delivering real business value through more and happier customers being sold better products brought to more markets sooner. 

But isn't that what business is all about anyway?

John Moe

Ch-Ch-Ch-Changes: Sustainable Improvement

No-one likes change; real people prefer a simple life with few surprises.  Of course, there will always be thrill seekers and rogue French traders, but they tend to have a short existence.

There is a lot of consultant-speak around about doing Change as Continuous Improvement, using Lean Management and/or Six Sigma techniques.  What they don't tell you is how unappealing the whole idea of Continuous Improvement is to staff - who will hear:

1. You are no good at your job so we need to make you more effective (work harder) and efficient (sack you).
2. We are going to change what you do because you are doing it wrong.  Then we are going to keep changing it forever as we don't think you'll ever get it right.
3. Your life will be run by a spreadsheet and some advanced statistics made up by a clever young suit who has never done what you do.

Ask anyone you know in the NHS and ask them how they like 'continuous improvement'.  (Best strap yourself into some thick padding first and put some earplugs in.) 

Perhaps what we should be considering is an approach that gives Sustainable Improvement.  This isn't part of the 'Go Green' bandwagon but looks at how performance (individual, team, departmental and company) can be improved by finding ways to make change work for real people.  And for this change to continue to work after the consultants have gone off to cash their fat cheques and the managers have been promoted to their level of incompetence.

Sustainable Improvement works on the following principles:

• People have to want or accept the change as something that benefits them personally.
• If you understand the context of the work you do and what impact your actions or inactions have on other people you will take more care in what you do.
• By asking staff what issues stop them doing their tasks to their own satisfaction AND you then help them fix the issues they will feel very positively about the change.
• You can't force people to change their ways of working; change that comes from within (individual, team, departmental and company) will endure longer than enforced change.
• Sustainable Change isn't continuous - it is more effective if change is tried, tweaked, bedded down and becomes second nature before another potential improvement is tried.

I'm not saying that this approach is easy.  What is certain is that this approach will give lasting benefits for all involved.

John Moe

A lot of process improvement projects I have come across go something like this:

• A Senior Executive (let's call him Gordon) is not hitting his performance (i.e. bonus) target.  He naturally blames his lazy workers and tells his managers to fix it.
• The Managers call in the Consultants who advise them to 'optimize their performance by automating their workforce', or some US-derived jargon-filled sound bite.
• The Consultants recommend implementing a Business Process Management (BPM) solution, as this has been 'proven to increase productivity by 50%'.
• IT are roped in to buy and implement the software, while the Consultants carry out a 'process review' (time and motion study to you) and pronounce what changes should be made to optimise the offending process.
• The new system is duly rolled out and the Workers are retrained to press different buttons to carry their re-imagined task.

The Result? 

• Productivity drops so more workers are needed to achieve the same output.  Project costs balloon.
• The Managers blame the Consultants for bad advice.  The Consultants blame IT for bad implementation.  IT blame the BPM vendor for rubbish software.  The BPM vendor blames the Workers for being stupid.
• The Senior Executive blames everyone but himself (a true Gordon) and moves on to head a new division.
• The Workers are left with a less efficient process that they don't fully comprehend, let alone own, a vague feeling of guilt and a strong feeling of unfairness that they are carrying the can for something that was done to them.

I'm sure you recognise the situation.  How could this have gone better?  Here's one we did earlier ...

• A Senior Executive (let's call her Joan) is not hitting her performance target.  She naturally wants to find out how to help her Workers improve their own performance and tells her Managers to provide the necessary support.
• The Managers use the Consultants to hold independent facilitated process workshops with the Workers to understand the challenges of the current situation, and to encourage ideas and discussion of ways to remove blockages, duplication and gaps.
• The Workers produce a set of recommendations that cover better training, clearer procedures, reduced unnecessary documentation and streamlined systems to reduce double entry of information.
• The Managers authorise the recommendations and use the Consultants to fill any skill gaps by providing education, training and mentoring of the Workers.  IT are given specific (minor) changes to existing systems along with clear SLAs for delivery.

The Result this time? 

• Productivity improves so more output is achieved with the same Workers. 
• The Workers thank the Managers for their support.  The Managers thank the Consultants for their facilitation and knowledge transfer.
• The Senior Executive thanks everyone but herself (a true Saint Joan) and moves on to run the company.
• The Workers feel confident because they now understand the context of what they have to deliver, and own the ways of working to deliver them.
• IT are disappointed because they don’t have much to do or new toys to play with.

This feels better, doesn't it?  Unless you're a BPM vendor, a big Consultancy, or an IT empire builder ...

John Moe

I'm sure that like me you will already have broken or conveniently forgotten your New Year's resolutions made in the foggy mist of Hogmanay.  Back at work, having waded through all the emails sent by those people who have worked their way through Christmas and want you to know it, it is time to make some business resolutions for the year that will bring you fame and wealth - or at least ensure you keep your job.

Here are my top 5 cunning plans to help you:

1.  Innovation.  This year's big idea is innovation.  From big-picture thought leadership down to better widgets designed and delivered to your customers.  Companies are demanding that their managers be more creative and less obsessed with cost and efficiency.  So take off pin-stripe suit, put on some shades  - the future is looking bright!

2.  Loosely-Coupled Thinking.  Get away from the tired labels of BPM & SOA - the future is loosely-coupled.  Push the flexibility of having loosely-coupled systems enabling loosely-coupled businesses to be much more agile to compete and succeed in the distributed world in which we now live.

3. Model-Driven Everything.  It's not just processes or use cases that can (and should) be modelled.  Graphical modelling tools and rich meta-data repositories allows us to now develop conceptual, logical and physical models of entire eco-systems, including people, process, data, systems, supply chains, etc.

4.  Real-time Monitoring.  Your lords and masters want more (management) information and (business) intelligence to make better and faster decisions.  Enable their fantasies by using your loosely-coupled systems and your meta-models to build a real-time dashboard of KPIs to find, extract and display everything they want - and if you are really good, everything they actually need.

5.  Going Green.  I'm not talking envy, the hulk or sweetcorn here.  Saving energy/water/the planet is going to continue to be a big moral plus this year.  Look for green benefits in the projects you do this year - it may be server consolidation/virtualisation, reducing supply-chain miles, or just planting a tree every time you buy a PC.  You can both save money AND feel smug this way.

Let us know if you have any better ideas!

John Moe

I'm sure many of you are either contemplating joining or actually sitting on the SOA bandwagon with high hopes of delivering the business benefit that we as IT professionals promise to our lords and (pay)masters on a regular basis. In case some of you are unsure of the true benefits or how to quantify them for budgetary purposes, here are some 'home truths' gleaned from real activity out in the wild.

• SOA can save money. But not in the beginning. One of the key benefits promised for SOA is re-use of the assets and services developed. One obvious consequence of this is that re-use is a benefit gained from the SECOND project onwards, but not the first. The business case for SOA requires a more holistic approach to benefits realisation over a longer period, e.g. reducing Total Cost of Ownership (TCO) for the key processes delivered using SOA.

• You can't buy SOA. SOA is not a product; it is a set of architectural concepts to develop a framework, a set of standards and (hopefully) a governance model. You may buy specific tools and services that are SOA-enabled, but this should only be when you already have the Architecture understood and agreed.

• Web Services are not SOA.  Most of the hype around SOA has been geared towards the development of XML and SOAP messages using HTTP. Web Services can be used as part of the delivery of rich business services with a Service Oriented Architecture, but SOA can exist and deliver benefit quite happily without Web Services.  Many companies have managed to use Web Services to create another island of development standards that are not part of any enterprise architecture - typically increasing the chaos within IT delivery rather than improving the quality.

We will be publishing more war stories and examples of good and bad practice in future blogs.

 John Moe

It has been months in the planning and is now unleashed on the world to show off the wonderful new services we offer, and also to highlight the excellent work we have been delivering for the past ten years. 

Seasoned visitors will be stunned by the cutting edge design and professional look to the site.  However, beyond the cosmetics, we now provide more depth, functionality and 'stickiness' to make your visits more productive and pleasurable.  The main highlights are as follows:

• A clear articulation of the Business Focus services and thought leadership content that we have become (in)famous for in the BPM and Process Improvement space.
• An expansion of technical services to encompass not only our deep (and crisp) WebSphere expertise, but also a wealth of help and support for those organisations struggling with understanding and delivering benefit from Service Oriented Architecture (SOA).
• A registration system to give you personalised access to our new events, newsletters and update service, so you don't miss any important news from Alphacourt.
• More and better education and training both for Business and Technical users and professionals.
• Better navigation through a variety of means - drop-down menu, side menus, site search, a tag cloud, and smarter 'next steps' on all pages.
• Regular updates will ensure that there is always something new and interesting every time you visit.

Well, I hope you enjoy looking around this new site.  We are very keen to have your feedback - please use the various hooks on the site to contact us and tell us what you think.  We will be offering a bottle of champagne for the best feedback or suggestion we receive each quarter that helps us make your browsing a better experience.

That's it for now.  We will use this blog to give you our finger on the pulse of the world of integration.  So please come back for more!

 
John Moe