News

Ovum on E-business: Don't fear vendor 'lock-in'

Is lock-in really that bad or are we just afraid to commit? Lock-in is often regarded as an intrinsically bad thing, and many technology adopters will go to great lengths to avoid being tied to a particular solution or vendor. Is lock-in the demon that we all make it out to be or is it just a fear of tying the knot?

In advising clients on technology selection, the issue of "lock-in" inevitably comes up. Some of my clients are so worried about being tied to a given solution or vendor that they'll do almost anything to avoid it. Vendors, naturally, seek to turn this obsession to their advantage by promising to be the most "open" and the most "standards compliant." There is a hidden irony in these claims. If vendor "X" is the ONLY vendor in the universe to be fully compliant with standard "A," then what they are effectively saying is that you'll be locked-in to their solution -- at least until the competition catches up. In practice, lock-in is largely a function of perspective and it can, and should, be looked at from another point of view.

Why not call it commitment instead? What is the difference between "lock-in" as a concept and "commitment"? The single distinguishing factor is "trust."

The notion of "trust" is hampered in the world of information technology. Technology users and vendors seem, at times, to be stuck in a perpetual merry-go round of mistrust. Recently, I was trying to help one of my clients negotiate with a vendor. We were looking for a price reduction on the understanding that my client would be using this particular product in the first of many projects. The vendor ultimately confided in me that "every single client asks for a discount on the basis that this is the beginning of something big. My problem is that I can't tell who is being sincere and who is just using the possibility of future business as a negotiating gambit."

Perversely, technology buyers can actually be extremely suspicious of vendors that offer to lower the cost of introducing their technology because, to quote another client, "they're only offering the discount to tempt me. Once I'm locked-in, they'll take me to the cleaners." So "Freedom from Lock-in" becomes a mantra that informs strategy and buying decisions. But this near obsession can result in a fairly blinkered approach to lock-in. In talking about lock-in, we worry a lot about the technology -- how technically difficult would it be to move from vendor A to vendor B in 12 months? This issue comes up all the time when technology buyers are trying to select an application server.

There's no doubt that selecting a standards-based application server should allow the transfer of an application from that product to another equally conformant product (assuming that one exists) with relatively little effort. Nevertheless, there is another very big reason such reasoning is difficult -- money. One could say that spending $1 million or so on a product implies a commitment. Very few of my clients seriously believe that they will ever be able to convince their CIO or, in the case of a million dollar investment, the CEO that after spending $1 million or so on product A that some new features in product B will better run key applications. To put it another way, is it not foolish to even consider spending a million dollars with someone you don't trust? If you believe that there is a real likelihood that you are going to want to throw out their solution and get another, then perhaps you shouldn't do the deal at all. The solution to this dilemma is to stop thinking in terms of lock-in and to talk instead about commitment and partnership.

Consider the criteria you use when considering a commitment to form a partnership:

* Will this commitment benefit us both?

* Is the other party willing to share some of the risk associated with the partnership?

* Will my prospective partner be able to support me over the long term?

* Is my prospective partner going to be flexible as my requirements change over time?

These criteria can, and should, form part of the contact you make with your partner. In marital terms, this is the equivalent of a pre-nuptial agreement.

Partnership entails four golden rules:

* Your partner has as much right as you to benefit from the relationship.

* You have a right to expect your partner to take on a fair share of the risk.

* The value of a partnership increases as it endures.

* You must both expect the relationship to evolve over time.

When negotiating long-term contracts, managers should address each of these criteria explicitly. The last of these -- the ability to adjust an agreement over time -- is the most important. One should never sign a long-term agreement without a framework in place for adjusting that pact over time. There is no point in signing a contract with a service provider to support 1,500 desktop computers over five years without having the ability to raise that number as your business grows, or even to reduce that number if your business shrinks. If the worst happens and your business does have to downsize, it's in your partner's long-term interest to insist that you continue to carry the burden of paying for unused services. At the same time, you should be aware that there may be economies of scale at 1,500 desktops that aren't available for 750; you must therefore remember that your partner has a right to benefit as much as you do from the agreement.

So instead of talking about lock-in, call it commitment instead. Be clear about the commitment you are making, as it will have a financial as well as a technical component. If you don't trust a potential partner enough to make a commitment, you have to consider whether you should be doing business with them at all. Commitment is something to be considered, it is not something to be feared.

For more information, go to www.ovum.com

About the Author

Gary Barnett is IT research director at Ovum Ltd., a United Kingdom-based consulting firm.

Featured

Most   Popular
Upcoming Events

AppTrends

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.