info@benchmarkconsulting.com
What we build

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.