OSS Functional Layering & Cross-Domain Orchestration
A strict functional layering of the OSS runtime path β CRM/CPQ, COM/SOM, cross-domain service orchestration, ROM / domain execution β and why each layer is a distinct product category. Clarifies where Itential, Ericsson Order Care, Hansen Order Management, Cisco NSO, Nokia E2E SO, Ericsson SOA, Blue Planet MDSO, and Oracle Unified Orchestrator actually sit.
OSS architectures are routinely miscommunicated. Automation tools are described as orchestrators. COM/SOM systems are described as cross-domain orchestrators. ROM systems are described as service orchestrators. The labels collapse, the layers blur, and transformation programmes inherit a fuzzy reference architecture that does not survive contact with a real network.
This section introduces a strict functional layering for the OSS runtime path, and names four distinct product categories that routinely get conflated: COM/SOM order management, cross-domain service orchestration, ROM / domain execution, and automation / workflow platforms. Each layer has a specific responsibility, a specific set of vendors, and cannot substitute for the others.
The OSS Functional Layering Model
The runtime path from a captured order to a configured network element spans four operational layers above the network itself. Each layer consumes an abstraction from the layer above and exposes a more abstract contract to the layer below. Collapsing any two of these into one product creates a recognised anti-pattern.
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.
Layer responsibilities and what each layer is not
| Layer | Owns | Does NOT own | Typical vendors |
|---|---|---|---|
| CRM / CPQ | Customer, account, opportunity, quote, commercial configuration | Service decomposition, network orchestration, device config | Salesforce, Siebel, Dynamics, vendor-native CPQ |
| COM / SOM | Commercial order capture, business/service-level decomposition (CFSβRFS), order lifecycle, jeopardy, SLM hand-off | Device configuration, VNF lifecycle (cross-domain orchestration may be combined in the same product β see Nokia) | Ericsson Order Care, Hansen Order Management, Amdocs, Netcracker, Comarch, Cerillion, Nokia Orchestration Center (also spans the layer below) |
| Cross-domain service orchestration | Technical/execution-level service decomposition, multi-domain workflow, coordination across IP, transport, access, 5G, cloud | Device-level configuration (commercial order state and CFS catalog ownership sit in COM/SOM β may be co-located in the same product) | Ericsson Service Orchestration & Assurance, Blue Planet MDSO, Oracle Unified Orchestrator, Nokia Orchestration Center (combined SOM + XDO) |
| ROM / domain execution | Resource order execution within a single domain, device/element configuration, VNF/CNF lifecycle, IP/number/spectrum allocation | Cross-domain coordination, commercial context, service-level saga orchestration | Cisco NSO, Nokia NSP, Juniper Paragon, ETSI MANO (NFVO/VNFM/VIM), IPAM, WFMS |
| Automation / workflow platforms | Task orchestration, pre/post checks, golden-config audit, multi-tool workflow glue, API abstraction | Service decomposition, commercial state, TMF service lifecycle, cross-domain service model | Itential, Ansible / AWX, StackStorm, custom runbook engines |
Automation Platforms Are Not Cross-Domain Orchestrators
Itential is a network automation and workflow integration platform. It is often positioned incorrectly alongside TMF-aligned service orchestration products. It is not one, and it was never designed to be one.
The Cross-Domain Service Orchestration Layer
Cross-domain service orchestration is a distinct OSS product category. It sits between the COM/SOM layer above and the ROM / domain execution layer below. Its purpose is to take a service-level fulfilment request, decompose it into a technical execution plan that spans multiple network domains, and coordinate the domain controllers that actually change the network.
- Receives a service fulfilment request from COM/SOM (typically a CFS/RFS-level instruction)
- Decomposes it at the execution level β which domains are involved, which controllers, in what order
- Coordinates multi-domain workflows across IP core, transport, access, mobile core, RAN, cloud/edge
- Calls into domain controllers (NSO, SDN controllers, MANO, IPAM, WFMS) and manages cross-domain dependencies and rollback
- Reports service-level execution status back to SOM
SOM performs service-level decomposition: it turns a commercial order and its CFS into RFS items, with service-lifecycle state, SLA metadata, and TMF641 semantics. Cross-domain orchestration performs execution-level decomposition: given an RFS (or a set of RFS items), which domain controllers need to act, with what payloads, in what order, and with what compensation logic if a step fails.
The two decompositions look similar on a whiteboard. They are not the same. SOM decomposition is driven by the service catalog. Cross-domain orchestration is driven by the network topology and domain capabilities.
- Domain heterogeneity: IP, transport, optical, RAN, mobile core, cloud and access each have different controllers, models, pacing and failure modes. Expecting SOM to understand all of them breaks SOM.
- Change-window and network-state semantics: execution ordering depends on live topology, maintenance windows, and capacity β concerns that do not belong in a service catalog.
- Rollback and compensation scope: cross-domain rollback is a different problem from service-order saga rollback. It is executed against live network state, not order state.
- Vendor decoupling: the orchestration layer insulates SOM from domain-controller churn (NSO upgrades, MANO swaps, SDN controller replacements).
Cross-Domain Orchestration Products
The products below all deliver cross-domain service orchestration. They differ in how much of the SOM layer above they also cover β some are narrow cross-domain orchestrators paired with a separate SOM, others (notably Nokia Orchestration Center) combine SOM and cross-domain orchestration in a single product. The architectural layering remains valid regardless β the two functions are distinct even when one product owns both.
Nokia Orchestration Center (FlowOne)
Catalog + COM + SOM + cross-domain orchestration in one product β spans three layers
- Explicit COM (Orderhub) and SOM split, with unified catalog and inventory modules β TMF/ODA aligned
- Same product performs multi-vendor, multi-domain network orchestration across 5G slicing, SD-WAN, IP/transport
- Part of the Nokia Digital Operations Center (with Assurance Center and Unified Inventory)
- Anchor deployment example: stc for 5G slicing and monetisation
- In hybrid deployments the operator can bypass the COM layer and use the product from SOM downward via an anti-corruption layer β the layering still applies internally
Ericsson Service Orchestration & Assurance
Cross-domain orchestration + closed-loop assurance β sits alongside Ericsson Order Care
- Multi-domain workflow coordination across mobile core, RAN, transport, cloud
- Distinct product from Ericsson Order Care (the COM/SOM system)
- Not a ROM and not an automation platform
- Integrates with SOM above and with domain/EMS/NMS below via APIs
Blue Planet (Ciena) MDSO
Multi-Domain Service Orchestrator focused on the orchestration layer
- Execution-level decomposition across packet, optical, and SDN domains
- Drives multiple domain controllers through model-driven workflows
- Typically deployed alongside a separate commercial/service order management system
- Not a ROM β sits above domain controllers, not inside them
Oracle Unified Orchestrator
Cross-domain orchestration paired with Oracle OSM for the COM/SOM layer
- Coordinates fulfilment across multiple network and IT domains
- Distinct from Oracle OSM, which carries the COM/SOM responsibilities in the Oracle portfolio
- Not a ROM β delegates execution to domain controllers and activation engines
- Integrates via APIs with upstream order management and downstream domain systems
COM/SOM Systems Are Not Cross-Domain Orchestrators
Several products that appear in architecture diagrams as "orchestrators" are in fact COM/SOM order management systems. They perform order capture, business/service-level decomposition, and order lifecycle management. They do not perform multi-domain network orchestration.
ROM and Domain Controllers Are Not Orchestrators
The domain execution layer holds the systems that actually change the network: resource order managers, domain controllers, NFV MANO stacks, element management systems, IP/number management, and workforce management. They operate within a single domain and expose execution primitives (configure VRF, instantiate VNF, allocate IP, dispatch technician). They are not cross-domain orchestrators, and they are not automation platforms.
- Cisco NSO β multi-vendor device configuration within a network domain. Transactional, model-driven, YANG-based. Not cross-domain at the service level.
- ETSI MANO (NFVO/VNFM/VIM) β VNF/CNF lifecycle on virtualised infrastructure. Not a service orchestrator.
- SDN controllers, IPAM, WFMS β domain-specific execution engines consumed by the orchestration layer above.
Strict Architectural Rules
Layering rules that must not be violated
- COM/SOM β cross-domain service orchestration. Order decomposition is not the same as execution decomposition.
- Cross-domain service orchestration β automation (Itential, Ansible, StackStorm). Workflow glue is not a service model.
- ROM / domain controllers β orchestration. A single-domain execution engine cannot be a multi-domain orchestrator.
- Each layer owns its own state and contract. A product may span adjacent layers (notably SOM + cross-domain orchestration), but the functions inside that product still have to be kept architecturally distinct.
- Do not blur SOM decomposition with orchestration decomposition. They use different catalogs, different inputs, and different rollback scopes β even when they live inside the same product.
- If a product with narrow scope is asked to operate across two layers it was not built for, expect the lower-layer responsibilities to atrophy or the upper-layer contract to leak.
Common Misconceptions and Anti-Patterns
Misconception vs architectural reality
| Common misconception | Architectural reality |
|---|---|
| "Itential is our service orchestrator." | Itential is an automation / workflow platform. It sits inside the domain execution layer as glue around controllers like NSO. It does not carry a TMF service model. |
| "Ericsson Order Care handles cross-domain orchestration." | Order Care is a COM/SOM system. Cross-domain orchestration is delivered by a separate product (for example, Ericsson Service Orchestration & Assurance). |
| "Hansen Order Management is our orchestrator." | Hansen OM is a COM/SOM system. Multi-domain network orchestration must be delivered by a dedicated cross-domain orchestration product. |
| "We use NSO as our service orchestrator." | NSO is a domain controller for device configuration. Treating it as the cross-domain service orchestrator collapses the orchestration layer into the execution layer and forces service semantics into YANG models. |
| "Our pure COM/SOM system will pick up the cross-domain orchestration as well." | A COM/SOM system built only for service-order decomposition cannot be retrofitted into a cross-domain orchestrator β the result overloads the service catalog with network-implementation detail. Products purpose-built to cover both (e.g. Nokia Orchestration Center) are a different case: they expose the cross-domain orchestration function internally, rather than pretending it does not exist. |
| "The cross-domain orchestrator will capture the order." | Order capture, commercial state, SLM hand-off, and TMF622/TMF641 contract ownership belong in COM/SOM. A cross-domain orchestrator that absorbs these stops being an orchestrator. |
Section 11.5 Key Takeaways
- OSS has four functionally distinct layers above the network: CRM/CPQ, COM/SOM, cross-domain service orchestration, and ROM / domain execution (which includes automation platforms as local glue).
- Cross-domain service orchestration is a distinct function with dedicated products β Ericsson Service Orchestration & Assurance, Blue Planet MDSO, Oracle Unified Orchestrator β and Nokia Orchestration Center (FlowOne) delivers both SOM and cross-domain orchestration in one product.
- COM/SOM systems that do not perform cross-domain network orchestration (Ericsson Order Care, Hansen Order Management, Amdocs, Netcracker, Comarch, Cerillion) still need a dedicated cross-domain orchestration layer below them.
- ROM and domain controllers (Cisco NSO, MANO, SDN controllers) are not cross-domain orchestrators.
- Itential is an automation / workflow platform that sits inside the domain execution layer, not above it.
- The fastest way to derail a transformation programme is to let one product cover two of these layers.