TM Forum Alignment
The tSM platform takes a TM Forum Open API first approach to designing its domain models, entity structures, and service boundaries. Each tSM business module starts from the relevant TM Forum Open API specification, adopting the standardised entities, attributes, and patterns as its foundation. On top of this, tSM exposes its own Public API for everyday integration, and provides dedicated TMF API endpoints where standards-based interoperability is required.
tSM supports standardized entity definitions, dynamic extensions using the TMF Characteristics pattern, and domain decomposition guided by the Telecom Application Map (TAM). Rather than enforcing strict one-to-one schema mappings, tSM takes a pragmatic approach: it follows TM Forum closely as the specification foundation, adopts the patterns and entity structures that bring real value, and extends them where customer-specific requirements demand it. The result is a platform that is TMF-consistent, readily interoperable, and flexible enough for real-world deployments.
TM Forum Frameworks
Three TM Forum frameworks are particularly relevant to tSM:
Telecom Application Map (TAM)
The TAM provides a standardized classification of telecom applications, organizing the BSS/OSS landscape into functional areas — Customer Management, Product Management, Service Management, Resource Management, and others. tSM's module decomposition is guided by TAM: each tSM business module maps to one or more TAM application areas, ensuring the platform covers the expected functional scope and that customers can quickly identify which parts of their BSS/OSS stack tSM addresses.
TM Forum Open APIs
The TM Forum Open API program defines standardized RESTful APIs for the telecom industry. Each API specifies entities, attributes, operations, and notification patterns for a particular domain. tSM uses these specifications as the starting point for defining its domain models — for example, TMF621 (Trouble Ticket), TMF622 (Product Ordering), TMF629 (Customer Management), or TMF638 (Service Inventory). Every tSM business module traces its entity model back to the corresponding TMF Open API.
The Ticketing module illustrates this approach well. The diagram below shows the TM Forum Trouble Ticket data model as defined by TMF621 — the entity structure that tSM adopts and extends:
TM Forum Trouble Ticket API (TMF621) — entity class diagram. Source: TMF621 Trouble Ticket Management API v5.0.0
SID (Shared Information & Data Model)
The SID framework provides a deeper, more granular information model for the telecom domain. While TM Forum Open APIs define the API contract, SID goes further into attribute-level detail and entity relationships. tSM consults SID for deeper attribute modelling, applying it pragmatically — only where it adds genuine value without introducing unnecessary complexity.
How tSM Adopts TM Forum Standards
Domain Model Design
The journey from a TM Forum specification to a tSM domain model follows a deliberate, layered approach:
1. TM Forum Open API as the blueprint — each tSM module begins with the relevant TMF Open API specification. The API defines the core entities, their attributes, and relationships. For example, the Ticketing module starts from TMF621, which defines the TroubleTicket aggregate with its status lifecycle, related parties, related entities, notes, and attachments.
2. tSM domain model — based on the TM Forum model, combined with real-world functional analysis, the tSM domain model is created. This model preserves the spirit of the TMF specification but adapts it for practical implementation:
- The Ticket entity becomes an aggregate root, enriched with operational attributes (process references, SLA dates, resolver assignments).
- TM Forum references like
RelatedPartyRefandRelatedEntityRefmap to tSM's cross-service reference pattern (ownerType/ownerId). - Enumerations (TicketType, TicketStatus, Severity, Priority, etc.) are managed as configurable registries — see Entity Type.
- Comments, Attachments, and Worklogs are provided by the core platform's supporting entities rather than embedded in the domain entity.
The diagram below shows the tSM Ticket domain model — notice how the core Ticket entity (blue) is surrounded by registries (orange), core platform references (teal), and cross-module references:
tSM Ticket domain model. Blue: core ticketing entity. Orange: configurable registries. Teal: references to core platform services (DMS, Process Engine). White: cross-module references (Inventory, CRM).
3. Extension via EntitySpecification (Characteristics Pattern) — the TM Forum defines the Characteristics Pattern as the standard mechanism for extending entities with dynamic attributes. tSM fully embraces this pattern through its Entities & Characteristics architecture:
- EntitySpecification (called Configuration Profile in the tSM UI) defines a subtype of an entity — e.g., distinguishing a Network Incident ticket from a Customer Complaint ticket.
- Each specification carries Characteristics — dynamic attributes defined using JSON Schema through the Form Designer.
- The pattern is universal: it applies to Tickets, Customers, Orders, Inventory items, Catalog entries, and any other tSM entity.
This three-layer approach — TMF blueprint → tSM domain model → characteristic-based extension — means that a new business requirement can often be addressed purely through configuration, without writing any code.
Public API and TMF API
tSM exposes two complementary API layers:
- Public API — the primary integration interface for tSM. It provides full access to all tSM entities and operations with a contract optimised for practical use, performance, and the tSM domain model. This is the API most integrations consume. See tSM Public API for details.
- TMF API — for domains where standards-based interoperability is required, tSM provides dedicated TMF-compatible API endpoints. These follow the TMF Open API structure — entity names, attribute conventions, and operation semantics match the TMF specification. Where tSM extends a TMF model with additional attributes, these extensions are additive and do not break the base TMF contract.
External systems using TMF-standard API contracts can integrate with tSM via the TMF API layer with minimal mapping effort. For other integrations, the Public API offers richer functionality and a more convenient developer experience.
What "Aligned" Means in Practice
tSM's relationship to TM Forum can be summarised as follows:
| Aspect | tSM Approach |
|---|---|
| Entity names and structure | Follow TMF Open API entity definitions as the starting point; extend where needed |
| Characteristics pattern | Fully adopted — EntitySpecification, dynamic attributes, JSON Schema |
| Module decomposition | Guided by TAM functional areas |
| Public API contracts | tSM Public API for all integrations; dedicated TMF API endpoints for standards-based interoperability |
| SID attribute modelling | Consulted pragmatically; simpler API-aligned approach preferred when SID is overly elaborate |
| eTOM process framework | Workflows and processes mapped to eTOM concepts where applicable |
| ODA architecture | Architecture mirrors ODA principles of modularity, separation of concerns, and open interfaces |
The platform is not a verbatim implementation of every TMF specification — practical considerations, performance optimisations, and customer-specific requirements mean some deviations exist. However, the design intent is always to stay close to the TMF standard so that mapping to a fully TMF-compliant interface remains straightforward.
Certification and Roadmap
tSM is on track to obtain the TM Forum Silver Badge certification. This is largely a formal and commercial milestone — the implemented APIs already pass RAND interoperability tests.
For the full certification roadmap and ongoing alignment plans, see TM Forum Alignment (Roadmap).