Architectural Decoupling – Managing Telecom Specification Complexity

Introducing telecommunications products and services to the market has always been challenging, as the technical realisation of services in the network tends to permeate the commercial definition and perception of the products and related services.

Network resources such as routers, switches, VNFs, CNFs, and network services (e.g., Layer 2 and Layer 3 VPNs and 5G slices) are tangible. In contrast, marketing definitions of product offerings, with related commercial implications for bundling, pricing of rate plans, and end-user devices, are intangible.

Additionally, the lifecycle of Products and services sold to customers differs from that of network resources and services. Commercial reasons for product changes may include sales periods, new end-user device launches, and competitors’ products and services. Conversely, technical solutions that build connectivity (access, aggregation, and core) can evolve as standards evolve (e.g., 3GPP), vendor equipment adopts new standards, and services are migrated to new equipment or virtualised resources that provide equipment functions and services (e.g., as in 5G core evolution).

This requires separating commercial concerns from technical concerns. Additionally, the implementation of the network and network services, using underlying multi-vendor, domain-specific ecosystems that now include network virtualisation, involves a degree of abstraction to manage the complexity of service delivery.

Decoupling commercial and technical changes

One way to achieve agility in the face of change is to specify products and the knowledge of how those products translate into services that the customer understands, and to demonstrate how product orders translate into service orders. Then relate these product specifications to the technical specifications that represent the resources that allocate and provide the capacity to deliver these services in the network.

Thus, the modelling approach adopted by TM Forum and, to some extent, the MEF is to separate the Specification of an Entity from the Entity that is instantiated. This is one of the four patterns discussed in this post. Given my additional work in enterprise architecture, I find it helpful to compare these patterns with Domain-Driven Design patterns.

The Specification / Entity Pattern

The Specification/Entity Pattern is different to the Specification Pattern in Domain-Driven Design (DDD). TM Forum EntitySpecification–Entity pattern is a type/instance configuration pattern, whereas the DDD Specification pattern is a business rule predicate pattern; they answer different questions and are used in different layers

TM Forum Specification /Entity Pattern

Intent: Model “type versus instance” and make entity types configurable at runtime. ‘EntitySpecification’ is a template/configuration profile; ‘Entity’ (or ‘ManagedEntity’) is a concrete instance that “conforms to” that spec.

Structure: ‘EntitySpecification’ holds characteristics, default values, and often an ‘entitySchema’ that defines the structure of instances. (example from TM Forum). Entity instances carry values for those characteristics and reference exactly one (or sometimes zero/one) specification

Example use cases: Situations where new “types” must be added or extended without changing the code model, using characteristics and schemas for dynamic attributes

This pattern is used when there is need for a catalog of types and a runtime-configurable data model: catalog-driven products, custom entities, configuration profiles, etc.

DDD Specification pattern

Intent: This is a behavioural design pattern used to encapsulate business rules (criteria predicates) that objects (or functions) must satisfy.

Structure: A Specification is a predicate over an entity (e.g. OrderIsApproved, CustomerIsCreditworthy). Specifications can be composed with and, or, not into larger rules.

Example use cases: Complex validation/business rules that do not naturally belong inside a single entity. Reusable filters for querying (e.g. passing Specifications to repositories).

This pattern is used when there is a need for  declarative, composable business rules that can be reused in validation, decision logic, and querying

Comparison

Summary

Specification Pattern (Wikipedia):

• Focuses on expressing and combining business rules.
• Used for querying/filtering objects based on criteria.

Specification/Entity Pattern (Catalog):

• Focuses on defining types and instantiating entities based on those types.
• Used for flexible, extensible data models.