1. Introduction

A tier-one carrier runs somewhere between 200 and 1,000 separate operational and business support systems. Each one was procured at a different time, from a different vendor, against a different requirement. A billing platform speaks to an order manager through a point-to-point integration that took eighteen months to build and that nobody dares touch. A new product offer that should take an afternoon to define instead takes a quarter, because the change ripples through a chain of brittle adapters that were never designed to move quickly. This is the cost structure that TM Forum Open Digital Architecture set out to dismantle.

ODA is the industry blueprint for replacing that estate with a single, component-based, cloud-native architecture. It defines a small set of functional blocks that describe what a service provider does, a catalogue of standardized software Components that implement those functions, a set of Open APIs that let the Components talk to each other without bespoke integration, and a Canvas — a cloud-native execution environment that deploys and operates those Components automatically. The combination is what removes the eighteen-month integration project and replaces it with plug-and-play.

This guide works through the whole architecture at engineering depth. It covers the five design principles that govern every decision in ODA, the eight functional blocks of the high-level map, the detailed functional architecture down to domain level, the anatomy of an ODA Component and its self-describing envelope, the role of the Gen5 Open APIs, the internals of the Canvas, and the data-centric model that ties the layers together. It closes with the migration story — how a carrier actually moves a brownfield estate onto ODA without a rip-and-replace it cannot afford — and with field evidence from operators who have done it.

The reader assumed here is a network architect or OSS/BSS engineer who knows what an order manager and a product catalog are, but who has not yet had to reason about ODA Components, the Canvas operator pattern, or why a self-describing envelope changes procurement economics. Every concept is explained from first principles in terms of the decision it shapes, but the pace assumes technical fluency.

2. The problem ODA was built to solve

Two architectural failures define the legacy CSP stack. The first is the hard wall between operational support systems and business support systems. OSS manages the network — inventory, provisioning, fault, performance. BSS manages the commercial relationship — product catalog, ordering, rating, billing. In the traditional model these are separate worlds with separate data, and the only path between them is a layer of integration code. The second failure is monolithic, vertically integrated applications that bundle dozens of functions into one product, so that changing one function means regression-testing the whole thing.

The cost of these two failures shows up as time-to-market. Closed-loop network operations stall because the data needed to drive them is locked inside systems that do not share it. The headline figure TM Forum uses to frame the opportunity is concept-to-cash compression from eighteen months to eighteen days — a target, not a measured average, but one that names the scale of the problem precisely.

The economic argument behind ODA rests on this quadratic-to-linear shift. With N point-to-point integrated systems, the integration surface grows as roughly N(N-1)/2 — every system potentially wired to every other. Replace the bespoke adapters with Components that all speak the same Open APIs, and the surface collapses to N: each Component conforms once to the published interface contract and is then interoperable with every other conformant Component. This is the same insight that drove the move from proprietary network protocols to IP, applied to the OSS/BSS layer.

3. From NGOSS and Frameworx to ODA

ODA did not appear from nothing. TM Forum has standardized OSS and BSS structure for decades, and ODA inherits the conceptual vocabulary of two earlier programs: NGOSS and Frameworx. Understanding that lineage explains why ODA looks the way it does and why its data model still carries names like SID.

NGOSS — New Generation Operations Systems and Software — was the industry-agreed framework for business process modeling, systems architecture, information models, and integration interfaces. Its stated goal was to make the development, procurement, deployment, and operation of OSS/BSS flexible and low-cost. NGOSS rested on four toolsets that became the Frameworx suite.

3.1 The three Frameworx pillars

The Business Process Framework, known by its working name eTOM (enhanced Telecom Operations Map), is a hierarchical decomposition of everything a service provider does. eTOM was published as ITU-T Recommendation M.3050. Its top level separates three process areas: Strategy, Infrastructure and Product covering planning and lifecycle management; Operations covering day-to-day management; and Enterprise Management covering corporate support. Within Operations, eTOM centers on the core customer-facing processes of Fulfillment, Assurance, and Billing, abbreviated FAB.

