Navigate lock-in complexities with Gribeauval's innovation mindset

Lieutenant General Jean-Baptiste Vaquette de Gribeauval, born on September 15, 1715, was a pioneering French artillery officer and engineer who significantly transformed French military artillery. His development, known as the Gribeauval system, replaced the older de Vallière system, introducing lighter, more uniform cannons that improved effective range and power. This innovation not only streamlined production but also made field operations more efficient. Crucially, Gribeauval was among the first to advocate for the interchangeability of gun parts, a approach that allowed for quicker repairs and standardization across the French artillery units. His reforms equipped the French army with superior artillery capabilities that proved decisive in numerous military engagements during the Napoleonic Wars, establishing France as the leader in European artillery technology during that era.

The concept of interchangeability that Gribeauval introduced is appealing to those in today's technology and architectural domains who are looking to establish similar technology dominance. Its ideas of componentisation and flexibility are inspiring and it is easy to think that adopting interchangeability across our architectures is best practice. However as we will explore the situation is more nuanced.

Adapting Gribeauval's Principles to Modern Technology

We live in a different era to Gribeauva and our rate of innovation and the number of market place offerings are significantly higher. Our era is landmarked by task-specific tools with high interoperability and rapid deploy ability. With this in mind we need to adapt Gribeauvals ideas and not blanketly apply interchangeability. For this we need to think of interchangeability on a per component basis where we evaluate not only the level of interchangeability but also the likelihood of needing to switch. For this we are essentially minimising vendor lock-in in areas where we will likely want to rapidly select and move to new innovative technologies.

We can define vendor lock-in as a customers dependence on a product or service for which they are unable to use another without incurring substantial switching costs. Vendor lock is not new, but it does largely shape commercial technologies. The classic modern example is the QWERTY key board whose layout is common place in the West despite more efficient layouts existing. The configuration stems from original type writers whose typebars had to be positioned in such a way that they did not collide with each other when typing.  A combination of early adoption, network effects, path dependence and compatibility issues has resulted in its continued use.

We can broadly define several types of lock-in:

1. Technology Lock-In: This occurs when a technology is inherently incompatible with other platforms, necessitating additional layers of abstraction for integration.
2. Skills Lock-In: This refers to situations where personnel have invested significant time and energy into developing expertise that does not transfer easily to other contexts.
3. Legal Lock-In: This happens when an organization is bound by a contract that incurs substantial expenses to exit.
4. Mental Lock-In: This occurs when individuals or groups become rigidly attached to specific solutions or tools, often influenced by established habits, cultural norms, or previous successes.
5. Architecture Lock-In: This takes place when organizations are significantly constrained by decisions made early in the development or implementation process, leading to increased costs and complexities when adapting to new technologies.
6. Vendor-lock In: This occurs when a organisation has become dependant on a third-party who often leverage the above types to constrain the organisations ability to transition away.

There are many more types of lock in but these cover most common scenarios.

Stance of the Major Cloud Providers

When examining the major cloud providers, we observe a complex blend of these different types vendor lock-in. Although these platforms offer largely the same foundational services, their specialized products and services contribute more significantly to vendor lock-in. As a general rule we can observe that, moving from bare metal solutions to Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS) increases both the difficulty of migration or replacement but also the richness of the features provided by these services.

‍

Analysing the stance of the top three cloud providers on vendor lock-in, we find that their well-architected frameworks lack specific provisions for portability. Despite this, these frameworks exhibit a high level of maturity in facilitating transitions in from on-premises infrastructure to cloud-based services. Yet, when organisations decide to migrate away from these cloud services, the costs related to data transfer mount and can be prohibitively high, with prices generally starting at $0.09 per gigabyte. The technical labour costs are also high as business have to rebuild parts of there architectures to change provider. It essentially at a regulatory level that portability is enforced, through standards, such as the General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), and the International Organization for Standardization (ISO) as well as others. These regulations are designed to ensure data portability, thereby directly influencing cloud providers' operations. Although compliance with these regulations increases customers capability to migrate, it also serves as a value proposition that attracts more clients than the lack of portability deters.

