by Laurie M. Orlov

Why You Need More Than One Software Vendor

Jan 10, 20086 mins

Lining up a single vendor to supply most of your software seems easy but isn't always smart, says an IT management expert. With fewer vendors to choose from these days, it's best to hedge your bets. n

The conventional wisdom is that it’s always better to have fewer software vendors—or even a single vendor—to manage than it is to use multiple vendors. Now that, according to a recent Forrester Research report, there are only 17 large independent software vendors left, it’s a good time to reevaluate this closely held belief.

More on

Why You Need a Vendor Management OFfice

9 Things to Know about Consulting and Contracting

CIOs who subscribe to the “one-throat-to-choke” approach to vendor management typically think about it in one of two ways: Either they want to get the various company departments that run different tools to agree to a single provider or they want to forestall deployment of new tools until their big enterprise vendor supplies them. The goal is to, one way or the other, achieve a standard platform and make running IT easier.

But reliance on a handful of vendors may not be in your best interest. This is especially true now, when the software market is consolidating. Take the recent acquisitions of business intelligence vendors Cognos (by IBM), Hyperion (by Oracle) and Business Objects (by SAP). IT customers are waiting anxiously to see what the big guys are going to do with their newly acquired products. In the meantime, IT departments should hedge their bets.

Why Vendor Standardization Is Wrong-Headed

At the core of the desire for standardization has always been the desire to optimize IT at the expense of business constituents who prefer (or believe they need) a variety of different tools to do their jobs. By reducing the number of software products to support, limiting the number of vendors to call with a problem and minimizing potential behind-the-scenes data complexity, the IT job will be easier and overall support costs will be reduced. This optimization may, however, engender substantial employee frustration during a switch to IT’s preferred tool.

Another questionable justification for standardization has been that integrating products from multiple vendors along with the data from multiple systems costs much more than standardizing on fewer vendors. Unfortunately, few IT departments compare the potential costs of integration with the costs of dependency on one vendor’s product. With fewer vendors in the IT portfolio, CIOs limit their negotiating leverage; vendors won’t budge on terms if they don’t think they have competition.

Meanwhile, standardization produces unfortunate side effects. Business constituents wait endlessly for that elusive next version or conversion. Resentment of the IT department bubbles and boils as end users’ favorite tools are retired or new tools lack functionality that users want.

Why Market Consolidation Hurts CIOs

During the past few years, IT organizations have gotten an assist in their quest for fewer vendors from the software industry. For example, as Oracle acquired Siebel, PeopleSoft and others, the acquired products have been integrated at the Oracle corporate level, and license and maintenance fees have become standardized.

But this isn’t exactly a standardization fan’s dream. Customers have to worry about organizational disconnects between the acquiring and acquired vendor teams, variability in pacing of technology upgrades, prospective higher license and maintenance costs, and new product development priorities. As my former Forrester colleague Vice President and Principal Analyst Andrew Bartels notes, “Customers need to worry that the acquired vendor’s product might not be a core part of the acquiring vendor’s technology universe.”

Even when an acquisition is based on acquiring the new technology (rather than absorbing the competition), customers should be concerned about the potential for diminishing entrepreneurship within the acquired company.

Five Ways to Reverse a Flawed Strategy

Given the downsides to the one-throat-to-choke approach, should IT organizations abandon it? In some cases, such as in prime contractor service vendor relationships (where a single consulting firm manages relationships with smaller subcontractors), it may be useful. But in the world of software, having one throat to choke has virtually no benefit. Enterprises need leverage with vendors to manage and maintain costs that can get out of hand as their organizations grow and the software market shrinks. Here are five ways to maintain your leverage.

1. Prioritize a common data model over common software. Sometimes IT migrates to a single software vendor but doesn’t get around to running identical application versions, or worse, enables users to enter nonstandard data. Making data usable is more important than having a standard version or vendor. Getting agreement on the data model is more difficult than decreeing a software standard, but the business results are more compelling than the number of vendors you use.

2. Retain more than one vendor in every important category. Even though it may be tempting to reduce IT support costs by limiting vendors to one, maintaining multiple products in a strategic software category protects your future leverage. Even if switching costs are high, you should keep vendors guessing by continually reminding them of their competitors’ unique and state-of-the-art product and service benefits.

3. Maintain your balance of power with competitive or reference bids. Vendors know that if you are fully dependent on their products, you will have difficulty eliminating them. Keep them guessing about how much you need them. One mid-market CIO I know attends the user conferences held by his current vendor’s competition, meets with the competitor’s salespeople, solicits bids from them, and considers their products for new deployments and at upgrade time.

4. Support third-party vendors. The struggles of third-party ERP maintenance provider Tomorrow Now (which competed with, then was bought by and is now being sold by SAP) raises the question of why more CIOs don’t support independent maintenance providers.

Are CIOs so dependent on a vendor’s feature upgrades in subsequent product versions that they give in to vendors’ threats to withhold them if maintenance is canceled? Think about whether you really want those upgrades. IT execs can band together to find the capital to fund third-party services and products they need to sustain their independence and leverage. There could be more tools out there for reverse engineering processes, data and reports from enterprise apps, which in turn could enable switching vendors if service declines or prices rise following an acquisition.

Instead, CIOs appear to be maintaining their victim status with an “Oh well, they’ve got us” stance. That’s surprising in light of their inadvertent and growing vendor dependency and the inevitable costs and risks that result.

5. Assess your portfolio for acquisition probability. Finally, take a close look at your portfolio to identify your greatest vulnerabilities. Figure out which software products are likely to be acquired—putting future product innovation at risk—and specify contractually any code escrow terms that preserve your options.

The end result? Those business constituents will be happy to hear that you will leave them alone to use Cognos or Hyperion or whatever application they want. Now, if only they will agree on the proposed standard definition of a customer name and address.

Laurie M. Orlov does research and consulting on business and technology strategy. She is a former vice president and principal analyst at Forrester Research.