Managing the Assets: Catalogue, Inventory, and the Case Against Consolidation
An amorphic system doesn’t work on faith. Before it can form a workflow to achieve an outcome, it has to answer two quite different questions: what kinds of things could I use, and what actually exists, at this point in time, that I can use. Most organisations may already have technology which can help answer both of these questions, though rarely connected, and rarely recognised as part of the same problem.
This is the piece the first article left aside. Amorphic Systems assumed a catalogue of resolvable assets: identities, qualifiers, a palette to compose from. A fair assumption to make, though it leaves open where that catalogue actually comes from. It likely exists already, in fragments, across the systems an organisation runs today.
If you are not yet a member of Medium.
Two Different Things, Often Confused
Consider books and libraries in your region. Somewhere in the library system is a catalogue: this book exists, here is its title, its author, its edition, its ISBN. The catalogue doesn’t record whether a copy is sitting on a shelf anywhere. It records what the book is.
Separately, each branch holds an inventory: the physical copies, their location, whether they are checked out, which edition is on the shelf at this moment. The inventory doesn’t define what a book is. It records what exists, at a location, at this moment in time.
In a library, this distinction is intuitive. In technology, the two questions are often blurred. Ask “do we have that dataset?” and the answer may quietly conflate “yes, there is a schema for it” with “yes, there is a live table with data less than a day old.” Ask “do we support that API?” and the answer may describe the interface specification, without clarifying which environments have it deployed and healthy at this point in time.
Separating the two questions makes the pattern useful:
Catalogue — the specification. Identity, contract, version, shape. What a thing is, independent of where it is running.
Inventory — the manifestation. The instances which exist, their location, their state. What is present, right now, at a location.
A schema registry exposes catalogue aspects. A list of running pods in a cluster exposes inventory aspects. A Maven artifact’s group, artifact and version coordinate exposes a catalogue aspect. The jar sitting in a specific repository, deployed to a specific environment, exposes an inventory aspect. Neither is more authoritative than the other. They simply answer different questions, and an amorphic system requires both to compose anything.
The Instinct to Consolidate, and Why It Fails
Once this split is noticed, the natural next step is tempting: build one system to hold everything. A single registry, a single source of truth, catalogue and inventory unified, every team required to register through it.
This has been attempted many times, and tends to fail in a fairly predictable way. A central registry will lag behind reality, someone provisions an instance, ships a new schema version, or decommissions a service, and the registry becomes stale, often within a day. To keep it current requires governance over the registry itself, who is permitted to register, who approves changes, who owns the taxonomy. This introduces a second layer of meta-metadata, which then requires its own stewardship, its own backlog, its own review process. The governance burden does not disappear, it simply relocates one level up, and slows down in the process.
Get Stephen James Price’s stories in your inbox
Join Medium for free to get updates from this writer.
Consolidation also assumes a single ontology can describe everything worth cataloguing, indefinitely. It cannot. The way a dataset is classified for a compliance team, and the way it is classified for a machine learning pipeline, may legitimately differ. Forcing both into one shared schema tends to either lose information or produce something too unwieldy to extend safely.
Composition Over Consolidation
The alternative is to stop attempting to build one single thing. Most organisations may already run several systems exposing catalogue aspects and inventory aspects: a schema registry, a package repository, a service mesh, an identity and access management system, a fleet of storage buckets, a configuration management database, a container orchestrator’s internal state. Each of these already answers its own slice of the question reasonably well.
The task is to make these systems addressable to each other, rather than replacing them. A request for “what exists that matches this specification” should be resolvable by consulting the catalogue for the specification, then consulting the relevant inventory or inventories for manifestations which satisfy it, without either needing to understand the other’s internal structure. Nothing needs to be removed for it to begin working.
What Makes Something Addressable
The pattern which enables this collaboration is not complex, and is already familiar from build tooling. Take Maven as an example: a dependency is addressed by group, artifact and version, org.example:widget-lib:1.2.0. That coordinate is a catalogue entry. It does not indicate where the jar physically resides, it indicates, unambiguously, what is being requested.
Resolving that coordinate against a specific repository (Nexus, Artifactory, or a local .m2 cache) produces a location. That location is the manifestation, the inventory answer. The same coordinate, resolved against different repositories, may return different physical jars, though the identity remains constant. This is the underlying pattern: identity, locator, qualifier. The identity describes what is meant. The locator describes where to look. The qualifier narrows the request, this version, this classifier, this platform build.
Similar thoughts are in Package URL (PURL) applied for the package ecosystems. The jar above can be written as pkg:maven/org.example/widget-lib@1.2.0?classifier=sources. Everything after the ? is a qualifier, narrowing the request to one variant of the package without changing which package is meant. PURL also defines a repository_urlqualifier, so a hint about where to look can travel inside the address itself.
This pattern is not limited to software libraries. A dataset can be addressed in the same way, an identity for the schema and version, a locator describing which store to consult, qualifiers for partition, freshness, or region. A service can be addressed in the same way, an identity for the contract, a locator for the mesh or registry to query, qualifiers for environment or SLA tier. The mechanics of resolution will differ between systems, though the shape of the address does not need to.
Start Today
None of this requires waiting for a platform team to deliver a unified catalogue. It requires identifying one system already in place (a schema registry, a service mesh, whichever is closest at hand) and describing what it holds using identity, locator, and qualifier, consistently. A second system can then follow the same approach. Each system addressed in this way is useful on its own, and becomes more useful as further systems join it. It can be adopted one connection at a time.
The Collapse
Once several of these are in place, it becomes clear that catalogue and inventory were never truly two separate systems. They are two aspects of the same asset, viewed from different angles. A specification is an asset carrying a catalogue aspect of metadata, identity, contract, version. A running instance is the same asset carrying an inventory aspect of metadata: location, state, health. Neither is the definitive record, both are simply metadata attached to the same addressable thing, and which one is consulted depends on the question being asked.
Once addressing is consistent, the distinction stops being structural, and becomes a lens. There is one class of addressable thing, an asset, where the metadata are different aspects be that catalogue, inventory or others. The extensions are composed on to the asset as required, without either being forced to model the other’s concerns. This is what makes an asset genuinely ready for an amorphic system, it makes little difference whether it is approached as a specification or a manifestation. Underneath, it was always a single asset carrying different aspects of metadata.
Composed aspects still need a way to travel together, between systems, between requests, alongside whatever payload they describe, without forcing every consumer to understand all of them at once. That is a separate question, and worth its own piece.
Close
There is little value in building the cathedral. A single registry to govern everything is not required, and attempting to build one is a common way for these efforts to stall. The more productive path is to start with what already exists, make it addressable, allow the systems to collaborate rather than merge, and allow catalogue and inventory to reveal themselves, over time, as the same idea observed from two perspectives.
