I know that for many Enterprise Architects it is blindingly obvious why everyone needs a Zachman or a TOGAF, but they are struggling to articulate this value in terms that normal folk (and other IT brethren) can buy into.

The consequence of this lack of buy-in is that most lovingly crafted architectural diktats (sorry, guidelines) are either ditched as being too cumbersome, or blamed for causing cost & time overruns.  Commonly both. 

On the surface it is difficult to find fault with the key perceived benefits of EA, typically around standardisation and integration.   However, there are two main challenges I have found with EA: the Theory and the Practice.

The issue at the theory level is that most EA frameworks promote standardisation as their mantra.  However, for quite a few business challenges this can lead to poorer performance due to the inevitable compromises that come with standardisation.  When a business need is time critical (measured by time to market or transactional performance) standardisation can slow down the delivery.
 

Aha! say the architects.  If the standards had been there in the first place, the business would have already been working well.   And this is where the practice falls down.  The sad fact is that most businesses exist in a chaotic state not because they are badly run (not always, anyway), but because of external factors; as Harold MacMillan said, 'Events, dear boy.  Events.'

Therefore, there is little chance of coherent standards being put in place initially because the business was almost certainly reacting to events rather than languorously designing and implementing an elegant and logical architecture.  Trying to persuade the business to retrofit a revised architecture for no obvious business benefit is easy if you have the sales talent, but then you would probably have been better pitching to Alan Sugar to win the Apprentice.

What seems to be working in the more successful organisations I have visited recently is a tighter engagement by the Enterprise Architecture team both with the business (understanding the specific challenges faced by different business units) and with IT (embedding architects full time into the major projects, having them incentivised to deliver the project successfully AND meet corporate architecture standards).  By engaging with all the stakeholders and communicating the merits of EA effectively, architects can deliver more than an ivory tower.

"Architecture is Politics."  Mitchell Kapor, Founder of Lotus and Mozilla.

John Moe

Giving the normal noise and meaningless labels that tend to adorn (re-)launches of products and offerings, I have to say that Smart SOA is certainly not one of the dumbest brand ideas, and even has some special merit, although perhaps not in the way that Big Blue's marketing folk may have envisaged.

First of all though, I need to get one thing off my chest.  Applying the tag Smart to software is an oxymoron.  Most people's experience of software is the other dictionary meaning of smart: "to be the cause of a sharp, stinging pain, as an irritating application".  Remember expert systems with their fuzzy logic? Or Intelligent software that can think for you - HAL 9000 from 2001?  Software only does what you it tell it to do, and then you have to be precise in how you say it.

Smart SOA works as a phrase when you consider it more as an application of the old acronym SMART (Specific, Measurable, Achievable, Realistic, Timely) to Service Oriented Architecture.   Given the ongoing challenge of IT to deliver genuine and lasting business benefits, it makes sense to at least appear to be trying to add value.

Most people's experience of SOA so far has been either patchy (we wrote a web service and it worked - we'll try another one next year) or frightened (analysts quoting cost of building SOA to be larger than most companies' annual budget).  Even though many CIOs see moving to SOA inevitable, most are still challenged to articulate what the business is going to get for its money if they allow their IT people another toy to play with (IT is usually seen as Kevin the teenager - inarticulate, negative, late for everything and getting bored with anything new they buy).

Taking a SMART approach, IT can provide their parents, I mean sponsors, with clear goals and benefits for any investment project, along with a set of metrics to ensure that promises are quantified and understood.

Another way to get SMART is to break down the journey, by phasing in the adoption of new architecture, rather than going for a big bang implementation.  I have found that this evolutionary approach is both more acceptable to business as well as being more practical, less risky and therefore more cost-effective.

It is unlikely that many CIOs are going to be given a blank cheque in the current economic climate - we are back to the 'do more with less' attitudes of the early Noughties.  So Smart SOA is not about clever software, but about being SMARTer in how we make use of it.

John 'Mensa (Retired)' Moe

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

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

• 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

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

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 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

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

• 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

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