Phoenix Platforms and the Elixir of Life
How to build a technology platform for the ages
At over sixty years old, IBM Z traces its lineage back to System/360, predating most of the people working on it. Most technology platforms disappear long before such vintage; vendors announce fresh starts, analysts declare paradigm shifts, and terms such as next-generation, cloud-native, AI-powered, and reimagined sprout like weeds over roadmaps. Customers attempt to divine whether the systems they spent the last decade building still have a future, as compatibility becomes increasingly fraught, maintenance is deferred, and dependencies develop perverse ecosystems of mutual hostage-taking until the compost of accumulated workarounds finally makes replacement easier than conservation.
Yet IBM Z remains an active platform. Banks, insurers, governments, airlines, and retailers continue adding workloads to a platform whose roots predate the microprocessor. Successive generations of hardware, operating systems, storage, networking, and development tooling arrived, decade after decade, without invalidating the investments that came before them.
Most historical technologies survive like an artefact from the past: admired, protected, occasionally restored, but mostly disconnected from the daily concerns of modern life. Mainframes tell the story of how to build a phoenix.
Platforms that Outlive their Obituaries
Backward compatibility is typically managed as technical debt, becoming a self-fulling prophecy: ancient assumptions leak across layers, legacy interfaces shape new design, accidental behaviours are ossified, and entire subsystems survive because somewhere, somehow, something depends on them. Architects inherit obligations nobody remembers agreeing to, and release notes serve as archaeological strata, each layer documenting long-forgotten civilisations.
IBM Z inherited sixty years of software without inheriting sixty years of architecture by preserving behaviour, not implementation; existing applications continue working, but the machinery underneath them is free to change. The result is a platform that carries decades of history without dragging decades of architecture behind it. Customers invest in software, so software is deemed sacred; IBM bear the costs of compatibility so that customers don’t have to. Applications continue to encounter the same interfaces and semantics, while schedulers, memory managers, I/O subsystems, and processor designs evolve repeatedly beneath them. A program written decades ago will typically run unmodified on a modern mainframe, allowing customers to upgrade hardware without abandoning their investments in software.
Ephemeral platforms do the opposite: interfaces drift with every strategic reset, implementations are untouchable because their dependencies have become too unwieldy to manage, and the code is too frightening to inspect in daylight. Users suffer from every internal fear and architectural compromise, until the vendor unveils a new generation, supposedly with a cleaner design and brighter future; analysts declare the old model obsolete, and customers are assured that this time the break with the past is not only necessary, but liberating.
Yet many platforms fade into history while maintaining excellent backwards compatibility. They become steam trains: mechanically sound, occasionally operated for historic fascination, but not part of a modern transport network.
IBM Z is more than a runtime museum. A COBOL application written before relational databases were invented can exchange Kafka messages, while a CICS service that was originally driven by punched cards can now be driven by REST. The platform is a Tardis, carrying the past into the future; new technologies are absorbed, while customer investments are preserved — not contained behind a compatibility cage, but as first-class citizens of the modern world.
Software by Name, Infrastructure by Nature
Some notable software platforms have achieved longevity by behaving more like infrastructure than software products. What works today will continue working tomorrow; dependability takes precedence over dazzle.
- Oracle’s database business was built on a simple promise: applications written before the upgrade should continue working after the upgrade. Customer-facing behaviour remained stable over decades while internals evolved aggressively, earning its position as the standard enterprise data store; a good release is one that requires no weekend upgrade heroics and no emergency rollbacks.
- Java promoted backward compatibility as a strategic asset. Enterprises could upgrade operating systems, hardware and JVM implementations without rewriting business logic. The language and platform accumulated features over time, but the promise of write once, run forever generally held.
- Microsoft weaponised continuity as a competitive advantage. Windows and Office absorbed the internet, 64-bit computing, virtualisation, cloud integration, and new application frameworks while meticulously preserving customer investment. The future grew around existing workloads; customers were not forced to choose between their accumulated assets and Microsoft’s strategic direction.
- SAP/ABAP was designed to treat custom code as an asset, not just a convenience. Even major architectural overhauls (e.g. HANA and S/4) were engineered to preserve as much customer logic as possible. SAP invested heavily in migration frameworks and compatibility mechanisms to ease the transition; customers treated like royalty responded with loyalty.
- VMware established durable virtual hardware contracts, allowing guests to move freely between disparate hosts while remaining blissfully unaware of the changes beneath them. Real-world contracts also benefited; VMware remained the dominant force in visualisation until commercial creativity overcame technical rigour.
The common denominator in all these platforms is that they frustrated observers looking for velocity, but rewarded those responsible for systems that still needed to function after five reorganisations and three changes of strategy.
Launches vs Customers
System/360 and its successors proved that IBM knows how to build platforms for decades, but the software division didn’t always appear to have got the memo.
- Rational accumulated capabilities through acquisition. The portfolio was a market leader in SDLC management, but coherence was not its strong point. A collection of loosely aligned tools for requirements, modelling, testing, configuration management and lifecycle governance, each following its own strategic direction, failed to achieve the vision of a single platform.
- Operational software prizes stability over novelty. Tivoli should have fitted the market like a glove, but instead, it became patchwork of products, policies, and platforms with divergent data models and inconsistent interfaces. Every upgrade encouraged customers to consolidate, migrate, or adopt successors, until they eventually defected as the suite repeatedly demanded adaptation instead of offering accommodation.
- Lotus Notes came closest to solving the puzzle. Domino applications continued working, and Verse introduced a modern user interface. Yet the past and present lived in parallel worlds, more polite neighbours than partners; old applications continued running, the suite grew a modern user experience, and the twain never met. iNotes made some tentative moves towards exposing Domino applications in a more contemporary fashion, but it fell short of true modernisation.
Notwithstanding technical capability, these products faded through accumulated pain and a deficit of trust. Had they instead followed the same discipline that shaped System/360, there would have been fewer grand launches, fewer repositionings, and fewer opportunities for analysts to declare a new era. They might also still dominate the categories they once defined.
Red Hat: The Trojan Mainframe
Could IBM infrastructure discipline save the software division?
Get Gideon Sireling’s stories in your inbox
Join Medium for free to get updates from this writer.
The mainframe earned its longevity by understanding that breaking trust is more expensive than maintaining it. Red Hat applied the same discipline to software, treating compatibility as an obligation and boredom as a virtue. Workload continuity holds a permanent veto over architectural purity; new functionality is not allowed to break old functionality.
When IBM acquired Red Hat, it came with a culture that views predictability as a feature. OpenShift was selected as the common substrate for Cloud Paks and other applications, reducing the number of competing stacks customers had to understand and manage. Software governance and lifecycle began resembling the OpenShift model over slash-and-burn; the software division learned how modernity could be additive without being disruptive. Architects may enjoy eradicating technical debt, but enterprise customers generally prefer eradicating operational surprises.
The Ship of Theseus Sails Java Sea
If promoting the past into the future was sufficient elixir for technology life, Liberty would reign supreme over WebSphere’s former empire.
WebSphere ND solved difficult problems with style: clustering, orchestration, scaling, failover, and high availability. Then containers and Kubernetes pulled the market out from under its feet, and WebSphere’s unique value proposition became a generic infrastructure concern.
IBM’s response was Liberty, an attempt to remain relevant in the cloud-native world without being abandoned to a legacy corner of the portfolio. Viewed through the lens of continuity, this was the right approach; existing JEE applications were carried forward on a modern, lightweight runtime. Yet Liberty never succeeded at succeeding WebSphere’s dominance.
When clusters of commodity servers became all the rage, IBM didn’t attempt to re-imagine the mainframe as a Dell competitor. A customer wants to replace their mainframe with a room full of x86s? So long, and thanks for all the fish. IBM recognised that by trying to compete in the new world, the mainframe would lose its identity, and be relegated to an also-ran in the crowded commodity market. Z didn’t just painstakingly preserve customer investments; it preserved its own identity, even at the cost of ceding market share.
Viewed through the lens of identity, WebSphere’s succession was murkier. Liberty preserved applications, but that which had made WebSphere distinctive became the responsibility of Kubernetes. WebSphere adapted to the future and carried customers forward, but in the process conceded the problem space that once defined it; Liberty inherited little of the WebSphere heritage that had made its predecessor so valuable.
Unlike the mainframe, there was no way to satisfy all platform requirements simultaneously; keeping WebSphere’s identity would mean competing against the standard orchestration layer the industry had already settled on. IBM played the hand dealt it as well as it could, but there was no longer a market for a WebSphere that remained recognisably WebSphere.
Winning Jeopardy!, Losing the Enterprise
Jeopardy! star Watson was launched with a blaze of hype, but enterprise platforms must first and foremost accumulate trust. While oncology may have been its most infamous failure, the core issue was that Watson suffered from an identity crisis, as the platform was repeatedly redefined, repositioned, repurposed and rearchitected. Is it a QA engine? Is it healthcare? No, it’s a data platform! Customers struggled to build long-term capability because the ground underneath them kept moving; today’s strategy would become tomorrow’s unceremonious pivot.
Watsonx was rebuilt as a collection of integrated capabilities with clearer architecture and stronger governance. It’s the flagship initiative of the reformed IBM software culture, one that optimises for longevity over publicity: a durable mission statement buttressed with firm governance, common foundations, and evolution by extension over replacement.
Enterprise platforms don’t get unlimited opportunities to rebuild trust, and customers do not appreciate being told to celebrate becoming explorers every time vendors tear up the map. If watsonx becomes a product, competing on novelty, positioning, and velocity, it will encounter the same fate as its predecessor. If, on the other hand, it is developed as a platform — governed, stable, and remaining recognisably itself — it may yet accomplish what Watson could not: become something enterprises build on, not just experiment with.
Platforms That Persist and Products That Perish
Immortal platforms are conservative because they choose continuity over opportunity. They reject feature requests, retain awkward interfaces, and carry constraints long after the original reasons have faded. In exchange, they accumulate trust.
Building something that lasts means treating continuity as a first-class engineering requirement for decades at a time. It requires governance that survives leadership changes, and incentives that reward restraint at least as much as innovation. It requires continuity as a constant when strategy pivots, keeping portfolios consistent when competitors are acquired, and remaining committed to commitments when they seem negotiable. It requires an understanding that when driving into the future it is the vendor’s responsibility, not the customers’, to ensure that the past is sitting comfortably in the back with its seatbelt on.
System/360/Z endured because IBM infrastructure treated continuity as part of the product. Oracle built a database empire by allowing applications to survive upgrades. Java accumulated decades of features without forcing application rewrites. Microsoft weaponised continuity as a competitive advantage, growing the platform around existing investments instead of abandoning them. Red Hat built a software business that treats predictability and compatibility as features. The same dynamics apply in other domains: POSIX, C, and the protocols that power the Internet all persist and thrive by promoting evolution over revolution.
Timeless platforms remain true to their mission while embracing modernity, and ensure that existing investments will remain citizens of the future, not artefacts of the past. Carrying continuity through change, they are more than products; they are phoenixes.
