Two years ago I was at BEA’s European subset of its BEAWorld event, at London’s Royal Lancaster Hotel, when a man from BT got a standing ovation for a presentation. A rare event in itself, the reason it happened was simple – he had simply told the audience that doing this `SOA thing’ was not as easy as some of the vendors liked to make out.

Given that his presentation followed immediately after two valedictory pitches from the company’s CEO, Alfred Chuang, and VP of Solutions and Product Marketing, Bill Roth, where the excellence of BEA technology was understandably lauded, this was hardly surprising.

What is a little more surprising is the fact that, two years on, a survey by PMP Research has shown that the gulf between the technology vendors and the business users is still as wide and unbridgeable as ever. SOA is already being seen as a `great white hope’. The next logical step is that becomes, along with so many other developments from the IT vendors, the next `great white elephant’.

In a way, it is hardly surprising. The one real trouble with SOA is the fact that, because the technology vendors came up with the notion, they are the ones that claim the privilege of selling it. And sell it they try to do – and try, and try. The trouble is, it is not an `it ‘ to be sold like a PC or iPod.

Two years ago Alfred Chuang launched into a BEAWorld keynote presentation by referring to business needs, but within minutes descended into a detailed discussion of Enterprise Service Bus architectures and the rest. The guy next to me fell asleep.

This is not a criticism, by the way; it is just a fact of life when technical people talk about what they have created. But to business users it is the equivalent of someone looking at a Leonardo Da Vinci sketch while someone goes on at length about the manufacturing processes used by the charcoal makers – technically interesting if you like that type of thing, but pointless to the subject.

The survey showed that the fundamental reasons that underpin the existence of SOA-oriented technology are still there – 88 per cent of respondents still need to integrate and interoperate disparate information systems. It is reasonable to suggest that, by now, most of the fundamental technical solutions have been developed and can be effectively implemented to satisfy the needs of many potential customers.

So why isn’t it happening? Why does the communications divide between business and technologists still exist? Maybe it is because the vendors need to stop talking, certainly about what they can offer. This is now about what users perceive they need to buy from vendors in order to solve problems that are defined in their terms.

It is not about what the vendors want to sell to them, especially if it is all that they actually have available.

There have been a couple of events recently which have demonstrated all is not as rosy in the web-based transaction world as the evangelists would have us think. It has been proven beyond a shadow of doubt that while it may be truly whizzy, running any sort of business via a website can be fraught with problems, particularly if you own the kit.

Let’s take the silly event first. It’s silly in as much as EasyJet was dumb and unthinking in its actions, though I doubt any malice was intended at all. To promote it’s `green’ agenda the airline used its customer newsletter to get them to cut and paste a boilerplate lobbying letter to their MPs and send it via the Charity web service, WriteToThem.com. So they did, in sufficient numbers to far exceed the Charity’s bandwidth allocation. The service promptly died. Many tears and a donation to the charity later things have been resolved and in the great scheme of things, not too much damage has been done.

The other event, of course, was somewhat more serious – Northern Rock and the ensuing flak it has received about the failure of its online service (as well as its branch-based service) to cough up customers savings on demand, in an instant.

I have seen the company castigated for failing to plan for unforeseen and unprecedented demand and therefore not laying in emergency capacity. Well, yes, in theory perhaps, but from where, and how much, and for how long?

This isn’t Second Life where you might flick your fingers and a small miracle happens. This is real life. And how do you actually plan for something that hasn’t happened for 140 years or more? How do the experiences of a quill-pen era relate to web-based transactions? Also, let’s not forget that there is speculation that the situation wouldn’t have happened at all if different Government actions were taken at different times.

I suspect this is where Risk Analysis and predicting the future through Rune Reading or that Friends Reunited prototype, the Ouija Board, get awfully closed to being the same thing.

Risk comes in many forms for any bank, of course, and one of them is to commit too much Cap Ex investment to services that are, in a risk analysis sense, definably no risk at all. What should they do, buy hundreds of servers to stand by, waiting, just in case? And they’d have to be upgraded of course, say every four years? On current statistics from the field that would be 35 upgrades of hardware that would probably never be used – and let’s not mention the software licences.

So there is no International Rescue waiting to come over the hill at 23:59:59? Well, no, not in situations like this and not if companies insist on owning the kit – or at least `owning’ the right to a defined lump of bandwidth. But it could exist in a different way.

The last few days have, in fact, been one of the best testimonials to the need to move towards a utility-based infrastructure – where that notion of `owning’ is restricted to `your data’ rather than `your computers (and the rest)’.

That way, there would be sufficient resources available to accommodate almost instant re-assignment to an emergency requirement like Northern Rock. And let’s not forget that half the problem was that once the story was out about the web-service `failing’ the more customers started to twitch and panic, making things worse. Just one story saying `web service still working fine’ would have calmed most of that very quickly.

The Utility Model won’t happen too quickly, of course, not least because users are still so attached to owning their infrastructure when it is only the information that actually worth claiming as `theirs’. Face it, no company can buy the resources needed to cope with a might-happen situation like Northern Rock’s and then have them standing around, idle.

I bet every vendor will be saying they should do just that, of course. They’ll probably even offer a small discount for bulk orders on scheduled call-off.

