BSS Modernisation and Real-Time Customer 360

Problem

A telecom operator with 20 million subscribers bills on a 25-year-old mainframe application. Customer data sits in 14 systems, and a tariff change takes three days to reach all of them. The operator wants a real-time Customer 360 and a self-service app that executes orders in seconds. It also wants to retire the mainframe within five years, without a big-bang migration. The mainframe team allows at most 2% extra CPU and no schema changes.

Approach

One constraint shapes everything: no extra load and no schema change on the mainframe. Integration can therefore use change events only. The design builds the read model from events first, grows new domains behind an anti-corruption layer (ACL), and runs each domain in dual mode. A domain moves over only after a measured reconciliation gate. Debezium reads Db2 through capture tables. Systems on IMS and VSAM use the MQ events they already emit.

Architecture

• Capture: Debezium for Db2, other CDC connectors for the satellite systems, and file or API adapters for the two nightly sources.
• Backbone: Kafka with Avro schemas in Apicurio Registry, using TM Forum models.
• Read model: Flink maps raw change data to a canonical model and joins 14 streams on the customer key. PostgreSQL and OpenSearch serve the apps (CQRS).
• New domains: Temporal workflows expose TM Forum Open APIs. The ACL is the only write path to the mainframe, through an MQ transaction it already knows.
• Data mesh and churn: Iceberg, Trino and DataHub for domain data products. Spark, MLflow and SHAP for churn scoring.

Decisions and trade-offs

• Old system stays the source of truth during dual run. Differences count as defects in the new system until proven otherwise, and customers still get the old answer. The gate is a number: under 0.1% overall and zero on money fields for four weeks. The cost is running both systems for years. I treat that as an insurance premium, cheaper than a failed big bang.
• Cutover by cohort with feature flags. Staff first, then 1%, 10%, 50% and 100%. Rollback is a flag flip, and data stays consistent because both systems keep processing. A failed gate stops cohort growth automatically. The cost is cohort design, which for billing must align with billing periods.
• One Kafka cluster across two data centres, not MirrorMaker 2. In other katas an async copy is enough. Here, order commands and reconciliation differences must be confirmed in both sites. A round trip under 5 ms makes that possible. The cost is a witness controller at a third site. Where an async copy is enough, I would keep MirrorMaker 2.
• Change events only, never a query. The mainframe allows 2% CPU and no schema change. So the 360 is built from log capture and existing MQ events, and read load on the mainframe is zero. Freshness is estimated at about 60 seconds at p99 against a five-minute target. The cost: IMS and VSAM have no log access and depend on MQ events.
• No blind retry on mainframe writes. The ACL records the correlation ID before sending a persistent MQ message. On timeout it asks for the order status before any retry. A double charge would need a blind retry, and that path does not exist. The cost is a visible pending state with a timer in the app.
• Purpose-based access. Usage attributes sit in a separate group. Reading them needs a declared purpose, and OPA decides in the gateway and in Trino. Every read goes to an append-only table and a monthly report to the regulator. It is a technical control, not a policy document. The cost: legal must define the list of purposes.

What I would revisit

• ASN capture on Db2 for z/OS. Is it allowed, and do capture tables count as a schema change? If they do, Db2 takes the same route as IMS and VSAM: MQ events or commercial log capture.
• IMS and VSAM coverage. Do the existing MQ events carry enough fields for the 360, or is commercial log capture required?
• Mainframe order time. If the tariff-change MQ transaction uses more than half of the 10-second budget, the app needs a designed pending experience.
• Dual-run threshold. I assumed 0.1% and zero on money fields. Finance and the regulator have to accept a number.

Outcome notes (design assumptions, not measurements)

This is a design exercise, not a migration that happened. The output is a four-page diagram set, a one-page whiteboard version and a 16-page Turkish PDF with a five-stage strangler-fig flow. The 5-minute freshness target is a requirement, and the design offers no measured result.

Sources

• Architecture PDF (Turkish, 16 pages).
• draw.io diagrams (English labels): four-page set and a one-page 30-minute version.