The key thing eTOM changed relative to the older Telecommunications Management Network model was direction of derivation. TMN, defined in ITU-T M.3010, was built bottom-up from the requirements of managing network equipment, with its four logical layers — Business, Service, Network, and Element Management — and its FCAPS functional split (fault, configuration, accounting, performance, security) from M.3400. eTOM was built top-down from the processes of the entire service-provider enterprise. That top-down orientation is exactly what ODA's functional map inherits.

The Information Framework, known as SID (Shared Information/Data Model) and published as GB922, is an enterprise-wide information model rather than a physical data model. It does not say how data is stored; it defines what the entities are and how they relate. SID organizes its entities into domains — Market/Sales, Product, Customer, Service, Resource, Supplier/Partner, and a Common Business domain holding shared entities such as Party, Location, Policy, and Agreement. When an ODA Component declares the data it manages, it does so in SID terms. The SID Resource domain is also where the joint information-modeling work between TM Forum, ONF, and MEF converged, drawing on ITU-T G.800-series and ONF Core Model lineage to produce a shared network resource model.

The Application Framework, known as TAM (Telecom Application Map), mapped OSS/BSS application capabilities onto the eTOM processes and SID entities. TAM is the conceptual ancestor of the ODA Component catalogue: it answered the question of which application owns which process and data, which is precisely what an ODA Component specification formalizes today.

3.2 The bridge programs: ZOOM, DPRA, DSRA, and Open APIs

Between Frameworx and ODA, TM Forum ran several programs that prepared the ground. The Zero-touch Orchestration, Operations and Management project, ZOOM, developed best practices for the operational shift that NFV and SDN forced — when network functions become software running on shared infrastructure, the sharp line between the network control layer and the operations support layer blurs, and the older equipment-centric information models stop fitting. The Digital Platform Reference Architecture and Digital Services Reference Architecture work addressed platform business models and B2B2X service interactions.

The Open API program, launched formally in 2016, was the program that made decoupling practical. It began as a way to support NFV at scale and grew into the mechanism by which operators could pull individual components apart — separating the customer experience layer from systems of record, the engagement layer from intelligence management — because each separated piece now had a published interface contract to talk through. ODA is the architecture that organizes all of this into one coherent model, and the Open Digital Framework is the wider envelope that adds the transformation tools, maturity models, and reference implementation around the architecture itself.

4. The five design principles

Five principles govern every structural decision in ODA. They are not aspirational slogans; each one forces a concrete property on the architecture, and each one rules out a class of design that would otherwise be tempting.

4.1 AI-capable and autonomous

Simple rule-based automation does not scale to the speed and combinatorial complexity of decisions a modern network demands. ODA therefore targets an event-driven model governed by a knowledge-defined intelligence layer rather than a fixed script. The practical consequence is that the architecture must expose events and state as data the intelligence layer can consume, and must accept intents the intelligence layer produces — which is why the data-centric principle below is not optional. The failure mode this principle guards against is an architecture that automates individual tasks but cannot close a control loop because the data it needs is trapped inside applications.

4.2 Data-centric, not process-centric

This is the principle that most distinguishes ODA from eTOM-era thinking. A process-centric architecture hard-codes the sequence of steps; a data-centric one lets the data drive dynamic, end-to-end processes that can be expressed as intent and policy rather than fixed flows. The requirement it imposes is a consistent data architecture that runs end to end through every layer of the stack, so that data generated in one functional block is available to components in any other. TM Forum is explicit that this was not feasible a decade or two earlier because database performance could not support it; technologies such as distributed clusters and solid-state storage made an end-to-end data architecture viable. The initial implementation can be a common data repository per functional block, with more sophisticated approaches layered on.

4.3 Microservice-based, using Open APIs

Capabilities are built from TM Forum-compliant microservice definitions exposed through Open APIs, which enables containerization and lets capabilities extend across organizational boundaries within an ecosystem. The early ODA work used the placeholder name "Framelets" for these subcomponents — the Lego-like building blocks of the architecture, deliberately kept at a granularity that balances assembly complexity against flexibility. Too many blocks and assembly becomes complex; too few and there is not enough flexibility for vendor choice. Vendors build to the block boundaries but may combine several into one product, provided the product exposes all the Open APIs of the combination. The stated measure of a good component is its reuse. This is the principle that delivers the plug-and-play property and the vendor differentiation in performance and resource utilization that the linear-integration argument depends on.

