Architecture and concepts
TMF ODA Support and Compliance

TMF ODA Support and Compliance

Intro

This section describes how the SCDOM platform aligns with the TM Forum Open Digital Architecture (ODA) model. It outlines the mapping between system components and ODA Building Blocks, and evaluates compliance with relevant TMF Open APIs.

The SCDOM platform directly corresponds to the TM Forum ODA Component C003 – Product Order Delivery Orchestration and Management, effectively covering its key functionalities and ensuring alignment with industry standards.

Our goal is to ensure modularity, interoperability, and readiness for telecom-grade integrations in line with industry standards.

ODA Concepts in SCDOM

SCDOM architecture is highly modular and aligns naturally with the ODA paradigm. Each major domain is implemented as an independent microservice, mapped to a well-defined business capability. The platform makes extensive use of TMF Open APIs to ensure integration readiness with external systems.

ODA Mapping Table

ODA Building BlockSCDOM ComponentTMF API SupportCompliance Level
Product Order Managementincoming-ordersTMF622Full support for TMF622 – single block mapping
Service Order Managementincoming-ordersTMF641Full support for TMF641 – single block mapping
Order Orchestrationorder-serviceTMF622, TMF641Full support
Order Decompositionplan-builderTMF622 and TMF641 (subset - mapping); TMF638 (read)Custom logic using TMF APIs selectively for decomposition and queries
Product Catalog Managementproduct-catalogue(optional TMF620)Not exposed externally but fully modular and hot-deployable
User Interaction / BFF Layerbff, guiDedicated API*Dedicated API, ready for external integration - not subject to TMF standardization
  • For more information please refer to BFF API chapter

Highlights

  • Full TMF622 & TMF641 support is provided by the incoming-orders component, qualifying as a complete implementation of the Product Order Management and Service Order Management building blocks.
  • order-service uses TMF APIs internally (TMF622 & TMF641), aligning well with orchestration logic.
  • plan-builder performs advanced decomposition using TMF APIs (TMF622, TMF641) in a selective and streamlined way — leveraging only the required fields for decomposition logic — and also queries service inventory via TMF638. Additionally, it can utilize TMF641 when SCDOM is used as a Service Order Management component.
  • plan-builder follows clean, modular principles using custom logic and asynchronous communication, ensuring scalability and maintainability.
  • product-catalogue supports dynamic, versioned deployments and may expose TMF620 in future iterations.
  • gui and bff layers are custom-built but fully decoupled from backend logic, providing flexibility for UI evolution.

Summary

SCDOM architecture demonstrates strong alignment with the ODA model:

  • Core building blocks are fully supported via dedicated components that offer complete TMF API compliance.

  • The Order Decomposition building block leverages TMF APIs selectively and effectively, ensuring integration readiness and interoperability while maintaining architectural flexibility. Although these components could fully support all fields defined by TMF standards, such comprehensive coverage has not been necessary to meet current business requirements.

  • Custom components, such as step-executors and product-catalogue, follow modular and ODA-compliant principles, utilizing internal APIs or messaging to provide scalability, independence, and ease of maintenance.

  • The platform covers all essential business capabilities required by telecom operations through TM Forum standards, ensuring readiness for integration within ODA-aligned environments.

Testing Methodology