Tag: enterprise software

Categories
Computers IBM

The Day the Last Mainframe Went Dark

Note: I literally grew up during the heyday of the IBM mainframe era. My first real job was working for IBM in San Francisco beginning in 1968. I’m a “big iron” kind of guy. But this post was imagined after reading the following in a July 14, 2026 announcement from IBM: When we discussed our expectations with you in April, we noted that we would be wrapping on the launch of z17 in the second quarter. Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing. In the last few weeks of June, we saw clients shift their quarterly capex spend toward servers, storage, and memory purchases to secure supply-constrained infrastructure ahead of expected price increases. This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.

It won’t arrive with fanfare. No countdown, no viral video of engineers raising a glass. One morning—sometime in the 2040s, perhaps later—a small team in a climate-controlled data center will complete the final cutover. They’ll flip the switches, watch the lights dim, and listen as the hum of the last production IBM mainframe fades to silence. An era that began with the System/360 in 1964 will end. Not with a crash. With the soft click of obsolescence.

We’ve been predicting the mainframe’s death for decades. In the early 1990s, pundits declared it doomed. They were wrong. Those systems—reliable, secure, capable of staggering transaction volumes with near-perfect uptime—became the invisible backbone of modern life. Your last bank transfer, airline reservation, insurance claim, or government benefit likely touched one. They endured because they solved hard problems well: high-volume, mission-critical processing where failure was never an option.

The path to that final power-down was never a rupture. It was a long, uneven evolution—driven by economics, technology, talent shifts, and the patient work of modernization. AI tools accelerated the transition. They didn’t cause it.

Lessons from Earlier Transitions

Steam engines dominated railroads for generations—powerful, reliable, deeply integrated into the industrial economy. Diesel won through incremental advantages: better efficiency, lower maintenance, longer trains with less labor. Railroads rebuilt infrastructure and retired the old iron as the economics aligned, route by route.

Prop planes opened the skies to mass travel. Jets brought speed and range that transformed global connectivity—but airlines didn’t scrap fleets overnight. They ran hybrids during the overlap, invested in new airports and training, and retired props as jet economics and passenger demand made the case irresistible.

The mainframe followed this pattern. AI coding agents—Claude Code, Cursor, OpenAI models, AWS Transform, IBM watsonx—transformed the brutal manual work of understanding undocumented COBOL, extracting buried business logic, generating tests, refactoring safely. What once demanded scarce veteran experts for months or years could now be accelerated, with rigorous human oversight and equivalence testing.

Platforms like Visa’s Pismo showed a smarter path: incremental modernization. Cloud-native microservices layered alongside legacy cores, rather than rip-and-replace. Banks demonstrated real progress. Hybrid strategies won—AI inference running close to sensitive data on evolved mainframes (IBM’s z17 and successors, with on-chip accelerators), while new applications and analytics moved to elastic cloud environments.

IBM positioned the platform as an “AI factory” for low-latency, secure workloads. But pricing pressure was constant. High, capacity-based software licensing made the economics harder to defend as cloud offered predictable, usage-driven costs and younger talent gravitated toward modern stacks. For CFOs weighing rising maintenance against retiring COBOL expertise and AI-assisted migration, the scales tipped.

By the mid-2030s, competitive and regulatory forces intensified. Fujitsu’s exit from mainframes created a cliff in affected markets. Skills shortages accelerated. Even the most conservative holdouts—ultra-high-volume, regulated systems in finance, government, specialized industries—began serious moves, as simulation environments and exhaustive parallel testing brought the risk down to manageable size.

The Final Act

The last systems to go were the stubborn ones, where disruption carried outsized consequences. When the final cutover succeeded—after months of flawless parallel running—the team powered down the machine. A global bank, a payments processor, a government entity. Maybe a small ceremony: engineers who’d kept it alive for decades, trading stories of the iron that never failed when the world needed it most.

Picture the aircraft boneyards outside Tucson or Victorville, retired 747s sitting in rows under the sun, giving up parts to new generations before they’re recycled. Mainframes will meet a similar fate, more climate-controlled. Some linger in warehouses as insurance, still humming faintly in test or archival roles. Others get dismantled by IT asset disposition teams—data wiped to standard, processors and I/O cards harvested for niche markets. The bulk gets recycled, metal and circuitry returning to the supply chain. Like the jets, the iron won’t vanish in disgrace. Its lessons in reliability and disciplined engineering at scale live on, embedded in whatever comes next.

