Don't let vendor lock-in limit IT agility. Due diligence will keep your vendor options open.

That is why cloud vendor lock in is one of most common (and important) conversations I have with clients. Decision makers are rightly concerned about being locked into a cloud platform with no clear exit strategy.

Vendor lock in is not a new concern in technology. I can remember over a decade ago being tasked to architect and develop a web application that was built to run on on both SQL Server and Oracle databases, just in case the company changed its “strategic” database vendor. That seems crazy now, and a real waste of money; but the customer had concerns about owning a technology that might die. The truth is, legacy never dies; it just hurts if you cant see the exit.

Vendor lock in is particularly important to consider in the design of cloud services and integration; Part of the promise of the cloud is to only pay for what you use when you use it. It is an OpEx driven financial model, avoiding a big up front costs for licensing and hardware in favour of metered consumption. This is good for most businesses, but some clients are concerned that they may incur greater costs in future if a vendor increases it’s pricing. Customers of cloud vendors need to understand what the exit looks like, even if it is unlikely they will exit in the near future.

Good lock in

If lock in is undesirable, how can it ever be a good thing? In software architecture (like all forms of design), no decision is a zero sum; there are always trade offs in the decisions we make. Beware the technologists who turn up with a single “right” answer. Life is not so simple as “AWS is wrong” or “Open source is the only way”. There are no new problems to solve in technology.

However much of the cloud services market is focussed on pioneering new approaches to old problems. This is particularly true of the software as a service and platform as a service market. Vendors are providing innovative new ways of solving problems, and if you are the first to market there is inevitably an element of lock in. Technologists cannot chastise vendors for lock in created through innovation. There are many first to market examples. Amazon were the pioneers of massive scale storage in S3 with a proprietary api to consume the service. Salesforce invented a new market in cloud crm with entirely proprietary tools and language constructs. Azure invented the notion of managed platform compute.

The trade off many face when choosing a cloud vendor is between buying into a unique selling point that is built, deployed and managed in production as a finished capability and building something new, costly and unproven. This is good lock in, so long as there is an exit strategy.

Bad lock in

After the pioneers create innovative new services, the competitors arrive to challenge them. And after some time, a “standard” emerges, normally in the form of protocols. Much of what ba.net does is about really understanding the protocol soup on standards that is the internet. This stuff is important to anyone who cares about the integration and operational model of their digital business. Standards are a good thing; they provide an exit strategy to vendor lock in. Proven standards de-risk complex undertakings, by defining contracts against a pattern that is proven to work against certain design goals. This is pure SOA philosophy.

However, the term “standard” should be treated with some caution; standards are open to interpretation. They are sometimes hijacked by a vendor as a marketing tool to attack their competitors. In my opinion, this is what open stack represents today; it’s a vendor backed (Rackspace) claim of a standard that the majority market leading cloud service providers have yet to adopt. The innovating cloud service providers tend to adopt standards when they become too mainstream to ignore anymore. Recently, Microsoft have become very good at doing this; examples include the Azure Service Bus adopting support for AMQP, and Azure Active Directory supporting the majority of identity protocols and token formats.

A vendors adoption of standards is where bad lock in can start. Many vendors approach standards with an “embrace and extend” strategy to keep you locked into an eco system. The most obvious examples of this are with browsers. Vendors adopt the latest HTML standard and then add their own browser features that extend the standard. When sites use these features, users remain locked into the browser. IE6 is the quintessential example of this problem.

Embrace and extend is caused by a vendor having an agenda to cross sell you more services. The truth is, all vendors have an agenda. One needs to understand the vendor’s business model to avoid the pitfalls of vendor lock in. Google sell advertising. Apple sell hardware. Amazon sell content. Facebook sell you. Microsoft are mid flight between being a seller of software licenses to a seller of cloud services. Each of these vendors have different forms of lock in caused by what is commercially most important to them. Because Amazon sell content, they push services such as Kindle onto all platforms no matter how exotic; the lock in is in the content itself. Microsoft’s move away from licensing into cloud services has meant that Office 365 subscribers now get a full fat (excellent) office suite on their iPad; the lock in no longer with Windows but to the Office 365 subscription.

