tSM Platform
The tSM (Telco Service Management) system is a microservice-based platform designed for developing and running telecom BSS/OSS application modules. At its core, tSM merges two complementary pillars: a low-code development platform that provides reusable services, tooling, and configuration-driven extensibility, and a suite of pre-built business modules aligned to the TM Forum standards. Together, they deliver a comprehensive solution for BSS/OSS domains — CRM, Service Fulfillment, Service Assurance, Workforce Management, and beyond — deployable in both On-Premise and SaaS modes.
The sections below explain how these two pillars relate to each other, where TM Forum sits as the specification foundation, and how the platform is decomposed into microservices.
Low-Code Platform vs. Business Modules
Low-Code Platform (Core Services)
The platform layer provides a set of generic, reusable services that accelerate development and dramatically reduce the need for custom code. These capabilities are not tied to any single business domain — they are building blocks that every module, whether shipped by tSM or built by a customer, can leverage:
| Core Service | Description | Configuration Reference |
|---|---|---|
| Process Engine | Visual workflow designer for defining and executing business processes with task management, deadlines, and SLA tracking | Process Engine Configuration |
| Form Designer | JSON Schema-based form designer for creating dynamic attributes (characteristics) and UI forms without code | Form Designer Configuration |
| Comments | Structured and freetext commentary bound to any entity via the ownerType/ownerId pattern | Supporting Entities |
| Attachments | File attachment management with DMS integration support | Supporting Entities |
| Output Management | Document generation using Jasper Reports, Word/Excel templates, or WYSIWYG editors with placeholder support | Output Management Configuration |
| Notifications | Configurable notification rules — when to send, which template, which channel | Supporting Entities |
| Worklog | Time tracking and work logging across any tSM entity | Supporting Entities |
| Business Logging | Kafka-based business log capture with per-type metadata and UI display configuration | Supporting Entities |
| Observability & Tracing | Distributed tracing and dynamic logging capabilities | |
| Listings | Configurable data listings with filtering, sorting, and export capabilities | Listings Configuration |
| Data Model Extension | Tools for extending the core data model with custom entities, attributes, and relationships | Data Model Configuration |
| User Management | User, role, and permission management with fine-grained access control | User Management |
| tSM Expression Language | Powerful scripting language for writing custom mappings, integration logic, and process automation | tSM Languages |
| Public API | RESTful API layer exposing all tSM entities and operations to external consumers | tSM Public API |
Because of this platform layer, tSM functions as an open development platform. New modules and extensions can be built on top of the core services using configuration and low-code tooling, resorting to custom code only where complex business logic demands it. For more details on the technology underpinning these services, see Technology Stack.
Business Modules
On top of the platform, tSM ships pre-built business modules that address specific telecom domains. Each module is composed of one or more microservices that consume the core platform services and implement domain-specific business logic:
| Module | Description | Details |
|---|---|---|
| CRM | Lead, Customer, and Account management; customer contact tracking and interaction history | CRM Module |
| Order Management | Product ordering with pricing, billing interface, and catalog-driven order lifecycle | Order Management |
| Catalog Management | Catalog structure, specifications, and product/service definitions | Catalog Management |
| Inventory Management | Product, service, and resource inventory with full lifecycle tracking | Inventory Management |
| Ticket Management | Trouble ticket management, change management, SLA, JIRA synchronization, and work logging | Ticket Management |
| Workforce Management | Work order management with planner, work catalog, and optimal route calculation | Workforce Management |
| Stock Management | Stock and warehouse management for physical resources | Stock Management |
| Bill Management | Billing and invoicing interfaces | Bill Management |
| Service Orchestration | Service provisioning with product-to-service-and-resource decomposition and network inventory integration | Service Orchestration |
Each business module follows the same architectural pattern — a core microservice with the standard domain model, extended by additional microservices for customizations, integrations, and add-on functionality. For a full overview of available modules, see Modules.
For module-level technical architecture documentation (domain entities, configuration points, and governance), see Business Modules, starting with Catalog Module.
TM Forum Alignment
tSM does not invent its domain model from scratch. The platform takes a TM Forum Open API first approach — each business module starts from the relevant TMF Open API specification (e.g. TMF621, TMF622, TMF629), the Telecom Application Map (TAM) guides module decomposition, and the SID framework is consulted for deeper attribute modelling. tSM fully embraces the Characteristics Pattern (EntitySpecification + dynamic attributes via JSON Schema) as the universal extension mechanism across all entities.
For the complete description of how TM Forum specifications are mapped to tSM domain models, API compatibility details, and the TMF API coverage matrix, see TM Forum Alignment.
Microservice Architecture Layers
The tSM microservices are organized into three distinct layers:
Infrastructure Microservices
Foundation services required for the platform to operate. These contain minimal business logic:
- API Gateway — single entry point for all client requests, routing, and security
- Config Server — externalized configuration management
- PostgreSQL — relational/transactional data store (each microservice owns its database)
- Elasticsearch — fulltext search and fast data previews across denormalized indexes
- Kafka — event-driven messaging and real-time data streaming
- Redis - distributed locks & caching
For details on the technology stack, see Technology Stack.
Core Microservices
Shared platform services that provide reusable functionality across all business modules. These correspond to the low-code platform capabilities described above:
| Service | Purpose | Configuration |
|---|---|---|
| Config & Forms | Metadata configuration, JSON Schema repository, form definitions, Elasticsearch index settings | Form Designer |
| Process Engine | Process configuration and task definitions (instances run in the target module for performance) | Process Engine |
| DMS | Comments, Attachments, Output Management, format conversion | Supporting Entities |
| Notification | Notification configuration, templates, and delivery orchestration | Notifications |
| Business Logging | Kafka-based log capture with configurable UI display per message type | Business Log |
| Calendar | Calendar events and virtual calendar views over tSM entities | — |
Microservice Decomposition
The decomposition of tSM into microservices follows Domain-Driven Design (DDD) principles and the concept of Bounded Context — each microservice represents a clearly bounded minimal set of domain objects that form a logical whole.
Key design principles:
- Each microservice owns its data — separate database per service, with Elasticsearch indexes for cross-service search and previews
- Inter-service communication via references — microservices store only references (
ownerType/ownerId) to entities in other services, never duplicating data - Stateless services — all microservices are stateless, communicating through RESTful APIs and Kafka events
- Independent deployability — each microservice can be deployed, scaled, and updated independently
Customization Approach
When tSM is deployed for a specific project or customer, customization follows a structured process:
- Design — domain analysis using techniques like event storming to identify aggregates, commands, domain events, and external system boundaries
- Domain Model Mapping — mapping identified entities to existing tSM modules:
- Attribute Classification — dividing entity attributes into core (implemented in the domain model, stored in DB tables) and dynamic (added as Characteristics at configuration time)
- Extension — when the standard model needs to be extended with new business logic, a new microservice is created following the same platform patterns. See System Configurations — Microservice and Module for registration details.
- Configuration — enumerations, processes, forms, and characteristics are configured through the application without code changes. See Configuration for the full configuration guide.