Many CIOs and other executives are looking for insight on the most critical steps in building an enterprise architecture. Increases in componentry and openness in packaged application architecture belie a megavendor agenda for greater architecture ownership and customer lock-in.
Vendor application and infrastructure stack
Packaged applications have always come with baggage. For years, the adage has been, “buy an application, inherit an architecture.” That adage remains true. Even with an increase in openness, service-oriented architectures, exposed integration layers, and metadata, mega-application vendors use architecture for account control and increased IT spending share.
Megavendors differ in the level of infrastructure associated with their applications and in their intentions for future infrastructure tie-in. To help enterprises in their evaluations and planning, Gartner has depicted vendor presence in the application and infrastructure stack (see Figure 1). The figure shows areas of origin and strength shaded and areas of less presence unshaded.
Why vendors improve their stack presence
Vendors have multiple reasons for increasing their presence in the overall stack:
Vendor approaches differ
As IT budgets get tighter, so does the battle for architectural domination and, thus, market share dominance increases. Many software vendors have tried one-stop-shop differentiation, while others offer a best-of-breed approach to differentiation. All are attempts to lock in customers to their solution sets. The ongoing tussle for control of the application deployment infrastructure in the enterprise has resulted in an overlap in the roles of the different layers of the computing and technology stack.
Because competing vendors have different strengths, it is reasonable for vendors to fashion strategies that play to their strengths and minimize those of their competitors. With functionality overlap crossing boundaries between layers, deployment options will lock enterprises into not only the products involved, but also the architectural direction of the vendor.
Enterprises should direct the search for optimal deployment of functionality by the constraints of the application, and not vendor perceptions of where the functionality should be placed.
The expansion of SAP's packaged suites has pushed it further and further into development and server technology. With business logic and transaction management centered in its application server, the vendor has little use for the features of high-end database managers, and has the potential to subsume the database into its stack, except for the highest-volume implementations. SAP's strength is breadth of application offerings. Its challenge is demonstrating an ability to expand into the platform markets. It would be quite late to market with any truly competitive technology offerings, such as database management system (DBMS) and file system.
Siebel migrated from a path of enhancing its proprietary application server layer to a strategy of greater reliance on using commercial application server technology. It intends to leverage the infrastructure of IBM and Microsoft. Siebel's strengths are its dominant position and its focus on customer relationship management (CRM). Its challenges are its dependence on other infrastructure and platform providers, and its lack of experience and depth in offering a platform.
Oracle has one of the fullest application and infrastructure stacks that has been built from the DBMS outward. Most recently, Oracle has begun to promote the use of Linux as all that is needed to host the balance of the Oracle stack. Oracle's strength is that it provides customers with a comprehensive stack. Its challenge is its reliance on Oracle's DBMS, which has experienced flat to declining revenue during the past two years. Although not coveting the operating system (OS) layer, Oracle seeks to commoditize the OS as a way to displace any customer foothold for database competitors, IBM and Microsoft.
IBM has built its substantial stack presence from hardware and OS upward. Historically, it has had more success in providing infrastructure and services around custom applications and other vendor applications than as a packaged application provider. IBM's strengths are its enterprise installed base, and the service capabilities aimed at complex enterprise environments. Its challenges are to consolidate its diverse and overlapping software portfolio, and maintain customers while expanding into new markets—such as small and midsize businesses. IBM will continue to shift the customer lock-in from hardware to software, and continue to consolidate and rationalize a complete IBM software stack.
Microsoft's significant presence in server OS, database, and middleware and dominance in desktop applications has not yet translated into equivalent penetration for business applications, such as ERP II and CRM. Microsoft's acquisitions of Great Plains and Navision have resulted in business application offerings targeted at small and midsize businesses. Nevertheless, Microsoft's potential as an application competitor remains partially responsible for larger ISVs being hesitant to lock in to more than the OS and database layers of the Microsoft stack. Microsoft's strengths are its ability to define a technology and development infrastructure for its products, partners, and customers to rally around. Its challenges are in completing execution and delivering on a highly integrated stack.
Gartner has compared the strategies of the megavendors to those of selected best-of-breed vendors (see Figure 2). A vendor's strategic choices are characterized by the degree to which they tie into the vendor's infrastructure stack compared to the breadth of its business application offerings. A vendor's position on the chart is a representation of the character of the strategy, not a judgment of its correctness; many winning and losing strategies are possible.
The strategy of "business utility" is a most challenging strategy to sustain, but perhaps the most richly rewarding for the vendor if executed. In this strategy, a complete infrastructure and a wide set of business application offerings come from a single vendor. Characterized by Oracle and SAP, these vendors tout integration and a community of applications, but market the efficiencies and benefits of one-stop shopping. Only vendors that can sustain high product R&D and demonstrate long-term viability can be successful in delivering product innovation over time and convincing prospective buyers to tie themselves to a single, preferred vendor. Enterprises choosing vendors in this category are more likely to abdicate architectural control of enterprise architecture to the vendor's architectural strategy.
Vendors with a wide range of business applications that seek to minimize the degree of infrastructure tie-in have been termed "infrastructure agnostics." Characterized by PeopleSoft and Siebel, these vendors seek to broaden target markets by remaining technology-neutral. The strategy remains credible only if the products for all supported environments come to market in the same timeframe, with equal quality, performance, and capability. Any unbalancing of technology support risks making orphans of customers based on the less-favored technology, with the accompanying loss of customer loyalty and reinvestment. This is the analog in infrastructure of a similar strategy that played out when vendors first considered supporting multiple relational DBMSs. Enterprises aligning with vendors using this strategy must judge the sincerity of the vendor's stated strategy as well as the credibility of the execution plan.
Vendors with more of a focus on loyalty to their technology than business applications have a "technical fortress" strategy. Characterized by IBM and Microsoft, they cultivate exclusive loyalty to their platforms. They court commitment from enterprise developers and ISVs. Success is measured by the ability to build an overall system. Cross-software platform interoperability, which is at the heart of an infrastructure-agnostic vendor's strategy, is counter to the "technology fortress" strategy objective. It is provided only to the degree that is demanded by platform constituents.
Microsoft's fortress includes the operating system and the application platform stack (and perhaps even the database). IBM is more neutral regarding the operating system and has built its technology fortress around the application platform stack. Through 2007, neither IBM nor Microsoft will dominate the other in terms of market share of total infrastructure stack (0.8 probability).
The cost of interoperability and platform neutrality will continue to shift away from technology fortress vendors and toward the infrastructure agnostics, making the strategies of the technology fortress vendors increasingly expensive to maintain. Despite references to standards, through the power of their brands, megavendors will continue to create barriers to entry and reduce the appeal to ISVs of alternative technology fortress platforms, such as BEA Systems.
Technology fortress vendors face their greatest market threat from the ability of "business utility" vendors to drain away loyalists to their technology fortress systems.
Application symbionts have a narrow, best-of-breed offering and little technology infrastructure of their own. Characterized by i2 Technologies, vendors with this strategy typically do not have the interest or resources to assert their own infrastructure stacks. Additionally, resource constraints inhibit their ability to operate neutrally across multiple infrastructure stacks. This forces them to choose, and any choice is market-narrowing. Choosing symbiosis with a technology fortress megavendor protects them from business application megavendors, but limits their presence in the substantial business application systems.
Partnering with megavendors exposes them to functional harvesting and direct competition megavendors that have more substantial channels. Ironically, at a time when component technologies and loose coupling offer higher access to discrete functionality expressed as services, best-of-breed vendors remain cut off from larger markets by the technical and functional turf grabs of larger vendors. Enterprises evaluating best-of-breed vendors must examine the stability of their technologies and market strategies along with their functionality and viability.
As the booming market of the late 1990s moderated to much lower growth rates, vendors have had to adjust. The adjustment has been sobering to the megavendors and punishing to smaller, specialized vendors with fewer resources. Diminishing license growth exposes the cost mistakes of the past and is forcing a new focus on margins. With this comes a rediscovery of the annuity nature of software applications.
Even with the rise of integration, Web services, portals, and componentry, vendors can rely on the sunk infrastructure cost of customers, the high cost of switching, and the desire for an application portfolio with fewer vendors as forces to keep revenue flowing from the installed base. To do that, vendors have focused on a time-honored formula: keep new functions coming, create a Trojan horse technical dependency, and siphon a share of professional services. Other variations, such as midmarket strategies, global differentiation, and alternate delivery channels, have become secondary.
Through 2008, "megapackage" vendors will use varying combinations of infrastructure depth and business process breadth in an attempt to increase their customer wallet share (0.8 probability).
Because megavendors would likely succeed in making them customers for life, enterprises should carefully evaluate compatibility with a vendor's industry, technical strategies, and service strategies—initially and over time.
The basis for that review is consideration of the application and its related technology in the context of an enterprise's architecture.
Most enterprises will find that they end up supporting multiple vendor stacks based on application requirements, development needs, and negotiation flexibility.
Enterprises should plan on incurring the additional costs of staffing and management requirements, based on the expectation that those resources will be required to maximize their enterprise architecture flexibility and agility.
TechRepublic originally published this article on 9 September 2003.