A map you can cut over on.
How catalog, billing, CRM, orders, and the core fit together — then the engineering that makes that map real. Not a deck left in SharePoint.
3/12 on the new path
Catalog as master, then party, then order as the strangler, then charging dual-run. Experience and the core last. Amber is how the industry usually runs it. Cyan is the stage that replaces that slice.
What we actually design
Architecture without delivery is a workshop. These are the four pieces that make the map executable.
Target architecture
A BSS/OSS map that survives a bill run: catalog, CRM, charging, orders, and the core — what stays, what is replaced, and in what order.
Integration design
TM Forum APIs, events, and identity between Cerillion, Comverse, payments, ERP, and the network. Contracts first, glue code last.
Coexistence and cutover
Strangler patterns so old and new run in parallel. Rehearsed traffic shifts, rollback you would actually use, and a first clean bill run.
Platform engineering
The services, APIs, and pipelines that implement the architecture — on Kubernetes, watched in the NOC, handed over with runbooks.
The same team that drew the map builds it
We stay for coexistence, the cutover, and the first bill run on the new stack.
Domain maps
Catalog, charging, CRM, orders, inventory, and the core — with TM Forum as the contract.
Engineering
APIs, events, Kubernetes, and the adapters onto Cerillion, Comverse, and payments.
Handover
Runbooks, observability, and 24/7 ops if you want the same team to keep it up.
What the map has to carry
- Billing and catalog transformations with a coexistence window
- Core network provisioning wired to the same order that billed
- Private AI that sits on the architecture, not beside it
- iOS and Android when the subscriber surface is part of the map