In What is TM Forum?, we covered the fragmentation tax: billions lost to custom integrations and siloed systems, and the alliance built to fix it. This post is the map of how that fix is specified.
The name of the map is Frameworx.
If you were building a house, you would not start by ordering random bricks. You would need construction steps, a materials specification, a floor plan, and building codes so the plumbing in one room actually joins the next. For a communications service provider, Frameworx is that shared blueprint.
At a Glance
- Frameworx is TM Forum’s suite of models that give telecom a common language for process, data, and applications.
- It is built on three models—eTOM (process), SID (information), and TAM (application)—with Open APIs as the mortar that connects them.
- ODA does not throw Frameworx away. It repackages those assets for cloud-native IT, and it replaces TAM’s application view with the Functional Framework and ODA Components.
You do not need the first post to follow this one. It helps: that article is the “why.” This one is the map.
Four drawings of the same house
Most Frameworx introductions stop at three pillars. That is the right starting picture, and it is incomplete. Three drawings of a house are still just drawings until the pipes and wiring actually join.
| Piece | Official name | Role | House equivalent |
|---|---|---|---|
| eTOM | Business Process Framework | The How — which work runs, in what order | Construction steps |
| SID | Information Framework | The What — shared entities and attributes | Materials specification |
| TAM | Application Framework | The Where — where functions live in software | Floor plan |
| Open APIs | Integration Framework | How those rooms talk in software | Mortar and building codes |
eTOM is the sequence of work. Pour the foundation, frame the walls, install the roof.
SID is the spec for the materials. Brick type, pipe diameter, wire gauge. When you order “a door,” the supplier sends a door that fits the opening you built.
TAM is the floor plan. Kitchen, bedroom, bathroom. Cooking happens in the kitchen; plumbing sits where the pipes are.
Open APIs are what stop the house from being three disconnected PDFs. Rooms only work as a house if the pipes join. In software, that join is a contract: the same product, party, and order objects moving between functions without a one-off mapping project.
Keep the house for Frameworx internals. Kubernetes and the ODA Canvas need different language—that is later in the series.
For Strategy: Frameworx is a shared vocabulary for RFPs, operating models, and vendor workshops. It is not a product you install.
For Developers: The models show up as process names in architecture docs, entity names in payloads, and TMF API numbers in tickets. You do not “code eTOM.” You implement the APIs that carry SID objects through eTOM-shaped flows.
eTOM — the How
The Business Process Framework, still widely called eTOM (Enhanced Telecom Operations Map), is a hierarchical catalogue of the processes an operator needs to run. It is famous because it is visible: the poster on the war-room wall, the swimlane in the transformation deck.
It splits the business into three process areas:
- Strategy, Infrastructure & Product: Long-term planning of what you will sell and how you will build the network.
- Operations: Day-to-day work of taking orders (Fulfillment), keeping the service running (Assurance), and getting paid (Billing).
- Enterprise Management: Back-office functions such as HR, finance, and IT.
That is enough of the map for this post. The grid itself, the FAB model as a design tool, and decomposition from Level 0 through Level 3 belong in the eTOM deep dive. Public eTOM is strongest through Level 3; Level 4 is often the operator’s own procedures, not a catalogue TM Forum publishes in full.
The business value is already visible without that grid. A company in London and a company in Tokyo can describe an “order-to-cash” process with the same words. That cuts ambiguity in audits, transformations, and vendor workshops. Two teams can argue about how well they fulfill, instead of arguing about whether “order management” means capture, credit check, or activation.
SID — the What
The Information Framework (SID) is the common dictionary: the entities (the things we talk about) and their attributes (the details of those things).
Have you ever integrated two systems where one calls a customer “Subscriber” and the other calls them “Account Holder”? That translation gap is a primary cause of integration failure. Months of mapping workshops are usually SID work that nobody named.
SID is organized into domains. For this series, four matter most:
- Customer: Who buys, and how we relate to them.
- Product: What is sold, and at what price.
- Service: What is actually delivered—customer-facing and resource-facing.
- Resource: The physical and logical network that delivers it.
When teams share SID entity names, systems “plug and play” with less custom mapping. The payload field is productOffering, not whatever the last vendor called a tariff.
The finer grain—Aggregate Business Entities (ABEs), and the difference between Party and Customer—is the job of the SID post. Developers will need that distinction before they put every “person” on TMF629. Party (TMF632) and Customer (TMF629) are not synonyms. Flag that now; we will unpack it there.
TAM — the Where (and what replaced it)
The Application Framework (TAM) groups functions into software application areas. eTOM tells you how to work; SID tells you what the data is; TAM tells you where in the software landscape that work has historically lived.
Imagine you are buying a billing system. One vendor includes “Account Management” in billing; another puts it in CRM. Without a shared map, comparing those bids is guesswork, and you discover the overlap in year two of the programme.
TAM’s lasting value is functional application blocks. In an RFP, you can ask vendors to map their products to the same blocks, spot gaps and overlaps, and compare like with like. You will still hear TAM language in vendor conversations and older architecture decks. That is useful. It is also not the current TM Forum packaging for new work.
In the Open Digital Architecture (ODA), TAM’s application view is succeeded by the Functional Framework and ODA Components: smaller, API-exposed building blocks rather than a map of traditional applications. Remember TAM so you can read the older maps. Plan new estates against ODA.
That is the whole TAM lesson for this post. There is no later TAM deep dive in this series. The successor view lives with ODA.
Open APIs — the mortar
Frameworx was never only three static models. Open APIs are the Integration Framework: REST (and event) contracts for the commercial objects SID names, used in the processes eTOM describes, by the functions TAM—and now ODA Components—locate.
A product order is not a PowerPoint alignment exercise. It is TMF622 talking to a catalog (TMF620), a service order (TMF641), inventory (TMF637), and billing (TMF678). Cart (TMF663) and qualification (TMF679) often sit on that path too; many operators skip the cart. We will walk a simplified order-to-cash chain, with code, in the API posts.
The point here is simpler. If eTOM, SID, and TAM are the drawings, Open APIs are how the house is actually plumbed. Skip the APIs and you still have a beautiful model and a pile of point-to-point integrations.
For Developers: The TMF numbers are the portable skill. Learn the Product Order shape once; the next vendor’s “TMF622-aligned” API is a dialect, not a new language.
One upgrade, four views
The four pieces are designed to move together. Take a familiar scenario: a customer wants to upgrade their data plan.
- eTOM names the process: a fulfillment flow that takes the request, updates what the customer holds, and notifies billing.
- SID names the data: the “data plan” that moves between systems has the same attributes (speed, volume, price) everywhere.
- TAM / Functional Framework names where the work sits: sales and engagement, product inventory, billing—not three invented buckets per vendor.
- Open APIs move the objects: the same product and customer representations cross those functions without a one-off mapping project.
If any one of the four drifts, you are back to the fragmentation tax. Process without shared data is a swimlane that dies in integration. Shared data without APIs is a dictionary nobody implements. APIs without process are endpoints in search of an operating model.
From Frameworx to ODA
The first post already covered the history (NGOSS → Frameworx → ODA). The useful question here is not “what year did the acronym change?” It is why the models must stay in sync.
ODA is a model- and data-driven architecture for open digital platforms. It keeps eTOM, SID, and Open APIs, and it changes the application story: components on a canvas, not a catalogue of monoliths mapped to TAM. You cannot skip Frameworx and “just do ODA.” Without shared process and information definitions, a microservices estate is still a pile of custom integrations—only now they are smaller and more numerous.
Think of Frameworx as the semantic foundation. ODA is the cloud-native execution of that foundation. The Functional Framework is the honest successor to TAM’s “where.” Open APIs are the contract the components expose.
Key takeaways
- Frameworx is a mental model, not a product you install. You align to it; you do not “go live on SID.”
- Four pieces, one operator: eTOM (how), SID (what), TAM then the Functional Framework (where), Open APIs (the join).
- ODA repackages Frameworx for cloud-native IT. It does not replace the need for shared process and information.
Industry reality: These are reference models. No CSP implements them exactly as documented. The value is a common reference that accelerates understanding—not rigid compliance. 100% Frameworx is rare; a shared language is the point.
3 questions for your team
- When we say “customer,” “product,” or “service,” do we mean the same entities as SID—or do we have three local dictionaries?
- Can a vendor map their stack to TAM or the Functional Framework without a two-week workshop to decode our terms?
- Are our integrations custom point-to-point, or are we actually using Open APIs as the mortar?
Next in this series: eTOM Explained: Mapping How a Telco Actually Runs — the grid, FAB, and order-to-activation.
Previous: What is TM Forum? The Industry Alliance Shaping Telecom’s Future
Leave a Reply