I use TM Forum frameworks to design OSS (operations support systems) and BSS (business support systems) for telecoms operators. This page explains the Business Process Framework (eTOM), the Information Framework (SID), the Functional Framework and ODA (Open Digital Architecture). It follows one order through the Open APIs (application programming interfaces), and shows how closed loops and intent move a network towards autonomy.
TM Forum is an industry association for telecoms operators and their suppliers. Its frameworks give the industry one vocabulary for processes, information, systems and interfaces. That shared vocabulary makes OSS (operations support systems) and BSS (business support systems) designs comparable, and lets software from different suppliers fit together.
Swipe sideways to see the whole diagram.
Many operators grew their OSS and BSS project by project. Each new system was wired straight into the others, so every change touches many interfaces, and nobody can say for certain which system owns an order or a customer.
The Business Process Framework, known as eTOM, names the work: order handling, activation, provisioning, problem handling and billing. With shared names, two teams or two suppliers can compare their processes without arguing about words.
The Information Framework, known as SID, names the things that work acts on: customers, products, services, resources and partners, and how they relate. It becomes the base of a common data model and of every API payload.
The Functional Framework names the functions software must provide. Mapping each system against it shows overlaps, such as two catalogues, and gaps, such as no service inventory. The aim is one owner for each function.
ODA turns those functions into components that run on a shared platform, the ODA Canvas, and talk only through Open APIs. Hand built point to point links give way to published contracts that any supplier can implement.
The layers line up. A process acts on information, a function holds it, and a component exposes it through an API. That alignment lets me trace a requirement from a process all the way down to an interface, and back.
| Framework | Also known as | The question it answers | How I use it |
|---|---|---|---|
| Business Process Framework | eTOM, document GB921 | What work does an operator do? | Map processes as they are, agree scope and find gaps in a high level design |
| Information Framework | SID, document GB922 | What does that work act on? | Name entities and relationships, and shape API payloads and the data model |
| Functional Framework | Formerly the Application Framework and TAM (Telecom Application Map), document GB929 | Which functions must software provide? | Map systems to functions, find overlaps and gaps, and plan what to retire |
| Open Digital Architecture | ODA | How should the software be built and joined? | Set the target: components on a canvas, joined by Open APIs |
| Open APIs | TMF numbers, such as TMF622 | How do components and partners talk? | Specify every interface between systems, and with partners |
| Autonomous Networks | Levels L0 to L5 | How far can operations run themselves? | Set an automation roadmap and measure progress against it |
The document numbers are TM Forum's own. Each framework is revised in regular releases.
TM Forum is an industry association of more than 800 member companies: operators, suppliers and integrators. Its frameworks describe what good looks like, so buyers and suppliers can compare like with like. They are not software.
TM Forum launched the Open Digital Framework in 2019. It brings ODA, the Open APIs, data and AI (artificial intelligence) standards and reference implementations together. It grew out of Frameworx, the older name for the set of eTOM, SID and the Application Framework.
Catalysts are proofs of concept: operators set a problem and suppliers build a solution over a few months, then show it at TM Forum events. Conformance certification tests a product against an API or component specification.
The Business Process Framework, still widely called eTOM (enhanced Telecom Operations Map), is a map of everything a telecoms operator does. It is a grid. Columns follow work from strategy to operations, and rows follow the domains: market and sales, product, customer, service, resource and partners. Each cell decomposes into processes, level by level.
Swipe sideways to see the whole diagram.
Level 0. eTOM splits an operator into three areas. Strategy, infrastructure and product plans and builds what the operator sells. Operations runs it day to day. Enterprise management covers what any company does, from finance to risk. The customer sits above them all.
Fulfilment turns an order into a working service: order handling for the customer, service configuration and activation, and resource provisioning. This column is where the order to activate flow on this page lives.
Assurance keeps services working: problem handling for the customer, service problem and quality management, and resource trouble management. Alarms, tickets and service level reports belong here.
Billing and revenue management turns usage and charges into bills: bill invoice management for the customer, service guiding and mediation, and resource mediation and reporting, which collect and clean usage records.
Domains are the rows: market and sales, product, customer, service, resource and engaged party, which covers suppliers and partners. They line up with the SID domains and the Functional Framework, so a process, its data and its system share one place.
Levels. eTOM decomposes level by level. Level 0 is the business view, level 1 the groupings, level 2 the processes, and level 3 and below the steps. I map an operator's real processes at level 2 or 3, which is detailed enough to scope a design and to compare suppliers.
Operators often call the three operations columns FAB (fulfilment, assurance and billing). Most OSS and BSS change lands in one of them, so they are where I start.
eTOM describes a telecoms business. ITIL, formerly the Information Technology Infrastructure Library, describes IT (information technology) service management. They overlap in assurance, where problem handling meets incident and problem management, and TM Forum has published guidance on using the two together. My ITIL page covers the service management side.
A process box is not a team. One team may run several processes, and one process may cross several teams. Mixing the two up is a common mistake.
The Information Framework, known as SID (Shared Information/Data model), names the things an operator manages and how they relate. Its most useful idea for network people is the chain from product to CFS (customer facing service) to RFS (resource facing service) to resource, with a specification for each one in the catalogue.
Swipe sideways to see the whole diagram.
A party is a person or an organisation. Customer is one role a party plays, and supplier and partner are others. Keeping the party apart from its roles stops the same company being stored three times, once per system.
The catalogue holds product offerings, which add price and terms to a product specification. One specification, such as an SD-WAN (software defined wide area network) branch, can sit behind several offerings for different markets or contract lengths.
When an order completes, a product instance appears in the product inventory, on the customer's account. Billing and customer care read from here. The dashed line shows that it was created from its specification.
A CFS is the service as the customer sees it: an SD-WAN branch with two paths and 100 Mb/s. It describes what is delivered and hides how the network delivers it.
An RFS is what the network must provide to deliver it: overlay tunnels, a VLAN (virtual local area network) and a QoS (quality of service) policy. The customer never sees these, and they can change without changing the product.
Resources are the logical and physical things in use: an edge router, its ports, IP (Internet Protocol) addresses and a licence. They live in the resource inventory, which should match what the network really has.
Every instance has a specification in the catalogue. The catalogue says what can exist, and the inventory says what does. That pattern is what lets orchestration decompose an order without a person drawing it each time.
| Domain | Example entities | Where it shows up |
|---|---|---|
| Customer | Customer, customer account, customer bill | CRM (customer relationship management), billing, self service |
| Product | Product offering, product specification, product, price | Catalogue, product inventory, ordering |
| Service | Customer facing service, resource facing service, service specification | Service catalogue, service inventory, orchestration |
| Resource | Logical resource, physical resource, resource specification | Network inventory, activation, assurance |
| Market and sales | Market segment, sales channel, sales lead | Marketing and sales systems |
| Engaged party | Party, party role, agreement | Partner and supplier management |
Domain names follow recent SID releases, which group partners and suppliers as engaged parties. Older material calls the domain supplier and partner.
SID is a conceptual model in UML (Unified Modeling Language). I use it to name things and their relationships, then derive a physical schema per system. Copying it table for table makes a database nobody can query.
Each domain splits into ABEs (aggregate business entities), groups of closely related entities such as customer bill or service performance. ABEs are a handy unit for deciding which system owns which data.
The Open API payloads are built from SID entities. A product order in TMF622 carries product, product offering and party references that a SID literate team will recognise at once.
Most OSS and BSS estates grew system by system, so several systems do the same job and some jobs belong to nobody. The Functional Framework lists the functions an operator's software must provide. Mapping systems against it is the first step I take in any transformation, because it shows what to keep, merge, build and retire.
Swipe sideways to see the whole diagram.
I start with an inventory of every system that touches orders, services and resources, including the spreadsheets. Acquisitions leave duplicates, and old projects leave systems nobody admits to owning.
Each system is mapped against the functions in the Functional Framework that it really performs, which is often more, or less, than its name suggests. A billing suite that also holds the product catalogue is a common example.
Two systems on one function means two versions of the truth: two customer records, two catalogues, or an inventory in the network manager and another in spreadsheets. Each overlap needs one master.
A function with no system is done by people, if at all. Here nothing holds the service inventory, so nobody can say which customers a failed router affects.
The target gives each function one owner. Some systems stay, some lose a role, and some retire. The order of that work becomes the transformation roadmap, which I tie to the processes it improves.
| For each function I record | Why it matters |
|---|---|
| The owning system, and any others that touch it | Shows overlaps and who masters the data |
| The data it masters, named with SID entities | Stops two systems claiming the same record |
| The processes it serves, named with eTOM | Ties the system to the work and its metrics |
| Its interfaces, and which are Open APIs | Shows how much point to point work remains |
| Its lifecycle: keep, change, replace or retire | Turns the map into a roadmap with dates |
The Functional Framework grew from the Application Framework, also called TAM (Telecom Application Map). The newer name reflects that it describes functions, not products, so one product can span many functions.
Its domains line up with eTOM and SID, so a function sits beside the processes that use it and the data it holds. That alignment is what makes the three useful together.
Asking a supplier to map their product against the framework shows quickly whether it really covers a function, or relies on a partner or on custom work.
ODA (Open Digital Architecture) is TM Forum's blueprint for modular OSS and BSS. Software is split into components, each owning a clear set of functions and data. Components run on a shared platform called the ODA Canvas and talk only through Open APIs (application programming interfaces) and events, so a component from one supplier can be swapped for another.
Swipe sideways to see the whole diagram.
Swipe sideways to see the whole diagram.
A supplier ships a component as a package, often a Helm chart, with a component specification. The specification lists the APIs the component exposes, the APIs it depends on, and its management and security functions.
Installing the package creates a component resource in Kubernetes. The component operator reads it and splits it into smaller resources: one per exposed API, one per dependent API, and one for its identity settings.
The API operator publishes each exposed API through the canvas gateway or service mesh, which adds security, throttling and routing. Nothing calls the component directly, so every component is reached the same way.
The identity operator registers the component's roles with the canvas identity service. Access is then controlled the same way for every component, whoever supplied it.
The dependency operator finds which component on the canvas provides each API this one needs, such as the catalogue and service ordering, and tells it where to call. Nobody hard codes an address.
The CTK (conformance test kit) runs against the component on a compliant canvas. TM Forum began certifying commercial components against its ODA component specifications in January 2025.
| ODA block | What it covers | Example components |
|---|---|---|
| Party management | People and organisations, their roles, accounts and agreements | Party, party role, agreement |
| Core commerce management | What is sold, to whom and for how much | Product catalogue, product order capture, product inventory, billing account |
| Production | How it is delivered and kept working | Service order, service and resource inventory, activation, alarms |
| Intelligence management | Analytics and AI across the other blocks | Data insight, prediction, closed loop decisions |
| Engagement management | Channels and user experience | Portals, apps, agent desktops |
| Canvas operators | The platform services every component uses | Component, API, identity and dependency management |
Block names follow TM Forum's ODA material. The component list grows with each release, and some specifications are still being written.
A component does one job and exposes it through standard APIs, so it can be bought, replaced or scaled on its own. That is the opposite of a suite where every part depends on every other.
The canvas is the runtime: Kubernetes, a gateway, identity and observability, with operators that manage components. A reference canvas is open source, and Microsoft released assets for running one on Azure in November 2024.
A product with a few certified APIs is not a set of ODA components. I ask which component specifications a product meets, and whether it runs on a standard canvas or brings its own platform.
TM Forum's models sit in the industry part of the Enterprise Continuum in TOGAF (The Open Group Architecture Framework), as my TOGAF page explains.
The Open APIs are TM Forum's standard interfaces between OSS and BSS functions, and between operators and their partners. Each has a number, such as TMF622 for product ordering, a data model drawn from SID, and a conformance test. Starting an integration from an Open API means the contract is already written, reviewed and testable.
| Area | API | Name | What it holds |
|---|---|---|---|
| Product | TMF620 | Product Catalog Management | Offers, specifications and prices |
| Product | TMF679 | Product Offering Qualification Management | Can this offer be sold here? |
| Product | TMF622 | Product Ordering Management | Customer orders and their state |
| Product | TMF637 | Product Inventory Management | Products a customer has |
| Service | TMF633 | Service Catalog Management | Service specifications |
| Service | TMF645 | Service Qualification Management | Can the network deliver it? |
| Service | TMF641 | Service Ordering Management | Service orders, including from partners |
| Service | TMF640 | Service Activation Management | Activate and configure services |
| Service | TMF638 | Service Inventory Management | Services that exist |
| Resource | TMF634 | Resource Catalog Management | Resource specifications |
| Resource | TMF652 | Resource Ordering Management | Resource orders |
| Resource | TMF639 | Resource Inventory Management | Resources that exist |
| Assurance | TMF642 | Alarm Management | Alarms in one format |
| Assurance | TMF621 | Trouble Ticket Management | Fault tickets with customers and partners |
| Assurance | TMF656 | Service Problem Management | Provider side service problems |
| Assurance | TMF657 | Service Quality Management | Service quality objectives and reports |
| Party and place | TMF632, TMF669 | Party Management, Party Role Management | People, organisations and their roles |
| Party and place | TMF673, TMF674 | Geographic Address Management, Geographic Site Management | Addresses and sites |
| Common | TMF688 | Event Management | Publishing and subscribing to events |
| Common | TMF921 | Intent Management | Intents and intent reports |
A selection. TM Forum lists more than 70 Open APIs, in version 4 and the newer fifth generation, which adds event driven and intent based patterns.
Choose a job and see which TM Forum Open API covers it. I use this mapping when I write interface requirements, so every integration starts from a published contract rather than a custom one.
Each choice shows the Open API that fits, its main resources and a typical call. Paths are shown relative to the API's base path.
POST /productOrderTMF622. The front door for every order. States run from acknowledged through inProgress to completed, or to partial, failed or cancelled.
GET a list or one item, POST to create, PATCH to update and DELETE where allowed. Lists take filters, fields to trim the reply, and offset and limit to page.cancelProductOrder.POST /hub and a callback address, then receives events such as a state change instead of polling.@type, @baseType and @schemaLocation let an operator extend a payload without breaking the standard./tmf-api/productOrderingManagement/v4/, so v4 and v5 can run side by side during a migration.An indicative product order for an SD-WAN branch, the reply, a listener registration and a trimmed status check. Identifiers are examples.
POST /tmf-api/productOrderingManagement/v4/productOrder
{
"externalId": "PO-1042",
"requestedCompletionDate": "2026-11-20T09:00:00Z",
"relatedParty": [{ "id": "C-7731", "role": "Customer", "@referredType": "Organization" }],
"productOrderItem": [{
"id": "1",
"action": "add",
"productOffering": { "id": "SDWAN-BR-100", "name": "SD-WAN branch 100" },
"product": {
"productCharacteristic": [
{ "name": "bandwidth", "value": "100 Mbps" },
{ "name": "paths", "value": 2 }
],
"place": [{ "id": "SITE-221", "role": "installationAddress", "@referredType": "GeographicSite" }]
}
}],
"@type": "ProductOrder"
}
201 Created { "id": "8a3f", "state": "acknowledged", ... }
POST /tmf-api/productOrderingManagement/v4/hub
{ "callback": "https://crm.example.net/listener", "query": "eventType=ProductOrderStateChangeEvent" }
GET /tmf-api/productOrderingManagement/v4/productOrder/8a3f?fields=state,completionDateThe clearest way to see the frameworks working together is to follow one order. A customer buys an SD-WAN branch. The order passes through the catalogue, product ordering, service ordering, activation and the inventories, each step behind an Open API, and events report progress back to the customer.
Swipe sideways to see the whole diagram.
The channel reads offers and prices from the product catalogue through TMF620. Every channel reads the same catalogue, so the shop, the contact centre and partners all sell the same thing at the same price.
Before taking the order, the channel asks through TMF679 whether this offer can be sold at this site. Behind the scenes that often calls service qualification, TMF645, to check coverage and capacity.
The channel posts a product order through TMF622. It is validated against the catalogue and acknowledged with an identifier. The channel registers a listener so it hears about every state change.
Order orchestration reads the catalogue to break each order item into the services behind it, then posts a service order through TMF641. The product order moves to inProgress.
Service order management activates the service through TMF640, and orders resources through TMF652 where something must be allocated or installed. Activation drives the domain controller, such as an SD-WAN manager.
Activation records the resources it used in the resource inventory, TMF639, and the service in the service inventory, TMF638. The links between them are what assurance needs later.
State change events flow back up: the service order completes, then the product order, and the product appears in the product inventory, TMF637. Billing starts from there, and the channel tells the customer.
Pick a product and a fault. The table shows each API call in order, and the state the product order shows the customer. The steps are simplified, but the states and the faults are the ones I design fallout handling for.
Order states follow TMF622: acknowledged, inProgress, pending, held, partial, completed, failed, rejected and cancelled. How an operator uses each one is agreed in its own design.
| # | API | What happens | Product order |
|---|---|---|---|
| 1 | TMF679 | Qualify the offer at the site | qualified |
| 2 | TMF622 | Create the product order | acknowledged |
| 3 | TMF641 | Decompose to a service order: SD-WAN branch, 100 Mb/s, two paths | inProgress |
| 4 | TMF652 | Resource order: ship and install an edge router | inProgress |
| 5 | TMF640 | Activate overlay tunnels and a branch policy | inProgress |
| 6 | TMF639, TMF638 | Record an edge router, a licence and IP addresses, then the service | inProgress |
| 7 | TMF622 event | Product order completed, product added to TMF637 | completed |
Completed. Every call succeeded, so the product order completes, the product appears in the product inventory and billing can start.
Decomposition rules live in the catalogue, not in code. A new product then needs new catalogue entries, not a new release of the order manager.
Some orders always fail: a site that cannot be served, missing details, a stuck activation. I design the fallout queue, the retries and the rollback as carefully as the happy path.
Long running orders report progress through events to registered listeners. Polling every few seconds from every channel loads the order manager and still misses states.
TM Forum's Autonomous Networks work describes how far network and service operations can run themselves, on six levels from L0, fully manual, to L5, fully autonomous. Operators use the levels to set targets and to measure progress, one workflow at a time.
Swipe sideways to see the whole diagram.
Every dynamic task is done by people. Systems may raise alarms, but people watch, find the cause, decide the fix and type it in. Many fault and change processes still sit here.
The system carries out certain predefined, repetitive sub tasks, such as a script or playbook a person chooses to run. It saves time on each task, but people still drive every decision.
Closed loop operation for certain units in certain environments. The system can detect and fix known faults on its own inside one domain, using rules and policies that people wrote.
The system senses changes in its environment in real time and adjusts its own operation within certain domains. This is where intent based, closed loop management starts.
Predictive or active closed loops across domains, driven by service and customer experience. The system analyses and decides in more complex, cross domain situations, and people supervise.
Closed loop automation across every service, every domain and the whole lifecycle. TM Forum describes it as the goal for network evolution, not a near term target.
Pick one workflow, such as fixing a fault in the transport network, and answer for how it really runs today, not how it should.
L1, held back by analysis. People still find the cause of most faults, so the loop cannot close on its own. I would start with root cause rules for the most common fault types, such as a fibre cut or a failed power supply.
A loop is only as autonomous as its weakest stage, so the level here is set by the lowest answer, and widened by the last one. TM Forum's formal method is its Autonomous Network Levels Evaluation Methodology, IG1252.
Higher autonomy levels depend on intent: stating the outcome a service needs and letting the network work out how to deliver it. TM Forum standardises the interface for this as the Intent Management API, TMF921. An intent handler turns the intent into policy for closed loops and reports back on whether the intent is being met.
Swipe sideways to see the whole diagram.
| Idea | What it means | Where it is defined |
|---|---|---|
| Intent | A statement of an outcome, with expectations to meet, not the steps to get there | TM Forum Intent Ontology, TMF921 |
| Intent owner and handler | The owner states the intent; the handler works out how to meet it, and may pass sub intents down | TMF921 Intent Management API |
| Intent report | Whether each expectation is met, so the owner can accept, change or withdraw the intent | TMF921, resource intentReport |
| Closed loop | Monitor, analyse, decide and act, repeated, with policies and limits set by people | TM Forum Autonomous Networks; ETSI ZSM (zero touch network and service management) |
| Mobile network intents | Intent driven management services for mobile networks | 3GPP (3rd Generation Partnership Project) technical specification TS 28.312, from SA5 (Service and System Aspects working group 5) |
TMF921 reached version 5 in the fifth generation of Open APIs. The ontology lets owners and handlers from different suppliers agree what an expectation means.
An intent says what must be true, such as a latency target at a site. The handler decides the configuration. That lets the network change how it meets the target without the business system changing at all.
A business intent becomes service intents, then resource intents, each with its own handler and loop. A loop that cannot meet its target escalates to the one above.
Every intent needs a report. Without one, automation becomes a black box, and nobody can tell a met target from a silent failure.
TM Forum is one of several bodies shaping how operators automate. MEF (first named the Metro Ethernet Forum, now Mplify), ETSI, 3GPP and the IETF (Internet Engineering Task Force) each cover different layers and interfaces. A sound design says which standard governs each layer, and maps the interfaces between them.
Swipe sideways to see the whole diagram.
TM Forum is strongest in the business and service layers: eTOM, SID and ODA for the operator's own OSS and BSS, and Open APIs such as TMF622, TMF641 and TMF921 for orders and intents. It reaches the resource layer through resource ordering, inventory and alarms.
MEF LSO (Lifecycle Service Orchestration) names the reference points between layers: Legato from business applications to orchestration, Presto to infrastructure control and Adagio to element control. Cantata faces the customer, and Sonata and Interlude join operators. MEF renamed itself Mplify in 2025.
ETSI NFV (network functions virtualisation) defines MANO (management and orchestration): an NFVO (NFV orchestrator), VNFMs (virtual network function managers) and a VIM (virtualised infrastructure manager). ETSI ZSM (zero touch network and service management), formed in December 2017, defines end to end closed loops.
3GPP SA5 defines management for mobile networks, including the RAN (radio access network) and the 5G core, network slicing, and intent driven management in TS 28.312. A TM Forum service order for a network slice ends up in these interfaces.
The IETF defines YANG (Yet Another Next Generation) data models and the NETCONF (Network Configuration Protocol) and RESTCONF protocols that controllers use to configure devices. It also defines customer service models in RFCs (Requests for Comments): the layer 3 VPN (virtual private network) service model (L3SM) in RFC 8299, and the layer 2 VPN service model (L2SM) in RFC 8466.
| LSO reference point | Between | What it carries |
|---|---|---|
| Cantata | The customer and the operator's business applications | Customer orders, quotes, tickets and bills |
| Allegro | The customer and the operator's service orchestration | Customer supervision and control of dynamic services |
| Legato | Business applications and service orchestration | Service orders and status inside the operator |
| Sonata | The business applications of two operators | Wholesale quotes, orders, inventory and tickets |
| Interlude | The service orchestration of two operators | Coordinating part of a service inside a partner's domain |
| Presto | Service orchestration and infrastructure control | Managing the infrastructure, such as SDN (software defined networking) controllers |
| Adagio | Infrastructure control and element control | Managing network elements |
From MEF 55.1, the LSO reference architecture.
Overlapping standards are normal. I agree which one governs each layer and each interface in the high level design, so two teams do not build the same thing twice.
Between operators, a Sonata or TMF641 order can replace email and spreadsheets for ordering access circuits, which removes rekeying and the errors that come with it.
IETF service models and YANG sit under the TM Forum APIs. Mapping one to the other is where most of the detailed design effort goes.
Replacing an operator's order, inventory or billing stack is one of the riskiest projects in telecoms. The frameworks help most here. They describe the target, and the Open APIs let old and new run side by side while traffic moves across, one product family at a time.
Swipe sideways to see the whole diagram.
Channels call the legacy order stack directly, each through its own interface. Replacing the stack would mean changing every channel at once, which is why big bang OSS and BSS replacements so often slip.
I put a standard API layer in front of the legacy stack, such as TMF622 for orders, and move the channels onto it one at a time. Nothing behind the API changes yet, so the risk is small.
One product family, often the newest or simplest, moves to the new components behind the same API. The channels do not notice. Orders for everything else still go to the legacy stack.
Product families move in waves. Each wave brings its catalogue entries, decomposition rules and inventory data, migrated and reconciled. Legacy order volumes fall with every wave.
When the last product family and its in flight orders have moved, the legacy stack is switched off. The API never changed, so neither did the channels. This is often called the strangler pattern.
I make Open API conformance, tested with TM Forum's test kits, a gate in supplier contracts. A certificate does not prove a product fits, but its absence is a warning.
Catalyst projects let an operator try an idea with several suppliers before committing. They show what works in a demo, and the design still has to prove it at scale.
Each wave has measures the business recognises: time to market for a new product, order fallout, and the licence and support cost of the systems it retires.
OSS and BSS faults rarely show up as an error message. They show up as an order that never completes, a customer billed for something that does not work, or an alarm nobody can tie to a customer. My method is to follow one order through every API, find the step where its state stopped matching reality, then decide whether to fix the order or the design. Choose a symptom to see where it usually sits. My general method is on the troubleshooting page.
Swipe sideways to see the whole diagram.
Orders stay inProgress although the service works. The work finished, but a state change event never reached the product order. Usually a listener registration was lost after a restart, or a callback address changed. I read the order with GET /productOrder/{id}?fields=state,productOrderItem, check the service order beneath it, look at the event delivery log, and re register the listener. Retries must be safe to repeat.
Orders rejected at once. The order refers to an offering or price that is retired, not yet launched, or not valid for this channel or date. I check GET /productOffering/{id}?fields=lifecycleStatus,validFor against the order, and fix the catalogue process that let a channel keep selling a retired offer.
Orders end partial or failed. One order item failed, often an activation that timed out at the controller or a resource that could not be allocated. I find the failed service order item and the activation job behind it, check the controller's own log, and decide between retry, manual completion through the fallout queue, or rollback.
The service works, but the inventory is wrong. Someone changed the network by hand, or an activation succeeded but its inventory update did not. I compare GET /resource results with network discovery, such as show inventory or controller exports, reconcile, and block manual changes that bypass orchestration.
Integration breaks after an upgrade. One side moved from v4 to v5 of an API, changed a base path, or started sending an extension under @type that the other side rejects. I compare the versions in the paths, replay a recorded order against both, and rerun the conformance test kit before go live.
Alarms arrive, but nobody knows who is hit. Alarms carry the resource, but the service inventory has no link from that resource to the services using it. I query the service inventory for services that rely on the alarmed resource. If nothing comes back, the gap is in how activation records relationships, not in assurance.
| Question | What I look at | What it tells me |
|---|---|---|
| Where is the order now? | GET /productOrder/{id} and the service orders beneath it | Which item stopped, and in which state |
| Did the events arrive? | Hub registrations and the event delivery log | Whether the consumer was told, and when |
| Is the catalogue consistent? | Offering lifecycle status, validity dates and the specifications behind it | Whether an order could ever have succeeded |
| Does the inventory match the network? | Inventory queries against discovery and controller exports | Drift, and where it started |
| Which versions are in use? | Base paths, @type values and conformance results | Whether both sides speak the same contract |
| Is it one order or many? | Fallout counts by product, step and error code | Whether to fix one order, or the design |
TM Forum work usually starts with a business problem: products take months to launch, orders fail and need manual fixes, or operations cannot scale. I follow the same path each time: agree the outcome, map what exists against the frameworks, design a target of components and Open APIs, prove it with one product family, then move in waves and keep it current.
Swipe sideways to see the whole diagram.
I start by agreeing the business outcome: faster product launches, fewer failed orders, or autonomy targets for operations. I record who decides, who is consulted and who must be told in a RACI (responsible, accountable, consulted, informed) chart, and agree how the architecture board signs off designs.
I write requirements against the frameworks: the eTOM processes in scope, the SID entities each system must master, and the Open APIs every interface must use. Non functional targets cover order volumes, cycle times, fallout and autonomy levels, each with a number and an owner who signs it off.
I map every system against the Functional Framework, list every interface and whether it follows an Open API, and walk real orders and faults through the processes. I sample inventory against the network to measure drift. The findings often change the business case, so they come before the design.
The high level design sets the target: which ODA components own which functions and data, which Open APIs join them, and how other standards fit underneath. The low level design fixes API versions, extensions, events and error handling. Transition architectures show each safe step from today to the target.
I prove the design with one product family end to end, fallout handling included, before any wave starts. Suppliers show conformance results for the APIs they claim. Each wave goes through change control with a rollback plan, parallel running and daily reconciliation of orders, services and inventory.
Before handover, order states, fallout by step, event delivery and API errors are in monitoring with thresholds. Support teams get runbooks for stuck, partial and rejected orders and for inventory drift. Hypercare, the period of extra support after go live, ends only when agreed criteria hold for a set period.
TM Forum revises its frameworks and APIs in regular releases. I keep a version roadmap for every interface, plan moves such as v4 to v5 as changes of their own, review autonomy levels each year against measured outcomes, and track each legacy system to its retirement date.
What it must do.
How well it must do it, with a number wherever one can be agreed.
Numbers are typical starting points. Each operator agrees its own.
| Tool or source | What it tells me |
|---|---|
| eTOM, SID and the Functional Framework | A common map for processes, data and systems |
| Open API conformance results and test kits | Which APIs a product really implements |
| Order management reports and fallout queues | Where orders stop today, and how often |
| Network discovery and controller exports | What the network really has, to compare with the inventory |
| API gateway and event logs | Who calls what, how often, and with which errors |
| ServiceNow or another ITSM (IT service management) tool | Ticket volumes and causes, linked to orders and services |
| Sparx Enterprise Architect or LeanIX | A repository for the as is and target models |
In OSS and BSS, a fault is usually an order or a record whose state no longer matches reality. I find the first step where the two part company.
| Layer | What I check |
|---|---|
| Channel | What the customer or agent submitted, and what state they were shown. |
| Catalogue | Offer status, validity dates and the specifications and rules behind the offer. |
| Product order | Order and item states, validation errors, and the events published to listeners. |
| Service order | Decomposition results, service order states and the activation jobs beneath them. |
| Activation and controller | Controller and element logs, configuration pushed, and timeouts or rollbacks. |
| Inventory and assurance | Inventory against discovery, resource to service links, and alarm correlation. |
My general method, with worked faults, is on the troubleshooting page.
An OSS and BSS stack stays healthy only if someone owns its fallout. I agree who does before go live.
Who owns each step: order management, NOC (network operations centre), service desk and each supplier, with escalation times in contracts.
A queue for orders needing a person, with owners, targets and a weekly review of the top causes.
Order states, cycle times, event delivery and API errors on dashboards, with thresholds tuned during hypercare.
Step by step guides for stuck, partial and rejected orders, inventory drift and lost listeners.
Catalogue, mapping and API changes go through change control and are tested with recorded orders first.
Monthly supplier reviews covering conformance, defects, version plans and the fallout they cause.
Frameworks, APIs and systems all move on. I plan their upkeep from the start.
TM Forum frameworks run through my telecoms work: high level designs for Virgin Media O2, automation architecture for Vodafone, and earlier roles building infrastructure for operators and their customers.
Produced high level designs for Virgin Media O2 across RAN, core, transport, OSS and BSS using TM Forum frameworks, and fed the architecture into its autonomous network and service orchestration roadmap.
Produced high level designs for Virgin Media O2 initiatives across RAN, core, transport and OSS and BSS using TM Forum frameworks, alongside multi vendor SD-WAN and SD-Access designs for enterprise clients.
Led discovery, due diligence and architecture for network infrastructure automation aligned to TM Forum and MEF standards, in support of Vodafone's digital customer platforms. The automation side is on the network automation page.
Tier 3 data centre and managed infrastructure for over 300 customer sites on Cisco ACI (Application Centric Infrastructure) and Nexus.
High and low level designs for BT's enterprise customers, including Rolls Royce, Virgin Money, Rio Tinto and Primark.
Cisco based telecoms infrastructure for over 4,000 clients across East Africa and South America.
TM Forum Architecture is listed with my delivery frameworks, and Python, Terraform, Ansible and ServiceNow cover the automation underneath. See all credentials
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.