A man with healthy lifestyle has higher resistance against illness compared to unhealthy one.

So properly architected software is the basics for "healthy life" of the product, it leads to reduction in dependencies and cost.

 

According to my experience working in different roles in IT, I have very often touch points with the topic of "vendor lock-in". This topic is quiet often discussed and is part of various concepts and processes. Sometimes to avoid vendor lock-in is a goal within vendor management, strategy, and operations departments. Some architects used it as part of assessment processes and thus incorporate into architectural principles like: "Avoid Vendor lock-in…".

 

Avoid vendor lock-in at any price!?

Very often a vendor lock-in is treated like an evil which we must be avoided by any price. Sure, no one wants to have any kind of dependencies, no one wants to be in the situation when, for example, a vendor increases price of their product, and we cannot move away and must accept new conditions. We want to be independent of changes in vendor prices, we want to continue to have the same product quality even if the vendor changes the SLA or even stops supporting the product, we want to own full control on our product! But what is exactly the issue with the vendor lock-in? How is it related to software quality? 

 

Definitions 

Definition of Vendor Lock-in in Wikipedia:

“Vendor lock-in, also known as proprietary lock-in or customer lock-in, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs.”[1]

 

Important to add that not only the dependencies of a vendor can occur, but in IT other dependencies are also common:

• Product lock-in.
• Platform lock-in.
• Technology lock-in.
• Skills lock-in.
• Resources/team lock-in.
• Dev practice lock-in.

 

In software product development it is important to see the whole picture, not to shift the dependencies from one lock-in type to another. There is no "silver bullet" to solve the lock-in problem, but it is possible to find the most suitable solution.

 

We should not fall into trap of avoiding the use of products and solutions from the market and instead use, for example, open-source software. The issue with vendor lock-in is the dependency of some external impact, which is difficult or even sometimes impossible to predict. Using a PaaS of well-known cloud service provider does not mean by default that you have a vendor lock-in. It is not correct to think that the usage, for example, MS SQL or Oracle specific analytic function, leads your solution automatically to the vendor lock-in and you have an issue there. 

Different kinds of vendor lock-in can occur. There are well known situations which relate to changes in contractual conditions (price, SLA…), changes in a service strategy regarding to its further development etc….

Let us look at some examples.

You develop software product, and you choose to use PaaS “X" from the cloud provider “A”. Your business runs good until same day your customer wants to add new functionality or implement some changes. You understand now that the PaaS "X" does not satisfy your demand anymore. Cloud provider “B” has on its portfolio PaaS "Y" which would be suitable for the most. But your implementation depends so strongly on the product “X” that it is not feasible to migrate without massive investments.

Is this the vendor lock-in situation? Probably yes. Is now the moment to complain about the poor vendor capabilities? :)  I would say that this is an architecture issue. There could be many resolutions for such a case. Using open-source solution(s) with standard interfaces could be one of these. But even with an open-source solution we could have a lock-in situation too. Open-source solutions have also its drawbacks.  You would need to host it, maintain, support, think about updates, etc... For these activities you need resources, a team, someone who can take care about the solution, take care about the documentation, knowledge transfer, and many other activities which are in many cases underestimated from the beginning. At this moment I would like to mention that only using an open-source solutions instead of PaaS will not release anyone from the lock-in situation. What could help here? As always – “healthy way of life” ;). Transforming to IT this means proper architecture design and apply well known architecture technics.

 

Another example.

You develop a software product and decide to use propriate functionality provided by the database management system (DBMS) of the world biggest database vendor. As you are using specific functionality you are depending on that vendor. This functionality is included to your licence, so no extra costs for it. You do not need to bother with the implementation of this function neither maintaining, support, updates, etc. Someday a high-level manager (or vendor management department) from your organisation after comparing the license costs of DBMS vendors finds out that the costs for another DBMS vendor are less than that of your current one. After analysing the possibility for migration, you find out that there is no equal functionality in the compared product. Means you must find a substitution of that specific functionality. One can directly say here - you must use standard features which are available everywhere. This will help to migrate.  Was it a wrong decision to use that specific functionality form that well-known vendor? I would say no.  If you would use only standard features, you would need to implement that functionality by yourself (meaning it should be implemented in your organisation). In such a case you would reduce the impact of vendor lock-in of that provider.  But that means you should have resources to do this. You should think about development, testing, maintenance, support, documentation. Your software engineers could leave your company, programming language will have a new version, your department could have reduced budget. We should not underestimate big advantage of a well-known vendor: the high professionality level of software engineers and decades of experience of product development. This guarantees the quality, lifecycle support. Implementing the functionality internally only shifts the lock-in from DBMS Vendor to lock-in in an own development team. The dependencies are still there, just shifted.

 

