Anti-Patterns & Failure Scenarios
Common architectural mistakes in telco BSS/OSS implementations. Each scenario includes the symptoms you will see, the root cause, and the correct pattern to follow.
Showing 7 of 7 scenarios
Situation
Product and service definitions are hardcoded across multiple systems — CRM, billing, order management, and provisioning each maintain their own local definitions of what products and services exist. There is no single catalog that all systems reference.
Symptoms
- •New product launches take 6–12 months because every system must be updated independently
- •Price discrepancies between the webshop, retail POS, and billing system
- •CRM shows products that billing cannot charge for
- •Order management rejects valid configurations because its hardcoded rules are out of sync
- •No ability to retire a product across all channels simultaneously
- •MACD (Modify, Add, Change, Disconnect) operations fail because systems disagree on what the customer has
Architecture View
Anti-Pattern: No centralised catalog — each system hardcodes its own product definitions
Root Cause
The architecture was built system-by-system over time. Each system was procured independently and implemented its own understanding of the product portfolio. No catalog-driven design principle was established, so product knowledge became embedded in code, configuration files, and database tables scattered across the stack.
Why It Persists
Each system team considers their local definitions "correct" and resists centralisation because it means giving up control. Migration to a central catalog requires mapping every local definition to a canonical model — a massive data reconciliation effort. Additionally, vendor contracts may lock product logic inside proprietary systems, making extraction difficult.
Correct Pattern
Implement a centralised Product Catalog (TMF620) as the single source of truth for all product offerings, specifications, and rules. All downstream systems — CRM, COM, billing, SOM — consume catalog definitions via API rather than maintaining local copies. The catalog defines what can be sold, how it decomposes into services (CFS), and what pricing applies. Changes propagate automatically to all consumers.
Situation
The CRM system has been extended to serve as the source of record not just for customers and accounts, but also for orders, products, services, and even network resource assignments. Custom objects and fields in the CRM hold data that should live in dedicated BSS/OSS systems.
Symptoms
- •CRM performance degrades as it stores millions of service and resource records it was never designed to handle
- •Order status is tracked in CRM custom fields instead of a dedicated order management system
- •Service activation teams query CRM for technical details like VLAN IDs and IP addresses
- •No clean API boundary — integrations are built around CRM data exports and batch syncs
- •CRM upgrades become impossible because custom objects break with every vendor patch
- •Reporting requires complex joins across CRM custom objects that do not map to any standard model
Architecture View
Anti-Pattern: CRM overloaded as SoR for customers, orders, products, services, and resources
Root Cause
CRM was the first enterprise system deployed and became the default place to store "everything about the customer." As new needs arose (order tracking, service status, resource assignments), they were bolted onto CRM rather than procured as separate systems with clear SoR boundaries. The CRM vendor may have encouraged this by selling add-on modules.
Why It Persists
The CRM is deeply embedded in every process. Sales, support, and operations all use it daily. Extracting data domains into dedicated systems requires re-training, process redesign, and migration of years of accumulated data. The cost and risk of decomposition is perceived as higher than living with the status quo, even though the status quo is increasingly fragile.
Correct Pattern
Apply Source-of-Record discipline per TM Forum SID boundaries. CRM owns Customer, Account, and Contact (SID Party domain). Orders belong to COM (TMF622). Product instances belong to Product Inventory / SLM (TMF637). Service instances belong to Service Inventory (TMF638). Resource assignments belong to Resource Inventory (TMF639). CRM becomes a System of Engagement (SoE) that reads from these systems rather than storing their data.
Related Sections
Situation
Commercial Order Management (COM) sends resource-level instructions directly to Resource Order Management (ROM) or activation systems, completely bypassing Service Order Management (SOM). There is no service orchestration layer to decompose commercial orders into service orders.
Symptoms
- •No service inventory — nobody knows what services a customer actually has active
- •Cannot perform service-level impact analysis when a network element fails
- •MACD operations require manual coordination because there is no service context
- •Multi-resource services (e.g., SD-WAN with multiple sites) cannot be orchestrated as a unit
- •Billing disputes are common because there is no service-level record linking orders to active services
- •Rollback of a failed order requires manual reversal of each resource change individually
Architecture View
Anti-Pattern: COM sends directly to ROM — SOM is bypassed, no service orchestration layer
Root Cause
The architecture was designed with only two layers in mind: commercial (what the customer buys) and physical (what gets provisioned on the network). The concept of a logical service layer — where CFS decomposition, service lifecycle, and service inventory live — was either not understood or deemed unnecessary complexity.
Why It Persists
For simple, single-resource products (e.g., a basic broadband line), the shortcut works "well enough." The pain only becomes acute with multi-component services, bundles, or when service assurance needs arise. By that point, COM→ROM integrations are deeply embedded and adding SOM in the middle requires re-architecting the entire order flow.
Correct Pattern
Implement SOM as the mandatory orchestration layer between COM and ROM. COM decomposes commercial orders into service orders based on CFS definitions from the service catalog. SOM then decomposes each service order into resource orders based on RFS mappings and sends them to ROM. SOM maintains the Service Inventory (TMF638) and provides service-level lifecycle management.
Related Sections
Situation
The NFV MANO platform (NFVO/VNFM) is being used not just for VNF lifecycle management but as the primary service orchestration engine. Business logic, service decomposition, and multi-domain coordination are implemented inside MANO workflows instead of SOM.
Symptoms
- •MANO workflows contain business rules about product bundles and customer tiers
- •Service changes that do not involve VNFs still route through MANO
- •MANO becomes a bottleneck because it handles both infrastructure and service-level concerns
- •Physical network functions (PNFs) cannot be orchestrated because MANO only understands VNFs
- •Day-2 service operations (e.g., bandwidth upgrades) require MANO workflow changes instead of service catalog updates
- •MANO vendor lock-in increases because service logic is embedded in their proprietary workflow engine
Architecture View
Anti-Pattern: MANO (NFVO) used as service orchestrator — business logic embedded in VNF lifecycle platform
Root Cause
When NFV was introduced, MANO was the most capable orchestration platform available. Rather than investing in a separate SOM layer, the team extended MANO upward to handle service-level concerns. The ETSI NFV MANO framework defines clear scope boundaries (VNF lifecycle, NS lifecycle), but these were ignored in favour of expediency.
Why It Persists
The MANO platform works for VNF-centric services, and the team has built significant expertise in its workflow engine. Extracting service logic into a dedicated SOM requires acknowledging that MANO was misused, re-implementing workflows, and potentially procuring a new system. The sunk cost in MANO customisation makes this politically difficult.
Correct Pattern
Restrict MANO (NFVO/VNFM) to its ETSI-defined scope: VNF instantiation, scaling, healing, and termination (Day-0/Day-1 lifecycle). Service orchestration — including CFS→RFS decomposition, multi-domain coordination, and service lifecycle — belongs in SOM. SOM calls MANO as one of several resource-domain controllers alongside NSO (for device configuration) and other activation adapters.
Related Sections
Situation
There is no Product Inventory or Subscription Lifecycle Management (SLM) system. Once an order is fulfilled, there is no persistent record of what the customer has. Billing maintains charge records, and the network has active services, but no system owns the "truth" of what was sold and what the customer is entitled to.
Symptoms
- •Billing charges for services that were disconnected months ago
- •Customers receive bills for products they never ordered (ghost subscriptions)
- •MACD operations fail because there is no baseline to modify — each change is treated as a new order
- •Contract renewal and upsell campaigns target customers with incorrect product data
- •Disconnect orders cannot be validated because there is no record of what needs disconnecting
- •Revenue assurance flags thousands of discrepancies between billing and network state every month
Architecture View
Anti-Pattern: No Product Inventory — order is fire-and-forget, billing becomes de facto SoR
Root Cause
The order management process was designed as a one-shot workflow: capture order → provision → bill. Nobody designed the "steady state" — the ongoing record of what the customer has after the order is complete. Billing was assumed to be the de facto record of active products, but billing records reflect charge items, not product entitlements.
Why It Persists
Billing is seen as "close enough" to a product inventory because it lists what the customer pays for. The gap only becomes visible during MACD operations, migrations, or audits. Introducing a Product Inventory requires back-populating it from billing and network records — a reconciliation exercise that nobody wants to fund until the pain becomes unbearable.
Correct Pattern
Implement Product Inventory / Subscription Lifecycle Management (TMF637) as the SoR for active product instances. When an order is fulfilled, COM creates a Product Instance in the Product Inventory. This record persists across the entire customer lifecycle and is the source of truth for what the customer has. Billing references this inventory for charge generation. MACD operations read the current state from Product Inventory before applying changes.
Related Sections
Situation
The architecture grew organically with no centralised catalog, no Commercial Order Management (COM) to capture and validate orders, and no Service Order Management (SOM) to orchestrate services. Orders arrive via email, spreadsheets, or tickets and flow directly to manual provisioning teams. There is no structured order lifecycle.
Symptoms
- •Orders are entered manually into provisioning systems from emails or spreadsheets
- •No end-to-end order tracking — status requires chasing individuals via email or chat
- •No service decomposition — provisioning teams interpret commercial requests ad hoc
- •No audit trail for what was ordered, when, or by whom
- •Provisioning errors are frequent because there are no validation rules or feasibility checks
- •MACD operations are near-impossible — nobody knows the current state to modify
Architecture View
Anti-Pattern: No catalog, no COM, no SOM — orders flow via email/tickets to manual provisioning
Root Cause
Systems were built piecemeal over many years. Each capability was handled by the team closest to it — sales took orders on paper, operations provisioned from memory and tribal knowledge. No one designed an end-to-end order flow because the organisation grew before BSS/OSS principles were understood or adopted.
Why It Persists
The manual processes "work" for the current volume and product set. Key staff carry institutional knowledge that substitutes for system logic. Any transformation requires simultaneously introducing a catalog, order management, and orchestration — a large, risky programme that leadership struggles to justify incrementally.
Correct Pattern
Implement a catalog-driven architecture with three key layers: (1) a Product Catalog (TMF620) defining what can be sold and how it decomposes, (2) COM (TMF622) for structured order capture, validation, and commercial order lifecycle, and (3) SOM for service orchestration, CFS→RFS decomposition, and service inventory management. All channels submit orders to COM via API rather than email/tickets.
Situation
COM, SOM, and ROM exist and work correctly for some newer products (e.g. fibre broadband, 5G fixed wireless), but the majority of legacy products (PSTN, basic DSL, leased lines) bypass them entirely via legacy order flows. Two parallel universes coexist — one modern and catalog-driven, the other manual and siloed.
Symptoms
- •Two completely separate order paths must be maintained, tested, and supported
- •Service inventory is incomplete — only new products appear; legacy products are invisible
- •Legacy products cannot be bundled with new products because they live in different systems
- •Reporting and analytics have gaps because legacy orders are not captured in the modern stack
- •Migration from legacy to modern order path stalls because there is always a higher priority
- •Customer-facing agents must switch between old and new tools depending on the product
Architecture View
Anti-Pattern: Partial COM/SOM/ROM — new products use the modern stack, legacy products bypass it
Root Cause
The modern COM/SOM/ROM stack was deployed for new product launches but legacy product migration was never funded or completed. The business case for the new stack was built around new revenue, not migration of existing products. Over time, the legacy path became entrenched and the cost of migration grew.
Why It Persists
Legacy products still generate significant revenue and "work" on the old path. Migration requires re-modeling every legacy product in the new catalog, mapping legacy fulfilment logic to SOM workflows, and running a parallel period — all with zero revenue upside. The transformation programme declared victory after launching new products and moved on.
Correct Pattern
Migrate all products to the catalog-driven order path. Model legacy products in the Product Catalog (TMF620) and define their CFS/RFS decomposition. Route all orders through COM→SOM→ROM regardless of product vintage. For legacy fulfilment systems that cannot be replaced immediately, use an adapter/facade pattern at the ROM layer — SOM sends standard resource orders and the adapter translates them into legacy provisioning commands.