How matrix telcos can maintain autonomy with a unified platform

Insights

• Matrix telcos face complexity from shared networks and independent business units.
• Siloed data and manual processes drive inefficiency and slow response times.
• ServiceNow unifies service management while preserving business unit autonomy.
• The result is better visibility, governance, automation, and customer experience.

Some communications service providers (CSPs) operate in a matrix operating model, where one or more horizontal network delivery units serve multiple market-facing business units. In such cases, each unit has distinct customers, profit and loss statements, processes, service level agreements, and data governance requirements, yet they all depend on the same physical network. This leads to structural tension between shared infrastructure and the autonomy of business units, demanding a high degree of operational integration to function efficiently. A platform that integrates with the matrix telecom companies' existing IT service management (ITSM) tools can provide a unified service management layer, enabling greater standardization across the network while allowing business units to retain operational independence.

Disconnected operations, rising complexity

A matrix telecom organization operates across two axes. The vertical axis comprises market-facing units (MFUs), such as consumer, business, wholesale, government, or any other commercial segment, each unit owning its customer relationships and service commitments. The horizontal axis comprises a shared network services unit or multiple technology-domain units responsible for delivering the underlying network infrastructure and connectivity across domains such as mobile/5G, fixed broadband, ethernet, voice, and data services (Figure 1).

Figure 1. Matrix telecom operating model with market-facing units and shared network services

Source: Infosys

This structure creates inherent operational tensions across two dimensions:

Data and inventory problems

Data duplication and drift: Each MFU tends to build or maintain its own records for the services it sells, leading to multiple inconsistent views of the same network resource.

Delayed disruption notification: One network fault can end up affecting multiple MFUs simultaneously, and communication relies on manual processes such as phone calls, emails, and bridge calls rather than automated, guaranteed notifications. For instance, a UK-based telecom company, which is a client of Infosys, was operating more than 20 systems holding inventory data, with information duplicated across the systems. The lack of a unified view of the services meant a fragmented experience for the service desk users and operations teams, making it challenging for them to assess the overall impact of their services.

Operational and governance problems

Fragmented assurance: In telecom companies, different network platforms are managed through separate systems such as network management systems (NMS) and element management systems (EMS) for each unit. This makes it difficult to have a unified view of network resources and services. For internal users such as network operations center teams, network engineers, service assurance teams, and operations teams, this fragmentation can lead to limited end-to-end visibility, inconsistent information, slower fault identification and resolution, and greater coordination between teams to piece together information across business units or network domains.

Governance and compliance risk: Role-based access, audit trails, and data sovereignty requirements cannot be enforced consistently without a shared, domain-aware platform.

In other words, as business units evolve independently, service management becomes siloed across the organization. Research shows that employees working in matrix organizations tend to experience less clarity about their roles than their counterparts in traditional organizational structures.

Other fallouts of operational fragmentation include disconnected inventory systems, duplicated and inconsistent service data, siloed assurance processes, inconsistent fulfillment workflows, and limited cross-domain visibility, which increase operational cost and complexity. Also, because systems and operational units are disconnected, there might not be end-to-end automated visibility of disruptions. As a result, a disruption detected in one system or domain will not automatically trigger notifications to all affected teams, systems, or customers. The service desk would need to identify the impact, connect the information across systems, and manually notify others.

Without a shared, domain-aware platform, impact identification, coordination, governance, and customer communications remain slow and heavily manual.

Operate independently, execute as one

Success depends on balancing the autonomy of business units with enterprisewide operational integration, governance, and service assurance, and the ability to enable AI-driven operations (AIOps) through a unified operational foundation.

The solution is to preserve the autonomy that gives each business unit its commercial and operational advantage while providing a platform that maintains those boundaries and eliminates duplication and fragmentation across the organization.

ServiceNow's Now Platform helps address these challenges by integrating with existing ITSM tools, using domain separation, a unified configuration management database (CMDB) aligned with the common service data model (CSDM) and TeleManagement Forum (TM Forum) standards, shared automation, and cross-domain workflows.

ServiceNow's domain separation capability maps directly to the matrix organization. Each organizational unit, whether it’s a market-facing business unit or the shared network services unit, is assigned its own domain. The solution approach with the ServiceNow platform provides the foundation for enterprisewide service management, and its architecture is constructed around two interlocking principles:

A unified CMDB for holistic view

The platform creates a unified data layer, or single source of truth, using a unified CMDB aligned with the CSDM and TM Forum's shared information data (SID) framework that addresses the telco’s need to have shared information definitions — that is, standardized definitions of the key business concepts and data used across the telecom industry — and models. It maps network resources to services and customer assets, providing end-to-end visibility, through a single product-service-resource model view, allowing users to see underlying problems affecting customer service.

Infosys delivered a consistent CMDB to the UK-based telecom customer, transforming the way its operation teams serve their customers, positively impacting key performance indicators like mean time to repair and cost to serve.

Domain separation for data and process isolation

Each market-facing unit is assigned its own domain. Within that boundary, all operational data such as orders, cases, incidents, and service records is visible only to the users and systems that belong to it. The access restrictions within a domain are achieved via role-based access controls. This ensures that domain autonomy is preserved by design and extended every time a new domain or sub-domain is added as the organization evolves.

This enables every business unit to operate independently and autonomously, while leveraging a single source of truth for service and resource inventory, a common orchestration engine, standardized enterprise processes, and a unified assurance platform. The result is improved visibility, governance, operational efficiency, scalability, and customer experience without compromising data isolation.

