The announcement at Hot Chips extends the z/Architecture by using a dual-architecture processor to pull Arm-native software, developers and AI-adjacent workloads into IBM’s most durable franchise.
IBM’s announcement at Hot Chips will likely be positioned by observers as a processor story. But there’s a more strategic meaning to this move in our view. Specifically, IBM is using Arm to widen the mainframe’s application space without weakening its mission-critical core. The company is not replacing z/Architecture with Arm. It is designing a system that can bring Arm-native applications closer to the transactions, data and operating controls that make IBM Z and LinuxONE valuable in the first place.
Notably, the mainframe does not need Arm to continue processing the world’s most important financial and commercial transactions. It needs Arm to make it easier for the growing body of software surrounding those transactions to run on the same platform. In that sense, IBM is trying to turn Z from a highly defended fortress into a broader enterprise platform, while at the same time keeping its mainframe fortress intact.
Perhaps more importantly, this announcement signals a more substantive collaboration between IBM and Arm, a relationship that started decades ago. In our view, it was a long time coming and could help make the economics of IBM’s silicon more attractive. As we’ve been advising our community for years, Wright’s Law tells us that volume confers cost and other advantages in semiconductors and other manufacturing situations.
Wright’s Law is fundamentally a learning curve concept describing how some metric improves (decreases) as cumulative experience (volume) rises. Although it’s commonly framed in terms of cost, it is easily applied to any production metric that tends to improve with experience, such as manufacturing time (per unit), labor hours, or defect rates.
The point is that the IBM and Arm collaboration has the potential to bring significantly more attractive economics and potentially time-to-market advantages to IBM, as the learning curve benefits of Arm accrue to IBM.
The news in brief
At Hot Chips, IBM previewed what it calls the first dual-architecture mainframe processor. The design is intended for a future generation of IBM Z and LinuxONE systems. It will allow Arm-native Linux environments to operate alongside z/OS and Linux on IBM Z while retaining the security, reliability and scale associated with the platform.
The most interesting technical detail is that IBM is not placing separate Arm and IBM core complexes on the same package. IBM says each processor core will be able to execute Arm64 and IBM Z instructions natively and concurrently. The planned processor will use a 2-nanometer process, contain 11 high-performance cores running above 5.7 GHz, and include AI inference acceleration, an on-chip data processing unit for I/O and a large cache architecture.
While there’s no specific mention of a foundry in the formal press release, we’ve confirmed that Samsung will manufacture the processor. The technology is expected to arrive with the next Z and LinuxONE generation in approximately two years, consistent with IBM’s three-year system cadence.
This is therefore not a near-term product announcement. It will not materially change IBM’s infrastructure revenue next quarter. But it moves the IBM–Arm relationship beyond the broad strategic collaboration announced in April. IBM has now attached that partnership to a specific processor, system generation and architectural design.
In our view, this is not a big-bang market event. It is a credibility-building milestone. It shows that the April agreement was not simply a partnership press release and decades of collaboration are becoming more meaningful. IBM and Arm are positioned now to build a multi-year technology roadmap.
The real strategy is to absorb the Arm ecosystem
The obvious headline is that IBM is putting Arm inside the mainframe. The more important point is that IBM is bringing the Arm software ecosystem and learning curve advantages to the mainframe’s operating environment.
Arm says its ecosystem includes more than 22 million developers and now spans cloud, edge and AI software. By our estimates, Arm wafer volumes are 10x those of x86. This brings economic and other benefits to Arm’s partners. In this case, IBM wants to give Arm applications access to the security, encryption, fault recovery, key management and AI capabilities associated with Z and LinuxONE. In return the volume and learning curve advantages can benefit IBM’s architecture.
That also gives IBM a way to address a long-standing challenge.
The core mainframe applications may be highly durable, but the software surrounding them changes quickly. Banks, insurers, retailers, airlines and government agencies do not run only COBOL and Db2. Their critical systems increasingly depend on data streaming, messaging, observability, security, API management, open-source databases, developer tools, containers and AI services.
Much of that software is developed first for x86 and Arm64. IBM and its partners can port it to s390x, but every port consumes engineering resources. Each new version must be compiled, tested, optimized, certified and supported. As open-source release cycles accelerate, the issue is not only whether a product can be ported. It is whether the Z version can remain current enough to be useful and seen as “modern.”
In a briefing with theCUBE Research, IBM cited several examples of its push toward modernization in the context of the Arm relationship. Confluent and HashiCorp products already run on Arm64, while IBM has also done the work required to support them on s390x. IBM expects the new architecture to reduce that porting burden for products such as monitoring software, messaging and queuing systems, security tools, developer tools, data-serving applications and databases. IBM also identified PostgreSQL, MongoDB and MariaDB as examples of software that could benefit.
Native Arm support does not mean every Arm application will work on day one. Software will still require a supported operating system, compatible dependencies, packaging, testing, licensing and vendor certification. But IBM is attacking the problem at a deeper level. Instead of porting every application to the mainframe’s instruction set, IBM is making the processor understand the instruction set that much of the software already uses.
That can materially reduce the friction between software availability and platform adoption.
The mainframe remains the foundation
IBM is not trying to run every enterprise workload on Z.
The best candidates are applications that sit close to mission-critical transactions or sensitive data and require high availability, predictable performance, strong isolation or strict regulatory controls. IBM specifically emphasized data sharing, data serving, messaging, security and open-source databases that surround critical applications.
This is an important boundary for observers to understand in our view. An enterprise will not move a generic departmental application to Z simply because it can run Arm binary code. But it very well may want a real-time data service, fraud model, event stream, security control or customer database on the same platform as a core payments system.
As such, the value in our opinion comes from proximity. Specifically, running those components on Z can reduce data movement, eliminate network hops and simplify the number of security and operational complexities around a transaction. It may also allow enterprises to apply AI against sensitive data without first copying that data into a separate cloud or distributed environment.
The mission-critical workload is the foundation and Arm expands what can be placed around it.
Red Hat may be the bridge but IBM must show the full software plan
Red Hat is essentially the core of IBM’s platform strategy and touches virtually all aspects of the IBM portfolio. In our view, the Red Hat angle could become one of the most important parts of this strategy.
In particular, OpenShift gives IBM a common application and container management layer across on-premises systems and public clouds. But container portability is not the same as binary compatibility. A container image still includes architecture-specific software and dependencies. An image built for Arm64 does not automatically run on s390x merely because both environments support Kubernetes.
The dual-architecture processor addresses that gap and is where the real engineering work takes place.
In principle, an enterprise could deploy an Arm64 application in the cloud and bring the same software build into an IBM environment without a separate s390x port. OpenShift could provide the management and orchestration layer, while the processor provides native execution.
That could make LinuxONE especially interesting. LinuxONE is already positioned as a high-capacity, highly secure Linux consolidation platform. Native Arm support could extend that proposition to cloud-native software built for Arm without turning LinuxONE into a commodity Arm server.
IBM will not beat, nor is it trying to beat hyperscalers or merchant server vendors on the price of a generic Arm core. It is trying to become the platform for the most mission critical Arm workloads. For Arm, this continues to extend its architecture into more use cases.
But this remains an opportunity, not yet a completed product strategy. IBM has not disclosed the full operating-system support matrix, the planned RHEL and OpenShift integration, the virtualization model, or the list of software vendors that will certify Arm-native products for the new system.
Those details will determine whether this becomes an ecosystem expansion or merely an impressive compatibility feature.
The economic objective is to expand the Z flywheel
The timing of the announcement is notable because IBM’s second-quarter infrastructure results disappointed investors.
Infrastructure revenue declined 7%, and IBM acknowledged that Z performance was below expectations during the first five quarters of z17 availability. At the same time, the overall z17 cycle remained nearly 130% of the comparable z16 cycle, which IBM described as the strongest program-to-program performance in its reported history.
Management also reported that IBM Z supports more than 140 million installed MIPS, that clients representing 85% of that capacity are maintaining or increasing it, and that the platform processes more than 70% of global transaction volume when measured by value.
The quarter was therefore weak relative to IBM’s expectations, but it did not provide evidence of a mainframe exodus by customers. IBM said the fifth quarter of a new Z cycle normally declines as the company laps the launch period, and z17 was still approximately $1 billion ahead of z16 at the same point in the cycle. IBM also said every dollar of mainframe hardware revenue generates more than three dollars of related software revenue.
This is the economic context for the Arm relationship.
IBM does not need Arm merely to sell more processors. It wants to attract more applications, increase total system consumption and expand the software and services attached to the platform.
The company claims it is already seeing new capacity associated with Linux, analytics and AI workloads. IBM said installed capacity had increased approximately 15% to 20% during the current program and that clients adopting its AI capabilities were expanding capacity faster than other customers.
Arm could add another source of workload growth. But it is too early to assume that Arm consumption will translate directly into traditional MIPS economics. IBM has not disclosed how it will meter, license or price Arm capacity. It could use existing Linux specialty-engine models, introduce new consumption measures or create a different commercial structure.
That decision will have ramifications. The technical architecture expands what Z can run. The pricing architecture will determine how much economic alpha IBM captures.
IBM may trade some software exclusivity for greater platform relevance
There is also a strategic tradeoff that IBM doesn’t openly discuss.
Supporting Arm-native open-source databases, messaging systems and infrastructure tools could introduce more competition inside the IBM environment. A customer that can run PostgreSQL, MongoDB, Kafka-compatible software or other Arm-native products on Z may have less need for an IBM-specific alternative.
In our view, this is a logical trade for IBM. We believe the company is willing to accept more software choice to preserve and grow the relevance of the underlying platform; which will expand the market. IBM is comfortable with its leadership position in this space, making this a rational decision.
The greater strategic risk is not that an enterprise chooses an open-source database on Z. It is that the enterprise moves the surrounding application, data and operational stack away from Z because its preferred software is easier to deploy elsewhere.
IBM is choosing platform participation over instruction-set purity. Put differently, it is better for IBM to host an Arm binary on a Z system than to force that workload—and perhaps its associated data—onto an external platform.
This reflects a broader change in IBM’s value proposition. The company is betting that customers will continue to pay for Z’s resilience, security, transaction performance and operational controls even when the software running above the system is not exclusive to IBM.
This is probably a decent bet.
From manufacturing Arm technology to hosting the Arm ecosystem
The historical context makes this announcement even more interesting.
IBM once controlled nearly every layer of the computing stack. System/360 established the concept of a compatible computer family in 1964, allowing customers to move between systems while preserving their software investment. That emphasis on architectural continuity remains central to IBM Z.
IBM was also one of the semiconductor industry’s most important process and manufacturing innovators. Its introduction of copper interconnect into production in 1997 helped address the performance and power limits of aluminum wiring and demonstrated IBM’s ability to connect semiconductor advances directly to system design.
The company later withdrew from volume logic manufacturing. In 2014, IBM agreed to transfer its commercial semiconductor technology business and fabs to GlobalFoundries. But IBM retained major capabilities in semiconductor research, processor architecture, packaging, Power, Z and AI acceleration.
IBM’s earlier work with Arm reflected its old manufacturing role. Beginning in the late 2000s, IBM and Arm worked to optimize Arm processor and physical IP for IBM-aligned 32-nanometer, 28-nanometer and planned 14-nanometer processes. IBM provided process technology, physical-design enablement and manufacturing access. Arm provided processor architecture and implementation IP.
The new relationship operates at a different layer.
Then, IBM helped make Arm-based chips viable on IBM manufacturing processes.
Now, IBM is trying to make Arm-based software viable inside IBM enterprise systems.
The common thread is IBM’s preference for co-optimizing across multiple layers. The layers have changed from transistor, physical library and manufacturing technology to instruction sets, virtualization, system architecture, AI acceleration, security and operational resilience.
This is also evidence that IBM remains capable of meaningful silicon and system innovation even though it no longer owns a leading-edge volume foundry. It is also likely that IBM will continue to assist Samsung. Remember, IBM has bolstered Samsung Foundry’s technological edge and market credibility by co-developing next-generation transistor architectures, including GAA nanosheet and VTFET designs, while validating Samsung’s manufacturing nodes through major production orders for chips like the Telum II and Power11.
One additional thought. One of the subtle signals we’ve picked up may be IBM’s hint of a next-generation Spyre AI accelerator expected over the same two-year horizon as the new processor. IBM provided no specifications, so it is too early to assess its performance or workload scope. But the roadmap suggests that the Arm initiative is about more than software compatibility. The processor already includes integrated inference acceleration for decisions inside the transaction path; Spyre we beleive is positioned to extend that capability to a broader class of enterprise AI workloads. In effect, Arm brings more applications to the platform, while Spyre could give those applications greater access to AI compute close to IBM’s most valuable asset – i.e. the mission-critical data already resident on Z and LinuxONE.
Spyre is the indicator that IBM is not merely opening Z to Arm software; it is preparing Z to become a broader execution environment for mission-critical enterprise AI.
Z remains IBM’s product leadership exception
IBM’s broader history gives this strategy additional weight.
The company once held product leadership across mainframes, distributed systems, storage, databases, middleware and other major categories. Much of that leadership eroded as lower-cost microprocessor systems disrupted the economics of computing and IBM shifted more of its focus toward services.
IBM recovered as a company, but it did not regain undisputed product leadership across every category it once dominated.
Z is the exception.
The mainframe remains the area where IBM defines the architecture, controls the road map and has no like-for-like competitor. It is one of IBM’s most durable businesses and an important anchor for its software economics.
That does not mean Z is immune to spending cycles, execution problems or shifts in customer priorities. The second quarter showed that even a highly defensible franchise can miss expectations. But the underlying market remains unusually stable because the systems support revenue-generating transactions and workloads that enterprises cannot casually replace.
The Arm relationship is best understood as an effort to protect that position over the next decade. As developers, Linux distributions, cloud platforms and AI software increasingly target Arm, IBM does not want the instruction set to become a reason that a workload cannot remain close to the mainframe.
The execution and what to watch
The processor design is ambitious, making commercial outcomes dependent on full-stack execution across several key areas, specifically:
- Software Ecosystem: Success requires major Arm-native infrastructure products certified at launch, whereas disappointment means native execution with minimal production vendor support.
- Operational Parity: Success brings strong isolation, recovery, encryption, and predictable performance, while disappointment exposes management compromises in mixed-architecture environments.
- Red Hat Integration: Success means a consistent lifecycle across Arm, s390x, cloud, and on-premises via RHEL and OpenShift; disappointment means hardware arrives before the management experience is ready.
- Commercial Model: Success highlights pricing that drives net-new workloads onto Z and LinuxONE, whereas complex licensing and metering could severely restrict adoption.
- AI Integration: Success looks like running Arm-native AI close to protected transactional data using IBM acceleration, while disappointment leaves AI confined to demos and press releases with no follow up.
- Customer Behavior: Success is enterprises deploying new data, security, and application services, whereas disappointment limits adoption to legacy compatibility or migration scenarios.
The hardest part will not be decoding two instruction sets. It will be preserving the mainframe’s operational promise across both.
Customers should dig into how mixed workloads are scheduled and isolated, how capacity is managed, how failures are contained, how software is patched, how performance is guaranteed and how IBM will support the complete environment. They will also want evidence that Arm-native applications receive the qualities of service that justify placing them on Z rather than on a less expensive commodity platform.
Action item
AI infrastructure leaders should not treat the IBM Z and LinuxONE dual architecture as a reason to delay current modernization. The processor is approximately two years away, and its value will depend on IBM delivering production-grade operating-system support, Red Hat and OpenShift integration, ISV certification, workload isolation, lifecycle management and a clear commercial model. IBM plans to let Arm-native Linux environments run alongside z/OS and Linux on IBM Z while retaining the platform’s security, reliability and scale, but the announcement remains a roadmap milestone rather than a deployable product.
We believe infrastructure leaders should use this runway to identify Arm-native applications that sit close to mission-critical transactions and data – e.g. security, messaging, observability, data services and AI inference; and determine where native execution could reduce porting work, data movement, latency and operational fragmentation. They should press IBM now for specific software commitments, pricing models, migration tools and reference architectures. The objective is not to replace the mission-critical Z foundation or convert Arm developers into mainframe specialists. It is to let Arm teams bring their most consequential applications to the same trusted platform. If IBM delivers on that promise, Arm will widen the Z moat; if it does not, dual architecture risks becoming an impressive compatibility feature with limited commercial impact.
