TM Forum Community

Following up on the earlier discussion around Decision Autonomy and Operational Centricity, I would like to share a small working artefact developed as part of our internal architecture work.

In the previous thread, there was strong agreement that while TM Forum frameworks clearly articulate autonomy maturity (L0–L5), centricity evolution (network → service → experience/value) is addressed implicitly and across multiple assets rather than as an explicit architectural lens.

To explore this further, I attempted to operationalize centricity - not as a maturity model, but as a characterization of what operations optimize for, and how this affects data, control scope, and success criteria.

At a high level, the characterization distinguishes four centricity categories:

• Network-centric: optimizing network resources and technical KPIs
• Service-centric: optimizing end-to-end services and SLAs
• Customer-centric: optimizing customer experience and perception
• Value / Business-centric: optimizing business outcomes and economic impact

Importantly, this lens is orthogonal to autonomy: high or low decision autonomy can exist at any centricity level. Centricity defines what the system optimizes for; autonomy defines how independently decisions are made.

I applied this centricity characterization to a real service case (enterprise connectivity) to test whether the distinctions are observable in practice - for example in terms of data models, intent scope, prioritization logic, and operational KPIs. The exercise proved useful internally for explaining why some highly automated use cases still struggle to demonstrate clear service or business impact.

I would be very interested in the community's perspective on a few open questions:

1. Do these centricity categories resonate with what you observe in your own operations?
2. Are there important dimensions or characteristics missing from this lens?
3. Would such a centricity characterization be useful as a complement to AN maturity discussions when planning automation roadmaps or next-generation Operations OS architectures?

This is shared purely as a discussion artefact, not as a proposal for a new maturity model or standard. I look forward to learning from your experiences and viewpoints.

#DigitalTransformationMaturity

------------------------------
Ngoc Linh Nguyen
Vietnam Posts and Telecommunications Group (VNPT)
------------------------------

------------------------------
Chirag Raval
Lead Consultant
Infosys Ltd
------------------------------

Thank you, Chirag - your observations on the Two-Axis View are extremely valuable and very much aligned with the direction we are taking.

Based on your feedback, we have clarified that the vertical axis represents full Centricity profiles (object, objective function, decision scope, and intent ownership), not simply KPI layers. We also refined the horizontal axis interpretation so Autonomy explicitly describes how decisions are made, while Centricity defines what is optimized, over which scope, and under whose authority.

We updated the matrix notes to show what's architecturally valid (not just theoretically possible). Also flagged high-autonomy network loops without service/business oversight as the 'Isolated Autonomy' anti-pattern.

For Customer/Value at low autonomy: feasible in theory but not viable without proven capabilities + governance.

Your input helped ensure the Two-Axis View functions as a coherent projection of Tables 1–1C and the Annexes, not a standalone model.
Appreciate the thoughtful engagement - further discussion is very welcome.

------------------------------
Ngoc Linh Nguyen
Vietnam Posts and Telecommunications Group (VNPT)
------------------------------

Original Message:
Sent: Feb 07, 2026 09:01
From: Chirag Raval
Subject: From Concept to Characterization: An Operational Lens on Centricity in Network Operations

1. Do the categories resonate?

Yes. These four levels are easy to observe in real operations:

 

Network → resource efficiency

Service → SLA/SLO

Customer → perceived experience

Business → revenue, margin, risk

 

Teams often operate at different centricities without realizing it, which leads to misaligned KPIs and automated loops that "work" technically but don't create value.

 

2. What might be missing?

To make the centricity lens operational, a few additional dimensions help:

 

Explicit objective function (what is being optimized mathematically)

Decision scope & blast radius

Time horizon (ms for network, hours/days for business)

Intent & contract models

Explainability (how decisions justify trade-offs)

Risk/guardrails

Ownership of policy

 

These turn centricity from a conceptual taxonomy into something you can use for design.

 

3. Is this useful alongside autonomy maturity?

Yes

Autonomy tells you how far to automate; centricity tells you the correct target for optimization. This avoids:

 

Highly autonomous loops optimizing the wrong objective

Service-level automation that ignores customer or business impact

CEM dashboards without control rights

 

In automation roadmaps and next-gen OPS OS architectures, centricity helps define:

 

Which loop arbitrates decisions

What the objective function should be

How to align network, service, customer, and business priorities coherently

------------------------------
Chirag Raval
Lead Consultant
Infosys Ltd
------------------------------