Telecom BSS/OSS Solution Design: [Programme name] on TM Forum Open Digital Architecture

Solution design for a communications service provider's business and operations support systems (BSS/OSS) built on the TM Forum Open Digital Architecture (ODA). It maps the business scope to the Business Process Framework (eTOM) and the Information Framework (SID), places ODA Components on the ODA functional blocks, selects the TM Forum Open APIs for every interface, describes catalogue-driven order decomposition from product to service to resource, the integration with network operations, the ODA Canvas deployment, migration from legacy stacks and conformance testing. Basis checked in October 2026: Open APIs in the public tmforum-apis repositories (for example TMF620, TMF622, TMF637, TMF638 and TMF639 at v5.0.0, TMF641 at v4.2.0); ODA Component specifications using the oda.tmforum.org/v1 component schema and referencing eTOM v24.0 and SID v25.0; ODA Canvas reference implementation release 1.2.5 (March 2026). Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Business scope and eTOM process mapping
3. Information model and SID alignment
4. ODA functional architecture and component map
5. Open API usage
6. Catalogue-driven design
7. Network and OSS integration
8. ODA Canvas and deployment
9. Events, security and privacy
10. Non-functional requirements
11. Migration and coexistence
12. Conformance and certification
13. Decisions, risks and traceability
14. Glossary and references

1. Introduction and scope

1.1 Purpose

This document describes the target BSS/OSS solution for [programme name]: which ODA Components deliver which business functions, how they interact through TM Forum Open APIs and events, how offers are modelled once in catalogues and decomposed into services and network resources, and how the solution is deployed, migrated and tested. The TM Forum frameworks give a vendor-neutral vocabulary, so components from different suppliers can be compared, replaced and certified against the same definitions.

1.2 Drivers and outcomes

1.3 Scope

1.4 Constraints and assumptions

• [Example: The operator buys components from at least two suppliers and requires each to expose the Open APIs listed in section 5 as its primary interface.]
• [Example: Components run on a Kubernetes platform with an ODA Canvas in two regions.]
• [Example: The online charging system stays in place and is integrated through its existing interfaces until a later phase.]

2. Business scope and eTOM process mapping

2.1 Business lines and volumes

2.2 Process mapping

eTOM organises processes in domains (for example Market and Sales, Product, Customer, Service, Resource, Business Partner and Enterprise) and in vertical groupings across the lifecycle. Record the elements that change and who owns them, and replace each bracketed identifier with the one in your licensed eTOM release.

2.3 End-to-end journeys

3. Information model and SID alignment

3.1 Entity ownership

3.2 Identifier and reference rules

• Every entity has one owning component that issues its identifier; other components store the identifier and an href, not a copy of the entity.
• Cross-domain references go downward only by specification: a product specification references service specifications, which reference resource specifications.
• Characteristic names and value types are governed in the catalogue; no component invents its own characteristic for the same concept.

3.3 Extension log

Use the @type, @baseType and @schemaLocation polymorphism pattern of the Open APIs for extensions, so that standard clients still process the base entity.

4. ODA functional architecture and component map

4.1 Functional blocks

The ODA Component Directory groups components into functional blocks such as Engagement Management, Party Management, Core Commerce Management and Production, with intelligence management functions alongside. Check the current block names in the directory before publication.

4.2 Component register

4.3 Component selection criteria

Weights total 100%. Score suppliers with the Vendor Evaluation Scorecard (business/vendor-evaluation-scorecard).

5. Open API usage

5.1 API catalogue

Versions in rows API-001 to API-007 are the latest found in the public tmforum-apis GitHub repositories in October 2026 (check the Open API Table for newer releases); bracketed versions must be fixed per supplier. TMF633 Service Catalog has no Gen5 release (latest v4.0.0 as of October 2026), so ADR-001 allows Gen4 for it until a Gen5 version is published.

