Learn the architecture
Cross-Cutting Architecture
Three capabilities that every BSS/OSS domain depends on and none of them owns: security and regulatory compliance, cloud and infrastructure, and observability.
Each is shown against Concept-to-Market, Lead-to-Cash and Trouble-to-Resolve, so you can see where it touches the chain — from the regulation a catalog change has to evidence, to where an order’s workloads run, to tracing that order end to end when it stalls.
One picture
Concept-to-Market, Lead-to-Cash and Trouble-to-Resolve describe what the telecom operating model does. Cross-cutting architecture describes the capabilities that make that operating model secure, integrated, data-driven, scalable and observable.
The capabilities
Each module follows the same shape: why it matters, where it sits in the order chain, the patterns and decisions, and what it means for a transformation.
Security & Regulatory
GDPR, ePrivacy, NIS2 & EECC — from Regulation to Evidence
Regulation → Requirement → Risk → Architecture control → Deliverable → Evidence. For a European operator four instruments set the scope — GDPR, ePrivacy, NIS2 and the EECC — and they reduce to three pillars of work: privacy, cybersecurity and telecom regulatory compliance.
How do we protect the architecture, data and operations while meeting regulatory obligations?
Cloud & Infrastructure
Deployment Models, Compute, Resilience & AI Infrastructure
Where modern BSS/OSS capabilities run, scale and stay up. Public, private and hybrid cloud, containers and Kubernetes, resilience topologies, and the infrastructure AI workloads add.
Where and how do modern BSS/OSS capabilities run, scale and remain resilient?
Observability
Signals, Service Impact & AI-Assisted Operations
Knowing a system is up is not enough. How metrics, logs and traces show what an order did across every system it touched, and how that connects to service assurance.
How do we understand whether the architecture is operating correctly?
Across the three journeys
One example per capability per phase. Follow a column to see everything a phase depends on; follow a row to see why a capability cannot belong to one phase.
| Capability | C2M | L2C | T2R |
|---|---|---|---|
| Security & Regulatory | Change control on catalog publication; who may alter an offer | Customer identity and MFA; scoped tokens on the order APIs | Privileged access to the network; every fix audited |
| Cloud & Infrastructure | Catalog as a cloud-native, read-heavy service | COM on Kubernetes; SOM and activation close to the network | Assurance platforms sized for alarm storms; edge for latency |
| Observability | Is the published version the one being served? | One trace per order, span per system; fallout visible | Service impact: which customers does this alarm affect? |
Transformation
Every transformation decision is a decision about these capabilities: security boundaries, integration complexity, data migration, cloud strategy, observability from day one.
Open the transformation track →AI
AI is a consumer of all of this: secure access, APIs and events, governed data, compute, and the observability to know whether it is working.
See the AI use-cases →