The Catalog Governance Function
Last updated 12 Oct 2026
At a glance
The catalog governance function turns an approved product concept into published, versioned catalog entities across the commercial, service and resource layers, and decides whether they may be released. It is the only C2M function that both designs and refuses, and what it publishes is the definition every downstream system executes against.
The picture
How it works
From requirements to a published catalog
Product requirements
Portfolio handoffResolve the concept into modelling questions with answers: what is committed, at what values, which variants, what eligibility, replacing or coexisting with what.
Catalog design
Catalog and service architectureModel the commercial layer first, then decompose through the CFS layer to RFS and resource specifications.
Reuse assessment
Design authorityDecide, with a named decider, whether each layer needs a new specification or an existing one covers it.
Governance and validation
Design authority, compliance, commercialTest the model against business intent, architecture, regulation and reusability. Any gate can send it back.
Publish
Catalog release managementRelease a versioned, effective-dated specification set, promoted through environments, into the catalog runtime systems read.
Linear on a slide, iterative in practice. Until an authoritative catalog exists, nothing has been produced: a specification agreed in a review but not published is not an output of this function.
Both halves of the model
The commercial half is the Product Offering, the Product Specification and the ProductOfferingPrice, in the product catalog under TMF620. The technical half is the Customer Facing Service Specification and the Resource Facing Service Specification (both service specifications, under TMF633), decomposing onto Resource Specifications under TMF634. Section 3.1 covers what each entity is.
The common drawing in Section 2.1 shows catalog design producing CFS, RFS and resource specifications and stops there; it skips the step where commercial intent becomes a commercial product model. That model is always built, because nothing can be sold without one. Scope catalog design as CFS/RFS/RS work and it gets built elsewhere: CPQ configuration, a CRM product list, a billing rate plan table. None decomposes to a CFS, and the one sales quotes from is usually not the one attached to a decomposition. Section 5.2 covers commercial bundling in its own right.
The reuse gate
For every layer of every product: new specification, or does an existing one already do it? It matters most at the service layer, where a new CFS means a new decomposition, new orchestration paths and something new for assurance to interpret, while an extension is a characteristic and a valid value range.
Without an accountable owner the answer defaults to "new", because a new specification is always available and reuse is not: it needs someone to know what exists, establish whether it can carry the requirement, and negotiate a change with its owner. The cost of reuse is real. Adding a characteristic to a CFS six live products use means regression-testing six decompositions, carried by an owner for a product that is not theirs. Reuse concentrates risk on the incumbent and spreads the benefit across the portfolio. It therefore needs two things together: a searchable register of what is published at the service and resource layers, and a named decider whose refusal stands against a launch date.
Versioning, effective dating and the installed base
A catalog change is a change to a live system, not a content edit. A product on sale for a year has customers, in-flight orders, inventory records and billing attached to its specification.
| Population | What has to be decided |
|---|---|
| Orders in flight | Whether they complete on the version they started on (normally yes), and whether the order records which version |
| Existing subscribers | Grandfather on the old version or migrate; if migrating, who pays and what the customer is told |
| Pricing | The effective date, whether it applies to the installed base or only new sales, and the notice obligations |
| New orders | Whether the previous version stays orderable for a transition window, and when it is withdrawn |
Effective dating makes these decisions expressible in the catalog rather than in release notes: a future price can be published now, and a withdrawn offer stops being orderable without being deleted, since deletion would orphan every inventory record referencing it. Grandfathering keeps both versions valid; that is correct, and it accumulates.
The four validation gates
Business intent, architecture, regulatory compliance and reusability each ask a different question and fail for a different reason. Architecture and compliance can refuse on evidence the review already holds. Business intent and reusability depend on someone outside the room (the product owner, the owners of existing specifications), and they are the two whose failures cannot be recovered later: a mis-modelled commitment reaches customers, and a redundant specification joins the sprawl. Implementation receives whatever they let through, with no means of sending it back.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Approved product concept | Product portfolio | — | Catalog governance | Input to modelling, not a definition |
| Product offering, product specification, ProductOfferingPrice | Product catalog (TMF620), owned by commercial product management | — | CPQ, order capture, billing | If CPQ or billing holds its own product list, that copy is a reference at best |
| CFS specification | Service catalog (TMF633), owned by service architecture | — | COM, SOM, assurance | — |
| RFS specification | Service catalog (TMF633), owned by network and domain engineering | — | SOM, ROM | — |
| Resource specification | Resource catalog (TMF634), owned by network and domain engineering | — | ROM, resource inventory | — |
| Reuse decisions, gate outcomes and change records | Design authority record (often a governance or ticketing tool) | — | — | Rarely held in the catalog itself; frequently lost if not written down |
| Version and effective dates | Catalog (on each specification and price) | — | Order management, product inventory, billing | — |
In practice
The four gates are frequently collapsed into one review. That is efficient until it becomes a single person confirming the model looks reasonable, at which point the business and reusability questions are no longer being asked at all.
Catalog sprawl is a rational local decision made repeatedly under launch pressure. It is created at design time, inherited by orchestration, billing and assurance, and not recoverable at runtime.
Migrating existing subscribers is a programme, not a publication: a mapping from old specification to new that survives characteristics with no equivalent, a decision on customers whose configuration the new model cannot express, contractual notice, and a fallback for accounts that fail mid-migration. Without a decommissioning deadline, most of the installed base is never migrated; plan for that rather than discover it.
Catalog changes are promoted through environments like any release, and test environments need a representative installed base. A change that is safe against ten synthetic subscriptions says nothing about ten million real ones. Section 8.8 covers how the installed base is tracked at runtime.
The trade-off
What it solves
One authoritative, versioned definition across the commercial, service and resource layers, with a deliberate decision on reuse and a defined way to change a product that already has customers.
What it does not solve
- It does not migrate the installed base; publication changes what new orders get, not what existing customers have.
- It does not stop commercial models being built in CPQ, CRM or billing unless its scope includes the commercial layer.
What it adds
- A register, a named decider and four gates that need people outside the catalog team to attend.
- Grandfathered versions that accumulate and must be supported by every downstream system.
- Regression cost carried by owners of reused specifications for products that are not theirs.
Architecture decision
Who owns the three catalog layers?
One team owns commercial, service and resource layers
Choose when The portfolio and estate are small, and the team genuinely holds commercial, service and network competence
Each layer owned by its competence, bound by the layer above
Choose when Commercial product management, service architecture and domain engineering are distinct groups, and a design authority can arbitrate between them
Breaks if A single team flattens the TMF semantics toward its own competence, leaving a CFS that decomposes nothing; or split ownership has no named decider, so reuse defaults to "new" and the catalog sprawls.
Takeaways
Key Takeaways
- Catalog governance has produced nothing until an authoritative catalog exists that runtime systems can read.
- It owns both halves of the model: the commercial layer (TMF620) and the service and resource layers (TMF633, TMF634).
- Scoping catalog design as CFS/RFS/RS work pushes the commercial model into CPQ, CRM or billing, where it decomposes to nothing.
- Reuse needs a searchable register and a named decider; without them the answer defaults to "new".
- A catalog change is a change to a live system: in-flight orders, subscribers, prices and new orders each need a decision.
- Business-intent and reusability gates are the ones that lapse, and their failures cannot be recovered later.
Check yourself
Sales quotes a product from CPQ that has no CFS beneath it, yet the catalog team says its models are complete. What has happened?Show answerHide
Catalog design was scoped as CFS/RFS/RS work, so the commercial model was built in CPQ instead. Two commercial definitions exist, and the one sales uses is not attached to a decomposition.
A price change is published. Why do existing customers still pay the old price?Show answerHide
Publication affects new sales from the effective date. Whether the installed base moves is a separate decision (grandfather or migrate), with its own notice obligations and, if migrating, its own programme.
Why does reuse rarely happen without governance, even when everyone agrees it is desirable?Show answerHide
A new specification is always available in an afternoon; reuse needs knowledge of what exists and a negotiated change, and it puts regression risk on the incumbent owner while the benefit goes to the portfolio.