In the last article, I laid out how technological sediment accumulates over time and becomes the fundamental source of technology lock in. This article takes the argument one step further: where exactly does lock-in come from, what can organizations do to reduce it, and what does avoiding it typically cost?

Lock-in is a 7 component glue

To understand the lock-in effects, it helps to look how the relevant component is integrated into the technological sediment of the organization it operates in. This is best explained using a concrete use case of a, lets say, an Oracle-based fraud application developed in the 2000s in a financial institute. This component is glued to the organization in 7 different ways:   

1. Within the technology component itself: The purchased Oracle Database (Version 11g) stored procedure calculates transaction velocity, such as the number and total value of a customer's payments in the last hour, and flags transactions that exceed defined thresholds.
2. On top of the technology component: A self-developed Java fraud detection application connects to the Oracle Database through a specific JDBC driver and queries its tables and stored procedures to display flagged transactions.
3. Under the technology component: The Oracle Database runs on Red Hat Enterprise Linux 6 and depends on specific kernel settings, system libraries, file systems, and storage drivers.
4. To another use case: The fraud detection system sends flagged transactions through a Kafka topic to the customer analytics platform, where they are combined with customer value data.
5. To related technical processes: The operations team monitors the Oracle database through custom scripts and backs it up with Veritas NetBackup using its Oracle integration.
6. To related business processes: A flagged transaction triggers an email to the fraud team. An employee enters it into an Excel file, which triggers a Power Automate workflow for review and approval.
7. To related humans: The details of the logic in the stored procedures are only understood by one developer who will be retired next year. The Linux configuration is poorly documented, and only one operations employee knows how the approval flow is implemented.

You Feel the Glue When You Want To Leave

Now imagine Oracle announces that it will double its prices. The company considers to replace Oracle Database 11g with an open source alternative such as PostgreSQL. This means touching the following components:

• The stored procedure containing part of the fraud detection logic needs to be rewritten.
• The Java application and its database connection need to be adapted and tested.
• The underlying Linux configuration, libraries, file systems, and storage setup need to be reviewed.The Kafka integration and downstream customer analytics need to be tested against the new setup.Monitoring scripts and the Veritas NetBackup integration need to be replaced or adapted.
• The email, Excel, and Power Automate based approval process needs to be tested to ensure it still works as expected.
• Finally, the company needs the people who understand all these connections, including those that are poorly documented or no longer documented at all.

What looks like replacing one technology component has become a full transformation project requiring business analysis, cost benefit estimates, project management, engineers from different disciplines, coordination across several business functions, testing, migration planning, and sufficient people and budget to carry it out.

Abstraction Layers are the Anti-Glue

An abstraction layer sits between a technology component and the systems that use it. Instead of every application connecting directly to Oracle and using its specific interfaces and features, they connect to an interface controlled by the organization. Oracle sits behind that interface and can, at least in theory, be replaced without requiring everything on top to change.

If the company wanted to keep Oracle exchangeable, it needed to prevent the rest of the landscape from becoming too directly dependent on Oracle. The usual way to do this is through abstraction and standardization.

Think of it like Esperanto. Oracle speaks its own language, while the abstraction layer translates it into a common language understood by the rest of the organization. If Oracle is later replaced by PostgreSQL, PostgreSQL only needs to be connected to that common language. The applications on the other side can continue speaking Esperanto.

A common real world example is an Object Relational Mapping layer such as Hibernate in a Java application. Instead of writing Oracle specific SQL throughout the application, developers interact with the database through Hibernate. Hibernate then translates these operations into the SQL required by Oracle. If the company later moves to PostgreSQL, much of the application can remain unchanged because Hibernate also knows how to communicate with PostgreSQL.

But what is the cost of abstraction?

But now come the managers. If a smart engineer had approached his boss in the 2000s proposing an abstraction layer, he would not only have needed to spend some time explaining the concept of abstraction, but eventually would have had to make a business case: What does it cost, and what does it bring?

The costs are relatively clear and immediate. The abstraction layer has to be designed, built, tested, documented, and maintained. Developers have to learn and consistently use it. Every new Oracle feature has to be evaluated against the abstraction, and some features may not be usable at all because they cannot be represented in a database independent way. All of this requires engineering time and budget from day one while potentially restricting access to unique features of the venture.

