Schlagwort: BSS/OSS

Every experienced BSS/OSS architect knows the basic rule: an order is completed only after the network has confirmed fulfilment and the product inventory has been updated. In a design review, nobody argues with that.

The difficult questions start where that rule stops helping:

• What does „completed“ still tell you a month later, after a field engineer, a migration or a failed rollback has changed the network?
• What state does a product have while a second order is already in flight against it?
• An order with five items ends as partial. What should the inventory say?
• Care sees the order completed, the service degraded and the product active. Which of the three is „the“ status?

These are not happy-path questions. They are questions about who owns which state, across layers and over time. TM Forum Open APIs define a well-structured state model for each resource, but they don’t say who writes those states or how they relate across APIs. That is an architecture decision, and it is where mature landscapes still accumulate their most expensive incidents.

This article gives a pragmatic answer: four rules, a reference flow, an approach to concurrent orders, and a reconciliation model for TMF622, TMF641, TMF637 and TMF638.

Key takeaways

• Orders own the state of a request. Inventory owns the state of a result. The network owns operational reality. These are different things and must not share one status field or one writer.
• Every state has exactly one writer. Channels never write state. They submit intent and read.
• State flows up, intent flows down. Fulfilment results move upward (network → service → product), while orders push intent downward (product → service → network).
• Completion is a statement about the past. After the order closes, inventory and network can still drift. Plan for it.
• Disagreement between order, inventory and network is a signal. Handle it through an explicit reconciliation process, not through silent patches.

The landscape in this article

To keep the discussion simple, I use only the components that matter for state:

• Customer Order Management (COM): receives product orders (TMF622), decomposes them, and owns the product inventory (TMF637).
• Service Order Management (SOM): receives service orders (TMF641), performs design, reservation and service activation as part of its fulfilment logic, and owns the service inventory (TMF638).
• Network: the systems that actually carry the service.

Channels (mobile, web, BFF, agents) sit in front of COM and only submit intent and read state.

1. Three kinds of state that get mixed up

A few concrete examples of each:

• Order state: product orders and their items move through states such as acknowledged, inProgress, held, completed, failed, partial or cancelled. Service orders (TMF641) use a similar vocabulary.
• Inventory state: a product in TMF637 carries a lifecycle status such as active, suspended, pending terminate or terminated. A service in TMF638 carries a lifecycle state such as designed, reserved, inactive, active or terminated.
• Operational state: is the service running, degraded or failed right now? In TMF638 this is typically an operating status that is fed by network and monitoring data, not decided by the order process.

(Exact enumerations differ between API versions and implementations. Check the version you actually use before building rules on top of them.)

The most common root cause I see in practice is simple: one word, „status“, is used for all three, and different teams read it differently.

2. Four rules for state ownership

3. Reference flow: new broadband service

The flow is deliberately short: channel → COM → SOM → network, with the two inventories beside it.

1. Intent in. The channel submits a product order (TMF622). COM validates it and acknowledges it. Order and items move from acknowledged to inProgress.
2. Decomposition. COM decomposes the product order item into service orders and submits them to SOM through TMF641. Service order items move to inProgress.
3. Design and reserve. SOM retrieves the service specification (TMF633), reserves resources and records the service in the service inventory (TMF638) as designed or reserved.
4. Activation. SOM executes the activation against the network. On success, it updates the service in TMF638 to active and completes the service order.
5. Fulfilment result up. COM receives the result (event or callback) and advances the product order item.
6. Inventory update. COM creates or updates the product in TMF637 as active, then marks the order item and the order completed.
7. Later, reconciliation. Inventory is checked against what the network reports. Differences go into a controlled drift process (section 6).

How the states line up in the happy path:

Two kinds of return information flow back to COM and the inventories: fulfilment results (which advance order state) and service state for reconciliation (which keeps inventory honest). Keep these as two separate paths in your design.

4. Where it breaks: seven failure patterns

1. Order state used as proof of current state.
Symptom: care or an automated process concludes „the order is completed, so the service is running“, weeks after completion.
Cause: order state describes what the process did, not what exists now.
Fix: use orders for history and progress, and inventory plus operational status for the current state. Show them side by side.

2. Channels write inventory.
Symptom: statuses changed by BFFs, scripts or support tools, with no order behind them.
Fix: remove write access. Corrections go through a controlled path with audit (see section 6).

3. Dual writes.
Symptom: SOM updates the service inventory and also pushes a product status, while COM writes the product status itself. Under failure, the two diverge.
Fix: one writer per state, and one fulfilment result that drives everything downstream of it.

4. Order status inferred from inventory.
Symptom: „where is my order?“ is answered by looking at inventory.
Cause: inventory only shows results, not progress. It can’t distinguish „not started“ from „failed“.
Fix: order tracking reads order state (TMF622, TMF641) and uses inventory only as additional evidence.

