The Catalog Governance Function

The catalog governance function receives an approved product concept and produces something a runtime system can read. Everything between those two points is modelling and the decision to publish. It is the only function in the chain that both designs and refuses, and what it publishes — not what was approved upstream — is the definition every downstream system executes against.

From product requirements to published catalog

The sequence is linear on a slide and iterative in practice: catalog design raises questions the requirements did not answer, and validation sends work back. 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

Catalog design has a commercial half and a technical half, and this function owns both. The commercial half is the Product Offering, the Product Specification beneath it and the ProductOfferingPrice attached to it — what is sold, to whom, on what terms and at what price — in the product catalog, under TMF620. The technical half is the Customer Facing Service Specification and the Resource Facing Service Specification beneath it — both service specifications, both under TMF633 — decomposing onto Resource Specifications under TMF634. Sections 3.1 and 2.2 are the reference for what each entity is; this section assumes them.

The common reference drawing of this function — the one in Section 2.1 — shows a catalog design stage producing CFS, RFS and Resource Specifications, and stops there. It is incomplete in a specific way: it skips the step where commercial intent becomes a commercial product model. Nothing in it says who turns "unlimited data for small business, three tiers, twelve-month term" into an offering with a specification, a price model and eligibility rules. The technical decomposition is drawn in full; the thing being decomposed is assumed to exist already.

Two commercial definitions then exist, only one attached to a decomposition, and the one sales quotes from is usually the other. Section 4.2 covers commercial catalog and bundling mechanics in their own right.

The reuse gate

For every layer of every new product the same question has to be answered: does this need a 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 a new thing for assurance to interpret, while an extension is a characteristic and a valid value range.

It has to be an explicit decision with a named owner, because the alternative is not neutral. Where nobody is accountable for answering it, the answer defaults to "new" — not through carelessness, but because a new specification is always available and reuse is not. Reuse requires someone to know what exists, to establish whether it can carry the requirement, and to negotiate a change with whoever owns it. Under a launch date, none of that competes with modelling something purpose-built in an afternoon.

Its cost is real and worth stating, because pretending otherwise is how reuse policies lose credibility. Adding a characteristic to a CFS six live products already use means regression-testing six decompositions, carried by that CFS's owner, for a product that is not theirs. Reuse concentrates risk on the incumbent and spreads the benefit across the portfolio — which is exactly why it does not happen without governance.

Anti-pattern: catalog sprawl

Why organisations choose it. Nobody chooses sprawl; they choose speed, one product at a time. Delivery models the specification under launch pressure, and a purpose-built one is faster than negotiating reuse — no impact assessment on other products, no regression against an installed base, no agreement from a team with its own backlog. It is the rational local decision, made by people measured on the launch rather than on the state of the catalog two years later.

What must hold for it to work. That the product is genuinely novel at the service layer — that what is delivered technically differs from everything already modelled, rather than differing commercially in ways that stop above the service boundary. A new price point, segment, bundle name or contract term is commercial variation with no service consequence. Where the difference is real — a new access technology, a new topology, a materially different SLA construct — a new CFS is correct and the gate should approve it.

How it fails. Every downstream consumer inherits the duplication. Orchestration maintains a separate fulfilment path per specification where one parameterised path would have served. Billing carries product codes with no shared lineage, so revenue cannot be reported by service without a hand-maintained mapping. Assurance cannot write one rule covering a family of products, because there is no family. Every future change is multiplied by the number of near-duplicates, and nobody knows what that number is.

Who owns which layer

The three layers need three different kinds of competence, so ownership follows the competence rather than the org chart. Each owner decides within their layer and is bound by the layer above.

Anti-pattern: one team owning all three layers

Why organisations choose it. It is faster and simpler to staff: no design authority, no cross-domain forum, no negotiation between commercial and network teams with different priorities. During a transformation programme it is often the only option — the product managers are running the legacy portfolio, the network teams are delivering their own roadmaps, and the programme has funded exactly one team to build the catalog.

What must hold for it to work. That the owner genuinely holds commercial, service and network competence — able to price a product, model a service commitment and describe how a domain realises it. That combination exists in individuals and almost never in a team of the size these arrangements are funded at. It also assumes standing to refuse: to tell commercial an offer cannot be modelled as described, and a network team that its resource model does not support the commitment being made.

How it fails. The layers flatten toward whichever competence the team actually has. A commercially-led team produces marketing SKUs wearing TMF entity names; a network-led one produces a service layer that is a thin pass-through to resources, decomposing nothing. Either way the catalog looks complete and the semantics are gone. The cost is deferred rather than avoided: the coordination the model skipped is paid later as rework, once a domain team is asked to fulfil against a decomposition it never agreed to and cannot deliver.

Versioning, effective dating and the installed base

A catalog change is a change to a live system with an installed base attached. It is not a content edit, and treating it as one is how a routine specification update becomes an incident. A product on sale for a year has customers on its specification, orders in flight against it, inventory records pointing at it and billing derived from it. Changing it touches all four, on different timescales.

Effective dating makes these decisions expressible in the catalog rather than in someone's release notes. Specifications and prices carry validity windows, so a future price can be published now and take effect later, and a withdrawn offer can stop being orderable without being deleted — deletion would orphan every inventory record referencing it. Grandfathering is then the decision not to migrate: the old version stays valid for the customers on it, and the catalog carries both. That is correct, and it accumulates. Section 5.6 covers how the installed base is tracked 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 is inexpressible in the new model, contractual notice where terms or price change, and a fallback for accounts that fail mid-migration. Absent a decommissioning deadline that forces the issue, the realistic default is that most of the installed base is never migrated — better planned for than discovered.

None of this reaches production directly. Catalog changes are promoted through environments like any other release, and the test environments need a representative installed base — a catalog change that is safe against ten synthetic subscriptions tells you nothing about ten million real ones.

The validation gates and what each is checking

Governance before publication runs four checks. They are frequently collapsed into one review, which is efficient until it becomes a single person confirming that the model looks reasonable — each gate asks a different question and fails for a different reason.

The two that stop being gates are also the two whose failures cannot be recovered later: a mis-modelled commitment reaches customers, and a redundant specification joins the sprawl. The implementation function receives whatever they let through, and has no means of sending it back.