Sometimes, there exists the dichotomy between stating the blindingly obvious and the fact that the blindingly obvious still needs to be stated. The recent news that a Microsoft-sponsored survey, conducted by IDC, has shown that the need for interoperability between applications and tools is driving the growing acceptance of XML-based standards as the glue between them is a good case in point.

It is blindingly obvious that some form of interoperability standard – a lingua franca of sorts – needs to exist if applications are going to co-exist in ways that make sense in a modern IT infrastructure. These days, they should just work together, not create another new engineering problem for the IT department.

It is also reasonably obvious that XML has already reached the point, in terms of penetration and reliability, to be considered the only sensible and widely accepted candidate for the job.

But there is still, as IDC analyst Per Andersen put it, the role of `pragmatic business needs’ that have a habit of making the blindingly obvious seem irrelevant and out of place for many users. In other words, there are still many users that feel such standards are not for them and have no place in the infrastructure employed.

If blinkers are worn then this, for many, will in fact be the case. It is fair to accept that it will also remain the case for some for a good while yet – legacy technology that still fulfils a role is going to take time to reach pensionable age. Fortunately for the legacy apps that have a life expectancy, the work has usually now been done to build the bespoke tools needed to integrate them into a standards-based environment. But from now on, those responsible for architecting and managing infrastructures must be looking at a new set of integration points that are built around those blindingly obvious standards.

In practice, what this is likely to mean is that the developers of applications, utilities, tools and service delivery technologies will need to make their offerings compatible with those standards and the existing systems that use them. Issues such as compatibility with an operating system will become irrelevant, while issues concerning the ability to integrate with infrastructure management systems out of the box are already high priority – all the major vendors understand the need for standards-based interoperability between their offerings.

The days of engineering integration between hardware, applications and tools has to be long gone….now, preferably, but at least in the very near future; that is now blindingly obvious.

As SOA becomes more endemic across the user community, one of the most important developments in the future management of IT infrastructures is going to be creating the tools that can build the services and processes businesses require, from a resource pool of components. This will be the core task where any business requires a process to be run `now’ and then be removed cleanly from the production environment when it is no longer needed. This is no mean task, particularly when what constitutes a `component’ will be the archetypal `piece of string’.

But technologies are starting to appear that do show signs of offering users what will be required in the role of services orchestrator. This is likely to be both a human and an accompanying set of tools. The human part will be in charge of managing the scheduling of tasks and processes so that business functions and objectives are met. The tools will be what that human `plays’.

The most important of those tools will be that which allows the orchestrator to bring together the components needed to create a desired process or service and allow them work together. This can be a lot harder than it sounds, not least because the first step needed will be to find those components.

One solution is about to emerge out of the Eclipse open source development environment, where one of the projects – Buckminster – is aimed at being the tool applications developers can use to build both components and applications. These, in turn,  may themselves be built of other components and applications. It can search through a wide range of different component repositories, both local and remote, to track down specified components, and can then track down the components that go to make up the specified component.

So, though the orchestrators’ task may well start by defining small components, they can soon start to build them together into the major process components that the business needs. In practice, a Buckminster file will be a list of the components required and where they can be found, together with a set of instructions on how they integrate and interoperate together. The only code it will contain is if something specific is required.

The details can be so precise that specific versions of specific components from specific repositories can be identified, so as to ensure exact repeatability of a service or process. This can be particularly important where issues such as corporate governance and compliance are high on the business agenda.

One of the interesting aspects of this approach is that it allows the term `component’ to be just about anything. OK, this is probably stretching a point in order to make it – certainly just at the moment - but earlier this week Ingres announced what it claims is the first open source application-specific software appliance, the strangely named `Icebreaker’ Business Intelligence tool. Its probably a bit big and requires too much management to be considered a Buckminster `component’ for now but , as an appliance, it has the theoretical potential to be one. It might even be one once Buckminster gets past project status and becomes an available tool in about a year’s time.

And that is the way things are going – in the same way that old cars had carburetors, distributors and sets of points and now have integrated ignition systems – so components will grow from useful code fragments to complete sub-system appliances, glued together by tools like Buckminster.

As SOA becomes more endemic across the user community, one of the most important developments in the future management of IT infrastructures is going to be creating the tools that can build the services and processes businesses require, from a resource pool of components. This will be the core task where any business requires a process to be run `now’ and then be removed cleanly from the production environment when it is no longer needed. This is no mean task, particularly when what constitutes a `component’ will be the archetypal `piece of string’.

But technologies are starting to appear that do show signs of offering users what will be required in the role of services orchestrator. This is likely to be both a human and an accompanying set of tools. The human part will be in charge of managing the scheduling of tasks and processes so that business functions and objectives are met. The tools will be what that human `plays’.

The most important of those tools will be that which allows the orchestrator to bring together the components needed to create a desired process or service and allow them work together. This can be a lot harder than it sounds, not least because the first step needed will be to find those components.

One solution is about to emerge out of the Eclipse open source development environment, where one of the projects – Buckminster – is aimed at being the tool applications developers can use to build both components and applications. These, in turn,  may themselves be built of other components and applications. It can search through a wide range of different component repositories, both local and remote, to track down specified components, and can then track down the components that go to make up the specified component.

So, though the orchestrators’ task may well start by defining small components, they can soon start to build them together into the major process components that the business needs. In practice, a Buckminster file will be a list of the components required and where they can be found, together with a set of instructions on how they integrate and interoperate together. The only code it will contain is if something specific is required.