At a time when much of the technology of the infrastructure is, in effect, a `done deal’ and well on its way to becoming additions in the commodity product roster that IT vendors are generating, it would seem sensible to suppose that embedding at least some of the smaller commodities into some of the larger ones would make sense. That is, one assumes, the thinking behind the announcement by VMware of its new, embeddable, ESX 3i virtualisation hypervisor. However, while it looks damned good on paper, there may be some risks attached for any user going down that route.

On paper the idea is indeed pretty damned good. There is a great deal of sense in integrating as much as possible of the slow-changing technologies into the core systems of the infrastructure. This is exactly what Intel has done, for example, with many functions that were external to the `CPU’ but are now an integral part of the `processor’. Graphics processing capabilities is just one obvious case in point. Indeed, the `CPU’ is, in real estate terms, now almost a side issue in most processor chips, given what else is integrated into the silicon.

So the notion of VMware burning the ESX code into a memory chip for incorporation into a server motherboard would seem to be just one more step along that road. In time it might well prove to be the case, but that phrase, `in time’, is potentially quite important here. Virtualisation may have been the buzzword de jour for the last couple of years but the issues surrounding the technologies that implement it, the APIs that integrate it - or even the concepts surrounding what different vendors mean by virtualisation and what different users think they expect to see from it – are still too numerous and nebulous to contemplate being set in the type of technical concrete needed for an embeddable technology.

For a start, VMware is suggesting that the ESX hypervisor is going to make the implementation of virtualised systems a great deal easier because most of the technology is embedded – sysadmins will be relieved of much of the burden of setting up a virtualised environment, which on the face of it sounds good. But this has serious potential to hark back to the bad old days (OK, the current days for many users) where the IT environment, maybe even the whole business, has to be tailored round what the technology can offer, not necessarily what the business actually requires.

Also, ESX will be shipped with VMware’s existing management software. But in many infrastructures it is virtualisation at the systems level rather then chip level that can offer significant performance and flexibility advantages, and here the systems management software that matters is IBM’s Tivoli, HP’s OpenView, BMC’s Patrol and the rest.

The one advantage for users is that it looks like most of the commodity (x86) server vendors are going to bundle ESX, and some will probably also bundle ZenSource as well. They’ll probably bundle them all as they appear, which means users can ignore them all without fear of showing favour. At best, it means they can dedicate a couple of server boxes to a sandbox to find out just how useful this all might be in the real world. It may even be great.

Is the benchmark for benchmarks that they are no longer worth attempting? The question arises because far less action or brouhaha has occurred in the world of the new TPC-E benchmark than might have been expected. Both Dell and IBM have recently joined Unisys in publishing first results but, strangely, neither has made much fuss about them.

Back in July Unisys became the first server vendor to announce results against the new tests. These set out to simulate the online transaction processing workload of a brokerage firm. This is aimed at giving a much more relevant impression of how a server and database combination will perform in the real world than the old TPC-C benchmark, which while not discredited, has ended up fairly tarnished by rumours and innuendoes about the ways databases and hardware could `tuned’ to improve results.

Being first at anything like a benchtest, of course, will always leave any company on a hiding to nothing. So for a while Unisys had nothing to compare itself against, so no one - even Unisys - had the remotest idea of the relevance of the results. The company has an enviable reputation in many areas, particularly in building infrastructures and systems geared to the specific needs of vertical market sectors. As `a consequence it has usually eschewed the publicity-generating game of `who can build the real screamer’? So could the silence and Dell and IBM about their results have any relationship to that? The answer, at least in part, is yes.

It transpires that building a screamer is what Unisys appears to have done, at least in these early days of TPC-E. Its ES7000/one server came in with a performance of 661 transactions per second (tpsE), running a Microsoft SQL Server 2005 Enterprise x64 Edition database. Dell currently lies second at 220 tpsE, while IBM is third at 170 tpsE. Both of these were running the SP2 version of the same database. This result is no doubt coloured by the fact that the Unisys Server used 16 dual-core processors, while Dell used four and IBM only two.

However, when it came to price/performance, Dell and Unisys reversed positions. Arguably a more important metric for many enterprise users, this showed Dell at $1,020 per tpsE and Unisys at $1,777 per tpsE. IBM came third at $1,898 per tpsE, which might certainly explain its backwardness in coming forward.

The upshot of all this? Well, I do wonder if the reluctance to crow about these things publicly may indicate that there are now some doubts amongst vendors as to what benchmark results actually prove. For example, it is possible to read the price/performance figures to show that Dell can make a 4 processor server that is faster and cheaper than IBM or that Unisys makes bigger, more expensive ones – not much new there, then.

The performance figures can be read to show that the performance, per processor, of SQL Server drops off the more processors that are added, but that is hardly a startling discovery. And without then factoring in the different operating systems each is using – Windows Server Datacenter Edition for Unisys, Server 2003 Enterprise Edition x64 SP1 for Dell and the SP2 Version of that for IBM, getting anything concrete out of the figures gets to be a complex task. Can we say for definite, for example, that ipso facto the SP2 version is slower than SP1? I’m not sure I’d stake my life on it.

For IT managers, maybe this just demonstrates that the old ways of gauging these important issues are still best – get the sales reps to take you out to dinner and have `Scepticism’ set to `High’.