Technology & Communications
Technology & Communications
Telecommunications, SaaS platforms, cloud services, and IT infrastructure — the backbone of India's $250B IT industry and 5G revolution.
$250B
India IT Export Revenue
5M+
IT Professionals
100M+
Jio 5G Users
$15B
India SaaS Revenue
What Engineers Miss When They First Enter Technology & Communications
The technology sector in India is unusual: it builds systems for other industries while simultaneously having complex internal systems of its own. A developer who joins a telecom company or a large IT services firm quickly discovers that the organisation they work for is as much an operations problem as a software problem. The infrastructure that runs the company — provisioning systems, billing engines, service catalogs, incident management workflows — is as important to master as whatever the external product is.
Telecom is the classic example. From the outside, it looks like a network company. From the inside, it is a billing company with a network attached. Every call, SMS, and data session generates a CDR — a call detail record — that has to be collected, normalised, rated, aggregated, and posted to a billing ledger before a bill can be generated. The systems that do this — BSS, mediation platforms, interconnect billing — are among the most data-intensive software stacks outside of financial exchanges, and they run without stopping because the network never stops.
IT services companies add a different dimension. They build enterprise software for clients across dozens of industries, which means their internal systems — resource management, project tracking, time-and-billing, knowledge repositories — have to handle the operational reality of managing hundreds of thousands of people, contracts, and deliverables across geographies. Tools like Freshworks, Zoho, and ServiceNow emerged to solve exactly these operational problems, and they now serve the global market.
What Teams Actually Do Day To Day
- 1Build and operate BSS/OSS integration layers that translate customer actions — a plan change, an add-on purchase, a number port — into the provisioning commands that update network equipment and the billing events that update the customer's invoice.
- 2Run mediation platforms that collect CDRs from network elements across multiple technologies (2G, 4G, 5G, VoIP), normalise heterogeneous formats into a single schema, and feed the rated records into the billing engine without gaps, duplicates, or delays.
- 3Maintain ITSM workflows in tools like ServiceNow that govern how incidents, problems, changes, and assets are managed across the IT estate — including the SLA timers, escalation paths, approval chains, and knowledge base linkages that operations teams depend on.
- 4Build client delivery tooling for IT services: resource allocation systems that match skills to project requirements, timesheet platforms that capture billable hours and link them to contracts, and reporting layers that give delivery managers visibility into engagement health.
- 5Manage the cloud-native infrastructure layer — Kubernetes clusters, observability stacks (Prometheus, Grafana, ELK), CI/CD pipelines — that both products and internal systems run on, while handling the toil reduction, cost optimisation, and security posture requirements that come with scale.
One End-to-End Flow: A Telecom Customer Changes Their Mobile Plan
A customer selecting a new plan in an app triggers a chain of systems across BSS and OSS. This walkthrough shows what actually happens between the tap and the moment the new plan is active on the network.
Customer selects a new plan in the mobile app or portal
The digital channel (app or web) calls the BSS product catalog API to retrieve available plans for the customer's circle, tenure, and account standing. Plans are filtered by eligibility rules — some plans require a minimum account age, some exclude post-paid accounts, some are only available during promotional windows.
Systems Involved
Digital channel app, BSS product catalog, eligibility engine
Where It Usually Breaks
Stale plan catalog data cached in the app can show plans that are no longer available, leading to a successful selection on the customer side that fails on the BSS side at order creation.
Order is validated and submitted to BSS
The order management component in BSS validates the change against business rules — effective date, any active add-ons that conflict with the new plan, proration rules for mid-cycle changes — and creates an order in pending state. The customer may confirm with a payment or OTP.
Systems Involved
BSS order management, business rules engine, payment service, OTP service
Where It Usually Breaks
Mid-cycle plan changes require proration calculations. If the billing cycle boundary logic and the order effective date logic disagree, the customer can be charged twice for the transition period.
Provisioning request sent to OSS
Once the BSS order is confirmed, it sends a provisioning request to the OSS layer, which translates the commercial change into network configuration commands. For a data plan upgrade, this means updating the subscriber's QoS profile on the relevant network nodes.
Systems Involved
BSS provisioning adapter, OSS service activation, network element management system
Where It Usually Breaks
BSS-to-OSS integration is frequently asynchronous with acknowledgement-based confirmation. If the network element returns an error or is unreachable, the BSS may show the plan as active before the network change is actually applied.
Network equipment updates the subscriber profile
The network element management system applies the new QoS or service profile to the relevant equipment — GGSN, PCRF, or SMF depending on network generation. For 4G/5G data, the Policy and Charging Rules Function (PCRF/PCF) applies the new data limits and speeds in real time.
Systems Involved
Network Element Management System, PCRF/PCF, HLR/HSS
Where It Usually Breaks
Multi-vendor network environments can have inconsistent profile synchronisation. A subscriber may experience the old data speed on one radio tower and the new speed on another until all nodes converge.
Billing system is updated for the new plan
The BSS billing component applies the proration for the remaining cycle, schedules the new recurring charge from the next billing date, and updates the product instance. Any add-ons that are incompatible with the new plan are flagged for automatic suspension or customer notification.
Systems Involved
BSS billing engine, subscription manager, notification service
Where It Usually Breaks
Proration logic bugs are the most common source of billing complaints during plan migrations. Edge cases like plan changes on the last day of a cycle or during a grace period require explicit handling that is easy to miss during development.
Customer receives confirmation and can verify the change
A confirmation SMS and push notification are sent once the network provisioning acknowledges success. The customer's app reflects the new plan details. Usage meters reset if the plan boundaries have changed.
Systems Involved
Notification service, digital channel, customer portal
Where It Usually Breaks
Notification delivery lags can cause customers to contact support before the confirmation arrives, generating duplicate interactions. More seriously, if the app data is cached and not refreshed from the updated BSS record, the displayed plan details will be stale.
Where Production Incidents Usually Happen
CDR Processing Gap
Symptom: Customers receive bills with missing usage or usage bunched into the wrong billing cycle.
Why it happens: CDR collection from network elements depends on scheduled file exports or SFTP pushes. If a network element goes offline during a collection window, CDRs are buffered locally. When the element recovers, a burst of delayed records arrives. If the mediation platform processes them by arrival time rather than event time, they land in the wrong billing period.
What good teams do: CDR processing must use event-time semantics, not processing-time semantics. Delayed CDRs should be flagged and processed into late adjustment buckets rather than mixed with current-period records. Reconciliation jobs compare expected CDR volumes against received volumes to detect gaps before billing closes.
Provisioning-Billing Mismatch
Symptom: Customer's network service reflects the old plan while billing has already applied the new plan charges, or vice versa.
Why it happens: BSS and OSS updates are not atomic. A failure in one system after the other has already committed leaves the two systems in different states. Without a rollback or compensation flow, the mismatch persists until a batch reconciliation job catches it — which may be days later.
What good teams do: BSS-OSS integration needs a saga pattern with explicit compensating transactions. Every provisioning flow should have a status that both systems can query, and operations teams need a dashboard that surfaces pending or mismatched states before customers notice.
ITSM SLA Breach due to Escalation Routing Failure
Symptom: High-priority incidents miss resolution SLAs despite being visible in the ITSM tool.
Why it happens: Escalation routing rules in ServiceNow or similar tools become stale as teams reorganise. A P1 incident assigned to a group that no longer has active on-call members does not get actioned. The ITSM tool marks the SLA timer as running while nobody receives an alert.
What good teams do: On-call schedules in ITSM must be synchronised with PagerDuty/OpsGenie. Escalation rules should have a fallback path that always reaches a human (e.g., a manager's mobile) regardless of group membership. SLA dashboards should alert on incidents approaching the 50% mark, not just at breach.
Technology Architecture — How Technology & Communications Platforms Are Built
The diagram below reflects how production Technology & Communications systems are structured at scale — nine layers from client channels through edge security, API gateway, domain microservices, polyglot data stores, async event streaming, analytics, external partners, and cloud infrastructure. Solid arrows show synchronous REST/gRPC calls; dashed arrows show async event flows via Kafka or a message queue.
Industry Players & Real Applications
🇮🇳 Indian Companies
TCS
IT Services
World's 2nd largest IT company — $29B revenue, 600K+ employees
Infosys
IT Services
Global IT services — $18B revenue, Finacle banking product
Reliance Jio
Telecom
India's largest telecom — 450M+ subscribers, 5G leader
Airtel
Telecom
India's #2 telecom — strong enterprise and B2B segment
Zoho
SaaS
India's largest SaaS company — 55+ products, $1B+ revenue
Freshworks
SaaS
CRM/ITSM SaaS — NASDAQ listed, 65,000+ customers globally
BSNL
Telecom (PSU)
Government telecom — 4G rollout with TCS
Wipro / HCL
IT Services
Large IT services — cloud, infrastructure, consulting
🌍 Global Companies
Microsoft Azure
Cloud Platform
World's 2nd largest cloud — Teams, Office 365, Azure AI
Amazon AWS
Cloud Platform
World's largest cloud — $100B+ revenue, 200+ services
Google Cloud
Cloud Platform
AI-first cloud — GKE, BigQuery, Vertex AI
Salesforce
SaaS CRM
World's #1 CRM — $34B revenue, 150,000+ customers
ServiceNow
SaaS ITSM
ITSM and workflow automation — $10B+ revenue
Cisco
Network Hardware & Software
Networking infrastructure — switches, routers, Webex
🛠️ Enterprise Platform Vendors
VMware / Broadcom
Virtualization
Virtualization and private cloud — used by large enterprises
Red Hat OpenShift
Container Platform
Kubernetes platform for enterprise Kubernetes
HashiCorp
DevOps Tools
Terraform, Vault, Consul — IaC and secrets management
Datadog / New Relic
Monitoring & Observability
APM and observability platforms
Core Systems
These are the foundational systems that power Technology & Communications operations. Understanding these systems — what they do, how they integrate, and their APIs — is essential for anyone working in this domain.
Business Flows
Key Business Flows Every Developer Should Know.Business flows are where domain knowledge directly impacts code quality. Each flow represents a real business process that your code must correctly implement — including all the edge cases, failure modes, and regulatory requirements that aren't obvious from the happy path.
The detailed step-by-step breakdown of each flow — including the exact API calls, data entities, system handoffs, and failure handling — is covered below. Study these carefully. The difference between a developer who “knows the code” and one who “knows the domain” is exactly this: the domain-knowledgeable developer reads a flow and immediately spots the missing error handling, the missing audit log, the missing regulatory check.
Technology Stack
Real Industry Technology Stack — What Technology & Communications Teams Actually Use. Every technology choice in Technology & Communicationsis driven by specific requirements — reliability, compliance, performance, or integration capabilities. Here's what you'll encounter on real projects and, more importantly, why these technologies were chosen.
The pattern across Technology & Communications is consistent: battle-tested backend frameworks for business logic, relational databases for transactional correctness, message brokers for event-driven workflows, and cloud platforms for infrastructure. Modern Technology & Communicationsplatforms increasingly adopt containerisation (Docker, Kubernetes), CI/CD pipelines, and observability tools — the same DevOps practices you'd find at any modern tech company, just with stricter compliance requirements.
⚙️ backend
Java / Spring Boot
Enterprise IT systems — BSS/OSS, ITSM, ERP integrations
Go
Cloud-native microservices, Kubernetes operators
Python
Automation, scripting, ML workloads, data engineering
Node.js
Real-time APIs, webhooks, lightweight services
🖥️ frontend
React / Angular
Enterprise portals, ITSM dashboards, admin consoles
Vue.js
Lightweight web apps, Freshworks product stack
🗄️ database
PostgreSQL / MySQL
Core transactional systems
MongoDB
Flexible document storage — configurations, events
Cassandra / ScyllaDB
Telecom CDR (Call Detail Records) — billions of records
Elasticsearch
Log analytics (ELK stack), full-text search
InfluxDB / Prometheus
Time-series data — metrics, telemetry
☁️ cloud
AWS
Default for most SaaS companies and startups
Azure
Enterprise IT — Microsoft ecosystem integration
GCP
AI/ML workloads, BigQuery analytics, Kubernetes (GKE)
On-premise / Hybrid
Telecom core network, government IT, BFSI
Interview Questions
Q1.What is the difference between BSS and OSS in telecom?
BSS (Business Support Systems) handle customer-facing business operations: billing, invoicing, CRM, plan management, revenue assurance, and mediation (processing call detail records). BSS answers 'Who owes what and for which service?'. OSS (Operations Support Systems) handle network operations: network inventory, fault management, performance monitoring, provisioning, and configuration. OSS answers 'Is the network working correctly and how is it configured?'. Together they form the operational backbone of any telecom company. Modern telecoms move towards BSS/OSS convergence with microservices and TM Forum Open APIs to handle 5G complexity, digital channels, and B2B services.
Q2.Explain the ITIL incident management process.
ITIL Incident Management process: 1) Detection — monitoring tools, user reports, or automated alerts identify a service disruption. 2) Logging — incident created in ITSM tool (ServiceNow, Jira) with description, time, affected services. 3) Categorization and Prioritization — priority assigned based on Impact × Urgency matrix (P1 = critical, immediate; P4 = low, scheduled). 4) Initial Diagnosis — first-line support (L1) attempts quick fix using knowledge base. 5) Escalation — if unresolved, escalated to L2/L3 with subject matter experts. 6) Investigation & Diagnosis — root cause identified. 7) Resolution and Recovery — fix applied, service restored. 8) Incident Closure — incident closed, user notified, CMDB updated. SLA tracked throughout — P1 typically requires response in 15 min, resolution in 4 hours.
Glossary & Key Terms
BSS
Business Support Systems — telecom billing, CRM, revenue assurance
OSS
Operations Support Systems — network inventory, fault management, provisioning
ITSM
IT Service Management — processes and tools for managing IT services (ITIL framework)
CMDB
Configuration Management Database — inventory of all IT assets and their relationships
SLA
Service Level Agreement — agreed performance standards (uptime, response time)
CDR
Call Detail Record — usage record for each telecom event (call, SMS, data)
SaaS
Software as a Service — subscription-based cloud software delivery model
ITIL
IT Infrastructure Library — best practice framework for ITSM
PIR
Post-Incident Review (also Postmortem) — blameless analysis after major incidents