Wednesday, June 03, 2009

The downside of vendor consolidation

Consolidation is generally an excellent strategy for reducing the cost of IT while maintaining or even improving service levels. Server consolidation, storage consolidation, data center consolidation, and applications consolidation are all examples of strategies that organizations use to accomplish these objectives. Our research at Computer Economics on consolidation consistently points to strong return on investment experiences of organizations that undergo server consolidation, storage consolidation, data center consolidation, and applications consolidation.

Vendor consolidation may also be included in the list. Reducing the number of IT suppliers has a number of benefits: fewer contracts to administer and volume discounts are two obvious examples. But vendor consolidation has one big downside: risk of vendor lock-in.

Vinnie Mirchandani has an excellent post on this subject this morning, Why I am not an Apple Fanboy. He writes,
The benefits of vendor consolidation are grossly overrated. Split your dollars across many vendors. Also, vendors often misinterpret long term relationships as license to pull lock-in shenanigans. Benchmark them constantly and refresh your vendor base periodically.
This is especially true in the case of enterprise software, such as ERP, CRM, business intelligence, and supply chain management systems. Once these systems are in place, it is very difficult to switch. Hence, enterprise software vendors promote the concept of vendor consolidation, with all of its benefits to the customer, realizing that it is also of immense value to the vendor that remains. Nowhere is this better seen than in the drive by major vendors, such as SAP and Oracle, in charging their software maintenance fees at 22% of original software license cost.

Larger firms especially have options. It is still the exception, rather than the rule, for large companies to standardize on a single enterprise software vendor. Most have two or more vendors, whether by design, or more likely as the result of mergers and acquisitions. What I am suggesting, which is contrary to conventional wisdom, is that there is some benefit to this situation. Rather than consolidate to a single vendor, rationalize the choices made and consolidate to no fewer than two.

There are several ways this strategy could be maintained. For example:
  • Consolidate to a single vendor for worldwide financials, but standardize operational systems on another vendor's platform. Always leave the option open to replace one with the other.

  • Consolidate to a single vendor for centralized CRM and order management, while allowing one or two different vendors to provide operational systems at the plant level, perhaps one for large plants and one for small plants.

  • Revive a best of breed approach. Leave HR, asset management, and other non-core systems outside the scope of the primary vendor's implementation.

  • Test vendors' touted SOA capabilities to build composite applications. If these capabilities really are what vendors say they are, they ought to allow "seamless integration" with third party applications.
Vendor consolidation does have merit in supplier relationships that do not lend themselves to vendor lock-in. Think supplies, such as laser printer toner. Or, temporary staffing. Or, equipment leasing.

But when it comes to enterprise applications, beware of vendor consolidation.


vinnie mirchandani said...

great point - lots of efficiencies from data center consolidation, back up consolidations (amazing how many copies some companies make) etc..

Matthew King said...

The major vendors themselves have embraced composite applications, therefore the service oriented technologies required to support them are assured. Take a look at for an example of what it already happening.

Replacing, modifying, and combining applications from the same or different vendors is much easier in a service oriented environment. But what is also possible, yet not so obvious, is that of changing the underlying infrastructure itself.

In other words a customer can swap out their entire service infrastructure for a new one, yet keep all their existing applications, meaning minimal disturbance for business users and unchanged application costs.

Swapping out an application service platform is no small task, but is much easier than changing an entire application landscape and all the change management and business disturbance that goes with it. Instead the impact is confined to the I.T. organisation.

Whether a customer implements IBM WebSphere, Oracle/BEA WebLogic, SAP NetWeaver, Microsoft .NET Framework, or some other technology stack, the lock-in effect is reduced at this level also.

I think it worth noting that a service oriented solution doesn't come cheap. But they reduce lock-in effect, smooth cashflow, spread risk, can be tailored to better meet business requirements at the outset, and are more easily changed and enhanced as an organisation evolves.

Frank Scavo said...

Matthew King wrote:
"In other words a customer can swap out their entire service infrastructure for a new one, yet keep all their existing applications..."

Matthew, as I said in my post, I agree that SOA should in theory reduce lock-in effect.

However, I would really like to see an example of a customer that has been able to successfully "swap out their entire service infrastructure for a new one, yet keep all their existing applications."

Do you have an existence proof?

Matthew King said...

I think it is more a question of cost-benefit than of technical feasibility.

QANTAS and British Airways run Oracle Apps (among others) over BEA infrastructure which raises some interesting questions, both before and after the acquisition of BEA by Oracle.

When a company reaches a point where all their apps are running on some kind of common SOA infrastructure, at that point it might be a more realistic proposition. Before then it would be too complicated.

Also, it might largely remain a theoretical proposition - for negotiation purposes. But an important one nonetheless.

An in cloud SOA infrastructure might offer an easier alternative. A customer would move their apps from one in cloud provider to another. This way a provider need only adjust their capacity in line with the change in load on their infrustrature, rather than having to decommission an old infrastructure altogether. There would need to be application installation and testing of course.