2.1 We all need something

Most IT departments have experienced the trauma of vendor or technology lock-in. They bought a system, and the vendor fell apart. They invested in technology to see its popularity decrease, causing costs to skyrocket. Their vendor lost interest in their business and moved the A-team to work with other clients. As a result, they are vocal about avoiding any lock-in. However, that is practically impossible.

Lock-in occurs when you become heavily dependent on a specific technology, vendor, or platform, making it difficult or costly to switch to alternatives. The root cause of the lock-in may be proprietary standards, high switching costs, integration complexity, skill dependency, or a vendor-specific ecosystem. All of these reduce the flexibility of your solutions. Lock-in is not bad if you don’t need to replace anything. Lock-ins are risks that you may or may not realize.

It’s important to remember that building software without lock-in is nearly impossible. Every technology choice comes with some degree of lock-in. However, your goal is to look at the issue of lock-ins strategically. You need to plan how to actively manage the lock-ins apparent to your chosen technology stack, putting you in control of your solutions.

Instead of allowing every vendor to bring their proprietary standards, you may mandate using open standards at critical APIs. Open standards are publicly available and can be implemented by anyone, while proprietary standards are owned and controlled by a single entity. By mandating open standards, you can reduce the risk of lock-in. You may need to switch vendors and products. You may decouple components with a high volatility risk, usually implementing APIs specific to your needs. You can also choose technologies that have an extensive vendor ecosystem providing services. Investing into portability via containerization is also a common requirement in modern IT environments.

Sometimes, when only a few potential vendors offer the only ready-made solutions in your field, you have a high risk of vendor lock-in instead of technology risk. In the case of critical applications, consider either building an in-house development and maintenance team, procuring services from several vendors simultaneously, or finding a joint company with a vendor to ensure the availability of professional services. These models are typical for mission-critical ERP systems.

Negotiating good contract terms for exit situations may mitigate some risks. In an exit situation, it is essential to get your data out of the system with the help of a vendor. Getting the documentation you need is also often helpful. However, contract terms rarely apply if your only technology vendor goes under. Always check your vendors’ financial status before doing business with them.

The correct approach to managing lock-in-related risks is to do a risk assessment. Risk assessment involves identifying which technologies have which risks, evaluating the potential impacts of these risks, and then designing the technologies with the most risk away (switch technologies if possible!). You then choose how to manage the remaining risks, include requirements in the tendering process, and actively monitor the implementation of your chosen strategy.

Single-trick pony IT departments will have weaker negotiating power compared to vendors. When the IT department can implement multiple technologies and pivot when necessary, the vendors notice. Customers who are more capable and have evident alternatives can negotiate better terms.

Paradoxically, when the IT department has good risk mitigation plans, monitors how their chosen technologies and vendors are doing, can make changes in their stack, and has good contract terms, it rarely has to resort to drastic measures. These drastic measures could include legal action against a vendor, a complete overhaul of the technology stack, or even the closure of the IT department. All of these measures have the side effect of improving the customer-vendor relationship! The more demanding customer gets better service, at least as far as the requirements are justifiable.

It’s also time to mention open source. Overall, open source is a perfect strategy for managing lock-in risks. Most of the commercial software on this planet has open-source components under the hood, even though it is not apparent from the surface. However, there are caveats you have to be aware of.

Software engineering nerds make most open-source software for software engineering nerds. They are usually super solid technologically but often not meant to serve (business) end users. Open-source solutions are frequently superior when looking at something that does technical heavy lifting in the background. When trying to solve a real-life issue, open source will likely not solve your problem but offers a few Lego pieces you could kick-start your development with.

Some open-source communities are alive and vibrant, meaning finding people who can configure and extend software for your needs is easy. Things seemed to go well, and then three years down the road, you see, there was a flame war in community forums. Most developers forked the software, and your version is now effectively frozen. Where corporations have mechanisms for smoothing ruffled egos, open-source communities do not.

Sometimes, you find a piece of open source that meets 90 % of your needs but won’t meet the remaining 10 %. If you want to succeed with that, you have to contribute to the open-source project. Usually, this means offering a bounty for someone who can implement what you need. Then, it becomes part of the software, and your company gets good PR in the open-source community. However, many, especially larger companies, have no decision framework that allows them to do this.

All the open-source caveats have the same mitigation that usually works the best. You contribute as a company to the open source, which generates positive feedback loops. More parties will actively use and support the software when it is better. After reaching the critical mass, you will see others building new valuable features for your company, inspiring and motivating you to continue contributing.

There is also a common misconception that you can not get support for open-source software. Larger enterprises especially have the cult of vendor support. When they have a vendor that says they support everything, they can outsource the downfall to the vendor if things go south. In reality, you can get support from open-source companies through several methods. You can get vendor support and hack all the open source you need. Some of the major open-source projects sell support packages.

Many companies fail to understand how to work with open source, which is why many up-and-coming open-source projects get fleeced, the maintainers lose interest, and the software effectively dies. This highlights the importance of caution and awareness when working with open source.

Well, the open-source software would not die right away. And the software you are using doesn’t spontaneously combust either. It will just start gradually causing more and more issues for your environment. At first, only a few specialists will know about it. If you let the process go too far, the boardroom will be talking about it, and they will be breathing down your neck because you are endangering their business.

You should actively monitor the technology trends concerning all your chosen technologies. For example, community forums, Gartner magic quadrants, and vendor and peer meetings are good tools for this. When you hear the popularity of a technology is decreasing, start analyzing the potential impact. If necessary, start planning for the transition to an alternative technology. Transitioning may be challenging, depending on your previous measures to decouple technologies. Take the transition up to the stakeholders and start the process.

As an architect, you are not alone responsible for managing lock-ins. You are, however, expected to steer the guidance of technologies and, when you do, advise on the related risks. You should be aware that many mitigation methods impact how you will purchase professional services to develop & maintain software. Some factors may be out of your hands, but your role is to guide your company through the required decisions. The overall goal is that all decisions made are informed, and you also look at the risks over a more extended period.