5. One status enum for everything.
Symptom: a single status field shows order progress, lifecycle and health, depending on who looks.
Fix: separate order state, lifecycle state and operational status, as in the table in section 1.

6. No handling for partial and failed orders.
Symptom: an order with five items ends as partial; two services are active, three are not, and nobody knows what the product state should be.
Fix: define up front what each outcome means for inventory (roll back, keep partial, compensate) per product family.

7. Out-of-order and duplicate events.
Symptom: a late „in progress“ event overwrites „completed“.
Fix: idempotent consumers keyed by event ID, state-machine guards that reject illegal or stale transitions, and a version or timestamp comparison before applying a change.

5. Concurrent orders: do you put „pending“ in inventory?

This is where architects disagree, and it’s worth deciding consciously.

Option A, realized state only. Inventory holds only what has been fulfilled. Everything in flight lives in orders. To check for conflicts, COM queries open orders for the product. It is clean, but every consumer who needs to know „may I change this product now?“ has to look in two places.

Option B, pending markers in inventory. Inventory also reflects in-flight changes, for example a product being activated or terminated. Consumers get a single place to look, but inventory now mixes result and process, which is exactly the blur Rule 1 tries to avoid.

My pragmatic recommendation is a hybrid:

• Inventory contains realized state plus a minimal, COM-written pending marker (the lifecycle models of products already include pending-type statuses for this purpose).
• COM is the only component that starts an order on a given product, and it serializes orders per product, so there is exactly one open change at a time.
• Channels and agents do not guess. They ask an eligibility question first (TMF679 is a natural fit: may this customer change this product now?), and the answer accounts for open orders.

Be aware that the standard product status model does not cover every real-world need. Concepts such as a lock on a product, or an operational sub-status next to the main status, are usually added as extensions in practice. If you add them, document who sets and clears them, because an orphaned lock is as harmful as a missing one.

6. Reconciliation: treating disagreement as a signal

Even with perfect ownership rules, reality will drift: manual network changes, failed rollbacks, lost events, migrations. You need a reconciliation process, not just good intentions.

7. A diagnostic matrix for care and operations

When a customer asks „where is my order?“, read order state, service state and product state together, instead of picking one:

This matrix is also what an AI agent or assistant should implement: report all three states, flag the inconsistency, and don’t decide which one is right. That decision belongs to operations or to your reconciliation process.

8. Events and idempotency: the plumbing that makes it work

TMF APIs offer state-change notifications for orders, services and products. For ownership rules to hold in practice:

• Make consumers idempotent. Events get redelivered. Processing the same event twice must have the same effect as once.
• Guard transitions. Reject illegal or stale transitions explicitly, and log them. They tell you about integration bugs.
• Carry correlation. Include the product order, order item and service order references in events so any state can be traced back to its cause.
• Use an outbox for completion. Writing inventory and emitting the completion event should not be two independent operations.
• Plan replay. Have a dead-letter queue and a safe way to replay events, so a lost message is a fixable incident, not a permanent inconsistency.

A simplified service state-change event shows what a consumer needs:

{
  "eventId": "evt-8f21",
  "eventType": "ServiceStateChangeEvent",
  "eventTime": "2026-10-05T09:14:22Z",
  "correlationId": "po-48213/item-2",
  "event": {
    "service": {
      "id": "svc-77310",
      "state": "active",
      "version": 4
    }
  }
}

The eventId supports idempotency, the correlationId supports tracing, and the version lets the consumer ignore anything older than what it already applied. The exact event schema depends on your implementation. The principles don’t.

9. A pragmatic checklist

Before your next integration or review, check the following:

1. Is there a written table of single writers for every state attribute?
2. Do channels have read-only access to all state APIs?
3. Is the product state derivation rule defined for each product family?
4. Does the order complete only after the network result and the inventory write are confirmed?
5. Are partial and failed outcomes defined, including what happens to inventory?
6. Do you have event idempotency, transition guards and replay?
7. Is there a reconciliation process with an explicit master per attribute class?
8. Are corrections audited and visible downstream?
9. Do care tools and agents show all three states instead of one?

Conclusion

The question „who owns the state?“ doesn’t have one answer, because there is more than one kind of state. Orders own the state of requests. Inventory owns the state of results. The network owns operational reality. And „completed“ is a statement about a moment, not a guarantee about the future. TMF Open APIs give you well-defined resources and state models for each layer, but they are integration contracts, not an ownership policy.

The pragmatic approach is to decide ownership explicitly, keep one writer per state, let results flow up through orchestration, and treat disagreement as a signal for a controlled reconciliation process. That is less glamorous than a new platform, and it prevents more incidents than most platforms do.

Working through order, inventory and reconciliation design in your own BSS/OSS landscape? A short initial conversation is free and non-binding.