OSS provisioning modernisation across business units

A satellite communications and managed connectivity operator serving several business units, each with its own products, networks and — over time — its own way of provisioning services. Provisioning had grown up around individual networks and vendor platforms rather than around a shared model of the service being delivered.

The result was familiar to anyone who has worked in a multi-business-unit operator: overlapping tools, manual hand-offs between order capture and activation, and a service picture that lived partly in systems and partly in people.

Modernise OSS provisioning so that orders from any business unit could be orchestrated and activated through a common architecture — without stopping the businesses that depended on the existing paths, and without pretending that the different networks were the same.

• Multiple legacy provisioning paths with different data models and levels of automation.
• Business units with genuinely different products, networks and operational constraints.
• The need to keep existing customers and orders flowing throughout the change.
• A service model that had to be made explicit before it could be orchestrated.

The approach separated what was common from what was specific. A shared order orchestration layer, driven by service specifications, sat above network- and domain-specific activation. Business-unit differences were pushed down into catalog content and domain adapters rather than expressed as separate provisioning stacks.

• Catalog-driven decomposition so new products did not require new orchestration code.
• Explicit service and resource models shared across business units.
• Domain adapters isolating each network's activation interface.
• Coexistence with legacy provisioning during migration, with a defined exit path per business unit.

Architecture for the provisioning modernisation: the target architecture, the service and order models, the sequencing across business units and the coexistence strategy with legacy provisioning — working with operations and business-unit teams to make the implicit service model explicit, and with vendor and delivery teams on how the architecture was realised.

The change was as much organisational as technical. Business units moved from owning a provisioning tool to owning catalog content and activation adapters within a shared architecture. Migration was sequenced by business unit and by service so that each step could be validated against live orders before the legacy path was retired.

A common provisioning architecture with business-unit-specific content rather than business-unit-specific stacks, and a defined path for retiring legacy provisioning. Specific delivery metrics are not published here.

• The service model has to be agreed before orchestration is designed, not discovered during it.
• Coexistence needs an exit criterion per business unit, or it becomes the permanent state.
• Adapters are cheap; a second orchestration layer is not.