2.410 min read

Reuse & Inheritance Patterns

Why Reuse Matters

A well-designed catalog maximises reuse — the ability to define something once and use it across multiple products, services, and markets. Poor reuse leads to catalog bloat: hundreds of near-identical specifications, inconsistent behaviour, and maintenance nightmares.

Reuse operates at every catalog layer: Product Specifications can be shared across offerings, CFS specifications can be shared across products, and RFS/Resource specifications can be shared across services. The key is designing specifications that are generic enough to reuse but specific enough to be meaningful.

Specification reuse pattern -- multiple offerings share one specification and its service realisations

Figure 2.4 — Reuse patterns across catalog layers

Pattern 1: Specification Reuse

The Most Important Pattern

Define product specifications as reusable building blocks, not per-offering definitions. One "Fixed Broadband Access" specification should serve all broadband offerings (100Mbps, 200Mbps, 1Gbps, home, business) — with characteristics (speed, SLA) controlling the differences.

Reuse vs Duplication

Approach	Specifications	Maintenance	Consistency
Reuse (correct)	1 "Broadband" spec with speed characteristic	Change once, applies everywhere	Guaranteed consistency
Duplication (wrong)	Separate specs: "BB-100", "BB-200", "BB-500", "BB-1000"	Change each independently, hope they stay aligned	Drift over time

Pattern 2: Characteristic-Driven Variation

Instead of creating separate specifications for each variant, use characteristics (configurable attributes) to express variation within a single specification. This is the most powerful reuse technique in catalog modeling.

Intermediate

Characteristics as Variation Points

A Product Specification for "Mobile Plan" might define characteristics: dataQuota (1GB–unlimited), voiceMinutes (100–unlimited), smsAllowance, roamingIncluded (yes/no). Product Offerings set specific values for these characteristics, creating different plans from one specification.

Characteristics can have value types (string, number, enum), constraints (min/max, allowed values), and defaults. They can be customer-configurable (chosen at order time) or preset (fixed by the offering). This distinction is important: a "speed" characteristic might be preset for a "200Mbps Plan" offering but configurable for an "Enterprise Custom" offering.

Pattern 3: CFS Reuse Across Products

The same CFS specification can be referenced by multiple Product Specifications. This means the service definition is written once and reused across products.

CFS Reuse Example

CFS:Internet-Access is used by: (1) "Home Broadband" product spec, (2) "Business Fibre" product spec, (3) "Enterprise MPLS" product spec (alongside CFS:MPLS-VPN), (4) "Fixed Wireless" product spec. Each product may configure CFS:Internet-Access differently (different speed ranges, different SLA), but the CFS specification — and its decomposition rules — is defined once.

Pattern 4: Shared Resource Pools

Resources are inherently shared. An IP address pool, an OLT, or a VLAN range serves many customers. The resource catalog defines resource types once, and the resource inventory manages allocation across all consumers. This is aggregation, not composition.

Shared vs Dedicated Resources

Resource Type	Sharing Model	Allocation Pattern
OLT Port	Dedicated per customer	One port allocated per service activation
VLAN ID	Shared or dedicated (configurable)	Pool-based allocation from VLAN range
IP Address	Dedicated per service	Allocated from DHCP pool or static range
Bandwidth (QoS)	Shared with policy enforcement	Policy applied, not physically allocated
Network Slice (5G)	Shared partition of physical network	Slice template instantiation

Pattern 5: Template Inheritance

Some catalog systems support specification inheritance — a base specification defines common characteristics, and derived specifications add or override specific attributes. This reduces redundancy while allowing specialisation.

Base: "Broadband Access" defines common characteristics shared by all broadband products:

downloadSpeed: number (Mbps)
uploadSpeed: number (Mbps)
dataQuota: number (GB) or "unlimited"
accessTechnology: enum (GPON, DOCSIS, FWA, DSL)
ipVersion: enum (IPv4, IPv6, DualStack)

Anti-Patterns to Avoid

Catalog Reuse Anti-Patterns

Watch out for: (1) The "one spec per offering" trap — creating a new specification for every offering defeats all reuse. (2) Over-generalisation — one mega-specification with 50 optional characteristics becomes unmaintainable. (3) Copy-paste specs — duplicating instead of referencing leads to drift. (4) Hard-coded decomposition — embedding specific resource identifiers in the catalog instead of letting the fulfilment engine resolve them at runtime.

