Glossary
52 terms — what each one means, and why it actually matters when you're the one accountable for the architecture. Deep-link to any entry with glossary.html#etom.
TOGAF's iterative cycle of phases — Preliminary through H — for developing an enterprise architecture, from vision through governance.
Why it matters in practice: I use ADM as the process skeleton and eTOM/SID/ODA as the content that fills it — ADM tells you what to do next, the telecom frameworks tell you what "done" looks like.
A short, dated document capturing one architecture decision, the alternatives considered, and why the choice was made.
Why it matters in practice: the single highest-leverage document in any programme — six months later nobody remembers why, and an ADR is the difference between re-litigating a decision and pointing at the record.
Software that listens to or reads a live customer interaction and surfaces suggested responses, relevant knowledge-base articles, or next-best actions to a human agent in real time.
Why it matters in practice: this is where most contact-centre AI investment should start, not with a chatbot — it improves the agent you already trust before you try to replace them.
The governance forum that reviews designs for conformance to architecture principles and standards before they proceed to build.
Why it matters in practice: an ARB that only reviews slideware is theatre — insist it reviews against the actual eTOM/SID/ODA mapping and the ADR log, or it will rubber-stamp whatever's already been bought.
The systems handling the customer- and revenue-facing side of a telecom operator: ordering, billing, charging, CRM.
Why it matters in practice: when a transformation programme says "BSS" loosely, I make them name which specific eTOM processes and ODA components they mean — the acronym alone hides where the real scope and risk sit.
The document justifying an investment in terms of cost, benefit, risk and timeline, used to secure funding and set success criteria.
Why it matters in practice: I write the business case before the HLD, not after — a solution designed before its business case is a solution designed to a guess.
A record generated for every call or session, containing metadata like duration, parties, time and route — the raw input to rating, billing and much of network analytics.
Why it matters in practice: CDR volume and quality problems show up as billing disputes months later — I treat CDR mediation as a revenue-assurance control point, not just a plumbing step.
The real-time or near-real-time process of applying tariffs to usage to determine what a customer owes, or how much of their balance or allowance to deduct.
Why it matters in practice: charging and rating get used interchangeably but shouldn't be — charging is the real-time enforcement, rating is the tariff calculation; conflating them is a common cause of prepaid/postpaid architecture mistakes.
An integration style where each service reacts to events independently, with no central controller directing the sequence.
Why it matters in practice: choreography scales beautifully and debugs terribly — I only recommend it once a team has the observability maturity to trace a business transaction across a dozen services without a single log to follow.
A unified view of a customer assembled from every system that holds data about them — billing, care, network, digital — presented as one coherent profile.
Why it matters in practice: most Customer 360 programmes fail as data-warehouse projects because nobody agreed which system is authoritative for which attribute first — resolve that governance question before touching the pipeline.
A structured definition of the entities an organisation cares about — customer, product, order, resource — and how they relate. SID is the telecom industry's standard version.
Why it matters in practice: systems-integration projects that skip an explicit data model always end up building one anyway, just implicitly and inconsistently across five interfaces.
The set of verified attributes and credentials that let a system confirm who a customer or device actually is, across channels and over time.
Why it matters in practice: digital identity is the prerequisite most self-service and AI initiatives quietly assume already works — check it before promising a seamless eKYC-to-activation journey.
An architecture style where components communicate by publishing and reacting to events rather than calling each other directly.
Why it matters in practice: EDA is what makes order-to-activate and revenue-assurance monitoring possible in near-real time — but it demands schema discipline and event-replay capability from day one, or it becomes undebuggable fast.
The digital equivalent of an in-store identity check — document capture, liveness detection and verification against an authoritative source, done remotely.
Why it matters in practice: eKYC failure rates are an architecture problem as much as a compliance one — I've seen more onboarding fallout from a brittle eKYC integration than from the actual policy rules.
TM Forum's business process framework — the reference map of what a telecom operator does, from Strategy & Commit down to Operations, at multiple levels of decomposition.
Why it matters in practice: eTOM is the one framework every part of an operator already recognises — I anchor AI and modernisation initiatives to it precisely because Finance, Ops and vendors all speak it.
The infrastructure — Kafka and similar platforms — that carries a continuous flow of events between producers and consumers at scale.
Why it matters in practice: event streaming is the plumbing under EDA — I treat topic naming, schema versioning and retention policy as architecture decisions, not platform-team defaults.
AI models that produce novel text, code, speech or other content in response to a prompt, rather than only classifying or scoring existing input.
Why it matters in practice: in telecom, Gen AI earns its keep fastest in agent assist and knowledge-base drafting — I'm far more cautious recommending it anywhere near real-time charging or provisioning decisions.
The set of decision rights, review gates and standards that keep individual delivery teams' choices coherent with the overall target architecture.
Why it matters in practice: governance that only exists as a document nobody enforces is worse than none — it gives false confidence. I'd rather have three enforced principles than thirty ignored ones.
A document describing a solution's overall shape — components, integrations and key decisions — without implementation-level detail.
Why it matters in practice: an HLD's job is to let a room full of stakeholders agree on the shape of a solution before anyone commits to how to build it — if it needs a code review to understand, it's actually an LLD.
Directing a customer interaction — call, chat, ticket — to the best-matched agent, queue or automated flow based on context, skills and predicted intent, rather than a fixed rule.
Why it matters in practice: the business case for intelligent routing is almost always in reduced transfers and faster resolution, not headcount — sell it on the metric that's actually true.
The automated phone menu system that greets and routes callers before — or instead of — reaching a human agent.
Why it matters in practice: a modern IVR is judged on how quickly it gets a caller to the right place, not on how many options it offers — I treat every extra menu layer as a fallout risk.
The planned retirement of an old system after its functionality and data have been migrated, verified and cut over.
Why it matters in practice: decommissioning is the step transformation programmes chronically underfund — until it happens, you're paying to run two systems and calling the new one "done".
A document describing a component's implementation in enough detail to build it — data models, API contracts, error handling.
Why it matters in practice: if two engineers could read the same LLD and build materially different things, it isn't done yet.
The layer that collects, normalises and correlates usage data — like CDRs — from network elements before it reaches rating, billing or analytics.
Why it matters in practice: mediation bugs are invisible until revenue assurance finds the discrepancy weeks later — I always ask to see mediation's error and rejection rate before I trust anything downstream of it.
An architecture style where a system is built as a set of small, independently deployable services, each owning a specific piece of business capability.
Why it matters in practice: microservices solve an organisational scaling problem more than a technical one — I don't recommend them to a team that isn't ready to own independent deployment, on-call and versioning.
TM Forum's target reference architecture for telecom operators — component-based, API-driven, cloud-native, superseding older monolithic BSS/OSS thinking.
Why it matters in practice: ODA is where I map every new component in a modernisation programme — if it doesn't fit an ODA building block, that's a prompt to ask why, not a reason to ignore the framework.
TM Forum's companion framework to ODA covering the organisational, process and ways-of-working changes needed to actually operate in an open, API-driven model.
Why it matters in practice: programmes buy ODA-aligned technology and then skip ODF — the operating-model change — and wonder why the new architecture still runs like the old one.
A customer experience design where interactions started on one channel — app, call, chat, store — continue seamlessly on another, with full context carried across.
Why it matters in practice: the tell for whether omnichannel is real or marketing: ask a customer to switch from chat to a call mid-issue and see if they have to repeat themselves.
TM Forum's suite of standardised, RESTful APIs for common telecom operations — product ordering, customer management, and so on — intended to reduce integration cost.
Why it matters in practice: Open API conformance is the first thing I check in a vendor RFP — a vendor's own proprietary API dressed up as "Open API-inspired" is a migration cost you'll pay later.
An integration style where a central controller explicitly sequences calls to other services to complete a business process.
Why it matters in practice: orchestration is easier to debug and govern than choreography, at the cost of a central component that can become a bottleneck — I pick it by default unless scale specifically argues otherwise.
An order that fails to complete automatically and drops into manual handling — the primary symptom watched to judge order-to-activate health.
Why it matters in practice: fallout rate is the single best proxy I know for whether an order-to-activate architecture is actually working — track it by failure reason, not just as one aggregate number.
The end-to-end journey from a customer placing an order to the service being live and usable, spanning ordering, provisioning and activation systems.
Why it matters in practice: most "digital transformation" promises collapse or succeed based on this one journey — I use it as the litmus test for whether a BSS/OSS modernisation is real.
The systems handling the network- and service-facing side of a telecom operator: provisioning, inventory, assurance, network management.
Why it matters in practice: OSS is where automation pays off fastest because the processes are already rule-based — I look here first for quick, defensible AI wins before touching customer-facing BSS.
The system of record defining what an operator sells — products, offers, pricing and their technical composition — that everything else (ordering, billing, provisioning) reads from.
Why it matters in practice: a messy product catalog is the root cause behind a shocking share of order fallout — I audit it before I audit the order management system it feeds.
The process of configuring network elements and systems so an ordered service actually becomes usable.
Why it matters in practice: provisioning is where order-to-activate journeys go to die — I treat provisioning success rate and mean time as leading indicators the whole programme should watch weekly.
A messaging pattern where publishers emit messages to a topic without knowing who, if anyone, is subscribed to consume them.
Why it matters in practice: pub/sub is the mechanism that makes event-driven architecture possible — but "nobody knows who's listening" cuts both ways: also nobody notices when a consumer silently stops.
Mechanisms and metrics for guaranteeing or measuring network performance — latency, jitter, packet loss — for a given service or customer tier.
Why it matters in practice: QoS commitments in a contract are only as real as the monitoring behind them — I insist the SLA and the QoS telemetry come from the same source of truth.
The process of applying a tariff to a unit of usage to calculate its price, before it's applied to a bill or balance.
Why it matters in practice: rating errors are silent and compounding — a small rating bug can run for months before revenue assurance catches it, which is why I push for rating logic to be tested against real historical CDRs, not just synthetic cases.
The discipline and tooling for detecting and preventing revenue leakage across the order-to-cash chain — mediation, rating, billing, and beyond.
Why it matters in practice: revenue assurance is the function most likely to catch an architecture defect before a customer or an auditor does — I involve them early in any BSS change, not after go-live.
Request for Proposal / Request for Information — formal documents used to solicit vendor solutions (RFP) or exploratory vendor input (RFI) before a purchase decision.
Why it matters in practice: an RFP written by procurement alone tends to score commercials well and architecture poorly — I always insist on co-authoring the evaluation criteria; see the RFP scorecard in the library.
AI-based detection of the emotional tone of a customer interaction — positive, negative, escalating — usually applied to calls, chats or reviews.
Why it matters in practice: sentiment analysis is diagnostic, not a fix — I only ever pair it with a defined escalation action, otherwise it's a dashboard nobody acts on.
TM Forum's reference data model defining the core business entities — customer, product, service, resource — and their relationships.
Why it matters in practice: SID is the vocabulary I insist integration teams use before they name a single field in an interface spec — most integration disputes are really SID disputes in disguise.
A contractual commitment defining the measurable service standard a provider must meet, and usually the remedy if they don't.
Why it matters in practice: an SLA without an agreed, automated way to measure it is a negotiating position dressed up as a commitment — I always ask how the metric will actually be captured before I sign off the number.
A migration approach that incrementally routes functionality from a legacy system to a new one, function by function, until the legacy system can be retired.
Why it matters in practice: the strangler pattern is how I migrate anything an operator can't afford to switch off for a weekend — which, in telecom BSS/OSS, is almost everything.
TM Forum's reference map of the application types an operator typically needs, organised by the business function they support.
Why it matters in practice: TAM is useful as a completeness check during a systems landscape review — I use it to spot gaps and duplication, not as a shopping list to fill mechanically.
The desired future-state architecture a transformation programme is working toward, as distinct from the current state and any intermediate transition states.
Why it matters in practice: a target architecture that never changes over a multi-year programme is a red flag — I expect it to be revisited at each major milestone as real-world constraints surface.
An industry-standard framework and methodology — centred on the ADM — for developing, governing and managing enterprise architecture.
Why it matters in practice: TOGAF gives me the process discipline; eTOM, SID and ODA give the telecom-specific content — using TOGAF's ADM without a telecom content framework produces beautifully governed, generically useless architecture.
An explicitly designed intermediate architecture between the current state and the target state, valid and stable in its own right — not just a snapshot mid-migration.
Why it matters in practice: programmes that skip transition state architecture end up stuck in an unplanned, unstable middle for years when funding pauses — I design every transition state to be a place the business could survive indefinitely if it had to.
The testing phase where intended end users verify a system meets their real-world needs, typically the last gate before go-live.
Why it matters in practice: UAT that only re-runs the same scripted test cases as system testing catches nothing new — I push for UAT scenarios written from the fallout and edge cases the design docs didn't anticipate.
A dependency on a specific vendor's proprietary technology, data format or contract terms that makes switching providers costly or impractical.
Why it matters in practice: lock-in isn't inherently wrong — sometimes it's a fair trade for speed — but I insist it's a conscious decision recorded in an ADR, never an accident discovered at renewal time.
Systems and processes for forecasting demand and scheduling the right number of the right-skilled agents or field staff to meet it.
Why it matters in practice: AI-driven forecasting is one of the highest-ROI, lowest-risk places to start an AI programme in a contact centre — the downside of an imperfect forecast is a staffing tweak, not a customer-facing failure.
Provisioning a device or service automatically, with no manual configuration step, typically triggered the moment it connects or an order completes.
Why it matters in practice: zero-touch provisioning is the end-state worth aiming order-to-activate architecture toward — every manual step still in the path is a future fallout category waiting to happen.