Keeping the Chimney Smoking

A quiet tribute to the modelers and information architects who keep FCO-IM working — day to day, year to year, decade to decade

There is a Dutch saying — de schoorsteen moet roken, "the chimney must keep smoking." It is what you say about the unglamorous, essential work that keeps a household fed and a business running. Not the launch, not the keynote, not the clever idea on a whiteboard — the steady, faithful labour that means the lights are still on next winter.

This article is about the people who keep the chimney smoking for the information side of an organisation: the modelers and information architects who took FCO-IM not as a theory to admire, but as a practice to live by — for years, and sometimes for decades. They rarely get written about. So this is for them.

The method is a safeguard — and someone has to keep it

FCO-IM is, at its heart, a disciplined route from one place to another. It takes you from an interview with a domain expert, to concrete facts in the expert's own words, to fact types, to a fully normalised conceptual model, and from there to whatever artifact the organisation needs — a relational schema, an ontology, a glossary, an API contract.

The beauty of the method is that every step is justified by the previous one. You don't invent entities; you derive them from facts. You don't guess at cardinality; you read it off a concrete population. You don't argue about whether something is an attribute or a relationship; the verbalisation decides. FCO-IM is a safeguard against the most common failure in data modelling: a modeller's untraceable opinions quietly hardening into a schema that nobody can later defend.

But a safeguard is not self-maintaining. The route has to be walked, and then walked again, and kept open when the landscape changes. Knowing the rules of the route is one thing — and a good thing. Keeping the trail intact for the next person who needs it, three years and two reorganisations later, is another thing entirely. That second thing is a craft, and it is the craft this article is about.

The questions that fill a real working life

In a classroom or a conference talk, a model is finished the moment it is correct. In a real organisation, a model is never finished — it is cared for. And the questions that fill a practitioner's working life are almost all questions the theory never has to answer:

• A fact type was created two years ago from an interview. Who said it, and which sentence did it come from? Can you still trace this one element back to its source?
• The business needs a regulatory attribute that has nothing to do with FCO-IM semantics — a sensitivity classification, an owner, a retention period. Where does that live without polluting the conceptual model?
• The same model now has to be published as a relational schema and an ontology and a data-vault design and a glossary, all from one source of definition. How do you keep them in sync when the model changes on a Tuesday?
• Someone arrives with a model from elsewhere — a UML diagram, a SAP catalog, an OWL ontology, a spreadsheet. How do you bring it into FCO-IM without retyping it by hand and losing the thread back to where it came from?
• Five years pass. Which version is in production, which is in review, and what changed between them — element by element?

None of these are FCO-IM theory questions. All of them are the questions that quietly consume the careers of the people who keep the chimney smoking. This is precisely where the method needs a tool built for the long haul — and where the practitioner's quiet expertise lives.

Where the tool carries the load

CaseTalk is the automation of FCO-IM, but "automation" undersells it. The tool is what makes the method survivable over the long horizons that real organisations live on — and what lets one careful modeler do work that would otherwise need a small army and a perfect memory. Four areas carry most of the weight.

1. Metadata and custom attributes

The conceptual model carries the meaning. But governance needs more than meaning: ownership, classifications, lifecycle status, links to external standards. The practitioner needs somewhere to put all of this that does not corrupt the model and does not rot in a spreadsheet beside it.

A tool built for the long game keeps these as first-class custom attributes, attached to model elements through profiles, so the conceptual model stays pure FCO-IM while the governance metadata travels with the element. The method gives you the fact; the tool lets the architect say everything else the enterprise needs to say about that fact, without contaminating the fact itself.

2. Model element lineage and versioning

This is the heart of the matter, and the part the maintainers will recognise most. FCO-IM's promise is traceability: every element justified by a fact, every fact by a verbalisation, every verbalisation by a person who actually said it. But traceability is only real if it persists. A whiteboard loses it the moment the photo is taken.

The tool's job is to make lineage durable — to keep the link from artifact back to model element, back to fact type, back to the original sentence, and to keep that link stable across versions. Stable identifiers are not a glamorous feature, but they are the difference between a model you can still audit a decade later and a pile of diagrams nobody trusts. When a modeler can answer "where did this column come from?" by following it all the way back to something a domain expert said in an interview in 2019 — that is FCO-IM keeping its promise, and a practitioner keeping faith with it.

3. Model publishing and transformations

A conceptual model has no value sitting still. Its value is realised when it becomes the artifacts other people consume — relational schemas, ontologies, exchange formats, glossaries, documentation, data-vault designs, catalog definitions. The theory says these transformations are possible because the model is normalised and unambiguous. The tool is what makes them repeatable and re-runnable when the model changes.

This is the multiplication step, and it is where one well-tended model quietly does the work of many. One safeguarded conceptual model becomes many downstream representations — each generated, not hand-built; each regenerable when the source updates. The architect who has lived in the tool does this on a Friday afternoon and does it again, identically, after Monday's change request, without drama.

4. Transformations into FCO-IM

Equally important is the reverse direction. The world is full of models that were not built with FCO-IM — UML class diagrams, SAP CSN catalogs, OWL ontologies, Turtle files, spreadsheets, existing schemas. The practitioner's question is never "should they have used FCO-IM?" but "how do I bring what already exists into the method, so it inherits the discipline from here on?"

A serious tool provides bridges that import these as facts and fact types, not as opaque blobs — so imported material becomes traceable, versionable, and republishable like anything else. The method gives you the target shape; the tool gives the architect the on-ramps; the practitioner does the patient work of merging the old world into the disciplined one.

Day to day, year to year, decade to decade

The phrase that captures the whole tribute is day to day, year to year, decade to decade — three timescales, each demanding something different.

Day to day, the tool makes the method easy — so the modeler actually follows the steps instead of cutting corners under deadline pressure. The discipline a theorist admires in the abstract is the discipline a working modeler will quietly abandon unless the tool makes the correct path the easiest path. Good tooling protects good practice from the ordinary erosion of a busy week.

Year to year, the tool makes the work traceable and manageable — versions, lineage, governance metadata, regeneration. This is the timescale at which untended FCO-IM silently dies: not through any flaw in the theory, but through the ordinary entropy of people leaving, requirements shifting, and diagrams drifting out of sync with reality. The architects who keep this from happening are doing real, skilled work, even when nobody notices because nothing broke.

Decade to decade, the tool — and the people minding it — are the only reason the model still means anything. A decade is long enough that every original assumption gets questioned, every source expert moves on, and every downstream system is rebuilt at least once. What survives is the traceable chain — and a chain survives only if something, and someone, has been faithfully maintaining its links the whole time. No human memory does that alone. A tool built for the purpose, in the hands of a modeler who cares, does.

To the ones who kept it smoking

FCO-IM tells you how to build a good model. CaseTalk is how you build it effectively and efficiently — and keep it manageable, so a good model stays good. But neither the method nor the tool keeps the chimney smoking on its own — people do. The modelers and information architects who treated FCO-IM not as a credential but as a daily practice; who kept the lineage intact, the metadata honest, the publications in sync, and the imports disciplined; who came back to the same model year after year and left it better than they found it.

They are rarely the loudest voices in the room. But theirs is the work that means an organisation can still trust, a decade on, that its data means what it says it means.

This one is for them.