SOM Decomposition & Orchestration
Last updated 12 Oct 2026
At a glance
SOM decomposes each CFS order item into technology-specific RFS items using catalog rules, then arranges them into an orchestration plan: what can run in parallel, what must wait, and what happens when something fails. This is where technology detail first enters the order.
The picture
One CFS order item, decomposed by a catalog rule, planned as dependency-ordered waves, dispatched to ROM
1 · CFS order item
CFS:Internet-Access
action: add · downloadSpeed=200
Address qualifies for: GPON
2 · RFS set by technology
IF technology = GPON
ELSE IF technology = HFC (not taken)
CPE and Wi-Fi CFS items in the same order add their own RFS
3 · Orchestration plan
Wave 1 · parallel
GPON-BearerCPE-Provisioning (ship)Wave 2 · after wave 1
VLAN-ServiceTR069-ConfigWave 3 · after wave 2
IP-ProfileQoS-ProfileCloud-Controller-Link
A failure in a wave holds the waves after it; compensation may undo the waves before
4 · Dispatch
ROM
resource orders per RFS
COM
state events via TMF641
How it works
CFS to RFS
The service catalog holds rules for how each CFS maps to RFS. The same CFS can map to quite different RFS sets depending on the access technology at the address:
| CFS | Technology | RFS set |
|---|---|---|
| Internet Access | GPON | GPON-Bearer, VLAN-Service, IP-Profile, QoS-Profile |
| Internet Access | HFC / DOCSIS | DOCSIS-Bearer, CM-Config, IP-Profile, QoS-Profile |
| Internet Access | Fixed wireless | FWA-Radio-Link, IP-Profile, QoS-Profile |
That branching is the reason CFS exists as its own layer: it keeps technology choices out of the product layer.
Design time or runtime
Some decisions are fixed at design time because they never vary: broadband always needs an IP profile. Others can only be made at runtime: which technology the address supports, whether an OLT port can be reused, whether the customer already has a CPE. Mature catalogs hold runtime branching as decision tables (IF technology=GPON THEN RFS:GPON-Bearer), so a new technology is catalog configuration rather than SOM code.
Dependencies
Items depend on each other because some services cannot exist before others. Dependencies come from the catalog (design time) and from conditions found during the order (runtime).
| Type | Meaning | Example |
|---|---|---|
| Finish-to-start | B starts only when A finishes | QoS only after the bearer exists |
| Start-to-start | B may start once A has started | Billing activation once service activation starts |
| Mutual exclusion | A and B never run together | Two configuration pushes to one network element |
| Conditional | B runs only if A gives a certain result | A manual task only if automated activation fails |
A circular dependency deadlocks the engine. SOM should reject it when it validates the plan, with a clear error, rather than wait forever.
The orchestration plan
SOM turns the items and their dependencies into a plan: a directed acyclic graph of tasks with conditional branches (a field visit only if there is no CPE) and a timeout per task for jeopardy. It then starts every task with no open dependency, waits for completion events, releases the tasks those completions unblock, and on failure applies the compensation rules. Patterns in the plan are parallel, sequential, fork-join, conditional and retry with backoff.
Order states
TMF641 states mirror the TMF622 product order states: acknowledged, inProgress, held (waiting for intervention), pending (waiting for a scheduled event such as an appointment), completed, failed (after compensation), cancelled and partial (some items done, some failed, awaiting a decision).
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| CFS-to-RFS decomposition rules | Service Catalog | — | SOM | TMF633. Decision tables live here, not in SOM code. |
| Orchestration plan | SOM | — | — | Generated per order; not exposed through a TM Forum API. |
| Service Order and item states | SOM | — | COM | TMF641, reported to COM as state-change events. |
| Address serviceability | Resource Inventory (network coverage) | Channel / CRM (pre-order) | SOM | Answered by service qualification (TMF645) before the order; decides which RFS branch is taken. |
In practice
Most implementations decompose from the catalog but run common order types from pre-defined templates, sometimes called golden paths: "new GPON broadband", "speed upgrade", "cease". These cover most orders; unusual combinations fall back to a plan generated from catalog rules.
In older estates the decomposition is often not in the catalog at all. It lives in workflow code or in an integration layer, one product at a time, and is found only when a new technology needs it changing in many places.
The trade-off
What it solves
One customer-facing service can be delivered over several technologies, and new technologies can be added in the catalog without changing products or SOM code.
What it does not solve
- Bad serviceability data. A wrong answer about the address picks the wrong branch.
- Untested combinations. Rules generate plans nobody has run before.
- Services delivered before the model existed, which have no RFS lineage to decompose from.
What it adds
- Rules and dependencies must be modelled, versioned and tested like code.
- Dynamically generated plans are harder to predict and to debug than fixed workflows.
- Compensation has to be designed for every step that can fail after an earlier one succeeded.
Architecture decision
Where should decomposition and sequencing logic live?
In the catalog (rule-driven)
Choose when many products and technologies, frequent catalog change, and a team able to test rules as rigorously as code.
In workflow templates (process-driven)
Choose when few order types, stable technology, and auditors or operations who need to read each path explicitly.
Catalog decomposition, template execution
Choose when the catalog decides what is needed and templates decide how common orders run, with rule-generated plans for the rest.
Breaks if technology branching is coded inside SOM workflows, product by product. Adding one access technology then means changing every workflow that touches it.
Takeaways
Key Takeaways
- SOM decomposes CFS into RFS from catalog rules; the RFS set depends on the access technology
- Some decisions are design-time, others runtime; decision tables keep runtime branching in the catalog
- Dependencies (finish-to-start, start-to-start, exclusion, conditional) shape the orchestration plan
- TMF641 order states include held, pending and partial, not just in progress and done
Check yourself
The same Internet Access order produces different RFS at two addresses. Which input made the difference, and where does the rule live?Show answerHide
The serviceability of each address (which access technology it supports). The rule that maps CFS to RFS per technology lives in the service catalog, ideally as a decision table.
QoS application fails after the VLAN was assigned. What should SOM do?Show answerHide
Apply the compensation rules: retry if the failure is transient, otherwise release the VLAN (and anything else the failed step depended on) or route to a manual queue, and report the item state to COM.
What does the TMF641 state "partial" tell COM?Show answerHide
Some service order items completed and others failed, and a decision is needed: accept the partial result or roll back.