🏛️
Section 12.1
Monolith vs Modular BSS/OSS
Comparing monolithic and modular architectures with trade-offs and decomposition strategies.
The most consequential architectural decision any telco faces is whether to build (or buy) its BSS/OSS as a monolithic platform or a modular, decomposed set of services. This is not a binary choice — most real-world deployments exist on a spectrum. There is no universally correct answer.
Monolithic vs Modular BSS/OSS
Hover each side to compare
Monolithic
Single deployment unit · shared database
Single Deployment Unit
CRM
TMF629
Product Catalog
TMF620
COM
TMF622
Billing
TMF678
SOM
TMF641
ROM
TMF652
SLM
TMF638
Resource Inv.
TMF639
Shared Database
All domains, one schema
Tight couplingShared dataSimple ops
vs
vs
Modular
Independent components · API-bound
BSS
CRM
TMF629
Product Catalog
TMF620
COM
TMF622
Billing
TMF678
OSS
SOM
TMF641
ROM
TMF652
SLM
TMF638
Resource Inv.
TMF639
TMF Open APIs & Event Bus
Standardised integration contracts
Independent Databases
CAT
COM
BIL
SOM
INV
Loose couplingAPI-boundIndependent deploy
Monolith vs Modular: Trade-Offs
Side-by-Side Comparison
| Dimension | Monolithic | Modular |
|---|---|---|
| Deployment | Single unit — one deployment, one release cycle | Independent per component — each domain deploys on its own schedule |
| Data | Shared database — ACID transactions across domains, but creates coupling | Database per service — loose coupling, but eventual consistency challenges |
| Scaling | Vertical only — scale everything or nothing | Horizontal per component — match resources to actual demand |
| Failure blast radius | A bug in billing can take down CRM, ordering, and everything else | Failures contained within component boundaries |
| Change velocity | Every change requires full regression. Monthly releases common. | Each team deploys independently. Daily releases possible. |
| Vendor strategy | Single vendor, single contract. Clear accountability but lock-in. | Best-of-breed selection. Flexibility but higher integration cost. |
| Operational complexity | Lower — one system to monitor, deploy, and debug | Higher — dozens of services, distributed tracing, service mesh |
| Team model | Shared codebase — merge conflicts, coordination overhead | Domain-aligned teams — full ownership, independent release cycles |
The Real Problem with Monoliths
The biggest issue is not technical — it is organisational. When a telco needs to change its commercial model rapidly (new bundles, new pricing, new channels), the monolith becomes a bottleneck because every change touches shared code. This is why digital-first operators almost universally choose modular architectures.
The Architecture Spectrum
Where Does Your Organisation Fit?
| Pattern | Deployment | Coupling | Best For |
|---|---|---|---|
| Pure Monolith | Single unit | Tight | Small operator, single product line, speed to market |
| Modular Monolith | Single unit, module boundaries | Medium | Want structure without distributed complexity |
| Macro-Services | 5-15 domain-level services | Loose (API-bound) | Most Tier-1/2 operators. Best balance of flexibility and manageability. |
| Microservices | 50-200+ fine-grained services | Very loose | Digital-native operators, telco-as-code platforms |
The Pragmatic Choice for Most Telcos
Most successful BSS/OSS transformations land on macro-services — roughly 8-15 domain-level components, each owning its own data, communicating via TMF Open APIs and domain events. This provides modularity without extreme operational overhead.
Decision Framework
Architecture Decision Matrix
| Factor | Favours Monolith | Favours Modular |
|---|---|---|
| Team size | < 30 engineers | > 50 engineers with domain specialisation |
| Change frequency | Quarterly releases | Weekly/daily releases |
| Subscriber base | < 2M, single country | > 5M, multi-country or multi-brand |
| Vendor strategy | Single vendor, integrated suite | Best-of-breed, multi-vendor |
| Cloud maturity | On-premise, limited containers | Cloud-native, Kubernetes-fluent |
| Product complexity | Single or dual product line | Converged (mobile + fixed + TV + IoT) |
Section 12.1 Key Takeaways
- Monolith vs modular is a spectrum — most operators land on macro-services (8-15 domain components)
- Monoliths are valid for small operators with low change velocity and single-vendor strategies
- Modular architecture is essential when business agility demands independent evolution of domains
- Decompose by business domain (aligned to ODA components), not by technical layer
- Avoid anti-patterns: shared databases, too-fine granularity, and layer-based decomposition
- In a modular architecture, source-of-record must be explicitly defined for every entity