My post content

Vendor Lock-In Has a 60-Year History.

Here's What It Teaches Banking Leaders About AI.

Why portability is not a technical luxury, but a strategic reserve of bargaining power.

In nearly three decades of enterprise architecture, I have watched the industry repeat the same pattern under different names.

Mainframes. UNIX. Windows. Java application servers. Cloud platforms. Kubernetes. Generative AI.

The technology changes. The economics do not.

A dominant platform emerges. Enterprises standardize on it. Operational dependence grows. Procurement leverage shrinks. And eventually, the industry creates standards, abstractions, and portability mechanisms to restore balance.

This is why I no longer think of vendor-agnostic architecture as a feature or an ideological preference. I think of it as a risk management and negotiating strategy.

The winners are rarely the organizations that avoid vendors altogether. They are the organizations that can change vendors without rewriting the business.

As Founder and Chief Architect at Stratonavis, advising enterprises in regulated industries, I believe this historical perspective is becoming especially important as banks and financial institutions make long-term decisions about cloud and AI platforms.

The pattern that keeps repeating

Every major computing era has followed a recognizable cycle:

• Innovation concentration — a small number of vendors move faster than the market.

• Enterprise consolidation — organizations standardize to reduce complexity.

• Dependency accumulation — skills, tooling, data, and operations become tightly coupled to the platform.

• Standards correction — interoperability, portability, and open ecosystems emerge.

The important question is not whether lock-in exists. Some degree of lock-in is often the price of acceleration.

The more important question is:

Which dependencies are acceptable, and which become strategically dangerous?

The three layers of lock-in

I find it useful to separate lock-in into three layers.

• Technical lock-in: APIs, runtimes, infrastructure, and deployment tooling.

• Operational lock-in: skills, processes, monitoring, support, and automation.

• Institutional lock-in: auditability, regulatory evidence, model governance, data lineage, and business workflows.

Most architecture reviews focus heavily on the first layer.

Most failed exits are caused by the third.

Mainframes: when proprietary was rational

The IBM System/360 era is often presented as the origin story of vendor lock-in. That is true, but it misses an important nuance.

In the 1960s and 1970s, proprietary platforms were not simply a commercial tactic; they were also a response to the technological realities of the time. Enterprises wanted integrated hardware, operating systems, support, and accountability from a single supplier.

For banks, reliability mattered more than portability.

What emerged from that era was not an anti-vendor movement. It was the first generation of dependency mitigation mechanisms:

• source code escrow,

• documentation escrow,

• exit clauses,

• and long-term support guarantees.

Enterprises were not trying to eliminate dependence. They were trying to survive supplier change.

That distinction still matters today.

The 1990s: standards become a competitive weapon

The operating system and browser wars introduced a different lesson.

POSIX, TCP/IP, HTTP, and later W3C standards were not academic exercises. They were mechanisms that prevented any single vendor from fully controlling the emerging digital ecosystem.

For the first time, interoperability became a competitive requirement rather than a technical convenience.

The market learned that open standards do not remove competition; they move competition to a higher layer.

Open source changed the leadership calculus

The most important impact of Linux, Apache, and the JVM ecosystem was not that software became free.

The strategic shift was that skills became transferable.

An engineer trained on Linux could work across hardware vendors. A Java application could run on multiple operating systems. Talent pools began forming around open ecosystems rather than proprietary stacks.

For technology leaders, this changed procurement economics:

• larger hiring markets,

• lower retraining costs,

• reduced supplier leverage,

• and longer architectural life.

Open source succeeded in the enterprise not because it was ideological, but because it reduced concentration risk.

Cloud: a new form of lock-in

Public cloud created extraordinary acceleration. I have personally seen modernization programs succeed because cloud platforms removed years of infrastructure friction.

But cloud also introduced a new category of dependency:

• proprietary databases,

• serverless runtimes,

• IAM models,

• observability stacks,

• and AI services.

Then came the industry response.

Containers addressed packaging portability. Kubernetes addressed operational portability. The CNCF emerged as a deliberate attempt to prevent the infrastructure layer from becoming permanently controlled by a single provider.

What is often overlooked is that Kubernetes did not solve every portability problem.

Data gravity remained.

And in banking, data gravity is frequently stronger than compute gravity.

The IBM WebSphere lesson is more interesting than abandonment

A common narrative says that IBM abandoned WebSphere in favor of open source. That is not what happened.

IBM introduced Open Liberty as an open-source runtime foundation while continuing to offer WebSphere as the commercial enterprise layer.

This is a far more significant architectural pattern than a simple migration story.

The portable core became open; the enterprise value moved to:

• support,

• management,

• security,

• governance,

• and operational assurance.

In other words, the industry began separating workload portability from enterprise accountability.

For modern procurement, this is a powerful lesson:

Choose vendors that build on portable foundations, not vendors that require proprietary foundations for basic portability.

Escrow has evolved

