{"id":2980630,"date":"2026-09-17T07:56:10","date_gmt":"2026-09-17T14:56:10","guid":{"rendered":"https:\/\/www.esri.com\/arcgis-blog\/?post_type=blog&p=2980630"},"modified":"2026-09-18T11:03:17","modified_gmt":"2026-09-18T18:03:17","slug":"building-reliable-arcgis-systems","status":"publish","type":"blog","link":"https:\/\/www.esri.com\/arcgis-blog\/products\/arcgis\/announcements\/building-reliable-arcgis-systems","title":{"rendered":"Building Reliable ArcGIS Systems: Matching Architecture to Business Needs"},"author":370372,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":{"_acf_changed":false,"_searchwp_excluded":""},"categories":[37101],"tags":[],"industry":[],"product":[421922],"class_list":["post-2980630","blog","type-blog","status-publish","format-standard","hentry","category-announcements","product-arcgis"],"acf":{"authors":[{"ID":3601,"user_firstname":"Rob","user_lastname":"Elkins","nickname":"Rob Elkins","user_nicename":"rpe2","display_name":"Rob Elkins","user_email":"relkins@esri.com","user_url":"","user_registered":"2018-03-02 00:15:15","user_description":"Rob is Managing Director of Product Management at Esri, helping guide the strategy and evolution of ArcGIS. He works with product development, and customer communities to bring innovative GIS capabilities to organizations around the world.","user_avatar":""},{"ID":446042,"user_firstname":"Julia","user_lastname":"Colbert","nickname":"Julia Colbert","user_nicename":"jcolbertesri-com_esriinc","display_name":"Julia Colbert","user_email":"jcolbert@esri.com","user_url":"","user_registered":"2026-03-19 17:24:57","user_description":"Julia is a Product Marketing Manager at Esri. She works on ArcGIS Enterprise and the Operational Intelligence team.","user_avatar":""},{"ID":370372,"user_firstname":"Nicole","user_lastname":"Welch","nickname":"Nicole Welch","user_nicename":"nwelch","display_name":"Nicole Welch","user_email":"nwelch@esri.com","user_url":"","user_registered":"2025-04-02 17:30:34","user_description":"Nicole is a Product Marketing Manager on the ArcGIS Enterprise team. She is experienced in strategic communications, marketing, and brand storytelling from her time at The Walt Disney Company and Spotify. In her role, she focuses on supporting customer success by developing resources for effective onboarding, training, and adoption of ArcGIS Enterprise on Kubernetes.","user_avatar":""}],"short_description":"Learn how to define reliability for your organization and design ArcGIS Enterprise systems that meet service goals.","flexible_content":[{"acf_fc_layout":"content","content":"

Reliability is critical to keeping business operations running, minimizing disruptions, and meeting user expectations. However, reliability is not a one-size-fits-all approach. For example, a city planning department using ArcGIS Enterprise for internal zoning and planning workflows may be able to tolerate occasional downtime due to patching and can accept some failure conditions and recover using backups within a few hours. In comparison, an emergency management agency providing public-facing incident maps during a natural disaster requires continuous availability and recovery times measured in minutes.<\/p>\n

These two systems have very different reliability requirements, yet both can be considered well-architected because their reliability strategies align with their organization\u2019s business objectives, user expectations, and operational constraints. When architecting for reliability, the ArcGIS Well-Architected Framework provides guidance for translating business requirements into architectural and operational decisions that support reliable, resilient systems. While ArcGIS is available as a highly reliable SaaS offering through ArcGIS Online, the guidance in this article focuses on self-hosted deployments including ArcGIS Enterprise on Windows, Linux, and Kubernetes.<\/p>\n

What Does ‘Reliable’ Actually Mean?<\/b><\/h3>\n

For a well-architected system, reliability means consistently supporting the GIS capabilities and workflows of an organization at the level of service the business requires. Defining reliability starts with understanding the business outcomes a system needs to support and the consequences of service disruption. This does not mean that every system must be highly available and highly redundant to be well-architected, because for some systems this would indicate an improper level of complexity or cost that may not be needed.<\/p>\n

Organizations commonly measure reliability through Service-level Agreements (SLAs)<\/b>, which are commitments from providers to business users and clients to maintain a level of service at all times. The process of defining reliability for your organization involves translating business requirements into concrete SLA commitments that reflect what matters most to your users and workflows. The architectural choices used to achieve those SLA commitments will vary by organization. Some may rely on traditional or virtual deployment models, while others may adopt cloud-native deployment models<\/span><\/a> that provide built-in capabilities for resilience, monitoring, backup and recovery, and automated failure detection. The specific approach is less important than ensuring that the chosen architecture aligns with business requirements and service expectations. An availability SLA defines a set of services, applications, or workflows; a time period during which they are expected to be available (usually 24 hours a day, 7 days a week); and a definition of what conditions constitute a breach of the SLA, such as repeated failures, slow requests, errors, or degraded user experiences. Rather than adopting a generic definition of reliability, well-architected systems focus on defining, monitoring, and responding to SLAs that are tailored to the organization’s own business needs instead of simply pursuing higher uptime numbers as a goal.<\/p>\n

When systems are designed for a certain level of reliability, they typically use a combination of several techniques:<\/p>\n

    \n
  1. High Availability.<\/b> Building redundant system components, configured together and designed to take over and provide the same services in case of an outage.<\/li>\n
  2. Backups.<\/b> Regularly backing up the state of a system, the important details, data, and services for future recovery.<\/li>\n
  3. Disaster Recovery.<\/b> Planning for uncommon but disruptive scenarios and identifying methods to quickly rebuild a site or system<\/li>\n
  4. Monitoring.<\/b> Using effective monitoring to identify potential issues early, measure downtime, and report results for post-event analysis<\/li>\n<\/ol>\n

    Reliability in Modern Architectures<\/b><\/h4>\n

    The techniques above can be implemented in many ways, depending on an organization’s needs, infrastructure, and operational practices. The right approach is the one that aligns with your business requirements and service expectations and not necessarily the one with the most redundancy.<\/p>\n

    High Availability<\/b><\/h4>\n

    Designing a highly available system rarely starts with a blank canvas. Existing IT infrastructure, operational practices, technical expertise, and governance standards all shape the framework within which an enterprise GIS must operate and contribute to its availability. Business requirements dictate acceptable levels of downtime and data loss; deployment patterns influence how availability responsibilities are shared; infrastructure capabilities define practical boundaries; and maintenance needs affect how updates are introduced with minimal disruption.<\/p>\n

    ArcGIS Enterprise gives organizations that manage their own software the flexibility to design highly available systems:<\/p>\n