Bad lock in therefore is essentially capitalism at work; it is bad, but it is also understandable.

Ugly lock in

Where bad lock is visibly unpleasant, ugly lock in is invisible and devious. It is the footballing equivalent of a cynical foul. Again, it is caused by a vendor agenda, but in my opinion the difference is that it involves a vendor removing support for something previously supported, or changing terms and conditions to force a third party to remove something.

There are several examples of this I can think of in technology:

Google attempting to remove support of the H.264 video codec from Chrome in an attempt promote its own WebM codec. Apple changing its iOS App Store terms and conditions to force third parties to remove in app purchases that bypass the App Store. This meant apps such as Amazon’s Kindle app had to remove the store button from its app, while iBooks keeps its link to iTunes. Fortunately, I am not yet aware of any ugly lock in scenarios with cloud services, but I suspect that is purely because the commercial market is still maturing.

Conclusions

Cloud service customers should embrace vendor lock in when there is a clear commercial advantage to adopting the vendor’s cloud platform. However, customers need to understand the trade offs this approach brings and should always enter lock in scenarios with their eyes open to the potential threats that lock in can cause. Above all customers should always have an exit strategy from lock in. At ba.net, we are committed to “no vendor agenda” with our clients, providing impartial advice to help client make decisions around the cloud services lock-in conundrum.

Within the last ten years, many companies have migrated to cloud-based technology to avoid the budgetary constraints of funding large capital projects for data centers and agile software development. While cloud solutions offer companies many benefits, it still introduces some risks. For example, vendor lock-in is as great in the cloud as it was in the data center.

Vendor lock-in is commonly defined as "Proprietary lock-in or customer lock-in, [which] makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs."

In short, if you are tied to a certain vendor, even a cloud vendor--and you want to change direction--it's going to cost you time and money.

How do you avoid getting locked in in the first place? Below are five steps to avoid vendor lock-in.

1. Negotiate both an entry and exit strategy upfront with your vendor Many companies are eager to sign on a contract's dotted line without reading the fine print. If you read the fine print, you will usually find clauses that address termination. Often, termination can entail giving a 30-day written notice.

In addition, there are other elements concerning termination that you should discuss with prospective vendors and write into your contract. For example, you need to ensure that your vendor will assist you with a deconversion if you want to migrate to another vendor.

This is important because vendors are notoriously uncooperative once they know you want to leave them for a competitor. The best way to avoid a potentially unpleasant and hostile situation is to document SLAs for deconversion assistance with your vendor upfront in your contract. This way everyone is clear about their respective responsibilities when it comes time to switch vendors.

2. Watch your contracts for auto-renewal Many IT vendors auto-renew contracts for a new term unless you notify them that you don't want to continue a contract. This common IT oversight occurs when no one keeps an eye on vendor contracts. To avoid this problem, monitor contractual commitments and when terms come to an end.

3. Have a backup vendor Let's say that you're using a cloud vendor for data storage. It's always a good idea to have a backup cloud storage vendor at the ready in the event that you wish to leave the first vendor. This way you already have a secondary business relationship, and you aren't exclusively tied to the first vendor.

4. Design portable applications If you're using infrastructure or platform as a service cloud vendor for your applications, design your applications so that they can easily be decoupled from the underlying infrastructure or platform of your hosting vendor. This simplifies the task of transporting applications and data to an alternate vendor.

5. Keep on-premise options open Don't overlook on-premises options. While some companies opt to move entirely to the cloud, it's not a bad strategy to retain the ability to failover to your own home data center when all else fails.

Service level agreement (SLA) policy

An effective SLA establishes standards for critical operational concepts like uptime, service quality, problem response/resolution times, and performance metrics. This policy provides a foundation for building an SLA that protects both service providers and their customers.

From the policy:

Service level agreements streamline operations and allow both parties to identify a proper framework for ensuring business efficiency and customer satisfaction. On the flip side, businesses can identify where problems lie if service level agreements are not adhered to, then make the necessary decisions to find additional budget funding, impose penalties, or seek alternate providers and staff.

These agreements can exist between businesses (such as between a company and an external cloud provider) or entirely within an organization (such as between an IT department or help desk and its user base). They can be unidirectional (one party assuming responsibility for all details) or bidirectional (both parties share responsibility for certain elements or actions).

Customer responsibilities Customer are expected to work with providers to establish acceptable and reasonable service level agreement requirements—such as performance metrics or response times—based upon operational need. For instance, seeking 99.999% uptime is a common and feasible trend, but 100% uptime may be impossible.

Customers are expected to follow all technical or legal requirements, such as security policies, acceptable usage governances, regulatory compliance mandates, internet access policies, and all other applicable guidelines.

Customers must contact the provider via appropriate and established methods A service level agreement can’t be applied to alternate or unapproved methods of contact, such as leaving a voicemail directly on a technician’s phone line. The technician might be on vacation, and therefore the service level agreement would be breached. Only an approved, shared contact number should be used.

Customers must acknowledge planned outage notifications (such as for maintenance) and work with providers as needed to address potential problems that may arise from these scenarios.

Customers must notify providers to request additions or changes in established service levels. If providers are represented by internal individuals or groups (such as the IT department) changes to service level agreements should be discussed and mutually agreed upon by authorized personnel (such as the IT director).

Vendor relationship management checklist

From the checklist:

Love ‘em or hate ‘em, vendors are key to the success of most every information technology consultant. Strong vendor relationships help good consultants excel, but a dysfunctional vendor alliance can sink even the most astute of consulting firms. Thus, vendor relationships are critical, yet their importance is often (and easily) overlooked.

Why? Simple.

The time, energy, and resources invested cultivating vendor partnerships, reseller relationships, and distribution agreements don’t constitute billable hours. As a result, consultants often have trouble justifying the required time to establish and solidify vendor relationships.

Unfortunately, without strong vendors, few consultants can meet client needs. And without proven sources for delivering competitively priced software, equipment, renewals, services, and related components in a timely manner, consultants end up frustrating customers—and customers walk.

Worse, disgruntled customers share their stories with other businesses. “Consultant X couldn’t obtain Windows systems quickly.” “Consultant X couldn’t reduce my enterprise security software licensing costs!” “Consultant X took three weeks longer than planned to complete a new platform rollout because the hardware was late, supposedly.”

Consultants can blame vendors all they want—even if delays, snags, and other issues that arise ARE the vendor’s fault—but the burden to deliver remains with the consultant, not the vendor. Whenever a consultant proposes a project or initiative with a client, it’s the consultant’s responsibility to source the required software, hardware, and other elements, recommend vendors, and establish pricing.

So what’s a time-pressed consultant to do? This checklist can help. It’s a simple guide based on lessons I’ve learned owning and operating my own IT consulting firm for 12 years. Use this checklist to select the best vendors, track your satisfaction levels, and maintain strong partnerships.

Private Cloud Office . Self-Hosted Office . Business Email . Domain for Life . AdBlock

BA.net Private Cloud Office . Self-Hosted . free Download . Blog . Managed Hosting . Business Email . GDPR . Testimonials . Reddit Forum . Lang . Video Demo . Tutorials . Partners . Price Advantage . Utils . Wordpress . AdBlocker . Manuals . Privacy . About Us . BUY PRO

BA.net/office +54911 2546 1403 iphone@ba.net BA.net - Private Cloud Office Hosting Replace O365 Managed Nextcloud Onlyoffice MS Microsoft Office Compatible Word Document Sharepoint Spreadsheet Excel Power Point Presentation Self-Hosted Premises Collaboration Groupware Talk Chat Teleworkers Remote Teams Office 365 G suite Gsuite Basecamp Slack Alternative back office gdpr cipa affordable easy enterprise files backup restore cloud storage server msp isp iphone@ba.net About BA.net