🔄

Section 3.10

Hybrid COM/SOM & the Anti-Corruption Layer

How most real transformations look — legacy COM retained, new TMF-aligned SOM introduced beneath it, bridged by an anti-corruption layer. Covers why operators keep legacy COM, what crosses the boundary (SKU→CFS in the ACL, CFS→RFS in SOM), where the product-to-CFS mapping lives, catalog governance in a hybrid, Spring Boot + Apache Camel implementation, and when the pattern becomes a clean-up-later smell.

Most real BSS/OSS transformations do not replace the commercial order management system. Legacy COM persists, and a new TMF-aligned SOM is introduced beneath it. The two are bridged by an anti-corruption layer (ACL) — an integration service that translates legacy XML orders into TMF641 service orders, and translates status events back. This section walks through that architecture, what actually crosses the boundary, where the product-to-service mapping lives, how catalog governance survives the split, and what a sensible implementation looks like.

Why this section matters

Greenfield BSS + OSS transformations are rare. The dominant pattern is a network-led programme that modernises SOM and the OSS execution path while leaving commercial order management, billing, CRM and channel integrations in place. Understanding the hybrid boundary — and its failure modes — is decision-critical for any telco architect working on a real transformation.

Why Operators Keep Legacy COM

The decision to leave legacy COM in place is rational and deliberate. It is not a failure of ambition — it is a recognition that the commercial stack is entangled with systems that cost far more to replace than the operational pain justifies.

The pain is downstream, not at order capture. Customers rarely complain about the order form — they complain that activations fail, provisioning takes days, and multi-domain services are handled by spreadsheets. That pain lives in SOM and orchestration.
Legacy COM is entangled with billing and charging, which is the single hardest BSS system to replace. Replacing COM pulls in rating, invoicing, collections, tax, revenue assurance — a 3–5 year programme.
Commercial catalog, pricing, discount rules, and channel integrations (retail, digital, dealer, IVR, partner portals) have been built up over many years. Migration produces no customer-visible value.
Financial history and audit trails cannot be abandoned. Years of orders, tax calculations, and regulated records live in legacy COM.
Network drives the programme. 5G, SD-WAN, or IP/optical transformation is usually the trigger — funded by CTO, not CIO. BSS is explicitly out of scope.
Risk and sequencing. A narrow SOM replacement is a 12–18 month programme with low blast radius. A full BSS + OSS replacement is 3–5 years with correspondingly higher failure risk.

The Hybrid Flow

Legacy COM emits orders in its own XML, keyed by commercial SKU. The ACL translates those orders into TMF641 service orders with CFS references. SOM decomposes CFS into RFS and orchestrates execution. Status events flow back in reverse, translated by the ACL into whatever format legacy COM expects.

Forward path (order)Reverse path (status / events)

Legacy COM

Commercial order capture · commercial catalog (SKUs, pricing, bundling) · channel integrations · billing & SLM triggers

proprietary XML

Anti-Corruption Layer (ACL)

Protocol bridging (JMS/SOAP ↔ REST) · format transformation (XML ↔ JSON) · SKU → CFS resolution against a catalog · idempotency · correlation · audit · status translation (reverse)

Spring Boot + Camel

Does SKU→CFSDoes NOT do CFS→RFSNeeds catalog access

New SOM (TMF-aligned)

Service catalog ownership · CFS → RFS decomposition · service-order lifecycle · jeopardy · dispatch to execution engines

TMF641 / TMF638 / TMF633

Execution Layer

ROM · Cross-domain orchestration · MANO · NSO / SDN controllers · IPAM · workforce

Why the ACL is named "anti-corruption layer"

A DDD term (Eric Evans, 2003). Without deliberate isolation, legacy concepts — SKUs, bundle IDs, legacy status codes — leak into the clean TMF service model, and the new SOM quietly inherits the constraints you were trying to escape. The ACL is the only place that knows both models. Keep it that way.

Why the ACL does not do CFS → RFS