Magic or proper work?

There is no solution which will give that one proper answer on how to avoid the lock-in.

International Standard ISO/IEC 25010[2] make the definition for product quality clear. Such characteristics like maintainability - modularity, compatibility - interoperability, and portability - adaptability and replaceability are part of a quality software product. The quality software is a healthy software, the standards and the desired level of each characteristic should be set in early stage of software solution design.

The proper architecture of the software will help you not only to avoid/mitigate negative impact of vendor lock-in but also create quality software. The struggle for the quality may seem very costly.  But as Martin Fowler wrote: "The cost of high internal quality software is negative."[3]

 

It is not possible to describe all necessary guidelines/principles to achieve the quality, but I will list out of some of them: 

• Use standards that are open or provider-neutral, such as RESTful APIs, JavaScript Object Notation (JSON) or Apache Parquet, HTML.
• Separate application domain from the platform.
• Do not reinvent tools, concentrate on development of specifics for your solution.
• Establish a thorough and accurate understanding of your technology and business requirements.
• Understand the legal limitations applicable to your use cases. Are there unique regulations applicable to the vertical of your business domain?
• Start the DevOps process since the beginning. This decouples people from infrastructure and in case of changes, you must adapt just the DevOps part.
• Establish an abstraction layer, both for the stream processing code from the underlying streaming platform and for the stream processing layer from other components in the data pipeline.
• Design architecture for application portability, not infrastructure portability. Consider realistically new hypes, do not expect containers to significantly improve portability. If the portability is not defined as explicitly (but only as imagination wish), embrace the full range of your provider’s offerings to maximize the value of your investment.
• Architect for contextual independence.
• Well-defined interfaces: The means of interfacing with those systems are very well-defined and easily understood.

 

The list is not complete, but it is well-known architecture practices!

 

Lock-In Is the Result of Architectural Choices

Architects should keep in mind that their primary role is to determine the architectural trade-offs involved, which primarily involves making architectural choices about where and why lock-in occurs. Architects should not expect to eliminate lock-in.

There is always a lock-in somewhere in the value chain of your IT suppliers. Thus, you cannot avoid lock-in; you can only choose where your point of lock-in is, and therefore determine which set of risks you prefer and how you will mitigate those risks. Even if you think you are avoiding lock-in by doing something yourself, you are actually still locked in — you are simply locked in to your own IT team, rather than being locked in to a vendor. Internal lock-in can pose greater risks than being locked-in to a vendor, especially if you are dependent upon a single brilliant engineer rather than a team of engineers.

Your goal should be to identify points of lock-in, so that related risks can be appropriately addressed, and maximal value is obtained in return for the lock-in that you choose to accept. Attempting to avoid lock-in can limit the variety and quality of the technology available, increase risk, and add financial and technical overhead to projects.

The proper way of the combination the best architecture practices and agile methods will give you a lot of benefits but underestimating or misunderstanding can lead to expensive consequences. "Agile and architectural practices … enable each other and there are significant benefits of having them integrated.”[4]

 

 

Summary

Vendor lock-in should not be treated separately, the dependency of a vendor should not be evaluated as an isolated topic. It is one of the quality attributes/characteristics of the whole software product. Just avoiding vendor lock-in could create even more dependencies with not pleasured consequences (technology lock-in, skills lock-in, resources lock-in, etc…). The solution is the proper architecture work that should be done for the software product. Properly designed software will reduce cost in a long run. Knowledge of modern technologies and architecture practices help you to achieve a healthy software!

 

 

[1] https://en.wikipedia.org/wiki/Vendor_lock-in

[2] https://en.wikipedia.org/wiki/ISO/IEC_9126#Developments

[3] “Is High Quality Software Worth the Cost?”, by Martin Fowler  https://martinfowler.com/articles/is-quality-worth-cost.html>  

[4] “On Agility and Architectural Engineering”, By Dr. Stefan Malich (https://stefanmalich.com/2019/12/30/on-agility-and-architectural-engineering/