Jane already exists in our system as a person and as a customer, and her loyalty tier has a place to live. This post asks a different question: which piece of software should own her? You need the two records from A TM Forum API, Written Out and the tier from TM Forum API Extensions. The series sits on the hub.
In many operators the honest answer is “the big system that also holds everything else.” TM Forum ODA, the Open Digital Architecture, is TM Forum’s answer to that. It keeps the shared names from Frameworx and splits the big system into smaller pieces of software, each with one job. This post explains the split. The platform those pieces run on is the next post.
At a Glance
- Many operators run one big business system (a BSS) that holds the customer record, the catalog, the order, and the network request together. Changing any part means releasing all of it.
- ODA splits that system into components: pieces of software with one job each, reached through Open APIs. The Frameworx names for the work, the data, and the calls still apply.
- Jane’s record goes in Party. The catalog and orders go in Core Commerce. Delivering the service goes in Production. Screens go in Engagement.
One big system holds Jane
Most operators have a business support system, or BSS. It is the software that sells things and bills for them. Often one supplier delivered it as a single suite: customer records, the product catalog, order handling, and the request that asks the network to switch something on. Jane’s record is in it. So are the prices. So will her order be.
That is a problem the first time something small changes. Updating Jane’s loyalty tier and changing a price in the catalog have nothing to do with each other. They still go out in the same release, because they share one database and one supplier’s roadmap. Or they wait for a meeting to decide whose change goes first.
Figure: One BSS holds Jane’s record, the catalog, the order, and the network request. Every change leaves in one release.
The rest of this post splits that box into pieces and says which piece should own Jane.
What stays the same
Splitting the BSS does not throw away the earlier posts. The Frameworx Suite said it briefly: ODA repackages Frameworx for cloud-native IT. Three things carry over.
The Business Process Framework (eTOM) still describes the work, such as fulfilling an order. The Information Framework (SID) still says what Jane is. She does not become a different kind of person because her record moves to new software. Open APIs still carry her details, and the prices, between systems.
What changes is where the software boundaries fall. If each new piece keeps its own private names for Jane, nothing has been fixed. You have several smaller systems that disagree about her. The shared names are what let the pieces work together.
From applications to functions
To decide where to cut, you need a map. Frameworx already had one: the Application Framework, or TAM. It grouped what an operator’s software does into application areas, so a buyer could compare suppliers’ products against the same map. That is how the BSS in the first figure came to be described, as a set of applications. You will still meet TAM in older architecture documents and supplier answers. Read it to understand them. Do not start a new design from it.
TM Forum replaced it with the Functional Framework, published as GB1033. It is the same idea with the application grouping removed. What is left is a list of functions: single jobs, each defined by the information it handles and the work it does. “Keep the record of who Jane is” is a function. The CRM product an operator bought in 2014 is not a function. It is one product that happened to do that job, along with others.
A function does not care which product does it. That is what makes it possible to cut the BSS along job lines instead of supplier lines. At the time of writing, TM Forum’s site lists version 26.0, dated 29 May 2026.
Figure: Frameworx stays: the work, the data, and the calls. TAM described the BSS as applications. The Functional Framework lists jobs instead. ODA splits the BSS into components, and the Canvas is the platform underneath.
Where each piece goes
TM Forum groups ODA components into four business domains. Its public component directory lists them, and this section follows that list. Jane’s record moves first.
Party Management holds records of people and organizations. Jane’s record lives here, with her loyalty tier as the last post set it. Her record as a buyer points back to it. Party Management is one job, not the whole suite. TM Forum’s directory also files billing accounts and payments under Party, so this post leaves them there.
Core Commerce Management covers what the operator sells and what customers buy. The product catalog belongs here, and so do customer orders. The catalog describes what can be sold. It does not contain Jane. When it needs her loyalty tier, it asks the Party component through an Open API. It does not keep its own copy of her record.
Production covers what it takes to deliver the offer: the network service, the SIM, the equipment. A mobile plan is something Jane buys, so it lives in the catalog. Switching it on for her is Production’s job. TM Forum’s notes on the functional architecture use this split as the practical example: pulling the commercial offer apart from the service that delivers it, so each can change without waiting for the other. A price change no longer waits for the network side. A change to how the network is set up no longer forces a change to the catalog. If the two still go out in one release, you have the first figure with new labels.
Engagement Management covers the screens and channels: the app, the website, the call-centre screen. They show Jane’s details but do not own them. A screen that keeps its own copy of her will one day greet her with out-of-date details.
Figure: The four domains. Jane’s record sits in Party. The Canvas underneath is the platform they run on. The next post covers it.
The test is a swap
An ODA component is a piece of software with one defined job, which other systems reach through Open APIs, and which can be replaced without touching its neighbors. Party Management can offer the party API that Jane’s record was created on (TMF632). The catalog component offers the catalog API. Each Open API belongs to one component.
The way to test a design is to swap one component. Replace the catalog with another supplier’s. If the design is real, Jane’s record stays in Party, the party API is unchanged, and the address you stored for her still works. If swapping the catalog means migrating Jane’s data, the boundary was only on a slide, and you still have the first figure.
Real estates are messier. A twenty-year-old BSS can be wrapped in four domain labels while everything still sits in one database. That is worth writing down honestly. A wrapper you cannot swap is the old suite with new names on it. It can still be a sensible first step, provided everyone knows that is what it is.
The platform underneath
The components need somewhere to run. In ODA that is the ODA Canvas: the software platform that hosts the components and connects them. It is built on Kubernetes, a widely used system for running software in containers. The Canvas is not a fifth business domain, and Jane does not live on it. Her record is in the Party component, which happens to run there.
How the Canvas works is the next post. This one only needs the name. One caution: moving the old BSS onto Kubernetes does not split it. You would have the first figure again, on new hardware.
What BT said
BT Group is the example TM Forum points to. On 22 February 2024, BT announced that its Digital unit had reached TM Forum’s “Running on ODA” recognition. The BT newsroom announcement and TM Forum’s copy of it describe delivering products and services from reusable, cloud-native, vendor-agnostic components, so BT can bring new products to market faster and shed the cost of legacy systems. That is BT’s own account. The announcement gives no figure you could check. Operator results get their own post later in the series.
You can run a smaller check on your own estate this week. Name the system that owns Jane’s record. Name the system that owns the catalog. If they are the same system, you are still in the first figure. If they are different, write down which Open API stays the same if the catalog is swapped, and which other system must not be affected. That sentence is your boundary. BT’s announcement cannot write it for you.
Three questions for this week
- Which system owns Jane’s record, and is it also the system that owns the catalog?
- If we replaced the catalog, which Open API would stay the same, and which other system must not be affected?
- Do we call our platform ODA because it runs on Kubernetes, or because replacing the catalog leaves Jane’s record where it is?
Key takeaways
- One big system, one release. A BSS that holds customers, catalog, orders, and network requests together ships every change together. ODA splits it into components with one job each, and keeps eTOM, SID, and the Open APIs.
- Functions replace applications. TAM described software as applications. The Functional Framework lists jobs instead, so the split follows jobs, not suppliers.
- Test it with a swap. Jane’s record is in Party, the catalog and orders in Core Commerce, network delivery in Production, and screens in Engagement. Replace one and the others should not notice. The Canvas is the platform underneath, and the next post covers it.
Terms in this post
| Term | Meaning in this post |
|---|---|
| ODA | Open Digital Architecture. TM Forum’s design for splitting an operator’s software into components. |
| BSS | Business support system. The software that sells, takes orders, and bills. |
| Component | A piece of software with one defined job, reached through Open APIs and replaceable on its own. |
| eTOM | Business Process Framework. Describes the work an operator does. |
| SID | Information Framework. Defines the data, such as what a customer is. |
| TAM | Application Framework. The older map that grouped functions into applications. |
| Functional Framework (GB1033) | The replacement for TAM. Lists single functions instead of applications. |
| Party Management | Domain for records of people and organizations. |
| Core Commerce Management | Domain for what is sold and ordered. |
| Production | Domain for delivering the service and the network. |
| Engagement Management | Domain for screens and channels. |
| TMF632 | The party API. Jane’s record was created through it. |
| ODA Canvas | The platform that hosts the components and connects them. |
| Kubernetes | A widely used system for running software in containers. |
| Running on ODA | The TM Forum recognition BT announced in February 2024. |
Leave a Reply