If the ACL pre-decomposes to RFS, the SOM loses its catalog-driven identity and becomes a workflow engine. The TMF641 contract is violated (TMF641 is a service-level order API, not resource-level). Keep the ACL thin — Product → CFS only. SOM owns CFS → RFS.

Hybrid COM/SOM flow with an anti-corruption layer — legacy XML/SKU in, TMF641/CFS across the boundary, CFS→RFS decomposition in SOM, and a reverse status path translated back to legacy format.

The forward and reverse path, step by step

Legacy COM emits an XML order

Legacy COM

Order lines identified by SKU (e.g. PROD_ENT_L3VPN_GOLD_100M) plus commercial characteristics (bandwidth, sites, availability). Sent over JMS / IBM MQ / SOAP — rarely sync REST.

ACL resolves SKU → CFS

Anti-Corruption Layer

For each order line, the ACL looks up the product-to-CFS mapping, maps legacy attributes to CFS service characteristics, and constructs a TMF641 service order. The ACL does NOT decompose to RFS.

SOM decomposes CFS → RFS

SOM

SOM receives TMF641, consults its service catalog to decompose each CFS into the required RFS items, with decomposition rules it owns. This is SOM's core catalog-driven responsibility.

SOM orchestrates RFSs

SOM → ROM / orchestration

SOM delegates each RFS to the correct execution engine — ROM for resource orders, cross-domain orchestration for multi-domain workflows, MANO for VNF lifecycle, NSO or SDN controllers for device configuration, workforce for physical installs.

Status events flow back in reverse

SOM → ACL → Legacy COM

RFS state transitions bubble up to CFS state, SOM emits TMF641 lifecycle events, the ACL translates them into legacy XML status codes, and legacy COM updates commercial order state — triggering billing, SLM hand-off, and collections.

What Actually Crosses the Boundary

The ACL does Product → CFS only. SOM still owns CFS → RFS.

A tempting mistake is to push both decomposition steps into the ACL — have it resolve SKU all the way to RFS, then hand SOM a pre-decomposed plan. That hollows out the SOM into a workflow engine and rebuilds the catalog-driven core inside the integration layer. The service catalog becomes decorative and the TMF641 contract is violated (TMF641 is a service-level order API, not a resource-level one). Keep the ACL thin — it translates the commercial/service crossing only.

Responsibility split across the hybrid boundary

Concern	Legacy COM	ACL	New SOM
Commercial order capture	Owns	—	—
Commercial catalog (SKU, pricing, bundling)	Owns	—	—
Product → CFS mapping	—	Owns (lookup)	—
Service catalog (CFS specs, characteristics)	—	—	Owns
CFS → RFS decomposition	—	—	Owns
Service order state (TMF641)	—	—	Owns
Commercial order state	Owns	—	—
Status event translation (both directions)	—	Owns	—
Billing / SLM hand-off trigger	Owns	—	—

Where the Product → CFS Mapping Lives

The product-to-CFS mapping is the most under-appreciated artefact in the hybrid architecture. It is a catalog whether the programme names it one or not — and wherever it lives becomes a de facto catalog team's responsibility.

A lookup table or rule set maintained inside the ACL itself. This is where most programmes accidentally end up.

Pros: easy to start with, no cross-system dependency for the ACL to run
Cons: becomes an undocumented, unversioned shadow catalog owned by no one
Failure mode: every new SKU requires a coordinated release across legacy COM catalog, TMF service catalog, and the ACL — time-to-market gated by the slowest link
Worst-case: the "mapping" is hard-coded Java — each new product is an engineering ticket

The Reverse Path Is Equally Important

Hybrid architectures fail on the reverse path more often than on the forward path. Legacy COM expects specific XML status codes at specific order-line granularity. CFS and RFS state transitions almost never map cleanly onto those codes. The ACL has to do the mapping in both directions — and that reverse mapping needs the same catalog awareness as the forward path.

