By: Ionut Grosu

We Modernized the Enterprise. Why Is Change Still Slow?

Communications Service Providers (CSPs) have modernized OSS and BSS platforms, moved workloads to the cloud, exposed APIs, automated manual processes, and invested heavily in digital customer experiences. Those programs have delivered real gains in efficiency, scalability, and service delivery.

Yet a familiar contradiction remains. Launching a new partner, commercializing a digital service, or supporting a new pricing model can still take months and require coordinated changes across multiple systems and teams.

The bottleneck has moved. Most transformation programs optimized the enterprise while the environment around it became far more complex. CSPs now operate within networks of hyperscalers, software vendors, cybersecurity providers, distributors, managed service providers, systems integrators, and AI platforms. Each participant brings its own products, APIs, lifecycle events, pricing structures, billing models, operational processes, and commercial obligations.

Operational agility is therefore no longer determined solely by how efficiently an organization runs its own systems. It increasingly depends on how effectively it coordinates the broader ecosystem in which it operates. The unit of optimization is shifting from the enterprise to the ecosystem.

Research from McKinsey & Company points in the same direction: the next wave of telecommunications growth depends less on isolated technology modernization and more on transforming operating models through digital technologies, AI, automation, and ecosystem collaboration.

The Architecture Problem Is Not a Shortage of APIs

The telecommunications industry has spent decades integrating systems, and integration remains essential. But integration alone does not create agility.

An API makes a capability accessible; it does not automatically make that capability independent, reusable, or safe to compose. A collection of APIs wrapped around tightly coupled processes can simply create a more accessible monolith. If launching a product still requires synchronized changes across five systems, three teams, and two partners, the architecture is not composable regardless of how many APIs it exposes.

Integration answers, “Can these systems communicate?” Orchestration answers, “How does the business outcome progress across them?” True composability requires capabilities with clear boundaries, stable contracts, independent lifecycles, and business meaning. Orchestration then coordinates those capabilities across an end-to-end journey, maintaining state, enforcing dependencies, handling exceptions, and ensuring that each participant completes its part.

An ordering API, a pricing service, an entitlement capability, and a billing service are useful individually. They create a business outcome only when the order can move reliably from qualification and pricing through provisioning, activation, billing, support, renewal, and partner settlement. End-to-end process logic should not be buried in point-to-point integrations or owned by the channel that initiated the transaction.

Composable Capabilities Need a Common Commercial Language 

Heterogeneous providers rarely describe the same commercial event in the same way. One provider may treat a service as a subscription, another as a metered entitlement, and another as a license with its own rules for activation, suspension, renewal, and cancellation. Passing those differences directly into every downstream process merely distributes vendor-specific complexity across the architecture.