The Job Description That Reads Like an FCO-IM Feature List

Something quiet is happening in enterprise job postings. Look at the roles being opened right now for information architecture — the responsibilities read almost like a description of a modelling method invented in the Netherlands in the 1990s.

The specific employer is not the point. The vocabulary is.

Words like: AI-ready, trusted, context-rich, semantically aligned, discoverable, reusable, governed.

Phrases like: business context layer connecting data, knowledge, metadata, taxonomy, ontology, and semantic relationships. Domain-level business semantics — shared definitions, terms, classifications, mappings between business concepts and system representations. AI-ready data with semantic consistency, contextual connectivity, metadata completeness, lineage, and data ownership. FAIR principles. Business glossaries with ontology-backed definitions. Semantic projections into modern platforms — the postings name whichever stack the organisation happens to run.

If you have read anything I have written over the past two years — Against the Stream, Meaning is Not Metadata, What We Lost When Datum Became Data — this language should feel familiar. Not because I invented it, but because a method has been asking these same questions since the 1990s.

It is called FCO-IM: Fully Communication Oriented Information Modelling. Built on Nijssen's earlier work by Bakema, van der Lek, and Zwart. Cited — a bit more so in the Dutch translation — in your DMBOK.

What that vocabulary asks for

Read that list of terms again, this time as a set of requirements. Not one of them is a requirement a tool can satisfy on its own. Every one of them describes work — the work of getting people to agree on what their words mean, and then keeping that agreement. What a method and its tooling can do is make that work tractable, repeatable and auditable instead of heroic.

With that caveat firmly in place, here is how the requirements line up.

• A business context layer that connects data, knowledge, metadata, taxonomy, ontology, and semantic relationships. This is the shape of an FCO-IM model. Verbalised fact types are the semantic backbone — but a modeller has to elicit them, sentence by sentence, from people who know the domain. Once that backbone exists, downstream artefacts are derived from it rather than re-authored beside it: an OWL ontology, a SKOS vocabulary, a business glossary, a graph schema, a relational schema. Deriving them is cheap. Earning the backbone is not.
• Master data, transactional data, analytical data, metadata, business glossary, semantic models, taxonomies, ontology structures, knowledge graph patterns. These need not be separate modelling exercises. They are different projections of the same agreed definitions — so the expensive part happens once and the rest is transformation. The model does not manage your master data. It settles what a master-data record is supposed to mean, which is the argument that usually stalls the programme.
• FAIR data. FAIR is a set of principles an organisation commits to, not a checkbox a tool ticks. But each principle has a modelling dependency. Findable and Interoperable both assume stable, shared definitions and a portable representation. Reusable assumes a single source of definition rather than four drifting copies. A fact-based model gives you a defensible starting position on all four; the governance, the stewardship and the publishing commitments remain yours.
• Semantic consistency, contextual connectivity, metadata completeness, lineage, data ownership, governed reuse. These carry forward through export because everything downstream traces back to a fact type, and that fact type traces back to a sentence a domain expert actually said. That traceability is the mechanism. Somebody still has to hold the review, assign the ownership and decide what "governed" means here.
• AI-assisted and agentic AI capabilities to accelerate metadata curation, semantic modelling, taxonomy development, ontology creation. The tooling that supports FCO-IM ships an MCP server, so an AI agent can read and interrogate the conceptual model directly rather than guessing at a raw schema. Note the order of operations: the agent is useful because humans built something worth reading. Point the same agent at an undocumented database and you get confident nonsense.

Where the honesty belongs

The postings also name platforms, standards and methods — often in one breath. They are not the same kind of thing, and it is worth separating them.

Platforms are targets. A model that has been properly built can generate for the ones the tooling actually supports: Snowflake, BigQuery, Databricks, SAP HANA, Neo4j, TypeDB, plus SQL Server, Oracle and PostgreSQL DDL, and code-side targets such as GraphQL, TypeScript, Kotlin and C#. Other names in the same sentence of a posting — an ontology IDE, an ERP suite, a catalogue there is no connector for — are not targets. They may share a format, which is a different and considerably weaker claim. Where a shared standard exists, OWL for instance, both sides can read it, and that is the whole of the integration.

Standards are agreements to conform to. RDF, OWL, SKOS, SHACL, XSD, ArchiMate, MIM, SBB — a model can be expressed in these, which is genuinely useful, and it is where a fact-based model pays off fastest, because the semantics were explicit to begin with. Conformance is still assessed against the standard, not against the export button.

Methods and architectures — data mesh, domain-driven design, medallion architectures, data contracts, data-product certification, ISO standards — are ways of organising work. No tool implements them. What each of them assumes, and rarely gets, is that somebody has already established what the domain's terms mean. That is the gap a fact-based model fills. It does not replace the method; it supplies the grounded input the method takes for granted.

The observation

The point is not "please, get this tool." The point is different, and more interesting.

For more than twenty years, the term fact-oriented modelling made most enterprise architects glaze over. The vocabulary was too niche, too academic, too Dutch. Modellers who used it published quietly, held small conferences, taught students, and worked inside a small set of enterprises where the method carries measurable weight — ProRail, whose public knowledge base at otl.prorail.nl originates for 86% from FCO-IM models, is just one visible example.

That vocabulary is no longer niche. It has been reformulated, one job posting at a time, into terms the enterprise now recognises: AI-ready context layer, business semantic model, governed reusable data products, ontology-backed business glossary. Same request, different words.

What this means

Two things.

First: if you have been quietly modelling in FCO-IM inside an organisation or enterprise, you are now doing what the industry has been trying — via ontology tools, semantic layers, data catalogues and data mesh — to reach from the other direction. You were ahead. The direction has finally turned right.

Second: if you are the person reading a job posting like this and wondering how to actually deliver on it — the job is still yours. Nobody generates their way out of it. But the work has a shape, and that shape is well understood: get the sentences right first, in language the business recognises, and let everything else be derived from them. That is not a shortcut. It is the difference between having one hard conversation and having the same hard conversation again in every stack.

The industry vocabulary caught up. The method has been ready.