State aggregation. Legacy COM may track one order line, but SOM tracks one CFS with N RFSs. An RFS failing is not necessarily an order-line failure. The ACL owns the aggregation rule.
Timing semantics. Legacy COM expects terminal states (activated, cancelled). SOM emits many intermediate events (in-progress, partially-provisioned, awaiting-resource). The ACL must filter or aggregate.
Billing trigger events. The moment at which legacy COM triggers billing may not match SOM's "service active" event. Getting this wrong causes revenue leakage or premature billing complaints.
Compensating actions. If SOM orchestration fails after partial success, legacy COM needs to know to reverse associated commercial state (orders, charges, inventory holds). The ACL must translate compensation events as first-class signals, not edge cases.

Catalog Governance in a Hybrid

A hybrid architecture creates a second catalog (the TMF service catalog) alongside the legacy commercial catalog. How the organisation governs this split is the single biggest determinant of whether the new stack is catalog-driven in practice or just catalog-shaped.

The team-merge anti-pattern

The default organisational path is to hand the TMF service catalog to the existing legacy commercial catalog team — they are already staffed, funded, and "know catalogs." This is usually wrong. Commercial and service catalogs model different things, serve different audiences, and change at different cadences. When commercial thinking dominates, the service catalog becomes a reflection of the price list: CFSes named after SKUs, characteristics that are repackaged commercial attributes, a new CFS for every product launch. The catalog exists on paper but is not load-bearing.

Commercial catalog vs TMF service catalog

Dimension	Commercial catalog	TMF service catalog
Models	Products, pricing, discounting, bundling, eligibility, promotions, tariffs, tax	CFS and RFS specifications, service characteristics, decomposition rules, SLAs, feasibility
Audience	Product managers, marketing, sales, finance	Network architects, OSS engineers, assurance teams
Change cadence	Frequent — every promotion, tariff, market campaign	Slower — tied to network capability changes
Skills required	Product modelling, pricing engines, bundle rules	Service modelling, CFS decomposition, network capability abstraction
Primary consumer	Legacy COM, CPQ, digital channels	New SOM, cross-domain orchestration, assurance

Healthy catalog governance

Two teams, one governance council — neither catalog should be owned by the other
Seed the service catalog team with a mix: some legacy catalog people (product knowledge), some network/OSS engineers (service knowledge)
The product→CFS mapping is its own artefact, owned by the council, not by either team alone
Track the rate of new CFS additions per quarter — if every new product requires a new CFS, the service catalog is disguised as a price list

Implementation Technology

The ACL is not exotic infrastructure. In practice it is a standard Java integration service — usually Spring Boot with Apache Camel. The language choice is usually the easiest decision; what determines success or failure is the runtime and governance concerns around it.

Spring Boot

The default Java application framework for microservices. Provides auto-configuration, starter dependencies, embedded servers, and production features (health, metrics, tracing). The ACL is typically a single executable JAR that runs under Kubernetes or a similar platform.

Apache Camel

An integration framework — not a web service — embedded inside the Spring Boot application. Provides a DSL for routes that combine protocol bridging (JMS ↔ REST ↔ Kafka), format transformation (XML ↔ JSON), routing, and the Enterprise Integration Patterns (splitters, aggregators, idempotent consumers, dead-letter channels).

What a Camel route looks like in practice

A typical ACL route receives legacy XML over JMS, deduplicates on the legacy order ID, parses the XML into a POJO, splits the order into lines, calls out to the catalog for SKU→CFS resolution, constructs TMF641, sends the result as JSON to SOM over REST, and retries with exponential backoff on transient errors. All of the above expressed in ~30 lines of route DSL, with the protocol adapters, retry policy, and dead-letter channel provided by Camel rather than hand-coded.

What actually determines ACL quality