4.4 Real time

Every layer of the model operates in real time — the customer- and ecosystem-facing layers and the resource-facing layers alike. This rules out batch-oriented designs that defer reconciliation, because a closed-loop autonomous system cannot wait for an overnight batch to know the current state of the network.

4.5 Decoupled and ecosystem-ready

Decoupling and integration happen between ODA domains and Components through Open APIs that manage the separation of functional borders based on families of closely related services. Unlike traditional layered architectures where a functional layer talks only to its adjacent layers, ODA's decoupling does not preclude data sharing or service combination across non-adjacent blocks. The Open APIs ensure services can be combined flexibly without restrictions imposed by adjacent processes. This is what lets an Engagement Management capability reach a NaaS function directly without routing through every intervening layer.

5. The eight functional blocks

The ODA high-level functional architecture map captures how a CSP operates in a deliberately simple picture — simple enough that people across job roles, not only software architects, can read it and explain it. The map is organized into systems of engagement (multi-channel interaction with people and partners through secured APIs), systems of insight (analytical processes that produce business insight), and systems of record (real-time operational processes). Across the top of the map sits the customer- and ecosystem-facing edge; the resource-facing edge sits at the bottom. Between and through every block runs Decoupling and Integration, the API-mediated layer that is itself a functional block.

Eight functional blocks make up the map. Six are functional domains and two — Decoupling and Integration, and the data layer — are cross-cutting. The descriptions below state what each block is, what it does in the architecture, and what would break without it.

5.1 Engagement Management

Engagement Management handles multi-channel interactions between people and systems, and between systems and other systems. It contains the front-end capabilities exposed to partners and customers through secured APIs — self-service portals, messaging channels, and the digital storefront. It is the systems-of-engagement edge. Without it, the architecture has no governed way to present capabilities to the outside world; every channel would reach into the systems of record directly, which is exactly the coupling ODA removes.

5.2 Party Management

Party Management handles all interactions and data associated with the entities involved in business processes — customers, suppliers, partners, and any other actor. In SID terms this is the home of the Party entity. Centralizing party data is what allows a single view of a customer to exist across the architecture rather than being reconstructed from fragments in CRM, billing, and ordering.

5.3 Core Commerce Management

Core Commerce Management covers the activities that directly or indirectly enable the exchange of goods and services: the product catalog, order capture, orchestration of product delivery, rating of charges, and product assurance. This is the commercial heart of what was formerly BSS. It consumes network capabilities exposed as services to create products and offers.

5.4 Production

Production abstracts the complexity of the infrastructure and is responsible for the delivery and lifecycle management of both customer-facing services and resource-facing services, regardless of the underlying technology. This is where the former OSS function lives, and it is where network capabilities are exposed as network-as-a-service so that other blocks can consume and manage network domains without knowing their internals. Core Commerce Management uses NaaS to build products; Engagement Management might use it to let a customer top up a balance or order video on demand. Without the Production block's abstraction, every commercial function would need to understand network technology directly.

5.5 Intelligence Management

Intelligence Management supports systems of insight — AI, machine learning, and cognitive capabilities — and the analytical processes that turn operational data and events into analyses, correlations, and aggregations that improve operations. Traffic analysis feeding revenue assurance or fraud detection is a representative use. This block is where the AI-capable principle becomes concrete; it is the consumer of the data the data-centric principle makes available, and the producer of the intents the autonomous principle acts on.

5.6 Decoupling and Integration

Decoupling and Integration is the block that makes the others independent. It governs and manages the separation of functional borders through Open APIs, organized around families of closely interrelated services, and it manages the integration between those families. Because it sits between and through all the other blocks, services provided by ODA can be combined flexibly without restrictions imposed by adjacent processes. This is the block that delivers the non-strict-layering property: unlike OSS/BSS architectures where layers communicate only with their neighbors, ODA's decoupling does not preclude sharing data or combining services across the map.

6. Inside the functional architecture map

The eight blocks are the executive view. Underneath them, the functional architecture decomposes into domains and individual functions that a vendor's product can be mapped against. The detailed map groups functions into domains that echo the SID structure: a Market/Sales domain, a Customer domain, a Product domain, a Service domain, a Resource domain, and a Common domain holding shared functions.

