This post is about the runtime pattern that hosts Open Digital Architecture (ODA) components: a component declares what it needs, and operators configure the platform to match. All you need from Blog 8 is that it named the Canvas as the platform that hosts the components (the series sits on the hub).
At a Glance
- The ODA Canvas is a runtime pattern, with more than one way to get one, and this post will not announce one published Canvas specification, because three sources describe the specification differently.
- A component declares its APIs and roles in metadata. Three operators (Component, API, Identity) configure the gateway or mesh and the identity system. The component never touches either.
- The reference implementation at one fixed commit is a Kubernetes starting point, packaged with Helm. Swapping the gateway changes which API operator is enabled. An identity swap is design intent: the README names Keycloak and Entra ID operators, but the chart depends on Keycloak’s. The declaration stays.
A pattern, not a product or a published standard
Blog 8 said the Canvas is the platform under the components. This post says what kind of thing that platform is. The design document in TM Forum’s open-source repository calls it an execution environment for ODA components, and the release-automation part of a continuous integration and continuous delivery (CI/CD) pipeline. It gives components an API gateway and/or a service mesh, observability, and an identity management system.
Now the awkward part. Whether there is a published Canvas specification depends on whom you ask, so here are three sources, kept apart.
TM Forum’s live Canvas page says the components and canvas project specifies the Canvas in which components operate. It also says the Canvas defines the environment for deploying, managing, and operating components in a consistent, cloud-native way. The repository’s Canvas-design.md, at commit 4f5e5ed, says there is no explicit standard or specification for the Canvas. The standard, it says, is the ODA Component Specification: the Canvas reads metadata from a component spec and runs the lifecycle that metadata requires. And an Inform article from 17 April 2025 says “the specification is platform independent and interoperable through the Kubernetes API.”
I’m not going to pick one. My reading is that what you can hold a supplier to is the component’s metadata and the behaviours the Canvas must show for it. The design document expects more than one Canvas implementation, and says they should show a shared set of behaviours, written up in a use-case library and as BDD features. (BDD, behaviour-driven development, means describing behaviour in plain scenarios that a tool can run as tests.) The test kit turns those features into executable tests.
The repository you can read is one such implementation. The design document calls it a reference implementation to start from: a cloud-native application designed to be deployed on Kubernetes. That describes this implementation. It does not say every Canvas product is a Kubernetes distribution.
One attributed line shows why anyone cares. In that same Inform article, Lester Thomas, Head of New Technologies and Innovation at Vodafone Group, says the Kubernetes platform he describes is used mainly for digital engagement systems, and that the canvas adds a layer so core IT systems can run as modular components on one platform rather than in separate siloed instances. That is attributed speech, not an audited result.
What a custom resource and an operator are
Kubernetes is the common foundation here, and two of its ideas carry the rest of this post. A custom resource is a document you hand to Kubernetes to describe something it did not know about before. In the Canvas, a Component is such a document. Its shape is fixed by a custom resource definition, or CRD.
An operator is a program that watches for those documents and acts on them. Kubernetes’s own description is that an operator is a software extension that uses custom resources to manage applications and their components, following the control loop. Operators are clients of the Kubernetes API. They do not modify Kubernetes itself.
The design document says the reference operators read component requirements from metadata and carry out deployment, maintenance, upgrade, and remedial action. The repository README adds that components declare their requirements in a technology-independent way.
Some of the reference operators are written with Kopf, a third-party library. It is not part of Kubernetes. The operators README says a Canvas operator may be written in any language that supports the operator pattern.
The three operators
The repository README names three jobs. The Component Management operator manages each component’s lifecycle and splits it into ExposedAPI documents, IdentityConfig documents, and other sub-resources. The API Management operators configure the API gateway and/or service mesh for security, throttling, and other non-functional behaviour. The Identity Config operator configures the identity management services. The same README also names an optional Secrets Management operator and a Dependency Management operator, and the operators README lists TMFOP001 through TMFOP011 plus planned cost-control and database-management operators, saying the list is not exhaustive. I won’t walk the rest. They are here so three operators aren’t mistaken for the whole Canvas. The model-as-a-service one belongs with the AI material in the next post.
Component Management (TMFOP001). TM Forum’s component directory lists it as a Prototype and says its component specification is not yet published. The TMFOP001 README still says identity and observability configuration are coming “in the near future,” so I followed the source file instead. At this commit, componentOperator.py is a Kopf operator for API group oda.tmforum.org, version v1, plural components. It creates child resources of kinds ExposedAPI, DependentAPI, SecretsManagement, and IdentityConfig, and it also handles published and subscribed notifications. It adopts labeled Services, Deployments, and other Kubernetes objects as children of the Component.
API Management (TMFOP002). The directory lists this one as a Prototype too, with the same “not yet published” note. Its README says the component operator creates an ExposedAPI for each exposed API in the core, management, and security sections. In the stored v1 ExposedAPI definition, the apiType is one of openapi, prometheus, openmetrics, mcp, or a2a, and the specification is a single object with a URL and a version. (The README’s own example is behind that definition, so don’t learn the schema from it.) The README names API operators for several gateways and meshes, including Apache APISIX, Kong, and Istio. At this commit the chart’s defaults enable only the Istio one: api-operator-istio is on, and the Kong and APISIX installs are off. The installation guide says the Istio API operator is the default, that it exposes APIs through the Istio service mesh without an extra API gateway, and that only one of Istio, APISIX, or Kong may be enabled. Those are defaults of the reference implementation. They aren’t a promise that every Canvas runs Istio.
Identity Config (TMFOP003). Its README says an identity operator registers the roles and permissions a component declares, and names operators for Keycloak and for Microsoft Azure Entra ID. Static roles are a list called componentRole. At this commit the chart sets keycloak.enabled to true, and the umbrella chart depends on the Keycloak identity operator. The dependency has no disable condition. The securityFunction of a v1 component also carries a canvasSystemRole, which the definition describes as the role Canvas controllers use to call the component’s APIs. The component declares roles, and the identity operator registers them. How dynamic roles are handled is still moving between two TM Forum role APIs, so I’ll leave it there.
For Developers: one component, from declaration to binding
Take one component, with the stored v1 Component definition as the guide. Its componentMetadata.id is the id of a published TM Forum component, and the definition’s own example is TMFC001 ProductCatalogManagement. I’m using it only as an id. The definition also allows optional mappings to the Business Process Framework (eTOM), the Information Framework (SID), and the Functional Framework (FF), which earlier posts cover.
What do you, as the component author, write? A Component document. It names the component, lists the APIs it exposes under coreFunction, managementFunction, and securityFunction, and declares its roles. That is all metadata, and none of it names a gateway or an identity product.
What happens next belongs to the operators. The Component operator creates the ExposedAPI and IdentityConfig children, plus the others named above. The API operator binds the gateway or mesh to each exposed API. The Identity operator registers the declared roles in the identity system. Your component never configures Istio, Kong, APISIX, Keycloak, or Entra ID itself.
Here is the swap. Choosing Istio, Kong, or APISIX changes which API operator is enabled. The identity swap is design intent, not a chart option. The TMFOP003 README names a Keycloak operator and a Microsoft Azure Entra ID operator, but at commit 4f5e5ed the umbrella chart depends on the Keycloak one with no disable condition. The Component document stays as written.
One note on versions. The webhooks README says the reference Canvas uses a conversion webhook, and the installation guide says a v1 Canvas supports v1, v1beta4, v1beta3, and v1beta2 with a deprecation warning. This post doesn’t print install commands or promise a laptop lab. The walk is of the design, not of a cluster.
Lifecycle, from UC002
UC002 is the use case for installing, updating, and uninstalling a component. While sub-resource updates are running, the component stays In-Progress. When they finish it becomes Complete. A sub-resource may use In-Progress-Retry-Backoff while it retries. On deletion the Canvas should remove the resources it created, and the deletion should be cancelled if cleanup fails.
UC002’s prose also lists Observability among the sub-resources. The operator source at this commit does not create an ObservabilityConfig. The use-case text and the code disagree. I’m following the code.
The test-kit README writes Canvas behaviour as Gherkin scenarios linked to use cases, and says the same suite is meant to validate more than this repository’s operators. At this commit it marks as ready the UC002 install, upgrade, and uninstall features, the UC003 expose-API features including component-specified rate limiting, and the UC005 static-role and permission-specification-set features. Later use cases in its list are still unmarked. The repository README also says the reference implementation will be used for ODA Component certification, and a later post takes that up.
The reference implementation, as packaging
You can read the code in the official repository at the commit this post walks. Its README calls it the reference implementation: open-source code, use cases, and a test kit, offered as a starting point for another Canvas. The live TM Forum page says the same assets are available for download. The license is Apache License 2.0. The design document says the implementation is released as Apache 2.0 assets for building a Canvas, and that teams are expected to add their own operators.
Helm, the package manager for Kubernetes, is packaging context here and nothing more. At this commit the umbrella chart canvas-oda is version 1.2.6-rc4, with appVersion v1, and describes itself as a Helm chart of charts that orchestrates the installation. The “rc” means release candidate. The README’s release table ends at 1.2.5, described as the March 2026 release ahead of Elevate, and calls 1.2.0 the release of the v1 component specification and general availability of the ODA Canvas. The table gives 1.2.0 no date. Inform says the Canvas became available for widespread use in January 2025, and I wouldn’t line those two up. One is an undated table row and the other is a feature article.
I’m also not quoting subchart versions or image tags as “the Canvas release.” They are packaging details, and they differ from the umbrella chart at this commit. The installation guide’s table of tested software, with its older Istio, Helm, and Keycloak versions, is not the current stack either. What that guide prints for v1 components is Kubernetes 1.22 through 1.30. That range can lag newer Kubernetes releases.
If you are choosing, the design document gives you three routes. You can take a public-cloud Canvas, build a Canvas from this reference implementation, or use infrastructure operators such as Istio and Kong. It says they can be mixed. My opinion: ask which route a supplier means before you compare anything else, because the answers are not like-for-like.
One more line, so this post isn’t contradicted by the live page. TM Forum says the Canvas is being extended for AI agents, including demonstrations of Level 4+ autonomy. The README adds that the Canvas can expose interfaces as tools for AI agents. The next post takes that up.
Three questions for this week
- If we removed the gateway and the identity system from the component’s own code, would the Component document still say what it needs?
- Which gateway operator are we on today (Istio, Kong, or APISIX), and would a swap leave the Component document unchanged?
- Are we treating a Helm chart and a cluster as the ODA Canvas, or as the pattern that reads component metadata and runs that lifecycle?
Key takeaways
- A pattern, not one announced standard. TM Forum’s page says the project specifies the Canvas.
Canvas-design.mdsays the standard is the ODA Component Specification. Inform says the specification is platform independent. Keep all three attributions. - Declare, then bind. The component declares APIs and roles. Three operators configure the platform. Other operators exist, so those three are not the whole Canvas.
- Swap the binding, keep the declaration. Changing the gateway or mesh changes which API operator is enabled. The identity swap is design intent: the chart at this commit depends on the Keycloak operator. The reference implementation at commit
4f5e5edis a place to read the design.
Terms in this post
| Term | Meaning in this post |
|---|---|
| ODA | Open Digital Architecture. The component model this runtime hosts. |
| CRD | Custom resource definition. The Kubernetes document shape for a Component. |
| TMFOP001 | Component Management operator in the reference implementation. |
| TMFOP002 | API Management operator. |
| TMFOP003 | Identity Config operator. |
| TMFC001 | Product Catalog Management. The CRD’s example id only. |
| eTOM | Business Process Framework. |
| SID | Information Framework. |
| FF | Functional Framework. |
| UC002 | The use case for install, update, and uninstall. |
| UC003 | The use case for exposing APIs. |
| UC005 | The use case for static roles and permission specification sets. |
| BDD | Behaviour descriptions the test kit turns into executable tests. |
| CI/CD | Continuous integration and continuous delivery. |
TM Forum · Part 9 of 14
10 · Autonomous Networks
Previous: TM Forum ODA: Frameworx, Cut into Components · All 14 parts
Leave a Reply