ISO/IEC 19506, in plain terms
The international standard for describing a software system that already exists. Also known as KDM, the Knowledge Discovery Metamodel. This is the structure we build every benchmark on.
Most standards tell you how to build something new. This one does the opposite: it defines how to describe a system that is already running, in enough detail that a machine can reason about it.
The short answer
ISO/IEC 19506 specifies a vocabulary and structure for representing an existing software system as a set of entities and the relationships between them. Not just the code: also the platform it runs on, the data it persists, the screens it presents, the jobs that drive it, the way it is built, and the architecture that emerges from all of that.
It was produced by the Object Management Group as part of its Architecture-Driven Modernization work, then adopted by ISO and IEC. If you have heard it called KDM, that is the same thing.
Why a standard exists for this at all
Because the alternative is what the industry actually has. Every analysis tool invents its own internal representation, so nothing any of them learns about your system can be handed to anything else. You buy a tool, it builds a private picture of your estate, and when the engagement ends the picture leaves with the licence.
A published metamodel breaks that. The description of your system is written in a form that is documented, versioned and readable by anyone, including tools that did not exist when it was produced.
What it actually models
The specification is organised into four layers, containing twelve packages, which between them define nine models. Each area of concern maps to one architectural viewpoint, in the sense used by ISO/IEC/IEEE 42010.
| Layer | Packages | What it covers |
|---|---|---|
| Abstractions | Structure, Conceptual, Build | Subsystems, layers and components; mined business rules; how the system is assembled from source |
| Runtime resources | Platform, UI, Event, Data | Operating environment and its services; screens and their content; events and state; files and databases |
| Program elements | Code, Action | Program structure, data definitions and behaviour. These two jointly define one model, the CodeModel |
| Infrastructure | Core, kdm, Source | The shared patterns the other packages reuse, the extension mechanism, and traceability back to source files |
The idea holding it together is the container: an entity that owns other entities. That one device is why the same system can be described at any granularity, and why an architecture view can be derived from the model rather than drawn by hand and then left to rot.
What it is not
This is the part most summaries skip, and it is the part that matters if you are evaluating tools.
- It is not an abstract syntax tree. KDM sits above the parse tree. Faithful, fine-grained syntax is the job of a sibling OMG standard, ASTM. If a vendor implies that 19506 preserves every syntactic detail of your source, they have the wrong standard in mind.
- It is not executable. The model describes a system; it does not run it and it will not regenerate it.
- It is not a constraint or query language. It defines what can be represented, not how you interrogate it.
- It is not a migration method. It is the substrate a method can be built on. Buying into the standard does not tell you how to move anything.
How to check a compliance claim
Compliance is not a single badge, which is why the claim needs unpacking. The specification defines three levels, and the middle one is claimed per area rather than as a whole.
| Level | Requires |
|---|---|
| L0 | Full support for Core, kdm, Source, Code and Action. In practice: inventory and code. This is the entry level and the common denominator for interoperability. |
| L1 | L0, plus full support for one further area and its semantic constraints. Claimed per domain, so "L1 compliant" is an incomplete statement until someone says which domain. |
| L2 | L1 for every domain. |
There is a second axis. Each level can be claimed for import and analysis, for an import API, or for export. A tool that can export the format is making a much weaker claim than one that can consume and reason over it.
Two questions worth asking any vendor: at which level, and for which domains? And is that for import, for export, or both? Precise answers are a good sign. Vague ones usually mean a partial export written to satisfy a procurement checkbox.
Versions, because they are genuinely confusing
Three numbers circulate and they are not interchangeable.
- ISO/IEC 19506:2012 is the ISO edition. It corresponds to OMG KDM version 1.3.
- OMG KDM 1.4 is the current OMG revision, published as
formal/2016-09-01. It is one revision ahead of the ISO text. - The machine-readable schemas carry their own namespace date, which is not the same as either version number.
So a tool can be accurate in claiming conformance to ISO/IEC 19506 while implementing KDM 1.3, and equally accurate in claiming KDM 1.4. Neither is wrong. It is worth knowing which you are being offered.
What it sits alongside
19506 does not stand on its own. It is defined using MOF (ISO/IEC 19508) and exchanged as XMI (ISO/IEC 19509), which is why the output is ordinary XML that any toolchain can read. ASTM covers the syntax detail below it. The business rule side aligns with SBVR, so recovered logic can be expressed in something a business analyst can actually read.
Where we sit
We build every benchmark to this structure. That is a deliberate constraint on ourselves, and it costs us something: a proprietary format would be easier to write and would make us harder to replace.
We think that trade is wrong for the client. What you receive describes your own systems in a published form. It can be consumed by tools we have never seen, including the AI-assisted pipelines now being pointed at legacy estates, which need resolved facts rather than raw source. And because the schema is public, when something is not captured that gap is visible rather than hidden.
Honest about the edges
Parts of the published schema set have gaps of their own, including two package schemas that have long been unavailable at their canonical addresses. Anyone who has actually implemented this knows it. We work from the normative model where that happens, and we will tell you which parts of your estate the standard does not reach.
Reading the source material
The specification is public. OMG publishes KDM at omg.org/spec/KDM, and the ISO edition is catalogued as ISO/IEC 19506:2012. It is long and it is written for implementers, but it is not secret, and nothing on this page requires you to take our word for it.
Want to see this applied to your estate?
We can show you what a benchmark of one of your applications would contain, and how much of it the standard covers, before you commit to anything.