IT Services App Development

Companies building IT service management (ITSM) platforms compete against incumbents (ServiceNow, Jira Service Management, Freshservice) that have set a high baseline for workflow automation, CMDB accuracy, and SLA management. Differentiating requires either going deeper on a specific vertical (MSP tooling, SMB IT, or industry-specific compliance like HIPAA-compliant ITSM) or building more flexible architecture than the incumbents provide. Scrums.com builds ITSM platform engineering infrastructure: service desk and ticket lifecycle engines, CMDB with configuration item relationship graph, ITIL v4 workflow framework covering incident, problem, change, and request management, AIOps event correlation for alert noise reduction, and SLA management with automated escalation, designed for multi-tenant SaaS deployment from the outset.

Our dedicated engineering teams have built ITSM infrastructure for MSP (managed service provider) platforms, enterprise IT tooling vendors differentiating against ServiceNow on flexibility and cost, and SaaS companies embedding service management capabilities into their existing product suite. We deliver dedicated squads (senior engineers, tech leads, QA) integrated into your sprint cycle, typically deploying first production infrastructure within 21 days of kickoff.

Core Architecture of an ITSM Platform

ITSM platforms differ from general-purpose ticketing systems in one critical respect: they model relationships between work items, configuration items, people, and processes in ways that generic ticket queues do not. Four subsystems define production-grade ITSM architecture.

Service Desk and Ticket Lifecycle Engine

The ticket lifecycle is a finite state machine with configurable states, transitions, and transition guards per ticket type. Incident tickets (unexpected service disruption) follow a different workflow from service requests (pre-approved, repeatable fulfilment) and change requests (risk-assessed, approval-gated). State machine configuration must be per-service, not global: the incident lifecycle for a Severity 1 production outage differs from a password reset. Each state transition fires configurable automation rules: notification dispatch, SLA clock start/stop/pause, related CI status update, escalation trigger, and integration webhook. The transition audit trail captures every state change with timestamp, actor (human or automation), and trigger reason: required for ITIL process compliance evidence.

CMDB and Configuration Item Relationship Graph

A Configuration Management Database (CMDB) is only as valuable as the accuracy of its CI (configuration item) data and the completeness of its relationship graph. Discovery integrations (Nmap-based network discovery, agent-based inventory collection, cloud provider APIs: AWS Config, Azure Resource Graph, GCP Asset Inventory) populate CIs automatically rather than relying on manual entry that rapidly goes stale. Relationships between CIs (hosts a service, depends on, connected to, virtualises, runs on) form a directed graph. Impact analysis traverses this graph upstream from an affected CI to identify which services and users are affected: this traversal must complete in under 500ms even for graphs with millions of nodes, requiring graph database storage (Neo4j, Amazon Neptune, or a PostgreSQL adjacency list with path query optimisation). Federation allows CIs discovered in separate discovery domains to be merged without duplication.

ITIL v4 Workflow Engine

ITIL v4 defines four core management practices relevant to ITSM platform design. Incident management requires: triage and categorisation (ML-based category suggestion from ticket text), priority matrix calculation (urgency + impact = priority), SLA target assignment, major incident workflow with separate bridge coordination track, and post-incident review scheduling on resolution. Problem management requires: problem record linked to one or more incidents, root cause investigation workflow with known error database publication, and proactive problem identification from incident trend analysis. Change management requires: change classification (standard/normal/emergency), risk assessment scoring, CAB (Change Advisory Board) approval workflow with configurable quorum, and change schedule conflict detection against the CMDB service calendar. Request fulfilment requires: service catalogue with configurable approval stages, fulfilment task generation from request templates, and SLA tracking per catalogue item.

AIOps and Event Correlation

Modern IT environments generate monitoring alert volumes that overwhelm human triage. AIOps reduces this noise through: deduplication (grouping repeat alerts from the same CI within a time window into a single incident), topological correlation (grouping alerts from CIs with known dependency relationships into a single root-cause incident), temporal correlation (grouping alerts that fire within a configurable time window across related services), and ML-based anomaly detection on metric streams (CPU, memory, latency, error rate) that identifies degradation before threshold-based alerts fire. Alert suppression during planned maintenance windows prevents false incidents during change execution. The correlation engine must process 10,000+ events per second without queuing delay at enterprise scale.

Compliance Architecture: SOC 2, GDPR, HIPAA, and ISO 20000

ITSM platforms handle sensitive operational data (system vulnerabilities, change histories, incident details, and user activity) that falls under multiple compliance frameworks depending on the platform's customer base.

SOC 2 Type II for ITSM Platforms

SOC 2 Type II is the baseline assurance requirement for enterprise ITSM buyers, particularly in North America. Trust service criteria relevant to ITSM platforms include: Logical and Physical Access Controls (role-based access, principle of least privilege, access review evidence), Change Management (audit trail of configuration changes to the ITSM platform itself, separate from customer configuration changes), Risk Assessment (documented risk assessment process with evidence), and Availability (uptime SLA evidence, incident response records, backup and recovery testing). The ITSM platform should produce SOC 2 evidence as a byproduct of normal operations: access logs, change logs, and availability metrics exported to the auditor rather than reconstructed during the audit window.

