System criticality refers to the degree to which a system’s unavailability or degraded performance causes harm to an organization — whether financial, operational, reputational, or human. Understanding how critical a system is before designing and building it is foundational to making the right investments in reliability, recovery, support, and operations. Assessments of criticality can also change over time as uses and workflows evolve, and should be regularly revisited.
Criticality is a general information technology (IT) concept, not specific to ArcGIS, but it applies directly to the design of ArcGIS systems as many GIS workflows support the key day-to-day business operations of organizations. A real time security and operations system providing situational awareness for a large scale special event and an internal self-service mapping portal are both ArcGIS systems — but they have fundamentally different consequences if they were to become unavailable and should be designed, operated, and supported accordingly.
A widely used IT reference model defines four criticality tiers, ranging from administrative systems with minor impact when unavailable, to mission-critical systems where disruption can lead to significant financial or human cost. The table below summarizes each tier.
This reference model is commonly used across the IT industry and is not specific to ArcGIS. Organizations may use different terminology or define tier boundaries differently. Use this model as a starting point for your own classification process, rather than a definitive guide.
| Administrative | Business Operational | Business Critical | Mission Critical | |
|---|---|---|---|---|
| Characteristics | Unavailability reduces individual performance of internal users — minor impact to productivity | Outages cause mild disruption to operational activities — efficiency loss | Outages and degraded performance disrupt business operations and reduce return on investment (ROI), but minor unplanned downtime is tolerable | Disruption associated with unavailability or underperformance leads to significant financial or human cost |
| ArcGIS example | Internal self-service mapping | Community engagement | Network management | Public safety operations systems |
| Outage impact | Minor | Moderate | Significant | Severe |
| Recovery time objective (RTO) | ~1 week+ | < 72 hours | < 24 hours | < 4 hours |
| Recovery point objective (RPO) | ~48 hours | < 24 hours | < 1–4 hours | < 1 hour |
| Support hours | Business hours | Business hours | Extended business hours | ~24/7/365 |
Criticality looks different depending on where you sit in an organization. Productive conversations about classification require input from multiple stakeholders, each of whom brings a different perspective.
The executive lens focuses on risk and exposure. Executives weigh the reputational, regulatory, and financial consequences of a system being unavailable. For mission-critical systems, the risk to the organization’s reputation and operations is extreme. For administrative systems, the risk is minimal. For executives, the system is simply available and working, or it is not – nuances of subsystems, applications or dependencies are beneath their level of review.
The management lens focuses on support commitments. Managers are concerned with what level of support the organization can realistically sustain — help desk hours, on-call expectations, escalation paths, and vendor service level agreements (SLAs). A mission-critical system demands around-the-clock coverage; an administrative system does not.
The operational lens focuses on recovery. IT operations teams think in terms of RTO — how quickly the system must be restored — and RPO — how much data loss is acceptable. These targets drive architectural decisions around backups and disaster recovery, high availability, and upgrades.
All three lenses are needed to arrive at an accurate and defensible criticality classification, and early collaboration between these viewpoints will ensure that a holistic definition or classification is reached.
Criticality classification does not exist in isolation — it connects directly to several adjacent concepts that shape how systems are designed and operated.
SLAs and non-functional requirements (NFRs) are the formal expression of what criticality means in practice. Once a system is classified, that classification should drive documented commitments around uptime, performance thresholds, support hours, and recovery targets. Criticality without a corresponding SLA is an opinion; a SLA without a criticality classification often lacks the business context to justify its targets.
High availability and disaster recovery are architectural responses to criticality. Higher-criticality systems typically require both, but the investment and complexity involved is substantial. Not every system requires full disaster recovery across multiple data centers — criticality classification is the basis for making that determination intentionally rather than by default.
System scalability is also shaped by criticality. Mission-critical and business-critical systems must be designed to handle not just average load but unexpected surges and shocks. A system that performs well under normal conditions but degrades under peak load may still fail its criticality requirements.
System lifecycle considerations are closely tied to criticality as well. Higher-criticality systems require more rigorous processes across the full lifecycle — from initial design through ongoing operations — including regular disaster recovery (DR) drills, patching cadences, upgrade planning, and capacity reviews.
Assigning a criticality tier is a business decision, not purely a technical one. It requires input from GIS practitioners, IT, business owners, and in many cases executive stakeholders. Useful questions to structure the conversation include:
A common pitfall is under-classifying systems that have hidden dependencies — a system that appears administrative may feed a business-critical downstream process. It is equally important to recognize that the relationship between a system and the solutions that run on it can be one-to-many. Multiple solutions with independent timelines, requirements, and teams may share the same underlying ArcGIS system. The criticality of the system should reflect the highest criticality of any solution that depends on it.
Criticality classification carries real organizational weight. A higher tier implies concrete commitments: increased infrastructure investment, more complex operational procedures, expanded support coverage, and rigorous testing requirements. Assigning a higher tier than the system’s actual business impact warrants can create unnecessary cost and operational burden — and can reduce an organization’s ability to focus appropriate attention on systems that are genuinely mission critical.
Organizations should resist the tendency to default to the highest tier as a precautionary measure. Instead, classifications should be grounded in an honest assessment of impact: what would actually happen to operations, stakeholders, and the organization’s obligations if this system were unavailable? A system that would cause significant inconvenience is not equivalent to one whose failure could result in financial loss, regulatory consequence, or risk to public safety. Calibrating that distinction carefully — and revisiting it as systems evolve — leads to a more sustainable and effective approach to system investment and operations.
Criticality classification should be established early in the design process, before architectural decisions are locked in. It has direct implications across every layer of a modern ArcGIS system: