Tagged Values Are Your Portal's Metadata

Publication exposes your metamodel

Inside the modelling tool, inconsistent tagged values are survivable. An architect looking at an element sees Owner on one and owner on another and mentally treats them as the same thing. The tool does not care, and neither does anyone else, because nobody is aggregating across elements.

Publish the repository and that changes immediately. A catalogue view aggregates: it produces one column per key, and now Owner, owner and OWNER are three columns, each about a third full. The inconsistency was always there; publication is just the first time anyone had to look at it side by side.

Design for the column, not the element

The shift in thinking is small and changes most decisions. When you add a tagged value, do not ask "what do I want to record about this element". Ask "what column do I want to be able to sort, filter and spot gaps in across two thousand elements".

That reframing kills a lot of well-intentioned metadata. Free-text Notes2 makes a useless column. Criticality with values drawn from an agreed list of four makes an excellent one.

The rules that matter

One key, spelled one way

Case, spacing and singular/plural all create distinct keys. Agree the spelling and enforce it — a validation rule that fails the build on an unknown key is not excessive once you have been through one cleanup.

Closed vocabularies wherever possible

Lifecycle = Invest | Maintain | Tolerate | Eliminate is filterable. Lifecycle = "being phased out over 2027 probably" is prose in a column. If a value cannot be one of a known set, it probably belongs in the element's documentation instead.

Dates in one format

ReviewDate is one of the most valuable columns a portal can carry — it lets a reader see at a glance whether they are looking at something maintained or abandoned. It is worth nothing if half the values are 2026-12-15 and half are Dec 2026, because you cannot sort them.

The keys worth having

A small set covers most of what readers ask, and each earns its place by answering a question that arrives repeatedly:

Note what is not on the list. Anything you can derive — element type, package path, relationship counts — does not need a tagged value; the portal already knows it. Duplicating derivable facts into metadata is a reliable way to create contradictions.

Gaps are the deliverable

The most useful thing a published catalogue does in its first month is not answer questions. It is show you that 40% of your applications have no owner recorded.

That is uncomfortable and it is the point. An empty cell in a published table is visible to the person who could fill it, which a blank field inside a modelling tool never was. Teams that treat the first published catalogue as a to-do list rather than an embarrassment get their metadata consistent within a quarter.

Retrofitting consistency

Most teams arrive at this article with the inconsistency already present across a few thousand elements. Advice about designing keys well is not much use at that point, so: how do you clean it up without a project nobody has time for?

1. Count first. Produce a frequency list of every key in the repository. It is usually shorter than people fear and the long tail is usually single-use keys created by one person once.
2. Pick the canonical spelling for the ones that matter — typically five to eight keys — and leave the tail alone.
3. Migrate mechanically. A script that renames owner to Owner across the model is an afternoon, not a project.
4. Add validation the same week. Otherwise the inconsistency returns within two months and the cleanup was wasted.

Who maintains this

Metadata decays because nobody owns it. The pattern that works is to attach maintenance to something people already do rather than creating a new obligation.

The natural hook is review. If an element has a ReviewDate, the review is the moment its other metadata gets checked. That gives you a rolling, distributed cleanup with no separate initiative, and it fails visibly — an element whose review date has passed is a query away.

Controlled values, and why free text loses

The decision that determines whether a property is useful is made before anyone populates it: whether the values come from a list or from a text box.

Free text is faster to set up and produces a column that cannot be filtered. An estate with lifecycle values of Live, live, Production, In Production and PROD has five values that mean one thing, and every filter built on it is wrong in a way that looks right.

The cost of controlled values is a governance conversation each time someone needs a value that is not there, and that conversation is the point. Most requests for a new value are actually a request to record something the property was not meant for, and refusing them is what keeps the column meaningful.

Where the modelling tool cannot enforce a list, the fallback is validation that runs before publication and reports non-conforming values. Weaker, and enough — as long as somebody reads the report.

Properties that should not exist

Metamodels accumulate properties the way drawers accumulate cables. Three kinds are worth actively removing.

• Properties that duplicate a relationship. A text field naming the system an application talks to, when a relationship already records it. The field will drift from the relationship and someone will build a report on the wrong one.
• Properties that belong to another system. Licence counts, support contract dates, server hostnames. They change on a different cadence, they have an owner elsewhere, and copying them into the architecture makes the architecture wrong.
• Properties nobody filters or displays. If it appears in no catalogue and no filter, it is a note, and notes belong in the documentation field.

Removing a property is harder than adding one, which is the entire problem. The annual review that lists every property with a population count is what makes removal possible, because a property populated on 3% of elements after two years is not going to recover.

Populating a column that starts empty