When implementing domain separation in ServiceNow, it is essential to design a well-defined domain hierarchy that aligns closely with the organizational structure, while maintaining strict data segregation and isolation through the effective use of domain separation principles. An example here could be the segregation of secured customers — those who have stricter security requirements and need their data to be kept more separate from other customers’ data — into a separate hierarchy from shared customers of the same business unit. Users from the operations teams are intentionally restricted from accessing secure domains; instead, dedicated secure APIs and specialized domains are created for specific users to facilitate the controlled exchange of sensitive data between systems.

Processes such as incident management and change management, on the other hand, are designed with a global-first approach, where core workflows, business rules, flows, and integrations are created in the global domain as reusable, domain-agnostic components. These processes can then run in the context of a specific domain, inheriting domain-specific data and behavior. Wherever required, individual domains can extend or override these processes to meet unique business needs, ensuring flexibility without duplicating logic.

The domain model is an extensible pattern. A telecom company with two market units today can add a third, fourth, or 10th tomorrow without having to change the underlying architecture. Shared automation, the unified CMDB, and the integration layer remain constant; only a new domain configuration is required to achieve faster time to market.

What a unified data model looks like

A single CMDB, built on the CSDM and aligned to TM Forum's Open API standards, forms the foundation of the entire architecture. It ensures that the data model built within ServiceNow is consistent, aligned to industry standards for telecom as well as being aligned to the ServiceNow data framework for a smooth user experience. It represents the complete service stack across three layers:

Product layer: This includes the product offerings and specifications per market-facing unit, held within each unit's domain.

Service layer: This includes the services provided for each customer, linked to product orders and maintained per unit domain. These customer-facing services refer to shared network resources, linked via technical resource-facing services such as circuits, paths, tunnels, and slices that realize customer services.

Resource layer: This includes physical and logical assets such as devices, ports, cards, bearer connections, and sites again held only in the network services domain and never duplicated into MFU domains.

This layered design eliminates duplication by maintaining a single representation of each network device, port, or circuit. This single representation is shared across all market-facing units through ServiceNow CMDB relationships rather than duplicating the instances of these devices across various domains.

Service graph connectors ingest and reconcile inventory from source systems such as multiprotocol label switching, transmission, mobile, and broadband controllers. This maintains CMDB health above 95% for critical classes, improving operational visibility and supporting accurate decision-making across ITSM processes.

A CSDM-aligned CMDB in a domain-separated ServiceNow instance ensures standardized service modeling. It enables controlled data ownership and scalable multitenant operations, and provides consistent governance and cross-domain service visibility without compromising isolation.

Blueprint for autonomy at scale

Matrix telecom companies need to take measures to implement this service management architecture to preserve business unit autonomy:

• Anchor at the highest domain and trickle down: All foundational ITSM and technology service management (TSM) processes must be defined and maintained at the highest domain level and inherited by child domains or downward domains, i.e., the individual business units or customer tenants. This ensures that a consistent, authoritative process baseline propagates across the entire platform hierarchy.
• Design for override, not exception: While the processes defined at the top domain represent the enterprisewide standard, they are designed to accommodate unit-specific adaptations where justified. Child domains should configure permissible variations to address the unique requirements of a given business unit or line of business.
• Govern and bound every deviation: Any process deviation introduced at a child domain level must be evaluated against platform stability and governance standards. Excessive or ungoverned customization at lower domains introduces technical debt, increases maintenance overhead, and risks undermining the integrity of the shared platform.
• Assign each market-facing business unit its own ServiceNow domain: This ensures that data, customers, services, catalogs, and operational processes remain appropriately segregated while supporting future organizational growth, acquisitions, and restructuring.
• Implement a unified CSDM- and TM Forum-aligned CMDB: This way services and products are linked to a single representation of shared network resources, eliminating duplication and creating end-to-end service visibility across the enterprise.
• Standardize using a global-first approach: Standardize ITSM, TSM, fulfillment, and assurance processes with core workflows governed centrally and only controlled business-unit-specific variations permitted through an 80:20 governance model, which is ideal according to Infosys experience in the field. In this model, 80% of processes are reused to minimize disruption to the existing system, while 20% are customized to allow flexibility for the other units involved in incorporating their business needs into it. Process governance failures typically emerge not from deliberate architectural choices but from incremental workarounds — a business rule added to handle one edge case, a sub-flow duplicated to accommodate one unit's reporting requirement. Enforcing the 80:20 ratio requires a named process owner at the top domain level with the authority to approve or reject domain-level deviations. Without that ownership structure, drift is inevitable.
• Automate cross-domain fulfillment and assurance workflows: This enables real-time service impact analysis, proactive customer communications, faster incident resolution, and seamless collaboration between network and customer-facing teams. Cross-domain relationships are critical for large telecom companies that deliver services across wireline and wireless domains.
• Leverage AI, AIOps, and intelligent event correlation: By structuring and streamlining the inventory data, matrix telcos can reduce operational noise, identify customer impacts faster, accelerate restoration activities, and improve service reliability.

The matrix telecom organization is not a problem to be solved by consolidating everything into one undifferentiated system. Each unit needs to retain some autonomy in terms of having its own customers, processes, or data because of legitimate business and governance reasons for doing so. But the duplication, fragmentation, and manual handoffs that exist between those units are operational costs.

This domain separation approach creates a common operational foundation across the organization while allowing individual units to retain the flexibility and control they require. These principles are not specific to the telecommunications industry and can also be applied to other matrix organizations using ServiceNow, with similar requirements for autonomy and shared capabilities.