The world didn’t stop. Transactions kept flowing, now on distributed, elastic, AI-augmented platforms that had absorbed the best of what came before. The mainframe era didn’t end in failure. It ended because better options finally existed for every workload.

What Endures

We’ll look back with respect and nostalgia. The mainframe wasn’t flashy, but it taught something durable: some problems reward obsessive focus on reliability and scale; disciplined engineering outlasts hype cycles; the wisest transitions are rarely clean breaks. They’re patient evolutions that carry forward what matters.

IBM will have completed its own transformation by then—software, services, hybrid orchestration, AI tools that work across environments. The company that built the platform helps close the book on it.

The last mainframe going dark won’t feel like loss. It will feel like the natural close of a chapter that powered the digital economy through its most formative decades. The iron did its job. Now the next architecture takes the stage, standing on shoulders built to last.

Categories
AI

What the Lessor Keeps

Two airlines can fly the same airplane. Not airplanes of the same type — the same airplane, serial number and all, handed back at the end of a lease and reassigned, sometimes within weeks, to a competitor on another continent. AerCap owns more commercial aircraft than any airline on earth, and it leases them to airlines that spend their advertising budgets convincing passengers that flying them is a distinctive experience. The 737 MAX that wears Ryanair’s livery this year might wear Lion Air’s the next, repainted, recertified, its avionics untouched, its airframe indifferent to the change of ownership. The lessor does not care who is flying its asset. It cares that the asset comes back in airworthy condition and that the lease payments clear.

What the airline owns, in the sense that matters, is never the aircraft. It is the route network built up over decades of slot negotiations at constrained airports. It is the maintenance log — every inspection, every part swapped, every anomaly a mechanic in Singapore flagged in 2019 that turned out to predict a fatigue crack nobody else had seen yet. None of that travels with the airplane when the lease ends. It stays behind, compounding, in systems the airline built and the lessor never touches.

Karl Mehta, who has spent a career inside enterprise software watching this kind of asymmetry repeat itself, put a version of it plainly: a model is a brain you rent, and you and your competitor rent the same one. The formulation has the compression of something that has been tested in a few dozen meetings before it found that sentence. It is also, structurally, the airplane story. Anthropic and OpenAI and Google are AerCap. They retain residual value on enormous capital assets — clusters of GPUs depreciating on a schedule, weights trained at a cost that only a handful of balance sheets in the world can absorb — and they lease access to those assets by the token, to anyone who can pay, including, in the same afternoon, two companies trying to put each other out of business. The model does not know whose prompt it is answering. It has no loyalty file. It has, in fact, no memory at all, in the ordinary sense of the word — each call begins exactly where the last one ended for everybody, which is nowhere.

The asymmetry that airlines exploit is the one available here too, and it sits one layer up from the engine. Call it the embedding store, the vector database, the fine-tuning corpus, the retrieval index — the terminology varies by vendor, but the function is constant. It is the accumulated, indexed residue of every customer interaction a company has had, structured so that the rented brain can be handed the relevant fragment of it at the moment of each new call. A bank’s fraud model and a competing bank’s fraud model can call the identical foundation model, route through the identical API, and arrive at entirely different verdicts on the identical transaction, because one of them is retrieving against eleven years of labeled chargebacks specific to its own card portfolio and the other is retrieving against four. The intelligence rented by the hour is, for practical purposes, a commodity, priced down toward marginal cost the way jet fuel is priced — everyone pays close to the same number per unit. The memory is not a commodity. It cannot be, because it is not for sale; it is the institutional record of what has already happened to you, and no amount of capital lets a competitor buy a copy of your chargeback history any more than it lets them buy your maintenance logs.

This produces a particular kind of corporate vertigo, which Mehta’s sentence is really addressing. For three or four years the industry conversation about artificial intelligence has been a conversation about models — which lab’s was larger, which benchmark moved, which release cycle a company should anchor its roadmap to. That conversation rewards being an early and aggressive lessee. But a lessee relationship, however aggressive, does not compound into anything a competitor cannot eventually also lease. The compounding, when it happens, happens in the layer below the API call: in how cleanly a company has structured the record of its own customers, its own failures, its own edge cases, so that the rented brain, plugged in fresh every morning with no memory of yesterday, can be handed exactly the right fragment of yesterday and made to look, for a few hundred milliseconds, like it has been there all along.

