Moe's SOA & BPM Blog

You would think that after decades of practice, Business to Consumer (B2C) companies would have worked out both the importance of customer service, and the mechanisms by which they deliver a good service at an affordable cost.

Luckily for purveyors of process improvement technologies and services (currently packaged as SOA or BPM), most of these companies are still struggling to provide anything like an acceptable service. Unluckily for the recipients of this service (including me) achieving a painless experience is nigh on impossible.

My latest experience is ongoing - the brakes failed on my car last week and I crashed into a 650 year old castle. As you may have guessed the car came off worse, and the castle was undisturbed. However, I have been extremely disturbed by the incredibly poor service I have received from the insurance company. On the plus side I have actually gotten through to UK-based call centre people whenever I have called. On the minus side they have provided misleading and conflicting information, and have left me car-less for a couple of weeks.

Part of this is standard business practice - minimise cost of claim, find someone else to blame and foist the costs onto them - no problem with this. But this can be achieved without making enemies out of your customers. The low quality of service I am receiving is unfortunately still typical of a lot of organisations.

In practice there is still a lack of understanding of the quantitative value of the quality of customer service in organisations that should know better. Although most companies put the customer first in their mission statements, very few have translated this into a cultural shift in the behaviour of the staff involved in key customer processes. This is very much a people-driven exercise that explains the benefits of good service, and encourages staff to improve the experience of customers when contact is made - the Moment of Truth. If the customer has a positive experience (a Moment of Magic), it will not only reinforce customer loyalty but also provide increased opportunity for the company through the social networking that the customer will engage in. However, a bad experience (Moment of Madness) will do the opposite - customer will look to take their business elsewhere, and tell everyone who will listen to avoid the company. Research has shown that Moment of Truth can have a ten-fold impact of the actual direct cost of the customer transaction, either negative or positive depending on the experience.

Does your organisation calculate customer service benefits this way? If not then your competitors soon will, if they are not already doing so. With customer service increasingly becoming a key differentiator in consumer decision making, it should be something that all B2C organisations should have top of their list of priorities.

Now, if you want to take part in my social networking and know who the insurance company is in this case contact me directly at john.moe@alphacourt.com. If you are that insurance company I suggest you contact me even sooner.

John Moe

If you talk to anyone in the trade (of hawking SOA solutions, that is), their first answer to the "Why SOA?" question is usually re-use. Their second is: "Do you want to buy some (new) software to do your re-use?" If you've spotted the slightly logical inconsistency here, and are keen to recycle your current (enormous) investment in existing systems, welcome to the world of Green SOA.

In the crazy world of SOA, the future is services; and to get there you are being told to restructure and rewrite your systems to meet this new world. Huge sums of money are following the hype in writing reams of WS-* compliant .NET and Java code to provide thousands of new services to feed the SOA beast.

However, like all major IT hype cycles (sorry, trends) it is worthwhile stepping back and considering the best way to approach SOA for your organisation. There are very few cases where there are no existing systems to achieve a particular process or function. The mythical 'green field site' belongs in the same fantasy category as clean customer data or 100% server uptime. Many existing systems are imperfect, and are seen as difficult to adapt to new requirements, but tend to provide the core 80% of functionality that actually runs the business. Throwing the whole system away and starting again is a luxurious approach that few organisations can or should be contemplating, particularly in the current difficult market conditions.

Unfortunately, this is how SOA is being sold at the moment. Going back to the re-use benefit, wouldn't it make more sense to start re-use with what you already have? The two major arguments against this view are:

Our existing applications are not service enabled
We don't have the tools currently (ESB, service registry, process engine, etc.)
There is a third defence of general ignorance, but this is rarely admitted to.

Taking the first point, most legacy applications and packages were not built as a set of consumable web services but they will all have entry points to gain access to their data and functionality. This could be APIs, function calls, queries, screens, etc. Many of these encapsulate everything required to work as a service, i.e. defined inputs, outputs and transformation. However, because they may not adhere to a specific WS-* standard, they are not seen as SOA services. I have recently worked with a number of companies to help them understand how to service-enable their existing applications, in order to gain access to key functions that can be re-used as services to share with other processes or newer SOA builds. It has been surprising to the companies how much is potentially re-usable.

Secondly, the requirement for SOA tools should be seen in the context of a three layer architecture: conceptual, logical and physical. At the conceptual layer, you should have an Enterprise Service Bus to separate publishing of services from consumption. However, at the logical and physical layer this can be accomplished in the short term by existing technology, or, in some cases, just a logical layer with no physical equivalent. Examples of existing technology that could provide service functionality are Message Brokers, EAI Hubs, or any legacy middleware you may have lying around. The adherence to the new world of SOA may not be absolute, but you can provide the necessary abstraction using these technologies. In some cases, just using standardised API/Service calls from current or new applications can emulate the abstraction layer with no need for a physical bus, particularly for low numbers of services.

This approach may not seem very elegant, and the few architects still reading my blog after my last entry may disagree. However, in today's more pragmatic climate it would be common sense to look at re-using what you currently have rather than start from scratch.

John Moe

I've just come back from an Enterprise Architecture conference in London, where I was struck by how defensive a lot of the discussions were around the value of architecture. I could sense the frustration of architects who felt either undervalued or ignored by the IT and business colleagues - it reminded me of a bunch of physicists trying to explain how cool superstring theory is.

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

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

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:

You are no good at your job so we need to make you more effective (work harder) and efficient (sack you).
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.
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