TM Forum ODA implementation: A practical path for telecom modernization

What is TM Forum open digital architecture, and why does it matter?

TM Forum Open Digital Architecture is a standardized reference architecture for telecom operators, which is based on a set of modular components with clearly defined business functions (order management, product catalog, billing, etc.) that are connected via APIs rather than proprietary software.

The need for such a standard was driven by the telecom operators’ historical development of their own OSS/BSS estates through decades of vendor selection, development, and acquisition. Such systems are typically highly integrated, with integration points being undocumented or proprietary, and therefore extremely costly and time-consuming to alter. With ODA, operators can now be able to develop common architectural descriptions that can be implemented across multiple vendors, systems integrators, and internal teams, in order to allow incremental changes to core systems without replacing the entire stack.

This flexibility has commercial implications as well. A telecom operator that is committed to a proprietary, vertically integrated OSS/BSS stack has to weigh the opportunity cost of any future software purchase against the integration bill that comes with it. Such an operator will also have significantly longer go-to-market cycles for new products and services, due to the complexity of changes required across the integrated stack. And when it comes to partnerships, it cannot easily integrate with a third party which has chosen a different architecture. ODA tackles all of these challenges by breaking the integrated stack into a set of common interfaces, which allows for individual components to be changed without affecting the rest of the architecture.

What is the ODA canvas?

The ODA Canvas is the open-source reference implementation and runtime environment that operationalizes ODA components on cloud-native infrastructure, specifically on Kubernetes. Instead of each vendor/operator creating their own bespoke mechanism to deploy, manage and connect ODA components, the Canvas provides a standard runtime layer to manage the component's lifecycle, service discovery and API exposure in a consistent way. For the enterprise architect considering ODA implementation, the Canvas is the piece that takes the ODA specification from a paper architecture to something that can be deployed and run in production.

What does an ODA implementation roadmap look like?

An ODA implementation roadmap generally moves through four distinct phases, each building on the validation of the one before it, rather than treating ODA adoption as a single monolithic project with one delivery date.

The first phase is architectural assessment and target-state design: mapping the existing OSS/BSS estate against ODA's component model, identifying which legacy systems map to which ODA components, and defining the target API contracts each component needs to expose. This phase also establishes the governance model — who owns the canonical data definitions each component will need to share, and how API versioning and deprecation will be managed as the architecture evolves.

The second phase is a pilot implementation, typically scoped to a single, lower-risk domain — often product catalog or a specific digital customer journey — deployed on the ODA Canvas and validated against real but limited production traffic. The purpose of this phase isn't primarily to deliver business value yet; it's to validate that the target architecture, the API contracts, and the operational tooling actually work as designed before committing to a broader rollout.

The third phase is progressive component rollout, following the risk-based sequencing described above: additional ODA components are implemented and integrated one at a time, each validated against production traffic before the next begins, with legacy systems continuing to serve any function not yet modernized. This is where the bulk of OSS/BSS modernization work happens, typically over an extended multi-year period for a full-scale national operator, though individual components can be delivering value within months of the pilot phase completing.

The fourth phase is legacy decommissioning and ongoing architectural governance — retiring legacy systems once nothing depends on them, and establishing the standing discipline needed to keep the ODA-aligned estate from drifting back toward the same fragmentation that motivated the modernization in the first place.

Not sure how your own OSS/BSS estate maps against the ODA component model, or where to start sequencing a pilot?

Get the BT-EE ODA case study

What is composable telecom architecture, and how does ODA enable it?

Composable telecom architecture refers to an operating model in which business capabilities — new products, new customer journeys, new partner integrations — are assembled from existing, standardized components rather than built from scratch each time. ODA is the architectural foundation that makes this composability possible: because each ODA component exposes standardized, well-documented APIs, a product team can combine existing components in new ways to launch a new bundle or offer, without requiring new point-to-point integration work for each new combination.

This has meaningful commercial consequences. Time-to-market for new products drops significantly once the underlying architecture is composable, because most of what a new product needs — customer management, billing, order handling — already exists as a reusable component rather than requiring custom development.

What organizational changes come with telecom operating model transformation?

Telecom operating model transformation is the organizational counterpart to ODA's technical architecture, and it's frequently the harder half of the work. A componentized, API-led architecture only delivers its full value if the organization around it changes to match — which typically means moving away from siloed teams organized around individual legacy systems and toward teams organized around ODA components or business capabilities, each with clear ownership of their component's API contract, roadmap, and data quality.

This shift also changes how new product development works. In a traditional siloed model, launching a new product often requires coordinated, sequential work across multiple system-owning teams. In an ODA-aligned operating model, product teams increasingly work by composing existing components through their published APIs, which requires less coordination — but only if those teams have genuinely adopted a "component as a product" mindset, with stable, versioned APIs that consuming teams can build against with confidence. Executive sponsorship matters considerably here, because this shift touches team structure, budget ownership, and career paths in ways individual engineering teams cannot drive on their own.

TM Forum ODA implementation at BT group

Torry Harris Integration Solutions partnered with BT Group on exactly this kind of ODA-based transformation — aligning BT's OSS/BSS modernization roadmap with TM Forum's Open Digital Architecture and Open API standards to unify BT, EE, and Plusnet onto a common, componentized architecture. Rather than a single cutover, the transformation was delivered incrementally, validating each component and integration against real customer traffic before expanding scope — the same risk-sequenced approach described throughout this article, applied at the scale of a national operator unifying three brands simultaneously.

See how BT unified BT, EE, and Plusnet on a TM Forum ODA-aligned architecture

Read the full BT-EE case study from Torry Harris