8 tips for avoiding vendor lock-in

Vendor lock-in makes you unable to switch vendors without substantial switching costs or inconvenience. While standards bodies and an increased focus on interoperability have helped reduce the threat of application lock-in, website and web application development can still be a minefield. In many cases, site owners only realise the dangers of lock-in once they are trapped with rising support and maintenance costs, slow and expensive change processes, and the prospect of prohibitive costs to develop an equivalent solution from scratch.

Vendor lock-in doesn't have to be an intentional attempt by the vendor to restrain their client's future choices. Plenty of companies are trapped in arrangements simply because their technical solutions were supposed to be short term. Lack of long-term planning can lock you into a vendor without that intent existing on either side.

Similarly, sometimes vendors just don't have the time or the resources to take on work the client wishes them to do at a given moment in time. If the site owner can't bring another agency in to do the work they are clearly suffering from lock-in.

There are, however, several steps you can take to realise the benefits of working with external suppliers without fear of lock-in.

1. Separate suppliers. Companies often contract a single supplier for a number of technical services, to achieve cost savings or to simplify supplier relationships. However, this exposes the company to risk of vendor lock-in, unable to switch to another system without significant overhead of money, time or hassle. The problem can be avoided by trying to separate suppliers, where practicable. One straightforward example might be separating hosting of a web application from its development.

2. Integrate rather than extend. Web service APIs are now a common feature in many commercial and open source applications. Common functionality across applications is separated into a service layer, available to all applications to use, reducing the need for maintenance. Tight coupling between different applications makes lock-in much easier, increases the complexity of the code base and makes the flexibility of a system equal to the least flexible component of that system.

3. Retain ownership of your data. One risk with using a hosted / software-as-a-service system is that potentially critical information is under the control of another company. This is one of the key factors in traditional vendor lock-in, and ensuring that data remains accessible should be a high priority. There are broadly two approaches to the problem: control the data directly, or ensure there is a reliable way of extracting the data in a usable format.

4. Retain ownership of intellectual property. There is a danger with bespoke development of moving away from a supplier only to discover that they own critical parts of a system, forcing the site owner to negotiate continuing use of those subsystems. This can be avoided by a contractual agreement that the client owns all custom work, or alternatively all custom work is released under a license that allows free reuse and extension.

5. Look for mindshare. It's relatively easy to look at proposed costs and features when considering proposals, but it's hard to see what the cost of changing developers on a system will be. As part of your RFP process, ask developers whether they will be building the site from scratch, or use some underlying system. Most companies won't be building in 'raw' PHP, Ruby, Java or .NET - they will make use of open source or commercial systems that provide many functions 'for free', and implement or extend these as necessary to meet the needs of the project. Should a proposal be entirely bespoke (not using any framework/application as its basis), it will be much harder for another agency to take over the work.

6. Document processes. Documentation is one of the best, but most misused, tools in ensuring site owners truly control their systems. In general, the documentation should cover the exceptional, rather than the normal. If the system follows a standard deployment procedure adequately documented elsewhere, there is no need to have the developer repeat that work. However, if special steps are required, then these variances must be accurately documented and recorded in reference to the standard procedure.

7. Prefer extensibility to features. One common, but unpleasant, situation is to be in an otherwise good relationship with a supplier, but for changes to their application to be prohibitively expensive. This can occur with the best of will, and is sometimes described as 'technical debt'. This effectively leads to a lock-in situation: the customer's choice is to either keep paying over the odds for changes, or to spend out on a replacement solution. It is always recommended to discuss future changes and challenges with the development partner as early as possible - with the proviso that these are not requirements, but options.

8. Get a second opinion. The very reason that a company would hire a development partner is the same reason that they are susceptible to lock-in: the agency has a set of skills and experience that are lacking inside the company. One way to ensure that the best decisions are being made is to hire a third party to provide technical and strategic oversight and consultation. This agency should not be eligible for any development work, and ideally should be from a company with dedicated professional technical or strategic consultants.

After examining techniques for avoiding vendor lock-in, it should now be clear that vendor lock-in isn't just about file formats and incompatible applications - it's about being trapped on a system that is no longer meeting your needs. Avoiding lock-in is mostly a case of being aware of the risks, and making choices that balance the features of the application with flexibility in the future. Following the principles and advice laid out herein will help IT managers better select vendors and systems.

Ibuildings is the leading PHP authority in Europe, helping enterprise clients leverage the power of open source technologies with the rigour of professional software development. Read more at www.ibuildings.co.uk.