From NOC to command center: operating services, not devices

Many organizations have a large screen showing network maps, green links and CPU charts. That is the NOC, the network operations center. For years it was enough: if links, routers and servers were up, the service worked. That equation no longer holds. A mobile app depends on APIs, message queues, databases, external providers and cloud services. Every device can be green while a customer still cannot complete a transfer.

This article explains why a network-centric NOC falls short, what a 24×7 command center does differently, and what it needs from observability and service management to work.

Why the traditional NOC falls short

The classic NOC was built to watch components: link availability, interface status, CPU and memory usage, disk space. Its mental model is the inventory. Each device has thresholds, and when one is crossed, an alert fires.

That model has three clear limits in a modern architecture:

• It does not see what the customer sees. A service can degrade because of a logic error, an expired certificate at a provider, a growing queue or a slow query. None of those turns a link red.
• It creates noise without context. A hundred high CPU alerts do not say which service is affected or how many users are hit. Operators end up filtering by instinct.
• It ends up in the wrong place. When the NOC can only say "the network is fine", the incident bounces between teams. Each team proves its component works, and nobody owns the whole service.

The problem is not the network or the NOC team. It is the unit of analysis. If you watch devices, you manage devices. The business, however, measures services.

What a command center is and what it watches

A command center is a 24×7 operations function whose unit of work is the end-to-end service. It answers a simple question: can customers and internal users do what they need to do, right now?

To answer it, the command center brings four kinds of signals into a single view:

• Applications: latency, error rate and volume of the main transactions, distributed traces across services, errors in web and mobile apps.
• Infrastructure: network, servers, containers, databases and cloud, read as dependencies of a service rather than as isolated parts.
• Security signals: relevant events that the security team shares with operations, such as spikes in failed logins or anomalous traffic that affect availability. The command center does not replace the SOC; it coordinates with it.
• Business transactions: approved payments per minute, successful logins, completed requests. They are the most direct proof that the service is doing its job.

The core difference is the question. The NOC asks "which device is failing?". The command center asks "which service is degraded, who is affected and who is fixing it?".

Aspect	Network-centric NOC	24×7 command center
Unit of analysis	Device or component	End-to-end service
Main signals	Availability, CPU, memory, links	User experience, transactions, traces, dependencies
Alerts	Per-device thresholds	Service symptoms and service level objectives
Accountability	The component is up	The service recovers and the business is informed
Relationship with ITSM	Opens tickets	Coordinates incidents, changes and communication

Service maps: the inventory that actually matters

A command center needs to know what each service is made of. That is the purpose of service maps: a representation of the components, dependencies and providers behind a business service.

A useful service map includes, at a minimum:

• The business service and its owner (for example, "card payments", owned by the payments area).
• The applications and APIs that make it up, and the dependencies between them.
• The infrastructure underneath: databases, queues, clusters, links.
• The external providers involved and their escalation contacts.
• The indicators that define whether the service is healthy, and their targets.

There are two sources to build it. The first is the configuration management database (CMDB) in the ITSM tool, which documents declared relationships. The second is automatic discovery in observability platforms, which detects real dependencies from traffic and traces. Use both: the CMDB provides owners and business context, and automatic discovery shows how the system actually communicates. When they disagree, the gap is a finding in itself.

Roles and escalation

A command center is more than a shift of operators in front of screens. It runs on defined roles and an escalation model everyone knows.

Typical roles

• Shift operator (first level): watches service dashboards, validates alerts, runs documented procedures and opens the incident.
• Second-level analyst: correlates signals, identifies the likely component and runs authorized recovery actions.
• Incident coordinator: in major incidents, leads the response, brings in resolver teams, keeps track of time and decides on communication.
• Communications lead: updates the business, customer service and leadership in an agreed format and cadence.
• Resolver teams: development, databases, network, cloud, security and providers, each with a defined on-call rotation.

Escalate on impact, not only on time

A common mistake is to escalate on the clock alone: if it is not fixed in 30 minutes, call the next level. It is better to combine time and impact. A degradation that hits a critical service at peak hours should bring in the coordinator from minute one, even if it looks minor. That requires a criticality rating for each service and a priority matrix (impact by urgency) agreed with the business before the incident, not during it.

We recommend writing escalation into per-service runbooks with three clear facts: who decides, who gets called and what is communicated at each stage.

What it needs from observability and ITSM

From observability

The command center depends on the system being observable from the outside. An observability platform (Dynatrace, Datadog or others) captures much of the infrastructure and applications automatically. But finding the root cause quickly also requires software written to be observable:

• Structured logs with correlation identifiers.
• Trace context propagated across services, for example with OpenTelemetry and the W3C Trace Context standard.
• Business metrics emitted by the application itself.
• Deployment and change events sent to the platform, so degradations can be correlated with recent changes.

An observable platform is not the same as an observable application. Without instrumentation in the code, the command center will see that something is slow, but not why.

Add to that service level objectives (SLOs) defined per service. Alerting on the symptom the customer sees, rather than on every technical threshold, is what lets a small shift cover a large estate without drowning in noise.

From service management

The command center is where several ITIL 4 practices meet: monitoring and event management, incident management, problem management, change enablement and service level management. In practice it needs:

• Integration between the observability platform and the ITSM tool (ServiceNow or another), so a validated alert creates or updates an incident with the affected service already identified.
• Visibility of the change calendar, because incidents often coincide with a recent change.
• A problem record for recurring incidents, with an owner and a review date.
• Service level reports that use the same metrics the command center watches.

In the European financial sector, Regulation (EU) 2022/2554 (DORA) requires entities to have processes to manage, classify and report ICT-related incidents. A command center with an orderly record of incidents, timelines and impact makes that work easier. Each organization should confirm the exact scope with its compliance team.

How to start the transition

Moving from NOC to command center does not require changing everything at once. A reasonable path:

1. Pick three to five critical services with an identified business owner.
2. Draw their service maps, cross-checking the CMDB against automatic discovery.
3. Define indicators and targets per service: availability, latency and one business metric.
4. Build one dashboard per service that the shift can read in seconds: healthy, degraded or down, and why.
5. Rewrite alerts so they fire on service symptoms, and route component alerts to technical teams as context.
6. Document runbooks and escalation for those services and test them with drills.
7. Review every major incident without blame and turn the findings into instrumentation or procedure improvements.

Once those first services run well under the new model, widen the scope. The NOC team is usually the best starting point: it knows the infrastructure and the night shift. What changes is the question it answers.