6.1 How the domains decompose

Each domain contains a set of named functions, and each function is the kind of capability a single ODA Component might implement. The Service domain, for example, contains Service Lifecycle Management, Service Catalog Management, Service Inventory Management, Service Order Management, Service Test Management, Service Problem Management, Service Quality Management, Service Capability Orchestration, and Service Assurance Control. The Resource domain mirrors this with Resource Lifecycle, Resource Catalog, Resource Inventory, Resource Order, Resource Test, Resource Performance, Fault Management, Location Management, and Resource Capability Orchestration. The Customer domain holds the billing and care functions — Customer Order Management, Customer Problem Management, Customer SLA Management, Bill Calculation, Billing Account Management, Customer Information Management, and a long tail of related functions.

This decomposition is what a vendor uses to declare conformance. When a supplier maps its product onto the functional architecture, it states which functions it covers and at what level — full, partial, or limited. That mapping is the basis of the catalogue-driven procurement model: an operator can read which Components cover which functions and assemble a stack from multiple vendors rather than buying one monolith.

6.2 Why the conformance grade matters

A function mapped as "full" means the Component implements the complete capability and exposes all its Open APIs. "Partial" means some of the capability or some of the APIs. "Limited or no support" means the function falls outside the product. The grade is not a marketing label; it is the input to an integration plan. A stack assembled from Components that are all "full" on their declared functions and that share the same Open APIs integrates without bespoke code. A stack with "partial" coverage on a critical function tells the architect exactly where the gap — and the custom work — will be.

7. ODA Components and the envelope

An ODA Component is an independently deployable piece of software, typically built from one or more microservices, with its integration defined through specified Open APIs. The Component is the unit of the catalogue, the unit of procurement, and the unit of deployment. It is the concrete form of the "Framelet" the early ODA work described — a Lego block at a granularity chosen so that blocks combine without excessive assembly complexity but with enough flexibility for vendor choice.

A Component has a defined boundary. Inside that boundary the vendor is free: it may use any number of microservices, any internal data store, any implementation language, and it may differentiate on performance and resource utilization. Across the boundary the Component must expose the Open APIs of the function it implements, must publish the events it emits, and must declare what it needs from its environment. That declaration is the envelope.

7.1 The self-describing envelope

The envelope is the metadata that lets the Canvas manage the Component automatically. It is the difference between software that has to be installed and configured by an integrator over weeks and software that the platform can deploy, wire up, secure, and monitor on its own. The envelope declares, in machine-readable form, everything the surrounding platform needs to know to run the Component through its full lifecycle.

The envelope carries the Component's exposed APIs (which interfaces it offers and at what versions), its dependent APIs (which interfaces it needs from other Components), the events it publishes and subscribes to, its security and identity requirements (the permissions it grants and the roles it recognizes), and its operational and management requirements (how it should be scaled, monitored, and upgraded). The early ODA Brochure material described this internal structure with recurring elements — core function, notification and reporting, management and operations, environment dependence and requirements, and security — present in every Component.

The economic claim attached to the envelope is steep: machine-readable component envelopes are positioned as a path to at least a tenfold improvement in operational efficiency through automated operations, standardization through open-source envelopes, and time to market through a component marketplace that aims to make much of the RFP procurement process redundant. That last point is the real prize — if a Component's envelope fully describes how to deploy and operate it, then selecting a Component becomes reading its envelope rather than running a multi-month procurement and integration project.

7.2 Component categories and the directory

Components are catalogued in an ODA Component Directory, and the reference implementation uses that directory as the basis for Component certification. The vendor community is actively uplifting existing applications to support plug-and-play through the Component Accelerator program, which provides the test environment and tooling to validate commercial products for conformance to the Component specifications. An ODA Component may be a single microservice application or several microservice applications, and the specifications encourage application design that supports zero-downtime upgrades. As a base, existing APIs can be deployed as single-microservice Components and progressively refactored.

8. Open APIs: the connective tissue

The Open APIs are the contracts that make Components interoperable. They are REST-based, service- and technology-agnostic, and the same APIs are used for internal integration and external ecosystem integration — which is what accelerates the build-out of a digital ecosystem, because a partner consumes the same interface a sibling Component does. TM Forum maintains a published table of these APIs, each with a TMF identifier.