Externalise the mapping. If product→CFS mapping is hard-coded Java, every new SKU is a deployment. Externalise it — config, DSL, or runtime catalog lookup. This is the single biggest signal of ACL quality.
Idempotency on the legacy order ID. Orders get retried. Every write downstream must be safe to repeat.
Correlation IDs end-to-end. Legacy order ID → TMF641 ID → SOM service order ID → RFS IDs → and back. Propagate as OTel baggage or an explicit correlation field. Debuggability of the hybrid flow depends on this.
Queue decoupling. Sync REST across a legacy boundary is a cascading failure waiting to happen. Use JMS / IBM MQ / Kafka between legacy COM and the ACL.
Schema binding from generated code. JAXB/XJC for the legacy XML, generated TMF641 classes from the OpenAPI spec. Hand-written POJOs rot.
Audit logging. Every order decision (input, mapping lookup, output, outcome) must be reconstructable — legally required in most jurisdictions, operationally required everywhere else.
Error taxonomy. Validation errors (reject to legacy), transient errors (retry), catalog misses (escalate — this is usually a missing product→CFS mapping), downstream failures (compensate). Never collapse these into a single "error" code.
TMF641 version pinning. TMF641 has evolved across v4/v5. Pin the version, plan the upgrade as its own effort.

When to reach for an ESB or iPaaS instead

Commercial ESBs (MuleSoft, WSO2, webMethods, IBM Integration Bus) and iPaaS platforms (Boomi, Azure Logic Apps) can implement the same pattern with visual tooling. They make sense when the organisation already has the platform, the skills, and the governance; they are usually over-specified for a single ACL. For a greenfield integration layer serving a single transformation programme, Spring Boot + Camel is lighter, cheaper, and easier to staff.

When Is the Hybrid the Right Call?

Right call vs "clean-up later" smell

Signal	Right call	Smell
Exit plan for legacy COM	Defined, funded, with a kill date — even if multi-year	Undefined — "we'll replace it eventually"
Scope of new SOM	Clear segmentation (new product lines, specific customer segments, or named products)	Everything, slowly, with no segmentation rule
ACL treatment	Treated as scaffolding with a defined kill date	Treated as permanent architecture and hardened accordingly
Catalog governance	Two teams, one council, mapping owned as a first-class artefact	Single team inherits both; mapping lives in the ACL code
Feature requests	New features go into either legacy COM or new SOM — never the ACL	ACL becomes a feature target; business logic accretes in the bridge
Funding model	Network-led programme with an agreed BSS modernisation follow-on	Network-led programme with no BSS modernisation plan at all

The "clean-up later" anti-pattern

If the ACL has no defined kill date, no one owns the legacy COM exit plan, and business logic starts accreting in the bridge, the hybrid is not a transition — it is the architecture. At that point the organisation has paid for a new orchestration stack and kept the original problem, and the cumulative cost of running both systems forever is usually higher than a proper replacement would have been.

Section 3.10 Key Takeaways

Hybrid COM (legacy) + SOM (new) is the dominant pattern in real telco transformations — not a failure of ambition, but a rational scope-limiting choice driven by the cost of replacing billing.
The bridge between them is an anti-corruption layer (ACL) — a DDD pattern whose purpose is to prevent legacy concepts from leaking into the new service model, and vice versa.
The ACL does product → CFS only. CFS → RFS decomposition stays in SOM — pushing it into the ACL hollows out the SOM and violates the TMF641 contract.
The product → CFS mapping is a catalog whether you call it one or not. Whoever owns it is a catalog team — plan for that, or the mapping rots in the bridge.
The reverse status path is as important as the forward path and is where hybrid designs most often fail in production.
Commercial and service catalogs model different things. Merging the teams that own them usually shrinks the TMF catalog into a disguised price list.
Spring Boot + Apache Camel is the default implementation stack. The hard choices — externalising the mapping, correlation IDs, idempotency, audit, error taxonomy — are what determine whether the ACL is load-bearing infrastructure or permanent technical debt.
The hybrid only works as a transition. An ACL without a defined kill date becomes permanent architecture — and the organisation pays for the new stack and keeps the original problem.