OSS Functional Layering & Cross-Domain Orchestration
Last updated 13 Oct 2026
At a glance
The runtime path from a captured order to a configured network element crosses four layers: CRM/CPQ, COM/SOM, cross-domain service orchestration and ROM / domain execution. Each owns a different truth and exposes a different contract. Products that span layers are common; the functions inside them stay distinct, and blurring them is where many programmes go wrong.
The picture
Customer, account, opportunity, quote, commercial configuration
Commercial + service-order decomposition (CFS→RFS), lifecycle, SLM hand-off
Execution-level decomposition + multi-domain workflow across IP, transport, access, 5G, cloud
Resource order execution, device/VNF config, per-domain controllers and automation glue
Routers, switches, optical, RAN, mobile core, CPE, NFVI, cloud infra
Why Cross-Domain Orchestration Is Its Own Layer
Service-order decomposition in SOM is driven by the service catalog. Execution decomposition in a cross-domain orchestrator is driven by live network topology, per-domain controllers, change windows, and multi-domain rollback semantics — different problems, different inputs, different failure modes.
◆ Products Can Span Layers
Nokia Orchestration Center (evolved from FlowOne) is the clearest example — it has an explicit COM/SOM split and performs cross-domain, multi-vendor network orchestration in a single product. Recognising a product spans layers is not the same as collapsing them: the two functions remain architecturally distinct and must still be designed, governed, and reasoned about separately.
Where Itential Actually Sits
Itential is a network automation and workflow integration platform. It lives inside the domain execution layer as glue around controllers like Cisco NSO, SDN controllers and IPAM. It is not a cross-domain service orchestrator, does not perform TMF-style service decomposition, and does not act as a service lifecycle engine.
How it works
Order Management decided what must be delivered. This module is about how it is coordinated across the network’s technical domains. What the work needs from inventory and activation comes next, in Module 10, and the domains themselves in Module 9.
Four layers above the network
Each layer consumes an abstraction from the layer above and offers a more concrete contract to the layer below. Collapse two layers into one product and the contract between them disappears.
| Layer | Owns | Does not own |
|---|---|---|
| CRM / CPQ | Customer, account, opportunity, quote, commercial configuration | Service decomposition, orchestration, device configuration |
| COM / SOM | Order capture, service-level decomposition (CFS → RFS), order lifecycle, jeopardy, SLM hand-off | Device configuration, VNF lifecycle |
| Cross-domain service orchestration | Execution-level decomposition, multi-domain workflow across IP, transport, access, 5G and cloud | Commercial order state, the CFS catalog, device-level configuration |
| ROM / domain execution | Resource orders within one domain, device and VNF/CNF configuration, IP, number and spectrum allocation | Cross-domain coordination, commercial context, service-level saga |
Each layer encodes a different truth. COM/SOM holds the commercial and service-order truth. Cross-domain orchestration holds the multi-domain execution plan. ROM and domain controllers hold the device-level intended state. Automation platforms hold the operational runbook.
The cross-domain orchestration layer
- Receives a service fulfilment request from SOM, usually at CFS/RFS level
- Works out which domains, which controllers and in what order
- Coordinates workflows across IP core, transport, access, mobile core, RAN and cloud/edge
- Calls domain controllers (NSO, SDN controllers, MANO, IPAM, WFMS) and manages cross-domain dependencies and rollback
- Reports execution status back to SOM
Two decompositions that look alike
| SOM decomposition | Cross-domain decomposition | |
|---|---|---|
| Question | Which RFS does this CFS need? | Which controllers act, with what payloads, in what order? |
| Driven by | The service catalog | Network topology and domain capabilities |
| State | Service-order lifecycle, SLA metadata, TMF641 semantics | Execution plan against live network state |
| Rollback | Service-order saga | Compensation against the network |
The layer exists separately for four reasons:
- Domain heterogeneity. Each domain has its own controllers, models, pacing and failure modes. Teaching SOM all of them breaks SOM.
- Network-state semantics. Ordering depends on live topology, maintenance windows and capacity, which do not belong in a service catalog.
- Rollback scope. Cross-domain rollback runs against network state, not order state.
- Vendor decoupling. The layer shields SOM from controller churn: NSO upgrades, MANO swaps, SDN controller replacements.
What sits in the other layers
COM/SOM systems such as Ericsson Order Care and Hansen Order Management handle order capture, service-level decomposition and order lifecycle. They do not coordinate multi-domain network execution; that needs a product in the layer below.
ROM and domain controllers change the network within one domain and expose execution primitives: configure a VRF, instantiate a VNF, allocate an IP, dispatch a technician. Cisco NSO configures multi-vendor devices within a domain, transactionally and model-driven. ETSI MANO (NFVO, VNFM, VIM) runs VNF/CNF lifecycle. SDN controllers, IPAM and WFMS are domain execution engines consumed from above.
Automation platforms such as Itential, Ansible/AWX and StackStorm run runbooks, chain API calls, and wrap device changes in pre-checks, post-validation, dry-runs and rollback triggers. They do not hold a CFS/RFS model, consume TMF641 service orders or manage multi-domain service state.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Service Order and CFS → RFS decomposition | SOM | — | Cross-domain orchestrator | TMF641. Driven by the service catalog. |
| Cross-domain execution plan | Cross-domain orchestrator | — | SOM (status only) | Which domains, which controllers, what order, what compensation. Not exposed as a commercial entity. |
| Device-level intended configuration | Domain controller / ROM | — | Cross-domain orchestrator | For example the NSO service instance or a MANO VNF record. One domain each. |
| Operational runbook (pre/post checks, golden config) | Automation platform | — | — | Holds no service-lifecycle state. |
In practice
Products do not line up neatly with layers. Nokia Orchestration Center (evolved from FlowOne) has an explicit COM/SOM split internally and also performs multi-vendor, multi-domain network orchestration. In hybrid deployments an operator can use it from SOM downward behind an anti-corruption layer. The layering still applies inside it.
| Product | Layer it covers | Usually paired with |
|---|---|---|
| Ericsson Service Orchestration & Assurance | Cross-domain orchestration plus closed-loop assurance | Ericsson Order Care for COM/SOM |
| Blue Planet (Ciena) MDSO | Cross-domain across packet, optical and SDN | A separate order management system |
| Oracle Unified Orchestrator | Cross-domain across network and IT domains | Oracle OSM for COM/SOM |
| Nokia Orchestration Center | Catalog, COM, SOM and cross-domain in one | Nokia Assurance Center and Unified Inventory |
COM/SOM products from Amdocs, Netcracker, Comarch and Cerillion likewise still need a cross-domain layer below them where the estate has several network domains.
The trade-off
What it solves
Separating service-order decomposition from execution decomposition lets SOM stay catalog-driven while the network domains change, and gives cross-domain rollback a clear owner.
What it does not solve
- Weak domain controllers. A cross-domain orchestrator cannot hide a domain that has no service-level API.
- A poor service catalog. Execution decomposition starts from the RFS SOM hands down.
- Organisational ownership. Someone still has to own each layer’s model and contract.
What it adds
- Another product category to buy, integrate and run, with its own state to reconcile.
- Two decompositions to keep consistent when products or network domains change.
- Layer-spanning products need internal boundaries that are designed and governed even though one vendor ships them.
Architecture decision
How should SOM and cross-domain orchestration be packaged?
Separate products
Choose when several heterogeneous network domains, a COM/SOM product with no orchestration capability, and a wish to swap controllers without touching SOM.
One product spanning both
Choose when the product keeps an explicit internal SOM / orchestration split and the operator is prepared to govern the two functions separately.
SOM driving controllers directly
Choose when one or two simple domains with stable controllers and little cross-domain dependency.
Breaks if one product with narrow scope is stretched across two layers. The lower layer’s responsibilities wither, or the upper layer’s contract leaks network detail into the catalog.
Takeaways
Key Takeaways
- Four layers sit above the network: CRM/CPQ, COM/SOM, cross-domain service orchestration, and ROM / domain execution
- SOM decomposition is catalog-driven; cross-domain decomposition is driven by topology and domain capability
- Products may span layers; the functions inside them stay distinct and need separate design and governance
- Domain controllers such as Cisco NSO, MANO and SDN controllers act within one domain and are not cross-domain orchestrators
- Automation platforms such as Itential sit inside the domain execution layer; they hold no service model
Check yourself
A vendor proposes Itential as the cross-domain orchestrator for an SD-WAN and 5G programme. What would you check?Show answerHide
Whether it owns a CFS/RFS service model, consumes TMF641 service orders and manages multi-domain service-level state. If it does none of these, it is an automation platform that belongs inside the domain execution layer, and a cross-domain orchestrator is still needed.
An operator runs Ericsson Order Care and plans to call NSO, MANO and the RAN controller directly from it. What is missing?Show answerHide
The cross-domain orchestration layer. Order Care does service-level decomposition; something must still work out which controllers act in what order and own compensation against network state.
Why can SOM and cross-domain orchestration not share one decomposition model?Show answerHide
They answer different questions from different inputs: SOM maps CFS to RFS from the service catalog, the orchestrator maps RFS to controller actions from topology and domain capability, and their rollback scopes differ.