8.1 The resource archetypes and CRUD mapping

The REST API Design Guidelines define three resource archetypes that every TMF API aligns to. A Resource Collection is a server-managed collection of resources. A Managed Resource is an individual entity — a database record or managed object — whose representation includes fields and links to related resources, and which the client can create, query, update, and delete. A Task is a resource that represents an executable function with input and output parameters, used where the required action cannot be mapped to standard create-read-update-delete operations.

The HTTP verb mapping is strict and worth memorizing because it is what makes any two TMF APIs feel the same to an integrator.

# TMF REST verb mapping (GB983 Design Guidelines)
GET    /resource          # query a collection
GET    /resource/{id}     # retrieve one managed resource
POST   /resource          # create a new resource
PATCH  /resource/{id}     # partial update
PUT    /resource/{id}     # complete update by URI
DELETE /resource/{id}     # remove a resource
POST   /task              # execute a Task (non-CRUD action)

# GET and POST must NOT be used to tunnel other request methods.
# HEAD retrieves response headers; support is always optional.

The discipline behind this matters more than it looks. Because every TMF API maps the same business operation onto the same verb against the same archetype, an integrator who has worked with one API already knows the shape of the next one. A partial update is always PATCH against a managed resource; an action that is not CRUD is always POST against a Task. The guideline that GET and POST must not be used to tunnel other request methods is what keeps the contract honest — without it, vendors would smuggle bespoke semantics through generic verbs and the interoperability guarantee would erode.

8.2 Gen5 and the generations of the API program

The Open API portfolio has generations. APIs at version 4 and below are REST with a universal payload — described in the program's own analogy as the reliable, multi-purpose vehicle. Gen5 is the current generation: still REST, but with both a universal and a context-specific payload option, and with asynchronous interaction patterns on the roadmap. Gen5 is positioned as future-proof, simplified, and easier to maintain. A single Gen5 API is designed to cover a multitude of use cases, which is part of how the program tackles technical debt — decoupling legacy solutions behind one standard interface rather than many bespoke ones.

The Open APIs also reach outward into adjacent ecosystems. Through the GSMA Open Gateway initiative, TM Forum and the GSMA collaborate on a set of APIs to monetize network capabilities, with TM Forum Operate APIs enabling the Linux Foundation's CAMARA APIs to be managed as products that developers consume and pay for. TM Forum and MEF are harmonizing MEF's APIs with the Gen5 standards to streamline automation in the MEF Network-as-a-Service domain — Carrier Ethernet, IP services, SD-WAN, and end-to-end network slicing — across a global partner ecosystem. For the optical and transport engineer, the relevant lineage runs through the joint information-modeling work between TM Forum, ONF, and MEF that aligned the network resource model, drawing on the ONF Core Model and the ITU-T G.800-series.

9. The ODA Canvas execution environment

Open APIs make Components interoperable, but they do not deploy, configure, or operate them. That is the Canvas. The Canvas is a software-defined blueprint for a cloud-native operating environment — an execution platform for ODA Components and the release-automation stage of a CI/CD pipeline. It exists to support Components by supplying the cloud-native services they require: an API gateway or service mesh so a Component can expose its APIs in a standard way, observability services so the Component can be monitored, and an identity-management system so the Component can register the permissions it grants.

9.1 There is no Canvas specification — the standard is the Component spec

The most counterintuitive design decision in the Canvas is that there is no explicit Canvas standard. The standard is the ODA Component Specification. The Canvas is any platform that can consume ODA Components, read the metadata from a Component's envelope, and then execute whatever lifecycle process is needed to satisfy those requirements. This inversion is deliberate: by standardizing the Component rather than the platform, ODA lets every hyperscaler and every operator build a different Canvas while guaranteeing that any conformant Component runs on any conformant Canvas. The Canvas can be built on any cloud platform.

9.2 The operator pattern

