Lessons from banking’s COBOL crisis: Building flexibility into technology choices

Businesses constantly seek the next efficiency boost, the next competitive edge. Today, that means adopting powerful Software as a Service (SaaS) platforms that promise rapid productivity gains. But rushing towards efficiency without considering long-term flexibility can inadvertently tie your hands for the future. It’s a lesson the banking industry learned the hard way, one which can act as a cautionary tale.

In an era of high business uncertainty - both technical and macroeconomic - preserving flexibility is more valuable than before.

The Ghost of COBOL: A Lesson in Lingering Constraints

The banking industry saw a powerful tool in COBOL. Developed in 1959, the language became deeply embedded in banking systems over the following decades. Modernising those systems can require lengthy, complex projects. Why? Because the business rules, integrations and institutional knowledge around the technology become difficult to disentangle.

The scale of the dependency is striking. A Reuters graphic published in 2017 reported that 95% of US ATM transactions used COBOL. That is a historical estimate, not a current measurement. Maintaining legacy systems can also become harder as experienced specialists retire. The convenience offered by today’s SaaS solutions risks creating similar dependencies for businesses down the line.

Understanding the Lock-In Cycle: From Convenience to Constraint

How does this happen? The path to infrastructure lock-in isn't purely technical; it's deeply rooted in common business practices and incentives:

• The Incentive Problem: Companies naturally reward short-term efficiency. Quarterly metrics often celebrate the immediate savings from adopting a new SaaS tool but rarely factor in the potential future costs of migrating away from it. Individual departments choose tools that solve their problems best, sometimes without prioritizing overall company flexibility. IT teams are praised for smooth rollouts, not necessarily for building easy exit ramps. This focus on the "now" means future-proofing often takes a backseat.
  
  • Strategic Shift: Reward managers for maintaining business capability flexibility, not just successful tool implementations. Include "system independence" metrics in performance reviews for digital transformation leaders.

• The Procurement Blind Spot: Standard procurement excels at comparing features and upfront costs but often overlooks the strategic risks of lock-in. Why would you consider ditching what seems like the best solution, just as you are procuring it? Key factors like data export formats, the completeness of APIs (how well the system talks to other systems), contract terms for exit support, and the potential cost of a future migration receive far less scrutiny. When evaluating SaaS platforms, this oversight mirrors the decisions made decades ago regarding COBOL.
  
  • Procurement Reform: Develop a lock-in risk assessment for significant technology purchases. This should explicitly evaluate data portability, API robustness, exit clauses, potential migration costs, and what it would take to maintain core business logic independently.

• The Integration Dilemma: Connecting different SaaS tools is often where the real value lies – streamlining workflows and data sharing. However, every integration point can reduce your flexibility to swap out a component later. It creates a tension: more integration can mean more value now, but less adaptability later. Unlike the banks decades ago, businesses today can manage this tension proactively, though it requires investment.
  
  • Governance Solution: Consider an enterprise architecture review board mandated to assess integrations for reversibility and potential lock-in, balancing immediate value against long-term freedom. They should be incentivised to get things done, not simply point out the risks - but they must also ensure the decreased flexibility is adequately priced in.

• The Ownership Question: The banks using COBOL discovered that their core business processes were inseparable from the technology. They technically own their data, but struggle to use it effectively without highly specialized (and scarce) talent. With SaaS, the challenge is slightly different: while your data might be technically portable, the business logic, custom workflows, integrations, and team knowledge built around the specific SaaS tool often aren't easily transferred. You own the data, but the operational capability becomes tied to the vendor.
  
  • Operational Defense: Maintain "shadow" process maps – documentation showing how your business functions independent of specific tools. This blueprint preserves crucial knowledge and aids rebuilding capability if a system change is needed.

Strategies for Sustainable SaaS Adoption: Building In Flexibility

Avoiding lock-in doesn't mean avoiding SaaS. It means adopting it strategically, with an eye on future adaptability. Here’s how non-technical leaders can guide their organisations:

1. Align Incentives With Independence: Ensure performance metrics and budgets explicitly value and reward maintaining business flexibility alongside technology adoption. Treat adaptability as a feature worth investing in.
2. Plan Your Exit Before You Enter: Include clear transition assistance requirements in SaaS contracts (data migration support, knowledge transfer, extended API access). Periodically run "exit drills" for critical systems – test your ability to extract data and imagine operating without that specific tool.
3. Develop Data Governance Beyond Compliance: Expand data governance policies beyond just security and privacy. Focus on ensuring data remains usable and independent from any single platform.
4. Build Deliberate Integration Architecture: Encourage IT teams to design connections between systems (e.g., via a central exchange layer) that minimize direct, hardwired dependencies between different SaaS vendors.
5. Document Business Capabilities, Not Just Tools: Insist on maintaining up-to-date maps of what your business does and how it achieves its goals, separate from the specifics of which tool is used currently. This preserves vital institutional knowledge.
6. Make Conscious Tradeoffs: Not all lock-in is equally risky. Use a framework to decide where deeper integration is acceptable and where flexibility is paramount:
   
   • Core vs. Peripheral: Demand maximum flexibility for core, differentiating functions; accept more lock-in for generic, peripheral ones.
   • Competitive Advantage: Invest in flexibility where processes give you an edge; accept less for commodity functions.
   • Ecosystem Maturity: Deeper integration is less risky in stable, mature technology areas; prioritise flexibility in new, rapidly evolving ones.

The Real Cost of Digital Transformation

Flexibility isn't free. Maintaining the ability to easily change platforms adds costs - in implementation time, in governance overhead, and sometimes in feature limitations.

Banks facing difficult legacy migrations illustrate the long-term consequences of trading flexibility for immediate gains. That does not mean the original technology choice was necessarily a mistake. In the relatively stable world of the late 20th century, this was a shrewd trade. In the increasingly volatile world of the 2020s, the balance is tipped.

The calculation is simple: The cost of maintaining flexibility must be weighed against the probability-adjusted cost of a forced transition. Large banking-system migrations illustrate how expensive a forced transition can become; whether earlier investment in flexibility would have cost less depends on the case.

For your business, the right balance depends on how central each system is to your operations, how quickly your market changes, and your risk tolerance. But the lesson from banking's ongoing struggle is clear: What seems expensive insurance today can seem like a bargain when change becomes inevitable. As you look forward to the next few years, ask yourself how likely such a change becomes.