GDPR and Data Residency in Multi-Tenant ITSM

ITSM tickets frequently contain personal data: requester names, email addresses, details of IT issues that may reveal health or financial information, and user activity logs. GDPR requires: lawful basis documentation for processing, data subject access request capability (export all tickets and log entries containing a specific email address), right to erasure workflow (pseudonymise personal data while retaining the operational record for audit purposes), and data residency controls for EU customers requiring their data to remain within the EEA. Multi-tenant architecture must implement tenant-level data isolation: a data subject erasure request for one tenant must not affect any other tenant's data, and the erasure must propagate to search indices, event logs, and backup snapshots.

HIPAA-Compliant ITSM for Healthcare IT

Healthcare IT teams use ITSM platforms to manage incidents involving systems that process Protected Health Information (PHI). HIPAA's Security Rule requires: access controls (unique user identification, automatic logoff, encryption), audit controls (hardware and software activity records), integrity controls (prevent improper alteration or destruction of PHI in transit), and transmission security (TLS encryption for all data in transit). For the ITSM platform, this means: ticket content that may contain PHI must be encrypted at rest, access to tickets is restricted to the minimum necessary users (not all-agents-see-all), and audit logs of ticket access must be retained for 6 years. Business Associate Agreement (BAA) execution is required before any healthcare IT customer can use the platform.

ISO 20000 and ITIL Certification Support

ISO 20000 is the international standard for IT service management systems, based on ITIL principles. Organisations seeking ISO 20000 certification must demonstrate that their service management processes are documented, consistently followed, and subject to continual improvement. The ITSM platform supports certification by: generating process compliance evidence (SLA achievement rates, change success rates, incident resolution times by category), maintaining the required management practice documentation as versioned records, providing measurement and reporting tooling for management reviews, and supporting the internal audit process with exportable evidence packages. ITIL 4 Foundation alignment means that the platform's terminology, workflow names, and process definitions match ITIL v4 guidance without requiring translation.

For engineering teams building ITSM mobile platforms, see our mobile app development services.

Technology Stack for ITSM Platforms

ITSM platform technology must handle the full range of requirements: sub-second ticket state machine transitions, graph traversal for impact analysis, high-throughput event ingestion for AIOps, and multi-tenant data isolation for SaaS deployment.

Ticket Workflow Engine

Java Spring Boot or Node.js/TypeScript for the ticket state machine engine. PostgreSQL with event-sourced audit trail for ticket state transitions: every state change appended, never overwritten. Apache Kafka for state transition events propagated to the SLA engine, notification service, and integration webhooks in order and without loss. Redis for SLA deadline caching and real-time escalation timer management (sorted set with expiry scores per ticket SLA target).

CMDB and Graph Infrastructure

Neo4j or Amazon Neptune for CI relationship graph storage and impact analysis traversal queries: both support Cypher or Gremlin for graph path queries with sub-second performance at millions of nodes. Elasticsearch for CMDB search (CI lookup by attribute, full-text service search). AWS Config, Azure Resource Graph, and GCP Asset Inventory APIs for cloud resource auto-discovery. Nmap and agent-based inventory (Lansweeper, Rapid7 Insight Agent) for on-premises network discovery. Schema registry for CI type definitions and relationship type definitions: configuration-driven rather than hardcoded so new CI types do not require code deployment.

AIOps and Event Processing

Apache Kafka for alert event ingestion from monitoring tools (Datadog, Dynatrace, Zabbix, Prometheus Alertmanager, PagerDuty). Apache Flink for stream processing (deduplication, topological correlation, and temporal grouping) in real time. Python/PyTorch for anomaly detection model training on metric time series; ONNX runtime for model inference deployment in the correlation pipeline. Elasticsearch for alert history storage and incident correlation analytics. Suricata and Zeek for network-layer event generation from infrastructure traffic.

Integration and Knowledge Management

ServiceNow REST API and Jira Service Management REST API for bidirectional ticket sync where customers use multiple platforms. Microsoft Teams and Slack bots for agent notification, approval workflows, and end-user self-service. Confluence or ServiceNow Knowledge Base APIs for knowledge article surfacing during ticket triage: ML-based similarity search against the knowledge base from ticket description reduces time-to-resolution. SNMP, IPFIX, and syslog receivers for network device event ingestion into the AIOps pipeline.

Multi-Tenant Architecture

PostgreSQL row-level security (RLS) for tenant data isolation with tenant ID on every table row. Kubernetes namespace isolation per enterprise tier for dedicated resource allocation. Vault (HashiCorp) for per-tenant secret management (integration credentials, encryption keys, webhook signing secrets). Tenant-specific configuration stored as versioned JSON schema in a separate configuration service: changes to one tenant's SLA matrix or workflow configuration do not affect other tenants.

Why Engineering Teams Choose Scrums.com for ITSM Platform Development