A hospital chart has two kinds of entries. There is the vital-signs strip clipped to the bed rail — temperature, pulse, blood pressure, checked every four hours and replaced every four hours, because a reading from yesterday tells the night nurse nothing about the patient in front of her right now. And there is the permanent record in the file downstairs: the allergy that nearly killed him in 2019, the surgery, the medication history going back a decade, written once and never overwritten, because that record is exactly as valuable ten years from now as it is today. Nobody confuses the two charts. Nobody staples last Tuesday’s blood pressure into the permanent file. The hospital figured out, long before anyone digitized it, that memory is not one problem. It is two, and they fail in opposite directions if you run them through the same system.

Most teams building the layer Mehta is describing make exactly that mistake — they staple everything to the same chart. The shorthand for it is dumping everything into a vector database and praying, and it is worth asking why that particular error is so popular. The answer is that it feels like progress: embeddings go in, something resembling memory comes out, and the team moves on to the next sprint without confronting the harder question, which is what kind of memory it just built.

Short-term memory is the vital-signs strip — everything the model needs to finish the task in front of it and nothing it needs after. A customer-service exchange in progress, the order number already mentioned, the fact that this is the second call today, belongs here. So does the scratchpad of a multi-step agent: the search results just pulled, the file just opened, the partial answer being assembled before it commits. The test is not how important the information is but how long it stays true. A customer’s mood this minute is real and gone in twenty minutes; storing it permanently is like stapling yesterday’s temperature reading into the permanent file, undated, until the chart tells you nothing about fever and everything about clutter. Short-term memory should live in the context window itself, or a session-scoped cache, and it should be allowed to die when the session ends. The sin is not forgetting it. The sin is remembering it forever.

Long-term memory is the file downstairs, and it does not come in one shape any more than that file does. The first shape is semantic memory — facts. A customer’s account tier. The chargeback history that decides, in fractions of a second, whether this morning’s transaction clears. Facts belong in a database with a schema, not a vector store, because a fact has a right answer and a vector store gives you an approximate neighbor. Ask a vector index what tier a customer is on and it hands you the five most semantically similar sentences in the corpus — one correct, four merely correct-sounding. Ask a schema the same question and it tells you, because that is what the schema is for.

The more sophisticated shops are already building the seam between the two, rather than picking one and living with its blind spot. A knowledge graph keeps the relationships a schema is good at — this customer, that account, this chargeback, in fixed and queryable connection to one another — while still letting a retrieval layer search across it by meaning rather than by exact key. The approach has a name now, GraphRAG, and the name matters less than what it concedes: that facts and resemblance are different operations, and the honest fix is to run both and let each one answer the kind of question it’s actually suited for, not to force a single index to pretend it can do both jobs at once.

The second shape is episodic memory — what actually happened. The specific conversation last March in which the customer explained, at length, why the previous fix didn’t work. The exact sequence of an agent’s failed attempt at a task, preserved so the next attempt doesn’t repeat it. This is where the vector store finally earns its keep, because an episode isn’t an exact-match lookup, it’s a resemblance — has anything like this come up before — and a vector index, built to find the nearest thing to a fuzzy question, is the right tool for that question and almost no other. The error was never using a vector store. The error is using only a vector store, for facts as well as episodes, on the theory that one hammer with sufficient cosine similarity can stand in for the whole toolbox.

The third shape is the rarest, and the one teams forget to build at all: procedural memory, which is not a fact and not an episode but a skill — the model’s learned sense of how this company writes a refund email, escalates a complaint, formats an invoice. Style is the visible half of it. The other half is harder to see and matters more: the rails the model is forced to run on before it ever gets to choose a word. A refund above some threshold routes to a human, no exceptions, because the workflow says so, not because the model was persuaded to think so on this particular call. An agent that touches a production database does it through a reviewed function with a fixed set of permitted calls, not through whatever query it improvises in the moment. None of that lives in a prompt, and none of it lives in the model’s weights either. It lives in code — the orchestration layer, the permissioning, the state machine the agent is required to pass through — and it is procedural in the oldest sense of the word: not a memory of what to say but a memory of what is and isn’t allowed to happen, enforced whether or not the model that day feels like remembering it. It doesn’t live in a database at all. It lives in fine-tuning, in carefully maintained house-style examples, and in the surrounding scaffolding of guardrails and permitted actions, and it changes slower than the other two, the way a surgeon’s hands carry both technique and caution years after the specific patients are forgotten. A company that has built rich semantic and episodic memory but skipped this layer has a model that knows everything about its customers, writes in exactly the right voice, and is one well-crafted prompt away from doing something the company never agreed to.

