Topaz Workbench: licensed by the seat, not the engine.

Topaz Workbench is the modern, Eclipse based development environment from the Compuware line, now branded within BMC AMI DevX following BMC's acquisition of Compuware. It gives mainframe developers a single graphical front end across editing, debugging, data management, and analysis, integrating tools such as Xpediter, Abend-AID, and File-AID, and acting as the workbench for ISPW source control. It is built to let staff without deep green screen experience work productively on z/OS applications, which is much of its commercial appeal. It is a development time tool: the value, and the licensing, sit with the developers who use it, not the workloads they build.

Topaz Workbench is typically licensed on a seat or user basis for developers, administered through Compuware Enterprise Services (CES). A developer checks out a license to enable functionality for a defined period, and entitlements can be managed as named or concurrent depending on the agreement. Because it is a development time tool, the cost tracks the number of developer seats and the modules enabled, not the MSU capacity of the LPAR. Confirm the precise user definition in your schedule, named, authorized, or concurrent, because the difference is a real number at renewal and the CES records are the evidence base for any true up.

Pull the CES report of provisioned versus actively used seats before renewal; it is the cleanest evidence of what you really need.

The primary driver is the developer seat count, however the contract defines a user. The second is module breadth: Topaz fronts a stack of capabilities, and entitlements for analysis, data, or test functions enabled beyond active use extend the bill. The third is concurrency model: named seats and concurrent seats price differently, and a workforce that peaks below its headcount can sometimes be served by fewer concurrent licenses than named ones. None of these track mainframe capacity, so a frame upgrade does not move Topaz cost on its own, which is worth confirming rather than assuming on a portfolio where most other lines are capacity priced.

Topaz exposure comes from seats and modules, not capacity. Common traps we see at pattern level:

Seat priced tooling rewards reconciliation and portfolio framing. The five levers that pay:

Topaz competes with IBM's developer tooling, notably IBM Developer for z/OS and the Wazi and z/OS modernization stack, and with open Eclipse and VS Code based mainframe extensions such as Zowe driven environments. Switching a developer environment is more feasible than replacing a runtime, but it still carries retraining, workflow disruption, and integration cost, so it is rarely a pure cost play. The alternative is most valuable as leverage: a credible evaluation of IBM or open tooling, especially where a modernization program is already running, disciplines the renewal. The usual outcome is a better Topaz deal, framed against a genuine option.