It may seem blindingly obvious, but the primary reason for the existence of IT infrastructure is the support of the business processes that have generated the cash needed to create them. It is also something worth restating, because there are certainly cases where, regardless of the amount of cash spent, the infrastructures have singularly failed to deliver on their promises (or more commonly, hype).  

A good example is the amount of money and time that has been dissipated by many companies on the additional hardware and software resources needed to consolidate the business results of a multi-entity operation. And just for clarity, that means companies with multiple business units around the world and/or those built around a series of acquisitions. Both types have the problem of trying to bring as many of the business numbers as possible into a consolidated, coherent whole. This is a legal necessity which cares not that it means translating many different currencies into that of the main business unit. It can also mean trying to translate the business processes of an acquisition into something comprehensible to both HQ and the other business units. 

Companies can spend $100 million or more on trying to achieve this, and spend five or more years essentially failing to achieve the goal. At best, what they end up with is a huge spreadsheet offering a financial snapshot of a single moment in time for the business. There is no guarantee that the snapshot is even accurate and it most certainly is, like a suddenly discovered old photograph, without any contextual relationship to the business. 

This is considered state-of-the-art in the application of technology to business, yet should businesses be accepting a single photograph as good enough at a time when businesses need the context of full-colour, real-time video with slow motion replay available at any time? We expect it when watching any sport on TV. 

So the fact that it is now possible to get that real-time contextual depth from a consolidation – in the form of NetSuite’s recently introduced OneWorld adaptation of its SaaS-delivered business management system – is something that is genuinely worthy of a cheer. The ability to consolidate the results of overseas subsidiaries or acquired companies in 12 different languages and some 170 currencies, all at a mouse click, is an important capability in the management of any company. The fact that business managers can then drill down into the data, also in real time, to identify and resolve problems in the consolidation is a development of some real significance. 

But perhaps the most important aspect of OneWorld is that is a SaaS offering. This means that it is both extremely cost effective – at $1,999/month on top of  other NetSuite charges – and very flexible. For example, the basics underpinning being able to consolidate results is that it requires just one model of the business and its processes and service requirements, which can then be spun-out to the subsidiaries in their own language and currency, as well as their particular tax regulations and other country-specific compliance issues. It can even be used to hold and deliver the source material for subsidiaries’ websites, each rendered in the language of the country.  

It is also quite undemanding. Though the basis of OneWorld is an updated version of NetSuite’s database – and therefore holds the potential to generate the fear of users facing a technology lock-in – it actually offers considerable flexibility. It is not a rip-and –replace, green-field-only solution which requires users to throw away their existing applications. It is definitely for the real-world of `brown-field’ infrastructures. For example, there will be many companies with existing ERP systems on top of which OneWorld can run to provide the consolidation capabilities as an addition to what has been possible so far. 

This alone is an important capability because of the way SaaS is likely to be implemented by a large number of companies. They are all likely to have a baseline of applications that are critical to the business and which they are unlikely to want to abandon without good cause. So SaaS is likely to creep into a lot of businesses, quite possibly starting with what are seen as unimportant tasks. But if it can creep in, accommodate and interoperate with existing infrastructures and also do something of core importance to the business, it could be just the tool needed to be the lever to prise open markets for SaaS. After all, just like every other major development SaaS will probably need a `killer application’ and OneWorld might just be it.

Sometimes markets change through the appearance of a thoroughly disruptive new technology, but more often the change comes about because of a collection of events and market forces. Just such a collection looks as though it is in play for the semiconductor industry.  

And what has this to do with servers and infrastructure? Well, it looks like the events and market forces are being generated in just those areas and the result is growing pressure on the makers of processors and support devices for the server marketplace. 

It would appear that at least some server vendors are a little miffed at the likes of Intel about the amount of business it is now generating out of selling direct to what should be, in their eyes at least, `their customers’. There have been, historically, a large number of sensible, economic arguments against `customers’ building their own systems rather than buying them in from a specialist vendor or two. But those arguments are now getting close to running on empty and for some of the biggest customers, such as Google, the tank is already dry and they have moved on. 