The real argument here is not which database serves which layer — that part is plumbing, and plumbing changes every eighteen months. The argument is that memory has to be triaged the way the hospital triages it, with something deciding on purpose what survives the session and what doesn’t, rather than writing every token of every interaction into the same undifferentiated store and trusting retrieval to sort it out later. A vector database with no triage in front of it is not a memory system. It is a landfill with a search function, and it will retrieve the wrong eleven-month-old conversation with the same confidence it retrieves the right one, because nobody wrote the part of the system whose only job is deciding what belongs on which chart.

The lessor’s airplane, repainted, will fly for someone else next year. The route network will not. Neither will the schema that knows a customer’s tier on contact, nor the index that remembers the conversation from last March, nor the fine-tuned hand that knows, without being told twice, how this company writes a refund email. These are the things that do not come back at the end of the lease, because they were never on it.

Categories
AI

The Coach Who Wouldn’t Change

In 1975, a twenty-four-year-old Kodak engineer named Steve Sasson built the first digital camera. It was the size of a toaster, captured a black-and-white image at 0.01 megapixels, and took twenty-three seconds to record a single photograph to a cassette tape. Sasson showed it to his managers. Their response, as he later recalled, was essentially: that’s cute, but don’t tell anyone about it.

Kodak was not a stupid company. It was a dominant one. At its peak it held 90 percent of the American film market and 85 percent of camera sales. Film was not just a product line — it was the entire economic architecture of the company. Processing fees, paper, chemicals, the retail relationships built around the assumption that photographs needed to be developed. Digital threatened all of it simultaneously. So Kodak did what dominant companies do when confronted with a threat they can’t absorb into the existing model: they managed it. They ran studies. They filed patents. They made incremental moves. They protected the thing that was working rather than building the thing that would work next.

Kodak filed for bankruptcy in 2012. The digital camera had been sitting in their own archives for thirty-seven years.

Nokia’s version of the same story has a different texture. Where Kodak’s failure was about protecting a margin, Nokia’s was about identity. Through the 1990s and into the early 2000s, Nokia was mobile phones — not a major player, but the category itself. At its peak it held over 40 percent of the global handset market. The company had navigated a remarkable transformation earlier in its history, shedding paper mills and rubber boots to become a pure technology company. It knew how to change. It had done it before.

What it couldn’t do was change from a hardware company into a software one. When the iPhone arrived in 2007, Nokia’s internal assessments were, by most accounts, accurate. They understood the threat. They had touchscreen prototypes in development. What they couldn’t manage was the cultural distance between building phones that were superb physical objects — durable, reliable, made to exacting standards — and building phones that were primarily platforms for software that other people would write. The excellence that had made Nokia great was manufacturing excellence. The game was becoming something else, and manufacturing excellence was not only insufficient for the new game; it was actively in the way, because it oriented every decision toward the object rather than the experience.

Nokia’s market share collapsed from over 40 percent in 2007 to under 5 percent by 2013.

Andy Grove, who built Intel into the dominant force in semiconductors, called it plainly: only the paranoid survive. He meant it as a prescription. His successors treated it as a trophy.

Both stories have the clean shape of settled history. We know how they end. The verdict is in, the lesson is available, and it’s easy to read them now as cautionary tales about obvious mistakes made by people who should have known better.

This is the wrong way to read them.

Kodak and Nokia didn’t fail because they were blind. They failed because they were standing on a fulcrum — a moment when the old game and the new game were both plausibly real — and they chose the wrong side. At the time, that choice was not obviously wrong. Film was still enormously profitable. Nokia’s hardware was genuinely superior. The rational case for staying the course was real, and the people making it were not fools.

The reason the Kodak story is still told fifty years later is not that the mistake was obvious. It’s that it wasn’t — and they made it anyway.

Which brings us to now. Because there is a fulcrum in front of the enterprise software industry, and nobody knows yet which way it tips.

The companies in question — Salesforce, ServiceNow, and most of the SaaS category built over the last twenty years — were constructed on a simple and powerful premise: that businesses would pay recurring subscription fees for software that managed their customer relationships, their workflows, their data. The premise was correct. It produced some of the most durable businesses in the history of technology.

The threat AI poses to this model is not subtle. If an AI agent can handle a customer service interaction, manage a workflow, or synthesize a CRM record without a human touching licensed software to do it, then the per-seat subscription model — the economic engine underneath all of it — starts to look like film processing in 2003. Theoretically intact. Quietly at risk.

The responses of these companies have been instructive, and they’ve diverged.

Here is the honest position: we don’t know yet. The fulcrum is still in motion.