The most useful historical analogy for BFSI leaders is this:

• Source code escrow → Open-source runtime

• Interface documentation → OpenAPI / AsyncAPI

• Database exit clauses → Data portability & event streams

• Single-vendor DR → Multi-cloud resilience

• Application portability → Containers + Kubernetes

• Supplier replacement planning → Model and agent portability

The mechanism has changed. The risk has not.

A simple test for dangerous lock-in

Earlier I asked which dependencies are acceptable and which are dangerous. Here is the practical heuristic I use in architecture reviews.

Acceptable lock-in: replacing the vendor primarily requires retraining engineers, migrating infrastructure, or rewriting adapters.

Strategically dangerous lock-in: replacing the vendor requires re-establishing regulator trust, rebuilding data lineage, recreating operational evidence, or changing business workflows across multiple systems.

In banking, infrastructure lock-in is often manageable.

Governance lock-in is usually not.

If a platform owns your audit evidence, decision history, model governance, customer-operating workflows, or regulatory reporting logic, it has moved from a technology dependency to an institutional dependency.

That is the category that deserves board-level attention.

AI is compressing the standardization cycle

What took nearly a decade in the cloud era is happening within a few years in the AI era.

MCP (the emerging standard for connecting AI systems to tools and data) crossed 100 million monthly downloads within about sixteen months of release — Kubernetes took several years to reach comparable ecosystem momentum — and it was donated to a vendor-neutral Linux Foundation body within its first year. A2A, a companion standard for agent-to-agent communication, has followed a similar path, with support from more than 150 organizations.

Whether these become the final dominant standards is less important than the signal they represent:

Enterprises are demanding interoperability while the AI platform market is still forming.

Historically, standardization followed widespread lock-in. In AI, standardization is arriving during the lock-in phase.

That is unusual.

A pattern I see repeatedly in modernization programs

In one lending-platform modernization program I've advised on, the organization successfully moved applications to containers and Kubernetes. From an infrastructure perspective, the program was considered cloud-native.

However, the critical orchestration logic — customer onboarding, exception handling, credit-decision routing, and operational approvals — had been embedded inside a proprietary workflow platform.

The containers were portable.

The business process was not.

When the institution later evaluated an AI-assisted operations model, it discovered that every meaningful workflow change required modifications inside the proprietary orchestration layer.

The estimated effort was not a cluster migration.

It was a multi-quarter re-validation exercise involving technology, operations, risk, and audit teams.

That is the difference between infrastructure portability and institutional portability.

And it is why some organizations become technically containerized but strategically immobile.

What banking leaders should do now

In regulated industries, the highest switching cost is rarely the application runtime.

It is the combination of:

• data lineage,

• regulatory evidence,

• security controls,

• operational runbooks,

• auditability,

• and model governance.

A vendor can often be replaced faster than the institution can re-establish regulator confidence.

That is why I recommend six architectural principles for long-lived platforms, designed for regulated enterprises, cloud modernization, and AI portability.

1. Contract for standards, not products. Prefer OpenAPI, AsyncAPI, OAuth2/OIDC, OpenTelemetry, and standards-aligned AI interfaces where practical.

2. Keep data on your side of the boundary. Compute is usually easier to move than data. Design exits around data ownership first.

3. Introduce an AI gateway layer. Avoid coupling applications directly to a provider SDK. Route models through an internal abstraction.

4. Build evaluation harnesses once. Prompts, benchmarks, safety tests, latency, and cost comparisons should survive model changes.

5. Separate business logic from orchestration. Treat workflows as replaceable; keep domain rules independent of agent frameworks.

6. Measure switching cost explicitly. Track the estimated effort to replace a cloud service, model provider, or workflow engine.

This is not theoretical governance.

It is operational resilience.

The leadership lesson

Technology leadership is not about predicting the next dominant vendor with perfect accuracy.

It is about recognizing recurring patterns, using past transitions as guidance, and making today's decisions in a way that keeps tomorrow's options open.

If you are leading a cloud or AI modernization program, a useful first exercise is not to ask:

"Which vendor should we choose?"

Ask:

"Which dependency would be hardest to unwind under regulatory scrutiny?"

That single question often reveals more about architectural risk than any feature comparison.

At Stratonavis, we use this lens to assess whether an architecture is merely cloud-native or genuinely resilient to future platform shifts.

The real lesson of 60 years

From IBM mainframes to cloud platforms to generative AI, the industry keeps rediscovering the same governance principle:

Portability is not a technical luxury. It is a strategic reserve of bargaining power, resilience, and future choice.

Organizations that preserve that reserve can adopt innovation aggressively without surrendering long-term control.

The technology stack will change again.

It always does.

The need to preserve strategic choice is the one constant that has survived every platform transition so far.

Part 1 of a Stratonavis series on architectural resilience in regulated AI adoption.

Next: what an AI gateway layer actually looks like in a BFSI architecture — and how to avoid creating a new generation of model lock-in.