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.

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.