The problem

Financial-services firms run large Windows compute grids for risk and pricing workloads — IBM Spectrum Symphony is reported in use at a majority of the top 20 banks (community/secondary-source reporting, not independently verified here). These grids share three problems, and every modernisation path a platform team reaches for next threatens the one thing that makes them auditable: ISV support.

Three problems, one estate

Static capacity. Compute hosts are provisioned once, for a peak that is rarely sustained. There is no elastic burst path without an application rewrite — capacity is whatever was racked, not whatever the workload needs this week.
Hardware refresh cycles. Every host is a pet on a depreciation schedule. Scaling means a procurement cycle, not a config change.
Hypervisor licensing volatility. VMware, the dominant virtualization layer under these estates, ended perpetual licensing in favor of subscription-only bundled SKUs following Broadcom’s November 2023 acquisition close (fully in effect by February 2024), with documented enterprise renewal increases of 150-500% and a restructured, narrower partner (VCSP) program (cio.com).

The 72-core hedge: a live-but-reversed data point

Trade press also reported a proposed increase of the minimum per-host core-license purchase from 16 to 72 cores, effective April 2025. Broadcom denied officially announcing it and the change was not implemented — the 16-core minimum remains current as of this writing. This document treats the 72-core figure as a live-but-reversed data point, not a settled fact, when read forward in time. It is included precisely because it did not stick: it is the shape of the volatility this design exits, not a number to plan capacity against.

The ISV-support trap

Every obvious next move a platform team reaches for trades away the one property that keeps these grids auditable:

Move	What it costs
Containerize the workload	Trades away ISV support — repackaging Symphony into containers it was never certified for. Windows Server Containers share the host kernel and are explicitly "not intended to be used in hostile multitenancy scenarios," a direct conflict with Symphony’s multi-user grid model (see ADR 0001).
Repackage onto a cloud-native scheduler	Trades away the vendor to call when it breaks. A Kubernetes-native batch/HPC replacement is a multi-year rewrite risk, not a modernisation of what already exists.
Lift the same static estate to new hardware	Trades away nothing about the pain — same pets, same refresh cycle, new depreciation schedule.

Move

What it costs

Containerize the workload

Trades away ISV support — repackaging Symphony into containers it was never certified for. Windows Server Containers share the host kernel and are explicitly "not intended to be used in hostile multitenancy scenarios," a direct conflict with Symphony’s multi-user grid model (see ADR 0001).

Repackage onto a cloud-native scheduler

Trades away the vendor to call when it breaks. A Kubernetes-native batch/HPC replacement is a multi-year rewrite risk, not a modernisation of what already exists.

Lift the same static estate to new hardware

Trades away nothing about the pain — same pets, same refresh cycle, new depreciation schedule.

Each path forces a choice between workload fidelity and a vendor to call. The opportunity is a platform that does not force that trade: run containers and VMs side by side under one control plane, so the grid does not have to choose between modernising and staying supported.

Modernise the platform, not the workload.

That is the design target this whole reference architecture is built to hit — change the substrate under Symphony, change nothing IBM certifies about Symphony itself.

Continue to The solution.