What we actually build
Not a report, not a diagram pack, and not a tool you have to operate. A queryable model of your system that other things can be built on.
A benchmark is a complete, structured description of your estate, assembled automatically from the code itself rather than from documentation or interviews.
What goes into it
We read COBOL, JCL and CICS together, as one system. That combination matters more than it sounds. Most analysis tools look at programs and stop, but the difficulty in a mainframe estate is rarely inside a single program. It is in the job network, the transaction state, the dataset that three systems quietly share.
- Programs and their contents: data structures, record layouts, procedures, and the real control and data flow between them
- Batch: job steps, dependencies, datasets and how the night actually runs
- Online: transactions, screens and conversational state
- Data: files, databases, and how information moves between systems
- Architecture: the subsystems, layers and components that emerge from the dependencies rather than from an out-of-date diagram
- Business rules: the logic embedded in the code, isolated and made readable
What comes out of it
Because it is a model rather than a document, you can ask it questions. What depends on this file. What would break if we changed this field. Where this rule is implemented, and in how many places. Which parts of the estate are genuinely complex and which just look intimidating.
Alongside the model you get the derived artifacts: application architecture, data and control flows, extracted business logic, code metrics, quality characteristics such as duplication and complexity, and the architectural anomalies that accumulate over decades.
Why it is built on a standard
The structure is defined by ISO/IEC 19506, the Knowledge Discovery Meta-Model, published by the Object Management Group. It is an international standard for representing existing software systems, and it has been stable for over a decade.
We could have invented our own format. Most vendors in this space did. We think that is the wrong trade for the customer, for three reasons.
You are not locked in. What you receive describes your own systems in a published, documented form. If you replaced us tomorrow, the model would still be readable and still be yours.
It can be consumed by other things. Increasingly that means AI-assisted transformation pipelines, which need resolved facts rather than raw source. A proprietary format would have to be reverse-engineered first.
It is complete enough to be honest. The standard covers code, platform, data, architecture and build. When something is not captured, that is visible rather than hidden, because the schema is public and you can check.
Traceability
Nothing we hand you is an assertion you have to take on faith. It can be followed back to the code that produced it, and for regulated industries that is usually the deciding factor.
Every claim carries its provenance
Each element in the model references the specific line of source it came from, so any finding can be checked rather than believed.
See what a benchmark of your estate would show
A short conversation is usually enough for us to say honestly whether we can help, and roughly what it would take. No obligation either way.