Google is already making its own low cost servers to its own spec and, given the volume that it consumes them there is an obvious economic justification for it. But if other users and other server vendors base their judgements on just that `volume requirement’ justification, and so dismiss Google as a statistical freak rather than a true market dynamic in the process of change, they will be missing an important point. 

The issue now is not just that some big users are starting to build their own servers rather than buy – just because they have large datacentres and it therefore makes economic sense. It is that large datacentres – very large ones – are starting to make important economic sense in their own right. That means the economic arguments are starting to point at every user having the largest datacentre possible. But that in itself is all-round economic nonsense unless the next obvious step is taken – not actually have their own, but share the services available from a few extremely large datacentres. 

The reason is straight up and down economics of the technology. Datacentres are now not only avaricious and expensive consumers of electricity, they are being identified as such. And despite much hand-wringing there is in fact not a huge amount yet being done to solve the real and perceived problems. But there are solutions available.  

Shared, virtualised servers have better utilisation and make for reduced resources – less bucks for each bang. Each server works better under more pressure – power supplies, for example, are at their most efficient when nearly busting a blood vessel to keep going – so more bangs for each buck. As management tools continue to improve, more systems can be managed by the same number of staff, and the bigger the datacentre the more real hotshot specialist staff it can justify employing, improving service provision and reducing downtime.  

SaaS as an alternative to onsite datacentres centres and `owned’ applications may as yet be a small part of the market but is showing the way in how to combine the reduction of operating costs and the increase in operational flexibility. Scale that up and there does come a point where pure economics is likely to be the lever that fundamentally changes the buy/build argument about servers and datacentres. The answer, for all but the big service providers, will be neither – just sign up for a service instead.

So, it appears that there were no significant announcements about server developments at Intel’s Developer Forum, while at the same time the biggest story from IBM is that the p-Series and i-Series systems are being merged into a rebranded entity. Of themselves neither story is worth too great an emotional outburst, but they are perhaps a sign that, at last, server vendors are starting to realise that they are now updating hardware faster than the users actually need. What they need is the ability to make better – probably re-architected and possibly upgraded – use of the applications and tools they already run on the platforms they already have.  Having announced a batch of new server-oriented developments a few weeks ago, Intel’s biggest server news at the IDF was sight of Tukwilla, the 4-core Itanium processor. That is of only marginal interest to most server users, though HP will pleased to see it and others, such as PSI, could be interested in its ability to run mainframe software on big Itanium boxes a more interesting proposition. There are obvious strong economic arguments for IBM to want to rationalise the hardware of the Unix-running p/Series boxes and the old AS/400 i/Series. They have been using the same processor for some time, so the more the internals of the hardware can be the same assembled circuit boards the bigger the manufacturing savings that are possible. There are some question marks as to how far the rationalisation can go as each system is, historically at least, aimed at different operational and application models and therefore may still require different I/O stages to meet those application needs. Branding issues obviously come in here as a necessary digression, for bringing the p- and i- families together requires a new name. IBM has opted for the safe – and under the circumstances undoubtedly sound – answer of `Power’. After all, both use Power family processors. This does actually also leave the door open to ultimately include the z/Series mainframe family, which runs on a close relative (definite first cousin material) of the Power processor line. That filial relationship is likely to get stronger as well.  

But the more that IBM can bring these application areas towards running on a totally common hardware platform the more sense there is in it for users. In short, it makes opting for the platform that bit easier – and is the essential argument behind common platforms and virtualisation: the users get far greater flexibility without having to revert to too many alternative platform options. They also spend less time – and money – on continually updating to the latest gee-whizz hardware across multiple platform types. IBM looks as though this is where it is heading – certainly a common hardware platform for Linux,Unix (AIX) and OS/400, and an outside, longer term place for z/OS as well. Long term, this may prove to be no bad idea either, as I do suspect the market for the z/Series mainframes is changing. There is growing scope for their application in areas such as web services, as well as others well outside of the scope of the traditional `mainframe’. To catch the wave, however, IBM has to be ready to move with it. The current announcements are not yet sufficient to say this is happening, but they are pointing in the right direction and getting a lot closer to where the future looks as though it is heading.  In fact, a single common hardware platform is a good theoretical goal – but in practice it is probably unachievable. At least two alternates are needed, probably three, which is likely to be the best compromise between real operational flexibility and manageability for both future and legacy systems. Three will cover most O/S and applications bases, yet should not cause too many operational and infrastructure management headaches. And this latest announcement from IBM makes it possible to speculate that the three could be x86 multicore, Itanium multicore and the `Power’ family. That would allow most users to perm any two from the three. In the end, however, much of this will depend upon IBM’s ability to look beyond the comfort of large, established but static markets for its systems and on to the potential that exists for real growth in new market sectors. A slow decline through atrophy may otherwise be a result.