What this kind of precaution brings, on the other hand, is uncertain and often far away. It creates the option to replace Oracle more easily at some point in the future. But nobody knows whether that switch will ever happen, when it will happen, what Oracle will cost by then, what alternatives will exist, or whether the fraud application itself will still be around.

What do managers usually do with such a problem? They apply what they learned in business school: discounting. Certain costs today and over the coming years are compared with an uncertain potential benefit somewhere in the future. The further away that benefit is, the less it is worth in today's calculation. And during the early introduction of a new technology, when even the next twelve months can be difficult to predict, a hypothetical database migration ten or twenty years into the future carries very little weight.

This creates the fundamental economic problem of avoiding lock in: you pay for flexibility today, while its value may only become visible many years later, if ever.

But Open Standards

The usual argument here is: Oracle should just offer open standards. The examples are quite convincing: If we enforce the use of a USB-C plug for every device, we only need one charging cable and switching becomes easier through regulation.

And to a large extent, this worked. USB-C standardized the physical connector remarkably well. The same small, reversible plug now fits anything from headphones to laptops. But the moment we move beyond the physical connector, things become much more complicated. Two identical looking USB-C ports or cables can support different charging power, data speeds, display capabilities, USB4, or Thunderbolt. Devices have to negotiate some of these capabilities through protocols and firmware after they are connected.

This illustrates a fundamental problem with standardization. Standardizing a physical interface is relatively easy because the target moves slowly. Software is different. Features are continuously added, APIs evolve, security requirements change, and vendors compete by introducing capabilities that do not yet exist in the standard. A standard can follow those developments, but then it needs new versions, extensions, profiles, and optional capabilities, eventually reintroducing the heterogeneity the standard was meant to eliminate.

And even reaching that point takes time. The EU's common charger initiative started in 2009, while the USB-C legislation was adopted in 2022. Software, by contrast, may be updated several times a day. More importantly, the underlying technological paradigm itself keeps changing. Technology analyst Benedict Evans observes that the center of the technology industry has shifted roughly every 10-15 years: from mainframes to PCs, from PCs to the web, from the web to smartphones, and now potentially to generative AI. Each shift changes not just individual products, but the basic assumptions about how our digital world is contructed, distributed, and used.

Open standards can therefore reduce lock-in of software in organizational tech sediment theoretically. But in practice, it seems unlikely that the digital world will slow down its pace and variety to match the timelines of standardization bodies. By the time every relevant party has agreed on how yesterday's technology should work, the industry is already adding new features to today's paradigm while preparing the next technological paradigm altogether.

But Open Source?

But there is one more intuition: The financial institute should simply have chosen PostgreSQL, the open source alternative of Oracle DB. That would not have reduced the technological lock-in as the tech sediment lays itself on any technological component no matter which licensing model. At least the commercial lock-in would have changed: Truly free and open source software does not raise prices at all, and thus, eliminates the trigger that lets you feel the glue in the first place.

This intuition seems to be something that managers are increasingly following. For organizations with expertise-rich IT departments and the budgets to operate middleware themselves on infrastructures they own or rent, there is a huge choice of open source software that solves the commercial lock-in of the tech sediment.

But this freedom is not free either. Someone still has to operate, patch, monitor, secure, update, and support the software. Organizations either hire engineers internally or buy expertise from external service providers. They also take on more responsibility for integrating the different components and deciding when and how to upgrade them. Open source therefore shifts part of the cost and responsibility from purchasing a product to operating and maintaining it. Whether that is cheaper depends heavily on the organization's existing skills, scale, and operating model.

Therefore choose your lock in deliberately

There is no lock-in-free technology landscape. Oracle creates dependencies, PostgreSQL creates dependencies, and even the abstraction layer introduced to reduce those dependencies becomes a dependency itself.

Every attempt to reduce lock-in therefore comes at a cost. Abstraction requires engineering and maintenance, open standards can restrict access to unique features, and open source shifts more responsibility toward operating and securing the technology yourself.

In the end, this makes lock-in a Total Cost of Ownership question. Organizations need to compare the certain and continuous cost of keeping a technology exchangeable with the uncertain future cost of actually having to replace it. And as discussed above, that future cost may be many years away or never occur at all.

The goal should therefore not be to eliminate lock-in. It should be to choose deliberately where the option to switch is valuable enough to justify paying for it. And maybe, just maybe, there will be a mythical new thing in the next platform shift, that lets you see the whole thing under a new light.