The reference implementation is built on Kubernetes, and it implements the Kubernetes Operator Pattern. Canvas operators are the cloud-native equivalent of network element managers — they are management-plane functions that embed the management and operations activities in software. The Component Operator, also called the Component controller, is central; it reads the Component envelope and drives the deployment and lifecycle. The Canvas is itself a modular architecture of independent operators, so an organization can mix and match them and replace standard operators with custom ones that encode its own operational policies.

The reference implementation's minimum viable set is the Component controller plus an identity-management solution and a service mesh. The click-and-deploy reference Canvas wires these together: Keycloak for identity management, Istio for the service mesh, and Kiali for mesh observability. The Kubernetes environment is standard, extended with custom resource definitions and namespaces that make the cluster ODA-compliant; the click-and-deploy scripts configure the CRDs and namespaces automatically. The specification is platform-independent and interoperable through the Kubernetes API.

9.3 What the Canvas changes operationally

The operational gains are measured, not theoretical. Configuring an API gateway on a Canvas takes roughly three seconds, against about two weeks for the equivalent manual approach reported in the same survey — a difference that compounds across every Component onboarded. The Canvas became available for widespread industry use in January 2025; general availability of the conformance tooling that lets vendors claim certification was expected in mid-2025. Vodafone ran an ODA Canvas in a live environment in Greece ahead of general availability and stated a target of improving agility and operational efficiency by a factor of ten, and from the start of 2025 it began requiring IT suppliers to demonstrate commitment to adopting the Canvas — the same contract-prerequisite lever the operator had used earlier to drive Open API adoption.

The three major hyperscalers have each built a compliant Canvas. Microsoft and Google Cloud contribute to the reference Canvas developed in TM Forum's Innovation Hub, and each has built its own; Amazon Web Services has a compliant Canvas as well. Microsoft published an open-source toolkit on GitHub that lets telcos of any size build ODA Canvases on Azure — the first hyperscaler blueprints for the reference Canvas released as open source, which lowers the barrier for smaller operators that cannot fund a Canvas build from scratch.

10. Data-centric architecture and NaaS

The data-centric principle is the one that most often gets implemented badly, so it deserves its own treatment. A common data architecture is the foundation for a single view of a customer — it reduces the number of systems and simplifies the overall architecture, and it fulfills the requirement that data generated in one part of the architecture be available to components in any other part. The initial, pragmatic implementation is a common data repository per functional block; more sophisticated approaches layer on top as the architecture matures.

10.1 Network-as-a-Service as a data abstraction

Network-as-a-Service is the mechanism by which the Production block exposes network capability to the rest of the architecture without leaking network technology. The NaaS layer presents network domains so that other ODA functional blocks can consume and manage them, hiding the technology beneath. The reason this matters for the data architecture is that it normalizes resource data: instead of every commercial function understanding optical, IP, mobile, and fixed resources directly, the NaaS layer presents a federated, normalized view.

Vodafone's NaaS Component Suite is the field example. It enables an end-to-end flow of information that lets multiple domains across multiple markets appear and behave as a single network from the customer's perspective — a requirement for an operator running mobile services in two dozen countries and fixed broadband in nineteen markets. The suite supports closed-loop automation for some network domains and a federated network model where local teams in different markets develop their own automation, which is what lets the operator move away from a single monolithic OSS toward many domain-scoped autonomous units.

The structural insight that drives this is exposure granularity. Pushing knowledge all the way down to the resource level for every consumer produces long time-to-market and difficult exit. Exposing and managing the end-to-end lifecycle of services through Open APIs at the network-domain boundary produces agility. The NaaS gateway sits at that boundary, presenting a master network services directory and federated resource data upward, while domain-specific systems handle the resource detail below.

10.2 The CFS / RFS distinction

The Production block manages two service abstractions that the data model keeps distinct. A customer-facing service is what the customer perceives and orders — broadband at a stated rate, a VPN between named sites. A resource-facing service is the internal realization — the access circuit, the transport path, the configured network function — that delivers the customer-facing service. Keeping the two separate in the data model is what lets the same customer-facing service be realized on different underlying technologies without the commercial layer knowing or caring, and it is what lets a network team re-home a resource-facing service during maintenance without touching the customer order.

11. ODA and autonomous networks

ODA and TM Forum's Autonomous Networks program are two halves of the same vision: ODA supplies the modular, API-mediated, data-centric architecture, and the Autonomous Networks framework supplies the intent-driven closed-loop control that runs on top of it. The AI-capable and autonomous design principle is the hinge between them.

