TM Forum's Open APIs and a graph topology model are often discussed as competing approaches to network inventory. They are not. They answer different questions, and an inventory platform that adopts one without the other ends up unable to do something important.
TMF639 Resource Inventory Management defines how to ask for a resource and what comes back. It does not define how to answer which customers lose service if a particular line card fails. The first is a contract; the second is a computation.
What the Contract Gives You
The TMF inventory APIs — TMF639 for resources, TMF638 for services, TMF637 for product inventory, with TMF634 and TMF633 covering the resource and service catalogues — standardise resource types, attribute names, lifecycle states, event structures, pagination and filtering. They inherit their structure from the SID information framework published as GB922, including its central Customer-Facing and Resource-Facing Service distinction.
This matters more than it sounds. TM Forum ships conformance test kits, conformance profiles, Postman collections and reference implementations alongside the specifications, so conformance is a claim that can actually be tested rather than asserted. TMF639 reached v5.0.0 in April 2026.
The TMF object model is already a graph. TMF639's Resource carries resourceRelationship; TMF638's Service carries serviceRelationship, supportingService and supportingResource. Those relationship arrays are precisely the edges of a topology graph, expressed in a REST contract. The specifications describe edges they provide no means to walk.
Where REST Runs Out
The queries that matter operationally are transitive and of unknown depth. Trace the path from a customer premises device to the core. Find every service affected by a failed shared element. Determine whether the working and protect paths of a circuit share a duct, a chamber or a power feed.
REST handles none of these well, for four structural reasons. Resources are addressed individually, so traversal becomes client-side iteration — the N+1 access pattern, with latency multiplied by depth and fan-out. Query depth is unknown at design time, so no fixed set of endpoints or expansion parameters covers it; field and depth parameters help for one or two levels and then fail. Filtering happens in the wrong tier, because the selective predicate can only be evaluated during traversal, so the client fetches everything and discards most of it. And there is no transactional consistency across a multi-hop read, so the topology can change between the third hop and the fourth and return a path that never existed.
It is worth being precise about the N+1 problem: it is a data-access anti-pattern, not a REST-specific flaw. Resolver-based and federated GraphQL exhibit it too, at different layers. The issue is the shape of the access, not the protocol.
What the Graph Gives You
A graph model makes traversal the primary operation. In Cypher, a variable-length path pattern expresses in one clause what REST expresses as a nested loop of unknown depth, and the traversal can be bounded — between two and seven hops, for instance — rather than left open.
The blast-radius query is the canonical example: start at a physical card, traverse to ports, to terminations, to resource-facing services, to customer-facing services, to products, to customers. The output is an affected customer list and, where SLA terms are attached, a credit exposure figure. This is one query on a graph and a programme of work against a relational inventory behind a REST façade.
Shared-risk analysis is the case that most justifies the model, because the answer requires joining logical topology to physical and geographic containment. Real implementations exist: Sopra Steria's Intelligent Network Analyzer reconstructs topology from over sixty configuration data sources into Neo4j to support impact analysis and change simulation, and Ciena's Blue Planet describes federating discovered and legacy inventory data into a single graph-visualised model overlaid on existing systems.
Modelling Mistakes That Cost You Later
A single untyped relationship — everything CONNECTED_TO everything — collapses the layer model and returns paths that hop between layers illegally. Client and server layer relationships need to be modelled explicitly, or a CPE-to-core trace will cheerfully cut through a wavelength to an unrelated service.
Mixing specification and instance data without a clear boundary is the second trap. Catalogue entities have different volatility and cardinality from inventory instances, and a traversal that wanders from an instance into its template and back out into every other instance of that template produces an explosion rather than an answer. Bound every traversal depth and set query timeouts; an unbounded variable-length path on a dense inventory graph will find pathological path counts.
Most implementations treat inventory as a snapshot and then cannot answer what the topology was at 02:14 last Tuesday — which is exactly the question root cause analysis asks. Either version the graph or maintain effective-dated relationships. Retrofitting temporality after the fact is considerably harder than designing for it.
Drift Is the Real Problem
There are at least three claimed truths, not two: the planned state in the inventory, the discovered state from the network via SNMP, NETCONF, telemetry, LLDP and controller northbound interfaces, and the as-built physical record of cable schedules and patch panels. The third is the least automatable and most frequently wrong, because nobody has ever discovered a patch lead.
Declaring the inventory the single source of truth by fiat does not make it one. The productive pattern is to model the discrepancy as a first-class object: hold planned and discovered state side by side, generate typed discrepancy records — missing in network, missing in inventory, attribute mismatch, relationship mismatch — route them to owners, and track the backlog as an operational measure. ServiceNow describes essentially this pairing of continuous discovery with discrepancy analysis and reconciliation workflows to counter configuration item drift.
Federated or Centralised
Consolidating every legacy inventory into one new platform is the textbook answer, and it is the transformation most operators defer on cost and duration grounds. Federation — an overlay presenting a unified graph across existing systems — reaches value faster and carries less risk, but inherits the latency and quality of its sources and raises a genuine question about where writes land.
Neither approach avoids the unglamorous core problem, which is entity resolution: the same physical port identified by three different keys in three systems. Federation does not solve it. It simply surfaces it earlier, which is an argument in its favour.
The Architecture That Follows
The pattern implementations converge on is a graph as the internal representation with TMF as the external contract. Store topology natively as a graph. Expose TMF639, TMF638 and TMF637-conformant REST for create-read-update-delete, catalogue integration and ecosystem interoperability. Add a purpose-built traversal interface — GraphQL, an openCypher endpoint, or a small set of domain-specific impact and path operations — for the questions the REST contract cannot express.
TMF conformance then becomes an integration property rather than a constraint on the internal model. Standardise the interface without a traversable model and you get a well-documented system that cannot answer operational questions. Build the graph without the contract and you get a powerful model nobody else can consume.