Steve Brain, vice president of analytical trading technology at electronic securities broker Instinet, has a simple piece of advice for organisations evaluating application server technology: “Go in deep”.
IT market analysts, he says, can give you a good idea of the market as a whole. But, he adds, “You have to evaluate carefully whether [a specific] product is the right fit for you.” Before selecting BEA Systems’ WebLogic application server to underpin a new electronic trading platform, he says, his team spent hours with BEA’s engineers, discussing the organisation’s needs and piloting different configurations of WebLogic in BEA’s laboratories.
As Brain of Instinet points out, selecting an application server is a tough challenge, involving numerous technological and business criteria. Two years ago, application servers were viewed as point products that simply provided an execution environment and programming
interface to underpin applications. Now, they are touted as the strategic and technological foundation of a complete and integrated environment for application development and deployment, and for application and business-process integration.
Organisations deploy application servers for many tasks, including building complex transactional web sites, enterprise or consumer portals; establishing mobile or multi-channel infrastructures; and for application integration tasks that span systems, departments and corporate boundaries. That makes the choice of application server architecture vitally important for the business as a whole – although the decision remains primarily a technological one.
Net or Java?
Arguably, the most fundamental choice is between Microsoft’s .Net architecture, which essentially bundles application server functionality into the Windows operating system, and the Java 2 Enterprise Edition (J2EE) architecture, adopted by suppliers such as BEA Systems, IBM and Oracle for their standalone application servers.
Typically, smaller companies and programmers who favour Microsoft’s Visual Studio development language are seen as likely candidates for adoption of the .Net architecture, while larger businesses and Java-based development tool users are viewed as more likely to select J2EE-based application servers, because often they do not regard Microsoft environments as being sufficiently robust for large transactional systems.
There is some truth in these perceptions, but the reality is more complicated. Microsoft is strengthening its product set and winning converts for .Net in large enterprises. For example, in early 2002, Continental Airlines announced it was to use .Net as the basis for a system that will enable passengers to access travel information on a range of mobile devices.
“There are differences in scalability and reliability [between .Net and J2EE], but these are less than they were. The decision whether to choose .Net or Java is actually to do with the types of applications that you are going to build or buy, and where they are going to run,” says Mike Gilpin, an analyst at IT market research company Giga Information Group. Analysts at AMR Research, meanwhile, claim that, “Selection between Microsoft .Net and the J2EE vendors depends on existing infrastructure, application requirements, and IT skills, not on features.”
The key choice
Once the Microsoft/Java decision has been made, what other factors influence which application server an organisation should consider buying?
Despite all the hype, say analysts at AMR Research, differences between transaction processing, security, high availability and load balancing should not drive application server purchases.
“Although implementation differences exist across products, all [of the leading application server vendors] do a satisfactory job in providing these services and no vendor could survive in this market without doing so.”
Since each product provides basically equivalent functions in these areas, they add, “Evaluation should be based on what your programmers and administrators must do to achieve results rather than on the specific algorithms, interfaces and utilities provided.”
Integration, for example, is now a more important factor, since many organisations are shifting their focus away from building isolated application ‘stovepipes’ to developing integrated application architectures. “Ease of integration is very important to us. I’d like to see application servers with more integration functionality. Integration is the key point by which vendors will differentiate themselves,” agrees Tim Hargest, manager for technology solutions at gas supply network company Transco.
Cost is also extremely important, says Gary Pugh, director of marketing for Oracle 9i. “Overall cost has moved higher up the list recently. People are more sensitive to costs.”
However, the lack of a uniform pricing methodology among application server suppliers means that it is extremely difficult to compare vendors on cost – although it can, however, make it easier for users to bargain with individual, competing suppliers.
All vendors report pressure on prices, increased demand for free or discounted pre-sales consulting services and a more intense focus on return on investment among prospective customers.
Another increasingly important factor, given the cautious buying environment, is peer recommendation. David Webberley, senior technical director at Virgin Money, oversaw the organisation’s migration from Oracle’s OAS (Oracle Application Server) product to BEA’s WebLogic, after seeking advice from his counterpart at another companies within the Virgin group.
“The fact that our sister company was using WebLogic was important, because it gave us an understanding of how good [the product] was. [It also] gave us a good insight into how good vendors are in dealing with support issues, and that’s important, because you are looking for support services as part of that mix,” he says.
Indeed, businesses don’t just want good products; they want reliable support and honest advice.
“We want suppliers who don’t just look for a quick win,” says Webberley. “We look for suppliers that are willing to tell us honestly whether we should go for the latest version, or if we should stay with the current version for now.” Brain of Instinet concurs: “We looked at whether vendors were going to be around in a few years’ time, their future, and their ability to provide professional services and support for product[s].”
Over time, however, the choice of application server may become redundant, as application server functionality is increasingly subsumed into the overall application architecture.
Microsoft, for example, has experienced significant success by bundling application server functions into its operating system software. “It’s reasonable to ask whether people are getting value for money from application servers. To the developer, it’s intuitive to provide these services as part of the operating system,”
argues Peter Bell, business strategy manager for Microsoft UK’s .Net developer group.
However, other companies that have tried this approach have had less success. Sun Microsystems, for example, bundles a low-end application server with its Solaris operating system, but finds that most users of its high-end Unix servers deploy BEA’s WebLogic, forcing it to partner with its rival in the application server market.
Similarly, Hewlett-Packard (HP) had planned a similar strategy of bundling its Netaction application server with its HP-UX Unix variant. But in June 2002, HP announced it was to back out of application servers altogether, discontinue Netaction (acquired through its October 2000 purchase of application server specialist BlueStone), and renew a partnership with BEA Systems that fizzled out in 1998.
Among users with high-end requirements, there is still resistance to the bundled approach. “We’re not interested in seeing the application server bundled with the operating system because it would tie us to the operating system and to the hardware vendors, and that would remove our flexibility,” says Brain of Instinet. “We don’t want to make false savings by taking something that’s free – free isn’t necessarily better.”
The story, however, is different for low-end users, says Rob Hailstone, an analyst at IT research company IDC.
“For the average site with the average workload, you probably should be able to take application server functionality for granted, which means that there’s going to be pressure to commoditise the market,” says Hailstone. “In many ways, Microsoft is right never to have distinguished between the operating system and the application deployment platform; it’s an unnecessary complexity,” he says.
The stacked approach
As Sun and HP have found out, high-end users are wary of choosing application servers that are clearly aligned with hardware and operating systems. But they are, nonetheless, still interested in purchasing application server software from a supplier that can provide them with other elements of their software infrastructure.
In other words, they prefer to purchase a ‘stack’ of middleware tools that includes an application server alongside other software infrastructure elements: portals, development tools and application integration adapters.
This offers them the benefits of single vendor support, a single management console, elimination of the need to integrate products with those of other suppliers, and volume discounts in pricing. “It’s not about the application server itself any more. If the application server is the engine of a vehicle, the issue now is more about the whole car,” says Guy Lloyd, sales director for the IBM WebSphere family in northern Europe.
There is plenty of evidence that suppliers are responding to this need: IBM has unified much of its software infrastructure under the WebSphere name; in 2001, Sun announced its intention to rebrand much of its software portfolio as the Sun One family; Oracle uses the 9i brand to unite most of its infrastructure products.
Stacks sound like good news to many users: Transco, for example, chose Oracle’s application server partly because it wanted tight integration with its Oracle databases, Oracle development tools and Oracle enterprise applications software.
“If you buy mainstream products from a [single] mainstream supplier, they are more likely to be integrated than if you buy them from different vendors. I want to minimise the pain that I take on,” Hargest argues. Brain of Instinet, however, is more reticent about embracing the stacked approach: he argues that the move to broader middleware stacks is only good “as long as it’s an open stack and you can still choose best-of-breed elements. You always want the choice of best-of-breed, even if you don’t exercise that choice.”
All this points to a growing commoditisation of application server technology. “For most people, the capabilities of the application server are good enough, and are no longer the key drivers. It’s the broader stack that drives the choice, not the application server individually,” says Gilpin of Giga.
Which is why the decision of which application server to deploy may gradually become more straightforward. “The business has its requirements. Provided that they are met, the choice [of application server] is down to me, based on technical and commercial criteria,” concludes Transco’s Hargest. And as Webberley of Virgin Money points out: “It’s the applications that run on the application server that provide the competitive edge.