ODA component specifications current in October 2026 (for example TMFC001 v2.1.2) still declare Gen4 (v4.0.0) exposed and dependent APIs, and component conformance (CNF-002) is tested at those versions. A "TMF620 v5.0.0 provided by CMP-001" row therefore holds only where the supplier offers Gen5 beyond the component specification: contract the Gen5 version separately and test it with the API conformance kit (CNF-001).

5.2 API design rules

1. Use the Open API resource model and the TMF630 design guidelines naming rules; add fields only through the polymorphism extension pattern.
2. Support the Gen5 (v5) API where the supplier offers it; run Gen4 and Gen5 side by side only with a dated retirement plan per consumer.
3. Use the API hub and listener pattern for notifications (create, state change, attribute value change) rather than polling.
4. Expose partner-facing APIs only through the API gateway with per-partner credentials, quotas and field-level filtering.
5. Follow the API Design Guidelines (architecture/api-design-guidelines) for anything the TM Forum rules leave open, such as error catalogue wording and pagination limits.

6. Catalogue-driven design

6.1 Catalogue layers

6.2 Order decomposition flow

The sequence shows a fibre broadband order moving from product to service to resource, with inventory updates and notifications at each layer.

6.3 Decomposition rules

6.4 Order handling rules

• Orders are accepted only when every item references an active offering and passes qualification.
• Order orchestration keeps the state of each item and supports amend and cancel while in flight according to point-of-no-return rules held per service specification.
• Every fallout creates a task with a reason code; the reason code list is reviewed monthly against DRV-002.

7. Network and OSS integration

7.1 Domain boundaries

7.2 Assurance loop

Correlate every alarm with service inventory (TMF638) to find affected customers, and notify care before customers call. Use the Observability Specification (ops/observability-spec) for the platform side of monitoring.

8. ODA Canvas and deployment

8.1 Canvas choice

8.2 Canvas services used

8.3 Component metadata rules

Each component is deployed with a component custom resource that declares its core function (exposed and dependent APIs), management function, security function and event notification (published and subscribed events). Treat this metadata as the contract:

• Every API a component exposes or calls appears in its metadata, with the specification version.
• Gateway routes, identity roles and dependency wiring are generated from the metadata by the Canvas, never configured by hand.
• A pull request that changes component behaviour without changing its metadata fails review.

8.4 Environments

9. Events, security and privacy

9.1 Events

• Components publish Open API notifications (for example product order state change, service created, resource attribute value change) to subscribers registered through each API's hub.
• For high-volume or cross-domain fan-out, bridge notifications to an event broker and describe topics with the Event API Specification (architecture/event-api-specification).
• Events carry identifiers, href links and changed attributes, not full personal records.

9.2 Security controls

10. Non-functional requirements

11. Migration and coexistence

11.1 Approach

11.2 Coexistence rules

• One system of record per customer at any time, held in a routing table consulted by channels, care and billing.
• Billing receives one feed regardless of which stack holds the product.
• Reconcile counts of customers, products, services and recurring revenue after each wave with the Data Migration Reconciliation template (project/data-migration-reconciliation); plan waves with the Migration Wave Plan (project/migration-wave-plan).

12. Conformance and certification

Write conformance into supplier contracts: version, test kit, retest on every major release, and remediation time when a regression is found.

13. Decisions, risks and traceability

13.1 Decisions

Record each in the Architecture Decision Log (architecture/architecture-decision-log).

13.2 Risks

13.3 Traceability matrix

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Structure aligned with the TM Forum Open Digital Architecture: Business Process Framework (eTOM), Information Framework (SID), ODA Components and functional blocks, Open APIs and the ODA Canvas. eTOM, SID and ODA documents are TM Forum materials; this template uses only their names, element identifiers and release numbers with original wording, and reproduces no TM Forum definitions, tables or diagrams. Open API numbers and names are cited from the public tmforum-apis repositories (Apache 2.0). TM Forum, Open Digital Architecture and ODA are trademarks of their owner; this template is not affiliated with or endorsed by TM Forum. This template is original text written for this collection. Check the current official releases before use. Template licence: MIT.