In eTOM Explained, eTOM was the construction sequence: the How. This post is the materials specification: the What.
You do not need the Open API posts yet. You do need a shared answer to a boring question that kills programmes: when two teams say “customer,” are they talking about the same object?
At a Glance
- SID is the Information Framework — a shared dictionary of entities and attributes, not a database you install.
- Four domains do most of the teaching: Customer, Product, Service, Resource. Party lives in Common Business. It is not another word for Customer.
- ABEs (Aggregate Business Entities) cluster related objects. Product has a specification, an offering, and an instance. Service splits into what the customer feels (CFS) and what the network must configure (RFS).
- On the same order-to-activation path: Party is TMF632. Customer is TMF629. Do not put every person on TMF629.
Why a shared dictionary
Frameworx still gives you four drawings of the same operator. The last post named the work. This one names the objects that work moves. TAM and the Functional Framework will still say where software sits. Open APIs will still move the objects. None of that helps if “customer” means a legal entity in one room, a billing account in another, and a row in a CRM in a third.
That is the problem the Information Framework (SID) — Shared Information/Data model, if you still use the old expansion — was built to shrink. Have you ever integrated two systems where one calls a customer “Subscriber” and the other calls them “Account Holder”? Months of mapping workshops are usually SID work that nobody named.
If you were specifying materials for a house, you would not let one contractor mean “door” as the slab and another mean the opening in the wall. SID is that spec: brick type, pipe diameter, the attributes that make “a data plan” the same object when it leaves the catalog and arrives in billing.
It is still a reference model. You align to SID. You do not “go live on SID.” No operator runs the wheel as a literal schema. The value is a common dictionary so you can argue about whether the offering is complete, instead of arguing about whether product means tariff, bundle, or the SIM.
Industry reality: The wheel on the war-room wall is not the data model. A named object on a real order is. Wallpaper is not a transformation.
The domain wheel
SID is organized into domains. For this series, four still do the teaching. The rest of the wheel is real — do not pretend SID is only four boxes.
Customer is who buys, and how we relate to them: the commercial relationship, the accounts, the orders.
Product is what is sold, and on what terms. The catalog lives here. So does the instance the customer actually holds after the order completes.
Service is what is actually delivered. SID splits this on purpose: a customer-facing service (CFS) is what the person experiences; a resource-facing service (RFS) is what the network and IT must configure to make that experience true.
Resource is the physical and logical stuff that carries it: SIM, MSISDN, radio, ports, virtual functions.
The other domains are not scenery. Market / Sales is how you take the offer to market. Supplier / Partner is who you buy from or sell with — the MVNO, the roaming partner, the towerco. Enterprise is the rest of the company: finance, HR, the identity that is an employee and not a buyer. Common Business is the shared kit every domain borrows: location, agreement, business interaction — and Party.
That last one is the whole point of this article. Party is not a domain of its own in the teaching wheel. It is an ABE in Common Business. Customer is a domain. Mixing them is how every “person” ends up on the customer API.
For Strategy: The wheel is an operating-model sketch for data. Use it to name owned objects and owners. Do not use it as a 200-box RFP.
For Developers: You will not code “the Product domain.” You will see these names in payloads (productOffering, customer, relatedParty). The field is the dictionary. The API that carries it comes next in the series.
ABEs — clusters, not a poster
An Aggregate Business Entity (ABE) is a cluster of related entities and attributes that travel together. It is not a table. It is not a microservice. It is a named lump of meaning you can point at in a workshop.
A few lumps are enough:
- Party — Individual or Organization. Who they are, before any commercial role.
- Customer — the relationship with this provider, plus the accounts that sit under it.
- Product grain — Product Specification (what can be sold), Product Offering (the commercial offer: price, terms, market), Product (the instance this customer now holds).
- Service grain — CFS versus RFS. Do not collapse them into “connectivity.”
- Resource grain — physical (the SIM, the port) and logical (the MSISDN, the bearer).
That is not the catalogue. SID has more ABEs than you want on a slide. The practical rule is the same as eTOM’s: decompose until a payload field has one meaning. If the next box is a column in your CRM, you have left the public framework and entered your estate.
For Developers: ABE names show up as payload fields and as the nouns in architecture docs. They are not REST collections by themselves. You cannot GET /sid/ProductOfferingABE. You implement the interface that carries those objects.
The failure mode is the poster of every ABE, laminated, with local nicknames still in the interfaces. Then every vendor is “SID-aligned,” and none of them share a field.
Party is not Customer
This is the distinction developers need before they touch a customer API.
A Party is an Individual or an Organization. Jane Doe. A limited company. A government department. Identity — legal name, identifiers, contact media — before anyone has bought anything.
A Customer is a Party playing a commercial role with this communications service provider. Accounts, orders, the product they hold. Not every Party is a Customer. Your employee is a Party. Your roaming partner is a Party. The towerco you buy from is a Party. The person in the shop who has not bought yet is already a Party.
That is why TMF632 Party Management and TMF629 Customer Management are different APIs. TMF632 names the person or the company. TMF629 names the buyer relationship. Put every “person” on TMF629 and you will invent customers for staff, for suppliers, and for the contact who is only a related party on someone else’s account.
The same Party can wear more than one hat. An MVNO is a partner (Supplier/Partner) and, in some processes, a customer. SID can say that without cloning the organization into two people. Clone them in your databases and you will spend the next programme reconciling “the same company, three IDs.”
Two teases, then we stop: the calls that create and update these objects in software — and the rest of the Open API list — are Phase 3. Here the job is only this: do not treat Party and Customer as synonyms, in the model or in the ticket.
Use case: one mobile subscription
Posters do not ship service. A named object on a named order does. Take the same path as the eTOM post: a customer orders a mobile plan, and we need it live. Now the objects have names.
- Party. Jane Doe exists as an Individual before she is your buyer. If she is already staff, or already a contact on a company account, she is still one Party.
- Customer. Jane (or her company) plays the customer role with you. This is the relationship you will bill.
- Product. The specification is the mobile plan as designed. The offering is what is sellable here, at this price, to this market. The instance is the product Jane now holds once the order completes. If you skip the instance, catalog and inventory are the same drawer — until they are not.
- CFS. The customer-facing service is mobile access: what Jane experiences when the phone attaches and data flows. This is not the SKU. The SKU was product.
- RFS. The resource-facing service is the bearer, the PDU session, the network configuration that realises that access. Designers who skip RFS discover it at activation, when “the product is live” and the radio disagrees.
- Resource. The SIM, the MSISDN, the radio and core objects that the RFS rides on. A SIM is not a product offering. It is not a CFS. It is a resource assigned to a service that fulfils a product.
If the site fails next Tuesday, you have not sold a new product. The Party is unchanged. The Customer is unchanged. Assurance restores the service and the resources. That is still eTOM’s other band. SID is why you do not reopen the original order as if Jane ordered an outage.
A London team and a Tokyo team can now argue about step 5 (RFS) using the same words. That is the whole point of the dictionary.
The calls that will execute this path — Product Order (TMF622), Service Order (TMF641) — are Open APIs. Those come when we leave the dictionary and enter the mortar.
How teams actually use SID
Used well, SID is a naming system for objects:
- Mapping workshops. “Subscriber” versus “Account Holder” becomes Customer, Party, and account — named, owned, done.
- Payloads. The field is
productOffering, not whatever the last vendor called a tariff. - RFPs. Ask vendors to map to domains and to the ABEs you actually care about (Party, Customer, Product Offering, CFS/RFS). You will see the gaps before year two.
- Audit of the programme itself. “Show me Jane’s subscription as Party, Customer, Product, CFS, RFS, Resource” is a better request than “show me the SID certificate on the wall.”
The failure mode is the opposite: print the wheel at A0, hang it behind the steering committee, and keep local nicknames in every interface. Then every vendor is “SID-aligned,” and none of them share an object.
3 questions for your team
- When we say “customer,” do we mean Party, the Customer relationship, or the billing account — and do the other rooms agree?
- Can we walk one mobile subscription across Product, CFS, RFS, and Resource with named owners, or only to a poster?
- Where are we putting people who are not buyers — staff, partners, related contacts — and have we mistaken them for TMF629 Customers?
Key takeaways
- SID is the shared dictionary. You align to it. You do not install it. Four domains do the teaching; Party lives in Common Business.
- Party is not Customer. TMF632 names the person or company. TMF629 names the buyer. Do not put every person on TMF629.
- One named subscription beats the whole wheel. Specification, offering, instance; CFS then RFS; then resource. That is how you prove the map is for work, not for wallpaper.
Terms in this post
Lookup only. Each term is taught in the body on first use.
| Term | Meaning in this post |
|---|---|
| SID | Information Framework — the shared dictionary (What) |
| eTOM | Business Process Framework — the process map (How) |
| ABE | Aggregate Business Entity — a cluster of related objects |
| Party | Individual or Organization (identity). Lives in Common Business |
| Customer | A Party in a commercial relationship with this provider |
| CFS | Customer-facing service — what the person experiences |
| RFS | Resource-facing service — what the network must configure |
| TMF632 | Party Management API |
| TMF629 | Customer Management API |
Next in this series: Open APIs Explained: The Calls That Move a Telco Order — the calls that carry the objects this post named.
Leave a Reply