Introducing a mandatory property to an established estate produces a conformance report with four hundred entries and no realistic path to clearing it. The report is then ignored, and after a month so is every other report.

What works is scoping the backfill to something achievable and visible. Not the whole estate — the applications marked business-critical, or one domain, or the fifty elements that appear in the published catalogue. Complete that, publish it, and the completion percentage on the portal becomes the argument for the next tranche.

The alternative that also works, and is unpopular, is to accept the property will only ever be populated going forward and to say so. A column that is complete for everything touched since March is honest and usable if the portal says that is what it is. A column that is 40% complete for unstated reasons is neither.

Where the values should actually come from

The most reliable properties are the ones nobody types. Anything maintained by hand in a modelling tool drifts, because updating it is somebody's tenth priority and there is no feedback when it is wrong.

Two properties in a typical estate have an authoritative source elsewhere: lifecycle status often lives in a portfolio or service management tool, and hosting location lives in whatever the cloud estate is inventoried by. Importing these on a schedule is more work than typing them once and far less work than maintaining them forever.

The rule worth applying: for each property, name the system of record. If the answer is "the architecture model", someone has to own keeping it right. If the answer is another system, import it and never let anyone edit it in the model, because a field that can be edited in two places will be.

Making properties visible in the portal

A property that is populated and invisible does no work. The default rendering — a list of key-value pairs at the bottom of an element page — is where properties go to be ignored.

The versions that get used are the ones that appear where a reader is already looking. As a column in a catalogue, so it can be sorted and filtered. As a filter facet, so it narrows a search. As a badge next to the element name, for the two or three properties that change how you read everything else — criticality and lifecycle usually qualify, and almost nothing else does.

A property worth rendering as a badge is a property worth making mandatory. If it is not worth a badge, it probably does not need to be mandatory either, and that symmetry is a useful check on a metamodel that has been growing.

Naming keys so they survive

Property keys become part of every downstream artefact: catalogue column headings, filter parameters, export column names, and any script anyone writes. Renaming one is a breaking change that arrives without warning, so the naming deserves more thought than it gets.

Three rules cover it. Use the concept, not the current organisational term — owner rather than service_line_lead, because service lines will be reorganised. Avoid encoding the value type in the key. And pick one convention for word separation and casing across the whole estate, because a mixture guarantees that every script contains a lookup table.

Where a key does have to change, keep the old one populated in parallel for a cycle rather than renaming in place. It costs a little duplication and it means nothing breaks silently on the day of the change.

The metamodel review that keeps this honest

Everything above decays without one recurring activity: an annual look at every property in use, with three numbers next to each.

Population — what proportion of applicable elements have a value. Distinct values — which reveals free-text drift instantly, because a controlled property with forty distinct values is not controlled. And usage — whether the property appears in any published catalogue, filter or report.

A property that is well populated, has few distinct values and appears in a published artefact is working. A property failing any one of the three is a candidate for either fixing or deleting, and the review exists to force that choice rather than to record the numbers. Without it, the metamodel only ever grows, and every catalogue built on it gets a little less trustworthy each year.

The properties an auditor will ask for

Most property design is driven by what architects find useful. A different and shorter list is driven by what someone external will ask for, and it is worth having because those requests arrive with deadlines.

Three come up repeatedly. Whether a system processes personal data, which decides its scope for data protection questions. Where it is hosted, which decides residency questions. And who owns it, which decides who has to answer everything else.

None of these is exotic and all three are frequently absent, because they are not what an architect needs to model a landscape. Adding them early costs three properties in the metamodel; adding them under a deadline means chasing four hundred elements in a fortnight, which is the situation they exist to prevent.

Five keys to start with tomorrow

For the practice that wants the benefit without a metamodel workshop, here is the minimal set that earns portal columns immediately, with the controlled values that make each one aggregatable:

Five keys, four of them from closed lists, populated first on the elements the executive perspective shows — the couple of dozen that matter most — and then outward as the gap columns apply their gentle pressure. Resist adding a sixth until all five sit above ninety per cent populated on published elements; a metamodel earns extensions with coverage, not with ambition.

The quiet property of this particular five: together they answer the first question every governance function asks of an architecture practice — what do you have, who owns it, how much does it matter, what data does it touch, and when did someone last check. A practice that can answer that from a generated table, for its whole published estate, has crossed the line from maintaining models to operating an asset register — and it crossed it with five keys and some discipline, which is a better origin story than most asset registers can claim.

Metadata discipline is the least visible investment in the whole publication stack and the one the readers touch most — every filter, every column, every catalogue row is a tagged value keeping its promise. Five keys, controlled values and a gap report: that is the entire machinery, and it turns a modelling habit into an asset register the organisation can actually run on.