One description of the whole estate
COBOL, PL/I and assembler merge into one queryable fact graph. The description is a build output you re-run and compare, not a consulting document that drifts.
Know what the estate is, and where it divides.
A modernisation programme depends on one question: do you actually know what the estate is? Most programmes answer it with workshops and spreadsheets. Cobra answers it with a machine-checked description, read from the code, that your architects can open in the tools they already use. A whole estate of nearly 4,000 programs exports and validates in about a minute.
The description
One fact graph, checked by machine.
Every fact carries its evidence
Each element is marked as read from source, derived from a stated assumption, or not determinable. Where the analysis cannot see, it says so and does not guess.
Gates that can fail
Nine conformance gates check every export. Each gate ships with a deliberately broken export that must fail it, so a passing build means something.
Your tools, not ours
The same facts, in five open standards.
Each export is validated against its own schema at estate scale, not on a test fixture.
Export
Structurizr / C4
Architecture diagrams
Export
ArchiMate 3
Your enterprise-architecture repository
Export
BPMN 2.0
The batch day, as a process
Export
DMN 1.4
Mined decision tables
Export
SCIP
Code navigation in the editor
The decomposition question
The code divides. The data does not.
Most estates are decomposed by grouping the batch jobs that share a dataset. A system that runs one nightly job in stages returns one group holding everything. Cobra follows every call from every transaction program instead, and records the record types each one reads and writes.
Read this diagram as text
- The code divides. Programs group cleanly into business capabilities such as billing, claims and policy.
- The data does not. Some record types are written by more than one capability. On one measured estate, 123 of 198 record types are written by two capabilities or more.
- So the data is sliced where it can be, and replicated where it cannot. A slice takes the records it owns. Records it shares with capabilities that stay behind are kept in step by data replication tooling.
The finding is consistent across the estates measured, and it is the one a programme most needs early. Sub-programs mostly belong to a single capability. Records do not: on one estate, 123 of 198 record types are written by two capabilities or more. A decomposition is a data-ownership problem before it is a code problem, and the analysis names the records that have to find an owner.
It also reads two kinds of dependency that a reading of the code alone cannot see: what the database configures, so that a capability that is switched off is not mistaken for one that is dead; and the estate’s own future-dated scheduling, where a write in one capability triggers a transaction in another on a later date.
The workbench
From a map to a unit of work.
Three tools turn the description into something a delivery team can act on.
Census
Classifies every program in the estate, so the plan starts from a complete count and not a sample.
Coupling prover
Says which serial batch loops are safe to run in parallel. It errs on the side of caution: where it cannot prove a loop safe, it refuses.
Seam carver
Extracts a proven unit behind a generated contract, with a map back to the original lines. The carved units are COBOL, compiled by the Rocket COBOL compiler, and each is run twice and compared byte for byte.
See your estate
Ask where your system divides.
Bring the source for one system. We will export the description, open it in the tools your architects use, and show you what each division would have to cut.