It’s possible that Salesforce’s Agentforce is the Kodak digital camera — the real thing, built by the right company, that gets buried under the weight of protecting what already works. It’s possible that the SaaS model is more durable than the threat suggests, that enterprises will pay for trusted platforms regardless of the underlying labor model, and that the companies racing hardest to cannibalize their own revenue streams are making a different kind of mistake. It’s possible that ServiceNow’s consistency is discipline, or that it’s the Nokia instinct to keep building the best version of the thing that used to win.

What the Kodak and Nokia stories actually teach — not the simplified version, but the harder one — is that the mistake is never visible in the moment it’s made. It only becomes visible later, when the fulcrum has tipped and the choice that was once defensible has become permanent.

The coach who wins five championships holds the philosophy and rotates the players. The coach who wins one holds the players and calls it philosophy.

The enterprise software companies standing at this moment have a version of the same decision. The ones who make it correctly will, in twenty years, be the ones we cite as examples of adaptation. The ones who don’t will be the ones we cite as examples of something else.

We just don’t know yet which is which. That’s not a comfortable place to stand. It is, however, exactly where we are.

Categories
AI Business

The Moat Drains

There is an old metaphor in investing — the “moat.” Warren Buffett popularized it: the idea that the best businesses are castles surrounded by deep, wide moats that keep competitors at bay.

For the past two decades, enterprise software companies built some of the most impressive moats in the history of capitalism. Sticky customers. Multi-year contracts. Switching costs so high that even dissatisfied clients stayed put. The moat wasn’t just deep — it was filled with concrete.

This morning, JP Morgan’s equity research team quietly suggested the concrete may be cracking. See also this recent Substack post by Jordi Visser.

In a note lowering price targets across their software coverage, the bank cited a striking phrase: “the exponential pace of AI proliferation raises doubts about competitive moats and the defensibility of software companies.”

They’re not alone in thinking this. But there’s something significant about seeing it written in the careful, hedged language of a major Wall Street research report.

When the analysts who model ten-year discounted cash flows start abandoning that framework — replacing it with simpler one- and two-year profitability multiples — it’s a signal worth decoding.

The shift in valuation methodology is itself the story. DCF analysis — the gold standard of software valuation for a generation — requires confidence in a company’s earnings trajectory over many years.

JP Morgan is saying, plainly, that they no longer have that confidence. The window of visibility has collapsed. When you can’t see more than a year or two out, you stop pretending you can.

“Investors are less comfortable underwriting defensive growth over multi-year periods.”

What’s driving this?

The suspicion — increasingly well-founded — that AI is not just a feature to be added to existing software products, but a force that restructures the value chain entirely.

If an AI agent can perform the function that previously required a $50,000-per-year SaaS subscription, the moat doesn’t just shrink. It evaporates. The castle becomes a historical curiosity.

Vertical software stocks — the specialized platforms serving specific industries like healthcare, construction, or legal — currently trade at 10 to 25 times EBITDA, according to the note. The S&P 500 as a whole trades at 15 times. The message embedded in those numbers is sobering: many of these once-premium businesses are being re-rated toward commodity valuations, and some may not have found their floor yet.

JP Morgan’s preferred companies in this environment are those with upside to 2026 revenue estimates and those they view as “defensive to AI proliferation.” That second phrase is the one I find myself turning over. It implies a new taxonomy is forming in the market — not growth vs. value, not cyclical vs. defensive, but AI-vulnerable vs. AI-resistant. That’s a categorization that didn’t meaningfully exist three years ago.

The moat metaphor may need an update. In the age of AI, the question is no longer how wide the moat is. It’s whether the castle itself still needs to exist.

Questions to Consider

  1. The Moat Inventory: If you were a software CEO this morning, which parts of your product would you genuinely consider defensible against AI substitution — and which would you privately admit are vulnerable?
  2. The Valuation Signal: When Wall Street abandons long-term DCF models in favor of near-term multiples, is that a temporary adjustment to uncertainty — or a permanent reset in how software businesses will be valued going forward?
  3. The New Taxonomy: JP Morgan implicitly divides the software world into AI-vulnerable and AI-resistant. What characteristics do you think actually define that divide — and can a company move from one category to the other?
  4. The Buffett Test: Buffett’s moat metaphor was built for a world of slow-moving competitive forces. Is the concept still useful in an era of exponential technology change, or do we need a new mental model entirely?
  5. The Timing Question: Is this re-rating of software companies a rational early response to a real structural shift — or is Wall Street, as it often does, overcorrecting in the short term for a change that will take much longer to fully materialize?