





















The mainframe sits in an odd spot in tech conversations. If you don’t run one, it’s easy to write it off as legacy infrastructure on its way out. Legacy infrastructure that’s been on its way out for the last 30+ years.
If you do run one, you know better. Most of a company’s data lives elsewhere, sure. But almost every record on the mainframe is business critical.
This changes how you should think about the mainframe’s role in AI. An AI project is only as good as the data and context behind it. And a big share of the most valuable enterprise data is locked inside these systems that large language models know nothing about. This was the heart of what Broadcom’s Mainframe Software Division laid out at its recent analyst summit. It’s also why the platform deserves more attention in the AI conversation than it gets.
Citing AI adoption research, Broadcom pointed out what we all kind of know but need grounding in: that enterprises adopt AI far more slowly than the models themselves improve. Yeah, the potential for AI to reshape knowledge work is real. But actual adoption in production stays modest once you look past software development and maybe some IT automation. Think back to the internet and the .com craze. The real value delivered to most organizations was realized a few years after the .com crash.
This is a realistic framing. So much of what we read suggests enterprises are one deployment away from total transformation. They aren’t. Adoption’s an evolution, and each organization sets its own speed. Every customer brings a different mix of technical debt, skills, governance maturity, and risk tolerance. And a strategy that ignores that and forces a single transformation model onto every account will fail in most cases.
Broadcom’s response is the most encouraging part of its strategy. It isn’t trying to run its customers’ AI program. Instead, it’s building tools that plug into whatever environment the customer has already picked. The LLM is the customer’s call. So is the agentic framework. Broadcom’s job is to expose what its products know about the mainframe so models and agents can act on it.
Broadcom has built MCP tools that surface the data and metadata its products hold about the systems they manage. That’s information an LLM has no way of knowing on its own. System health, application dependencies, what changed yesterday, and the lifecycle details buried in Endevor (change management and DevOps). All of it is invisible to a general-purpose model. Expose that context through MCP, and a developer in VS Code, Cursor, or any compatible client can ask a plain-language question and get an answer grounded in the real state of the environment.
Picking MCP is smarter than it first looks. By building on that standard rather than a proprietary mainframe bridge, Broadcom makes mainframe context consumable by the agent stack a customer already runs. The same protocol that lets a ServiceNow workflow trigger an agent is what lets that agent reach into Endevor.
What ties these together is what’s missing: anything mainframe-specific in the experience. None of the demos I saw required the user to know the platform, its terminology, or the tooling underneath. That’s the real thesis of Broadcom’s strategy. The mainframe’s future depends on becoming invisible to the people who use its data. Not every developer and operator who touches it needs to understand it. It just needs to surface the right context at the right moment and otherwise get out of the way and do what it does best.
There’s a demographic shift running underneath all of this. The demos Broadcom showed hint at this, but never name it, and it matters more than the usual story suggests. That story is a retirement cliff: the COBOL veterans who built these systems are leaving, and no one’s coming up behind them. The data says something more interesting. The mainframe workforce isn’t emptying out. It’s turning over. By some estimates, millennials now make up just over half of the field, up from about a third seven years earlier. And Gen Z jumped from a rounding error in 2018 to fifteen percent. More and more, the people responsible for these systems aren’t the people who built them.
This changes the problem Broadcom is trying to solve. The risk isn’t that no one will be left to run the mainframe. It’s that the engineers inheriting it never wrote the applications they now own. The institutional knowledge of how a COBOL program behaves and what breaks when you change it is left with the people who wrote it. A sharp, newer engineer can still be stuck, with no fast way to recover context that used to live in someone’s head.
This is where Broadcom’s approach earns its keep. A developer new to an application can recover its structure and downstream impact through natural language, rebuilding in minutes what the platform’s previous stewards learned over years. You can’t hire your way out of this. Recruiting scarce veterans or running multiyear training programs can’t keep pace with a handover that’s already happening. The better answer is to expose mainframe context through a standard interface, so incoming engineers and the agents next to them can act on it without deep platform expertise. The same abstraction layer that makes mainframe data consumable by an AI agent is what lets a newer, leaner team keep business-critical systems running at all.
The most important thing Broadcom can do now is keep leaning into the data and the abstraction of complexity around it. Enterprise IT teams have no patience for siloed groups wrestling with proprietary tools just to connect a data estate that spans the hybrid datacenter.
This is where Broadcom’s opportunity and its risk meet. The company is well placed to be the layer that makes mainframe data and context available to the rest of the enterprise, without requiring customers to learn the mainframe to access it. But this spot isn’t guaranteed. The same neutral standard that lets Broadcom expose mainframe context lets other vendors reach for the broader hybrid-data layer. Holding the ground means resisting the pull toward mainframe-specific tooling and staying disciplined about meeting customers inside the standards they’ve already adopted. And that pull can be quite strong.
I think the broader lesson reaches well past the mainframe. Enterprises moving into agentic AI are finding that the constraint is rarely which model they pick. It’s whether the data an agent needs is accessible and well-governed enough to act on safely. CIOs shouldn’t be asking which model their teams prefer. They should be asking how much of their data estate is actually exposed to those models, with the right context and controls in place. The mainframe makes this impossible to ignore because business-critical data leaves no room for approximation.
An agent that garbles a meeting summary is an annoyance. An agent that misreads a transaction record is a liability.
This points to a shift that career mainframers may find counterintuitive. As the platform gets more tightly woven into the distributed environment, it has to give up some independence. The mainframe as a self-contained island, run by its own tools and its own teams, doesn’t fit a world where a ServiceNow workflow kicks off an agent that reasons over mainframe data and ends in a GitHub issue. Integration only works when the platform shows up as a peer, not an exception. And that’s as much an organizational and cultural change as a technical one.
If Broadcom keeps seamless integration as its north star, much of the rest follows. Customers win because the mainframe stops slowing their AI ambitions and starts feeding the context that makes those ambitions credible. Broadcom wins because it becomes indispensable to that outcome. The strategy I’ve seen in the summit shows the team gets it.
The real question, as always, is execution.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。