What Belongs in a Technology Registry, and What Does Not
Most estate inventories fail because they try to record everything. The ones that survive are ruthless about scope, and the test for whether a field earns its place is simpler than it looks.
Every organisation has tried to build one. A single list of the platforms it runs, who owns them, what version they are on, and what depends on what.
Most of them work for a quarter.
The failure is rarely the tool. Spreadsheets, wikis, CMDBs and purpose-built registers all fail in roughly the same way and for the same reason: the register was scoped by what could be collected rather than by what would be used. Someone exported everything available, added columns for everything anyone asked about, and circulated it. Six months later a third of the fields are stale, nobody trusts any of them, and the register has quietly become a thing people work around.
Scope is the whole discipline. So it is worth being precise about what earns a place.
Two tests
A field belongs in the registry if it passes both of these.
Something keeps it current. Not someone: something. A field maintained by an agent, an integration, or a workflow that people already have to complete for another reason will stay accurate. A field that depends on somebody remembering to update it after a change will be wrong within two quarters, and a field that is sometimes wrong is worse than a field that is absent, because absent fields do not mislead anyone.
A decision depends on it. Name the decision. If the honest answer is “it might be useful one day”, it will not be, and it will cost maintenance every day until someone deletes it. Registers do not collapse under the weight of the fields people use. They collapse under the weight of the ones they do not.
Applied properly, these two tests remove most of what people instinctively want to record.
What belongs
The distinction between a type and an instance. This is the structural decision that everything else rests on, and it is the one most often missed. A platform type such as IMS, EPC, 5G Core or an SDN controller is defined once, with its structure, its typical dependencies and its lifecycle characteristics. Every deployed instance inherits that definition. Without the split, the same platform is described eleven slightly different ways across eleven records, and no question can be answered across the estate without reconciling them first.
Instance identity. Vendor, software version, environment, operational status, criticality. These are the fields every subsequent question routes through, and they are cheap to keep accurate because they change through processes that are already governed.
Lifecycle dates at the component version level. General availability, end of sale, end of support, end of life. Not against the platform in the abstract, but against the specific version deployed, because that is the granularity the risk actually has. A registry that records “Nokia IMS” without the release is not able to tell you anything about exposure.
Dependencies, recorded in both directions. What this platform needs, and what needs this platform. One direction is a diagram. Both directions are impact analysis. The asymmetry matters: the question asked in an incident is almost always the reverse of the one recorded during design.
Ownership. A named team, and preferably a named person, with a cost centre attached. Ownership is what converts a finding into an action. Without it, everything the register surfaces goes into a queue belonging to nobody.
The joins. Where the platform physically runs, what it costs, and which projects touch it. Not copies of that data: the joins to it. A registry that connects to the asset record, the support contract and the project portfolio can answer questions none of those systems can answer alone.
What does not
Anything with no owner for its accuracy. The rule holds regardless of how useful the field would be if it were correct. Usefulness is not the test; maintainability is.
Point-in-time operational metrics. CPU utilisation, memory, current throughput. These belong in monitoring. A registry describes what exists and what is true about it structurally. The moment it starts carrying values that change by the minute, it is competing with a system that does that job properly and losing.
Data with a system of record elsewhere. Purchase orders belong to finance. Headcount belongs to HR. Ticket history belongs in the service desk. Copy any of it into the registry and you have created a second version that will diverge from the first, and a reconciliation task nobody asked for. Reference it instead.
Documents, as opposed to links to documents. Floor plans, electrical schematics, architecture diagrams and runbooks should be linked from the record, not reproduced in it. The link stays true when the document is revised. A summary pasted into a field does not.
Free text standing in for structure. A notes field is where a registry goes to die. Every unstructured note is a field somebody needed and could not find, and it is invisible to every query you will later want to run. When notes start accumulating, that is not a documentation problem. It is a signal that the model is missing something, and the right response is to add the field.
Things you will never act on. This is the uncomfortable one, because it usually means deleting a column somebody fought for. If no decision changes based on the value, it is costing maintenance and returning nothing.
Why the discipline holds
A registry earns trust slowly and loses it all at once. The first time someone checks a field, finds it wrong, and mentions it in a meeting, every other field becomes suspect, including the ones that were right.
That is why scope is not a matter of taste. A smaller register that is true is more useful than a comprehensive one that is approximately true, because only the first can be relied on without checking. And a register nobody checks against reality is the one that quietly gets replaced by a spreadsheet on somebody’s desktop, which is where this always started.
Record less. Keep it current. Connect it to the things that make it answer questions.
DemandFlow holds the technology registry as platform types and deployed instances, with lifecycle dates at the component version level and dependencies recorded in both directions. Platform lifecycle management covers the estate view, and network asset management extends the same model down to the rack, the port and the addressing.