ITSM platforms are deceptively complex: the surface area looks like a ticketing system, but the underlying requirements (sub-500ms CMDB graph traversal for impact analysis, correlation engines processing 10,000 events per second, multi-tenant SLA enforcement without cross-tenant data leakage) require the same engineering rigour as any enterprise data platform. Across our client engagements building ITSM infrastructure, the most expensive architectural decisions made upfront are: choosing a relational database for CI relationship storage (switching to a graph database after the product is live requires a full data migration), building global SLA logic rather than per-service-configurable logic (every enterprise customer has different SLA requirements), and building single-tenant first with multi-tenancy retrofitted (retrofitting tenant isolation into an existing data model breaks every query that lacks a tenant ID filter).

ITIL Domain Knowledge

Our engineers understand ITIL v4 management practice requirements: the difference between an incident and a problem, why CAB approval workflow must handle emergency changes differently from normal changes, and how the service catalogue relates to request fulfilment SLA tracking. This domain knowledge reduces requirements clarification cycles and prevents data model design mistakes that require expensive migrations to fix.

Dedicated Squads, Not Rotating Contractors

Each engagement is staffed with a fixed squad (senior engineer, mid-level engineer, tech lead, and QA) who stay for the project duration. ITSM platform context accumulates: your CI type taxonomy, your SLA matrix, your correlation rule set. Rotating contractors lose this context; our squads retain it. Typical first production deployment within 21 days of kickoff.

Multi-Tenant by Design

We design multi-tenant ITSM platforms from day one: tenant-isolated data models, per-tenant configuration, and tenant-level SLA policies. Retrofitting multi-tenancy after launch is significantly more expensive than designing for it from the start: every query, every analytics aggregation, and every data export must be rewritten to filter by tenant.

Discuss your ITSM platform requirements with us, or explore how we staff dedicated engineering squads for complex platform builds.

Frequently Asked Questions

How do you design a ticket state machine that is configurable per service without becoming unmaintainable?

The state machine definition is stored as data, not code: each ticket type has a configuration record defining its states, permitted transitions, transition guards (conditions that must be true for a transition to be allowed), and automation rules fired on each transition. The state machine engine reads this configuration at runtime and executes transitions generically: no code change is required to add a new ticket type or modify an existing workflow. Versioning the state machine configuration (each definition has a version, and live tickets track which version they were created under) allows workflow changes without retroactively breaking in-flight tickets. Schema validation on configuration changes prevents invalid state machine definitions (unreachable states, missing terminal states) from reaching production.

How does CMDB impact analysis work when the CI relationship graph has millions of nodes?

Impact analysis is a graph traversal problem: given a CI that is degraded or unavailable, which services and users are affected? The traversal follows dependency edges upstream from the affected CI. For a graph of millions of nodes, this requires a native graph database (Neo4j or Amazon Neptune) that can execute Cypher or Gremlin path queries with index-backed traversal rather than performing a full graph scan. Query performance is further improved by materialising common traversal paths (service-to-infrastructure mappings) as cached impact maps that are invalidated when relationships change. Alert correlation benefits from the same graph: a set of simultaneous alerts from CIs that form a known dependency chain can be correlated into a single probable root cause rather than generating N separate incidents.

What is the engineering requirement for SLA management across hundreds of different customer SLA policies?

SLA policies must be stored as configuration data per customer and per service catalogue item: not hardcoded. Each policy defines: response time target (time from ticket creation to first agent response), resolution time target (time from creation to ticket closure), business hours calendar (timezone, working days, public holiday overrides), and clock pause conditions (waiting for customer response pauses the clock). The SLA engine reads these policies at ticket creation time, calculates deadline timestamps accounting for business hours, and stores the deadlines as sorted set entries in Redis for efficient expiry-based escalation processing. Breached SLA events fire automation rules: escalation to a supervisor, notification to account management, and SLA breach logging for reporting.

How does AIOps correlation reduce alert noise without suppressing genuine incidents?

The correlation engine uses layered suppression: first, deduplication groups repeated alerts from the same CI and metric into a single representative event within a configurable time window. Second, topological correlation groups alerts from CIs with known dependency relationships (a network switch and all the servers connected to it) into a single probable root cause incident, suppressing the downstream alerts. Third, temporal correlation groups alerts across unrelated CIs that fire within the same short window (suggesting a common cause like a network partition). Each correlation decision is logged with the grouping rationale: an analyst can always drill into the raw events that were suppressed. Manual override allows an analyst to separate incorrectly correlated alerts or promote a suppressed alert to a standalone incident.

Can you build an ITSM platform that integrates with both ServiceNow and Jira Service Management for customers who use both?

Yes. Bidirectional sync integrations between ITSM platforms require: a canonical data model that maps ticket fields between systems (status codes, priority values, custom fields), conflict resolution logic for concurrent edits (last-writer-wins with a configurable override, or field-level locking per system of record), loop detection to prevent a sync update from triggering a resync (typically via a sync origin flag in the ticket metadata), and webhook-based real-time sync rather than polling to avoid propagation delays. The most common use case is a platform-layer ITSM that holds the canonical incident record while syncing to ServiceNow for enterprise reporting and to Jira for dev team escalation tickets.