TM Forum Implementation of Reuse Patterns

Every reuse pattern described above maps directly to TM Forum Open API constructs. Understanding this mapping is essential for implementing reuse in a standards-compliant way.

Reuse Patterns → TMF API Mapping

Reuse Pattern	TMF API	Implementation Mechanism
Specification Reuse	TMF620 (Product Catalog)	Multiple ProductOffering resources reference the same ProductSpecification via productSpecification.id. The spec is defined once; offerings configure it commercially.
Characteristic-Driven Variation	TMF620 (Product Catalog)	ProductSpecCharacteristic defines available attributes with valueType, minCardinality, maxCardinality, and productSpecCharacteristicValue for allowed values. Offerings bind specific values via prodSpecCharValueUse.
CFS Reuse Across Products	TMF633 (Service Catalog)	ServiceSpecification resources are independent of product specs. ProductSpecification references ServiceSpecification via serviceSpecification relationship. Multiple product specs can reference the same service spec.
Shared Resource Pools	TMF634 (Resource Catalog) + TMF639 (Resource Inventory)	ResourceSpecification defines the resource type once. Resource Inventory manages pool allocation. Multiple RFS instances share the same pool via the Resource Inventory allocation API.
Template Inheritance	TMF620 / TMF633	Implemented via specification relationships with type "derivation" or "isReplacedBy". Derived specifications carry a parentSpecification reference. Characteristic constraints are expressed via overridden productSpecCharacteristicValue entries.

TMF Characteristic Model

The TMF characteristic model (used in TMF620, TMF633, TMF634) distinguishes between: (1) Specification-level characteristics — define what CAN be configured (e.g., downloadSpeed: 100-1000 Mbps). (2) Offering-level characteristic use — constrain what IS offered (e.g., this offering fixes downloadSpeed to 200 Mbps). (3) Instance-level characteristic values — record what WAS configured for this customer (e.g., downloadSpeed = 200). This three-level model is how TM Forum implements reuse: the specification defines the shape, the offering constrains the range, and the instance records the actual value.

Reuse Governance: Decision Criteria

Reuse does not happen automatically — it requires governance. Without clear decision criteria, teams will default to creating new specifications because it feels safer. The following framework helps architects decide when to reuse vs when to create new.

Reuse Decision Framework

Question	If Yes → Reuse	If No → New Specification
Do the products share the same CFS decomposition?	Use the same Product Specification with different characteristic values per offering.	Create a new Product Specification — different service structures need different specs.
Is the variation expressible through characteristics alone?	Add characteristics to the existing spec. Use offering-level constraints to differentiate.	Create a derived specification. Characteristics cannot express structural differences (different mandatory components).
Does the service behave identically regardless of which product uses it?	Share the CFS specification. Let the product-to-CFS characteristic binding handle variation.	Create a new CFS specification. If SLA, activation sequence, or resource requirements differ materially, reuse creates fragility.
Can the resource be allocated from a shared pool without conflict?	Use shared resource pool with allocation rules. Define pool capacity and reservation policies.	Use dedicated resource allocation. Some resources (e.g., dedicated wavelengths) cannot be pooled.

Version Management for Shared Specifications

When a shared specification changes (e.g., adding a new characteristic to "Fixed Broadband Access"), all offerings referencing it inherit the change. This is powerful but dangerous. Governance must enforce: (1) Non-breaking changes (new optional characteristics) can be applied immediately. (2) Breaking changes (removing a characteristic, changing cardinality) require a new specification version and migration plan. (3) Active product instances continue to reference the spec version they were created with — they are not automatically updated. TMF620 supports specification versioning via the version and lifecycleStatus fields.

Key Takeaways

Design specifications as reusable building blocks, not per-offering copies
Use characteristics (configurable attributes) to express variation within a single spec
CFS specifications should be shared across multiple product types
Resources are naturally shared via pools — use aggregation, not composition
Template inheritance (base + derived specs) reduces redundancy while allowing specialisation
TMF620 characteristic model operates at three levels: spec defines shape, offering constrains range, instance records value
TMF633 and TMF634 enable CFS and resource specification reuse across products via independent specification references
Reuse governance is mandatory — without decision criteria, teams default to creating new specifications
Specification versioning must distinguish breaking from non-breaking changes — active instances reference their creation-time version