11.1 The six autonomy levels

TM Forum defines a six-level taxonomy that has become the industry's common reference for where a network process sits on the path from manual to fully autonomous operation. Level 0 is manual operations and maintenance — the system provides assisted monitoring but every dynamic task is manual. Level 1 is assisted O&M — the system executes a specific repetitive subtask from pre-configuration. Level 2 is partial autonomy — closed-loop O&M for specific units under certain conditions, via statically configured rules. Level 3 is conditional autonomy — the system senses real-time environmental changes and, in certain domains, adjusts itself via dynamically programmable policies. Level 4 is high autonomy — in a complex cross-domain environment, the system makes decisions via predictive analysis and active closed-loop management driven by AI modeling and continuous learning. Level 5 is full autonomy — closed-loop automation across multiple services, multiple domains including partners', and the entire lifecycle, via cognitive self-adaptation.

Level 4 is the current industry target. The leap from Level 3 to Level 4 is the shift from machines assisting human decisions under human oversight to the network self-managing and self-optimizing. Field-level assessments of operational AI against this taxonomy show where the genuine Level 4 deployments are — alarm clustering, anomaly detection, and predictive fault management — and where the claims run ahead of the evidence.

11.2 Intent and the closed loop

Intent is how the autonomous architecture expresses requirements: it states the what, not the how. You tell the system the goal or outcome required without telling it how to achieve it, and that decoupling is what lets autonomous systems fulfill the intent using data, machine learning, and AI while enabling supplier innovation that integrates cleanly. Intent is expressed at multiple operational layers — business intent, service intent, and resource intent — and it guides a continuous closed-loop control process of monitoring, analyzing, and adjusting.

Autonomous domains are the structural unit. Each domain operates independently, guided by the operator's business objectives, hiding its implementation behind an API abstraction layer. When several domains are deployed, upper-layer service operations use intent-driven interactions between them to manage the full service lifecycle. The Intent Management API, TMF921, is the interface that carries intent between autonomous domains to coordinate closed loops across the business, service, and resource layers. The mapping to ODA is direct: autonomous domains are the closed-loop systems within an operator's access, metro, core, edge, and customer networks, and the API abstraction layer that hides each domain is the same Open API mechanism ODA uses everywhere else.

12. The migration story: brownfield to ODA

No tier-one operator can rip out its OSS/BSS estate and replace it. The migration to ODA is evolutionary by design — the Open Digital Framework provides a migration path from legacy IT systems to modular, cloud-native software, and the framework is explicitly built so operators realize a return on existing investments while adopting new technology step by step. The framework wraps the architecture itself with transformation tools that guide the move from legacy, and maturity tools and data that baseline digital capability and benchmark progress.

12.1 The five migration moves

The transition follows a recognizable sequence. First, reimagine the target rather than upgrading the old one — a roadmap that focuses on what customers need to achieve, not a functional diagram of the existing stack with a new color palette and a few new arrows. Second, expose existing systems behind Open APIs so that decoupling can begin without rebuilding anything; the API layer is the wedge that separates the customer-experience layer from systems of record and the engagement layer from intelligence management. Third, introduce a Canvas and start deploying new capability as conformant Components on it. Fourth, bridge the legacy estate into the ODA environment so external and legacy applications participate as first-class citizens rather than being stranded. Fifth, progressively re-home functions from legacy systems onto Components as their replacements mature, retiring the old systems gradually.

12.2 Decoupling systems of engagement from systems of record

The hardest and highest-value move in a brownfield estate is decoupling the systems of engagement from the systems of record. Open APIs provide the standard integration mechanism, but they do not by themselves solve deployment, configuration, and operation of a complex application landscape — and they do not solve the problem that the data needed by an engagement-layer function is mastered across many systems of record. The practical answer is API orchestration plus adaptive data mastering across the potentially many systems of record involved. An industry framework can use TMF Open APIs to expose the capabilities of the systems of record — catalog, sales, commerce, care, billing, order management — orchestrate API requests across them, and adaptively master key data, which is what enables true decoupling of engagement from record in a brownfield setting.