Strategic Decision-Making: Balancing Utility and Switching Costs

So how can we navigate this dynamic and move past the lockin = bad approach? Firstly, it's important to acknowledge that some degree of lock-in is inevitable. Secondly, we might willingly accept certain lock-ins if they offer substantial benefits, such as unique features or utilities that competitors don't provide. This concept can be illustrated using a straightforward two-by-two matrix:

The matrix evaluates our choices along two axes:

1. Switching cost (lock-in): How difficult would it be to switch to another solution?
2. Unique utility: How much does the solution offer compared to alternatives?

Each of the four quadrants represents different scenarios:

1. Disposable: These are components with low unique utility and low switching costs. They are easy to replace if issues arise. Examples include most developer IDEs (except perhaps EMACS) and cloud storage for personal data on smartphones. These are low-risk components that can be mixed and matched without much concern.

2. Accepted Lock-in: These components offer high unique utility but come with high switching costs. Although we generally prefer less lock-in, the trade-off is acceptable due to the significant benefits. Examples include Google Cloud BigQuery or AWS Bare Metal Instances, where the payoff justifies the lock-in. For small applications, using native AWS services can reduce development and operations effort.

3. Caution: The least favorable quadrant includes components with high switching costs but low unique utility. Proprietary relational databases often fall into this category. They do not significantly increase revenue, and migrating off them can be challenging. This quadrant requires careful consideration, ensuring a low likelihood of needing to switch.

4. Ideal: The most desirable scenario involves components with high unique utility and low switching costs. While this is the ideal, it is rare because unique utility often implies difficulty in migration. An example could be S3-compatible APIs across cloud vendors, making switching relatively easy while still offering distinct advantages. Protecting such portability requires preventing APIs from being copyrighted or patented.

Though simple, this matrix is a valuable tool for evaluating and visualizing your software components and helps in understanding your exposure to lock-in. But it isnt the only framework we should use. Understanding the true cost of lock-in requires a us to evaluate future needs. And so we can create another matrix. This matrix differentiates between the cost of making the switch and the likelihood that a switch will be necessary. Items with low switching costs and low likelihood of switching are not concerning, while those with high costs and high likelihoods are problematic and should be addressed. The quadrants represent different strategies:

1. Low Cost, Low Likelihood: Minimal concern. These items are easy to replace if needed.
2. High Cost, Low Likelihood: Accept the risk but prepare. Limit scope changes or increase maintenance budgets to mitigate risk.
3. Low Cost, High Likelihood: Embrace agility. Design systems for low-cost changes, even if they accumulate quickly.
4. High Cost, High Likelihood: Problematic and should be minimized. Examples include proprietary systems with low utility.

Common biases would be that we tend to over estimate the likelihood of switching platforms and under estimate the cost to switch.

Bringing these models together we can formulate a strike price (or option price) where the cost to switch is the strike price and where we can invest some energy upfront to lower our liability. Achieving lower switching costs increases the value of the option but requires significant upfront investment. For example we can add a layer of abstraction to our application so that its works with multiple vendors but we have to pay upfront to build this. Often, minimising switching costs is not the most economical choice.

To decide how much to invest in reducing switching costs, consider the total cost, which includes both the upfront investment and potential liability (calculated as the product of switching cost and likelihood). Over-investing can lead to higher overall costs due to diminishing returns, particularly in low-probability scenarios. It's crucial to strike a balance between upfront investments and potential future savings. Investing too heavily in minimizing switching costs for scenarios that are unlikely to occur can result in wasted resources. Conversely, under-investing can leave an organisation vulnerable to high costs if a switch becomes necessary.

‍

In conclusion, while the concept of interchangeability inspired by Gribeauval's innovations offers compelling advantages in today's landscape, it must be approached with careful consideration of the nuances of modern lock-in. Acknowledging that some degree of lock-in is inevitable, organisations can navigate this terrain effectively by evaluating each component's unique utility and switching costs. By employing frameworks like the two-by-two matrix and comprehensive cost models, stakeholders can make informed decisions that balance innovation, flexibility, and strategic alignment, ensuring they harness the benefits of technology while mitigating potential drawbacks.

‍