Building Infrastructure with Integrated Stacks

Tradeoffs are Key

November 18, 2004

The cost and complexity of designing, purchasing, deploying, and maintaining a stack of software applications to provide needed infrastructure for customer-facing applications sinks many projects prematurely. Customers would like to see software stacks that comprehensively provide all the necessary infrastructure services and are consistent across all components, use common tools for management and development, and are manageable as a complete entity through a set of common management tools and interfaces.


Complex customer-impacting applications are increasingly being built by IT organizations using service-oriented architectures (SOAs). An SOA depends on having a software infrastructure that supplies a comprehensive set of services, including code execution, security, data storage and access, workflow, transaction support, and more. These complex infrastructures are beginning to be designed and built using products provided by software platform providers that are taking the form of complete stacks of software components. A software stack comprises many different packaged applications, including directory servers, database servers and many other components. Ideally, all of the applications in the stack are integrated so that they can be installed, maintained, and developed for in a consistent, comprehensive manner.

There are distinct advantages gained from using an integrated stack to build out a system infrastructure, but the stack must support Web Services standards and other standards to achieve its integration in order for these advantages to be realized. Integrated stacks that have proprietary interfaces are risky propositions at best. Customers who try to build their own stacks from components supplied by different vendors will likely be frustrated by the lack of consistency in many different areas, ranging from standards supported to a multiplicity of tools for development and management.

An integrated stack holds the promise of providing an easy to deploy and easy to manage set of components that will reduce costs and minimize time to deployment for both infrastructure and, because of the integration across components, applications. However, there is always the risk of vendor lock-in if programming against the stack’s components has to rely on proprietary interfaces and protocols rather than standardized Web Services interfaces. Selection of a stack needs to be made carefully to provide the greatest flexibility possible, including the ability to deploy stack components selectively or even substitute another provider’s component without sacrificing integration.

Availability of complete and well-integrated stacks is a few years away. Nevertheless, efforts on the part of key software suppliers to integrate their stack components need to be tracked and encouraged by customers.


Developing and deploying software to support today’s customer-facing business applications has become an extremely complex proposition. Corporate IT decision makers and CIOs are faced with an impossible task of delivering those applications in a timely maanner for the lowest possible cost, while meeting or exceeding customer expectations. At the same time, IT decision makers and CIOs have to continue driving the alignment of business and technology goals.

That alignment is represented by customers’ expectations for seamless, end-to-end, cross-channel interactions and processing that incorporate all aspects of their interactions. This includes logging in or calling in, being recognized, resolving issues, configuring and/or locating goods and services, checking inventory and delivery times, placing orders, making payments, tracking orders, and managing all of their relationships. The same kinds of expectations apply to an internal customer as well, illustrated by a help desk process that has to track the initial trouble ticket through to its ultimate resolution and assessment of satisfaction and service level.

Service-oriented architectures (SOAs) and a set of backplane services (directory, security, identity management, transaction management, etc.) can be used to enable the development and deployment of customer-impacting applications, making systems easier to design, deploy, maintain, and enhance. But underlying those services has to be an infrastructure comprising an array of software components that provide the necessary functionality. This is far more comprehensive than the services provided by an application server, although application servers provide some of the required services. This infrastructure was described in an earlier Patricia Seybold Group report that described them as a Web Services Backplane[1].

One emerging approach for delivering that backplane is in the form of an integrated stack of software that corporate IT would purchase from a software platform provider. This approach holds the promise of greatly simplifying development and deployment, reducing cost, and accelerating time to market. Microsoft’s Windows Server System is currently the most aggressively marketed integrated stack, but other options from IBM, Sun Microsystems, and other software platform suppliers are emerging.

Apart from the complexities IT decision makers and CIOs face in delivering comprehensive customer-facing, cross-channel applications, the underlying infrastructure stack carries its own set of complexities involving component design and development; integration across components; software installation, maintenance, monitoring, and management; security; and other services. An integrated stack holds the promise of reducing that complexity.


In the current context, we’re talking about a stack as an assemblage of software applications, including an operating system, that provide the platform on which business applications--either commercial off-the-shelf applications or custom-developed applications--run. We are not referring to the memory address stack that programmers and chip designers are familiar with.

The discrete pieces of functionality required of the stack as a whole may be distributed in different ways across individual products, depending on how the vendor has chosen to design the stack. For example, one vendor may have chosen to provide directory services as a part of the operating system, while another may choose to provide a separate directory server. Microsoft’s Active Directory is an example of the former, while Sun’s Java System Directory Server is an example of the latter. Similarly, many application server capabilities are provided in IBM’s WebSphere, while Microsoft chooses to implement them directly in Windows Server.


Various audiences are motivated by different factors to consider supplying, leveraging, or buying an integrated stack.

Software Platform Suppliers

Software platform suppliers are motivated to develop and deliver an integrated stack by the potential of enticing customers to go with a one-stop infrastructure solution. While account control may be too harsh a motive to attribute to suppliers, the more software from a particular supplier a customer commits to, the longer that customer is likely to remain with that supplier. Once a stack is in place, the customer is likely to extend the stack with other products from the same vendor to the exclusion of products from that vendor’s competitors. Continuing and increasing revenue is a strong motivator.

Application Software Suppliers

Application software suppliers are motivated to develop to an existing stack to reduce their development costs, reduce time to market, and leverage the strengths of the selected stack’s supplier, including technology, as well as sales and partner organizations.

One of the key characteristics that is likely to emerge among integrated stacks is that they are highly differentiated. Applications that run on one stack are unlikely to run without extensive revision on another vendor’s stack. That doesn’t mean they won’t interoperate--but running on more than one stack will require that application providers develop and support separate versions. There are a relatively small number of platform suppliers that will become suppliers of integrated stacks, making the stack selection decision on the part of application software suppliers a straightforward choice of supporting the stacks that have the greatest market share and growth potential.

IT Organizations

IT shops are motivated to buy into an integrated stack to reduce complexity and the associated costs that go along with multivendor, heterogeneous infrastructures. The time, cost, and effort in getting the various pieces to work together the first time is only a part of the challenge. Maintaining mixed-supplier infrastructures over time is a continuing drain on resources. The overwhelming attraction of an integrated stack to IT decision makers and CIOs is the potential for controlling software costs and achieving significant gains in operational efficiency, including the cost of management on a continuing basis ...


Sign in to download the full article


Be the first one to comment.

You must be a member to comment. Sign in or create a free account.