The details can be so precise that specific versions of specific components from specific repositories can be identified, so as to ensure exact repeatability of a service or process. This can be particularly important where issues such as corporate governance and compliance are high on the business agenda.

One of the interesting aspects of this approach is that it allows the term `component’ to be just about anything. OK, this is probably stretching a point in order to make it – certainly just at the moment - but earlier this week Ingres announced what it claims is the first open source application-specific software appliance, the strangely named `Icebreaker’ Business Intelligence tool. Its probably a bit big and requires too much management to be considered a Buckminster `component’ for now but , as an appliance, it has the theoretical potential to be one. It might even be one once Buckminster gets past project status and becomes an available tool in about a year’s time.

And that is the way things are going – in the same way that old cars had carburetors, distributors and sets of points and now have integrated ignition systems – so components will grow from useful code fragments to complete sub-system appliances, glued together by tools like Buckminster.

So IBM has decided to cut a deal with arch-rival, Sun Microsystems, that will allow it to offer Sun’s Solaris x86 operating system on its Xeon and Opteron-powered servers. The news has caused something of a stir. Well, I suppose at face value it is a bit exciting, but in practice I suspect it is simply an indicator of how far down the scale of importance technologies such as server hardware and operating systems have slid.

It is no more than should be expected anyway, even if you can afford only a cursory glance at the history of such things. Twenty years ago the actual nature of server hardware design and architecture was still considered the crown jewels for many vendors. Ten years – indeed, up until recent times with the likes of IBM – some operating systems were similarly considered crown jewels. On that basis, the mere fact that IBM has its own Unix – AIX – would be considered more than sufficient justification for banished the very notion of selling arch-rival, Solaris.

But times have changed, and even though this deal specifically covers Solaris x86, which IBM could therefore argue `competes’ with AIX in much the same way as Linux, it does seem as though some true sacred cows are set to be slaughtered. There are strong hints that the deal could be extended to IBM offering Solaris on its pSeries servers – home turf of AIX – and even on the most sacred cow of all, the mainframe systems.

Has IBM gone mad or lost faith in its own technology? I very much doubt either. Instead, this is all about a simple realisation – that there is significant long term business in consulting, architecting, building and extending enterprise infrastructures.

Against that level of business, getting sniffy about the choice of operating system favoured by the customer is a total irrelevance. IBM, like HP, makes no secret of the fact that it would love to eat Sun’s server business, but it also accepts the inevitable – there are a great more many enterprises that like Solaris more than enough not to want to change from it.

This can get a good deal more complicated the bigger and more distributed an enterprise becomes, especially if it is an amalgam of different businesses. You can bet good money that some of them will be, historically, Sun shops and won’t want to change. As most CIOs and IT managers will know in such situations – such changes can be positively harmful.

Think what you like of IBM, it has the experience in building and managing such infrastructures and, in the shape of
Tivoli, some management technology with a more than suitable track record. For an enterprise to bail out of choosing Tivoli because it still wants to run Solaris servers and applications, or for IBM to say “shan’t” until they agree to switch, would now be foolhardy.

So if it marks anything at all, this deal marks the end of the era of the operating system supremacy wars, and a move towards a time when all that is irrelevant. At last businesses may be able to get on with some real work.

The thought has occurred to me that it might be a sign of insipient curmudgeonly luddism on my part that I think Linden Labs’ Second Life is a waste of time. But the thought that it was also a serious waste of energy – at a time when energy management and all things `green’ are amongst the hottest topics (oops, sorry) in infrastructure management – had not really occurred to me. But the issue is an important one, particularly for businesses; there they are running (often) huge server farms and important applications, but not always knowing what their users are doing or, more to the point, what demands their customers are making on the systems.

Second Life customers, it seems, are making significant demands upon the Linden Labs infrastructure. I recently bumped into the Blog of Former Harvard Business Review Executive Editor, Nicholas Carr, where he set out some simple maths which demonstrated that, with an average of around 12,500 Avatars `living’ in Second Life, and with 4,000 servers running flat out to provide their `world’, each Avatar over a year consumed the equivalent electricity to the average Brazilian. Let’s face it, that’s a lot of energy going on….well…..not a great deal really.

The hardware vendors are making significant noises about offering systems with reduced energy consumption, lower heat dissipation and the rest of that good stuff. They are doing their bit. The software vendors are starting to catch on as well, with IBM’s `Big Green Linux Initiative’ being the latest contender – though the sales pitch seems to be “buy more Linux and have a cooler datacentre”. I’m not sure that cause and effect are that closely, or simply, related.

This raise a wider issue in energy consumption arguments: just what demands are being made on the applications, particularly web-based applications, by users? If there is little or no control over those demands, then it matters not how energy-efficient the servers – they’ll just be thrashing away, consuming energy for little return in business terms.

Here’s a simple example. You have a web-based online trading site, together with a very pretty website. Thousands of people seem to spend lots of time faffing around on the site, window shopping but not buying. There are so many of them that the servers are always overloaded and running slow – so you consider buying some more. But the revenues are also worse than expected as most site visitor are not buying, so that is a difficult business decision.

This type of scenario is surprisingly common, with website window shoppers consuming infrastructure resources and slowing systems to the point where real customers abandon ship and go elsewhere. They rarely come back. And all for the lack of some management of what website visitors do when on a site. I wonder how much energy, cumulatively, is wasted in such ways, and how many additional servers are installed in a vain attempt to overcome it?

Perhaps IT infrastructures are comparable to our growing obsession with obesity. Eating more `slimming food’ may not be the best solution when set against controlling what, and how much, gets eaten. It is a part of the energy and infrastructure management equations that has not yet been truly taken in hand.