When large organisations build and implement major systems, they don't buy all the components from a single vendor. They might prefer to but, in reality, no single IT vendor can provide absolutely everything so they have to pick and mix.

Imagine a big ebusiness project involving a heavy transaction load, some database applications, a web server and a customer relationship management (CRM) package. All of these components are likely to be key to the project which is, in turn, likely to be very important to the business.

So how do you choose which products to use? You might think that the obvious thing is to pick the best of breed or best value for money in each product category, then link them all together. Unfortunately, that is rarely practical. Even if it is, it may be a bad idea.

Well-stacked?

Large systems are normally based around a 'technology stack'. Someone building such a system will probably have a configuration of server hardware, an operating system, a system management regime, a database and back-up technology to go with it, an application server, a web server and any functional packages that have been pre-selected.

The stack has to work from top to bottom, otherwise the system will not work. The most important element of the stack is likely to determine which other sales occur.

It might be that, on consideration, the CRM package is the most important component of the whole project, and the best value occurs when it is implemented on a weighty Intel server running Linux.

This will probably make BEA the favourite to provide the application server, while favouring Dell as the hardware provider.

Alternatively, it might be that the database is seen as the most important element, and perhaps the company is already committed to Oracle, which it has installed on Sun. This would mean that the hardware purchase is likely to go to Sun.

In any context there is likely to be one incumbent vendor that is favoured, possibly because a bulk purchasing arrangement already exists and sticking with that vendor will represent the best value.

If we turn the whole thing around and look at it from the vendors' perspective, we can see some very distinct technology stacks out there.

There is, for example, the Microsoft-dominated stack: Windows NT running on Intel with Microsoft SQL Server and the Microsoft Transaction Server coupled with Microsoft development products.

Then there's is the Oracle stack, which is driven by an Oracle database and Oracle applications with your choice of Unix/Linux and hardware vendor, such as Sun, Hewlett Packard (HP) or Dell.

Then the BEA stack, driven by the application server and middleware, which gives a similar likely choice of hardware.

Then the IBM stack, which tends to be very IBM - the mainframe with Linux, DB2 and Websphere - but there are variants that involve the iSeries (previously known as AS/400) and IBM's AIX-based Unix range. There are also other variants that could be mentioned.

The intricacies of 'co-opetition'

What is interesting about these stacks is that they cause the formation of informal alliances. For example, Oracle and IBM are in deadly competition for the database revenue, so Oracle prefers Sun, HP and Dell to win hardware sales and keep IBM out, and Sun, HP and Dell also tend to prefer it that way.

Microsoft has the most proprietary stack and can only really partner with the Intel hardware vendors, all of which will be happy to get the business. However, as it has no Unix position, it is eliminated from some sales that depend on specific packages or on scalability where NT is usually thought to be weak.

You might think that the systems integrators (CAP, Logica, PCW, KPMG and others) are neutral in this, but in many instances they are not.

They all fear competition from IBM Global Services and are likely to try to influence a sale away from IBM technology if they can. The enterprise resource planning vendors such as SAP and Siebel are not neutral either. Oracle has competitive packages, so they would like to steer database business away from Oracle towards IBM.

They may once have favoured Microsoft, but the Redmond giant has been buying business applications.

Finally, all of these considerations blend with the prejudices and preferences of IT users who, as we have already noted, are usually committed to one technology or another in some part of the stack in their existing installation.

And that is how the game of co-opetition is played.