12.3 Bridging external and SaaS components into an ODA ecosystem

Most operators will run Components in more than one place — on a Canvas, on multiple public clouds, and as licensed or SaaS products in external environments. The ODA ecosystem concept extends the Canvas to a hybrid and multi-cloud model so operators can use applications running outside the Canvas without rebuilding them. Two integration patterns recur. In the more complex pattern, an ODA SaaS proxy Component represents an external SaaS capability to an on-Canvas Component — for instance, a proxy representing a SaaS product-catalog offer launch to a Canvas-hosted billing Component, with the proxy exposing the standard TMF interface and the Canvas supplying common services such as object store, auth, logging, and monitoring. In the simpler pattern, an external SaaS care application queries an on-Canvas billing Component directly through an API gateway, using the standard TMF interfaces, with no proxy required. Both patterns let external applications participate as first-class ODA citizens, which is the bridge that makes adopting ODA principles compatible with protecting existing application investments.

13. Operators in the field

ODA stopped being a paper architecture some years ago. The field evidence spans founding adopters, award-winning transformations, and the maturity-survey data that shows where the broader industry actually sits.

13.1 Vodafone: founding adopter to Canvas mandate

Vodafone was a founding contributor to ODA from its 2018 launch and has used the architecture to increase agility through a combination of Agile sprint teams, cloud-native development, DevOps automation, and Open API adoption. Its early adoption concentrated in experience management, with the next step being core commerce systems — service design and creation for new 5G and IoT services. By the time the Canvas reached general availability, Vodafone was running one in a live environment in Greece, targeting a tenfold improvement in agility and operational efficiency, and had begun requiring its IT suppliers to demonstrate Canvas adoption as a contract prerequisite. That contract lever is the same one the operator used earlier to drive Open API adoption — a useful pattern for any operator wondering how to make a standard stick across a vendor base.

13.2 Swisscom and Netcracker: decomposing OSS into autonomous domains

Swisscom, working with Netcracker, won a TM Forum Excellence Award for Impact and Innovation at DTW Ignite in Copenhagen for a transformation built on decomposing its OSS into many smaller autonomous operational domains based on the ODA framework. IP Transport was the first domain to be fully modernized and automated, incorporating intent-based service orchestration, real-time resource inventory, and AI/ML. The operator reported shorter time to market, increased service stability, cost reductions, and improved efficiency, and built a domain-automation blueprint to replicate the approach across all domains — offering IT-as-a-Service so domain teams could modernize and deploy additional domains at scale. This is the autonomous-domain model from Section 11 realized in production: decompose the OSS into ODA-decoupled domains, automate one fully, then replicate.

13.3 BT: model-driven OSS for network planning

BT's Agile OSS automation work targeted the network-planning bottleneck created by surging core-network capacity demand for 5G, data, TV, media, and voice. The legacy environment relied on convoluted transactional planning across multiple OSS platforms, heavy people-intensity for repetitive transactions, and manual interactions between plan-and-build, engineering services, and supplier teams. BT's response was a model-driven OSS that handles resource plan-and-build, dynamic end-to-end service design, activation, and management for legacy and future network and services — built on human-centered design principles. The architectural lesson is that adding headcount to plan and build a software-driven network is not sustainable, which is what forces the re-engineering and automation that ODA's structure enables.

Data: CSP ranking of most-valued future-OSS attributes, in order of priority — automated closed-loop service fulfillment and assurance, automated closed-loop network optimization, scalability, container and microservices based, AI-driven network optimization, being cloud native, single centralized OSS/BSS, running on virtual architecture, open and ecosystem driven, AI-driven customer engagement.

14. ODA versus the old stack

The clearest way to see what ODA changes is to line up its properties against the architecture it replaces. The comparison below is not a marketing scorecard — each row names a structural property and the concrete consequence of having it or not.

Radar comparison on a 0 to 5 scale. Traditional OSS/BSS: agility 2, integration efficiency 1, automation readiness 2, vendor flexibility 1, data sharing 1, time to market 1. ODA: agility 5, integration efficiency 5, automation readiness 5, vendor flexibility 5, data sharing 4, time to market 5. Values are illustrative of the structural difference, not measured benchmarks.