Choosing architecture components

During the architecture design process for an ArcGIS system, there are many decisions related to the apps, software, supporting infrastructure, and other components of a system. While most choices are primarily subjective and should be decided by experienced designers with knowledge of the requirements, system inputs and approach, there are also general guidelines that can help make a better decision or make a decision with increased confidence. This section will attempt to summarize some of the key choice areas, with helpful guidance that will allow organizations to choose more intentionally, based on sound criteria.

ArcGIS Online, ArcGIS Enterprise, PaaS and hybrid systems

Each of the system patterns provided in this website can be constructed across several different deployment patterns, including components of ArcGIS Online, ArcGIS Enterprise and ArcGIS Platform, along with related applications and interfaces. During the design process, the decision of which primary components to implement is important. This decision applies whether the design is based on these system patterns or a specific, fit-for-purpose business system.

Many organizations traditionally chose either ArcGIS Online or ArcGIS Enterprise as their main “portal” system for users, and focused their efforts on that one system, but increasingly organizations choose to combine both systems in their enterprise, focusing on the strengths of each providing clear governance to users to know which system to use.

The blog post ArcGIS Online or ArcGIS Enterprise? You don’t have to choose provides an overview of differences between these approaches and some helpful guidance, along with a detailed documentation page in the ArcGIS Enterprise documentation.

While there are hundreds of capabilities that are shared between ArcGIS Online and ArcGIS Enterprise, a few key differences exist that can guide design choices.

Key differentiators for ArcGIS Online:

ArcGIS Online is a SaaS offering – Esri is responsible for deploying, updating, and patching the system, and all these activities are completed with minimal user downtime. SaaS systems are less extensible through custom code or applications, and generally have a fixed, robust set of capabilities that are available to all tenants.
Esri provides a robust Service Level Agreement for all users of ArcGIS Online. This SLA guarantees availability for specific components of ArcGIS online, and a status page is provided for tracking any outages.
ArcGIS Online is a multi-tenant SaaS, where users can search for and access content from other organizations (if allowed by your organization), increasing their access to external data sources, including the ArcGIS Marketplace for partner content providers.
ArcGIS Online is designed to make use of Content Delivery Network (CDN) acceleration for many functions, including static website assets, tiled basemaps and user-managed tiled services, and feature tiles from hosted feature services. This also contributes towards a good level of service globally – where users far away from the central data centers are not negatively impacted by network latency with the support of the CDN.
ArcGIS Online provides access to several capabilities that are not currently available in ArcGIS Enterprise, such as ArcGIS Hub Premium, ArcGIS Data Pipelines, integration with ArcGIS Platform and the Developer site.
As an Internet-facing SaaS system, ArcGIS Online is automatically available over the internet to any user or mobile device. There is no need for an organization to manage public DNS, certificates, or patching for security vulnerabilities, this is all provided by Esri directly through ArcGIS Online.
ArcGIS Online is already accredited for several security standards, and goes through rigorous security testing, planning and implementation with each release. Achieving a high level of infrastructure security with a SaaS system can be significantly more cost-effective than building your own system.

Key differentiators for ArcGIS Enterprise:

ArcGIS Enterprise provides additional fully featured server roles that are not available in ArcGIS Online or only partially available, including: ArcGIS Knowledge, ArcGIS GeoAnalytics Server, GeoEvent Server, the Data Interoperability Extension for ArcGIS Enterprise, Production Mapping Server, Maritime Chart Server, and other capabilities.
ArcGIS Enterprise can connect directly to your existing data storage systems: databases, file shares or other data sources. Web services published from these sources dynamically display and provide access to data from your existing systems of record.
As software that your organization deploys and manages, you have control over when changes and upgrades happen, unlike SaaS where an upgrade is deployed for all users at the same time. Change management to inform users of changes or test application functionality ahead of a release is available with a software-based approach.
ArcGIS Enterprise supports tighter IT integration for authentication, including web-tier authentication, use of enterprise groups through AD or LDAP, and tighter specification of SSL and TLS protocols or ciphers.
As software that runs within your network, connectivity to other enterprise data systems is possible, including direct, real-time connections where appropriate. ArcGIS Online as SaaS cannot “reach in” to your network to access these datasets.
Running on your network, ArcGIS Enterprise can also more easily share content to “everyone in the organization” by providing open services to the intranet, without requiring authentication as a SaaS-based system does.
ArcGIS Enterprise can be used in an internal-facing pattern or can be exposed to the internet and used for internet-facing workflows.
ArcGIS Enterprise, as software built from many components, has significant third-party software dependencies that can complicate security scanning.
ArcGIS Enterprise deployments can be hosted behind an organizational domain name where ArcGIS Online organizations are only available as https://<orgname>.maps.arcgis.com

Key differentiators for ArcGIS Platform

ArcGIS platform service usage is provided through a single, developer-focused website which gives users access to their services, billing, and access controls in one place.
API keys are available as an authentication pattern exclusively with ArcGIS Platform, which allows for the creation of keys that are long-lived, but scoped to a specific service or capability, and limited through a list of allowed referrers.
ArcGIS Platform uses a pay-as-you-go model where usage translates directly to cost, which can give application authors more control over the cost profile of their application.
ArcGIS Platform gives access to specific services that are only available through that system, including the Places service and Basemap Styles service.

Hybrid deployments

Scenarios using ArcGIS Online and ArcGIS Enterprise together in a “hybrid deployment” can also provide advantages:

Separating internal and external content. Some organizations choose to publish all public-facing content to ArcGIS Online while reserving ArcGIS Enterprise for internal purposes, which provides easy separation of use and helps to guarantee data is properly shared. They might also use performance capabilities (caching + CDN) of ArcGIS Online to manage cost while still providing highly scalable services to users.
Supporting mobile use cases: some organizations use ArcGIS Online to enable public internet-based data collection by staff or contractors (so that devices do not need to be on VPN).

Operating system for ArcGIS Enterprise

ArcGIS Enterprise is supported on a variety of Windows operating systems and Linux-based operating systems, detailed in the Windows and Linux documentation for ArcGIS Enterprise. ArcGIS Enterprise on Kubernetes runs on what can be considered a third type of operating system, a Kubernetes cluster, which is Linux-based but not accessed and operated as a normal Linux operating system.

Windows and Linux or Kubernetes?

ArcGIS Enterprise on Windows and Linux is used by tens of thousands of organizations around the world, and runs in a traditional, machine-based deployment where individual software components are deployed to different hardware or virtualized ‘servers’ and are combined together into a deployment. Most organizations have experience managing Windows and Linux workloads and are comfortable with this deployment pattern, which is a stable, consistent, and future-ready deployment pattern.

ArcGIS Enterprise on Kubernetes is for organizations that have invested in Kubernetes to orchestrate and manage their containerized applications. For organizations that have the resources and staff to deploy and maintain enterprise software on Kubernetes, the ArcGIS Enterprise on Kubernetes deployment option separates IT administration and maintenance from GIS administration. Most members of your organization’s GIS will notice no difference when using ArcGIS Enterprise on Kubernetes versus Microsoft Windows or Linux. Each deployment option offers the centralized, intuitive ArcGIS Enterprise portal and the GIS services that power maps and apps.

In short, consider some of the following recommendations:

Kubernetes deployments of ArcGIS Enterprise are generally a better fit for organizations that already have an organizational investment in Kubernetes, including skilled staff support and organizational standards for deployment
Windows and Linux deployments may align to other organizational standards related to security, upgrades, patching or other enterprise-wide requirements.
While most features are fully comparable, not all ArcGIS Enterprise-based functionality applications are available on ArcGIS Enterprise for Kubernetes. See the release blog post for more details.

Windows or Linux?

Most organizations run a mix of workloads across Windows, Linux and other operating systems or deployment patterns. Both Windows and Linux families of operating systems are fully supported and can run ArcGIS Enterprise effectively. Esri technical support analysts are well-versed in both operating system types, and the vast majority of applications and experiences are supported across both systems. Specific operating system requirements for Windows and Linux are provided in the ArcGIS Enterprise documentation.

Key differences between Windows and Linux deployments of ArcGIS Enterprise include:

Server Object Extensions and Interceptors (SOEs and SOIs) written with the .NET version of the ArcGIS Enterprise SDK can only be deployed to Windows-based ArcGIS Enterprise deployments of ArcGIS Server.
Certain ArcGIS Server extensions, including Data Interoperability for Server and Production Mapping for Server, are not supported on Linux operating systems. Other extensions such as GeoEnrichment Server or Maritime Chart Server, recently added Linux support, so use of a recent operating system is required.
Single Sign On scenarios using Integrated Windows Authentication (IWA) require a Windows operating system for ArcGIS Enterprise.
Some Python-based tools may expect Windows-specific or Linux-specific modules or libraries, and may work on a developer’s system which runs Microsoft Windows but fail when published to a Linux-based ArcGIS Enterprise environment due to missing standard libraries.
When troubleshooting data source issues such as connections to file shares or databases, validation and detailed troubleshooting is generally more difficult on Linux as ArcGIS Pro cannot be installed on the system to test any functionality. Troubleshooting through OS-specific tools or Python libraries and arcpy can be used to assess connectivity.

When selecting which operating system family to use for an organization, consider some of the following best practices guidance:

The experience your organization has with a certain operating system should guide your decision. For example, if most enterprise applications run on Windows, choosing a Linux-based system may lead to operational challenges as there are fewer IT staff able (or willing) to assist with the maintenance of the systems. If your operating system is out of sync with the organizational standard, the odds of missing patches, key maintenance and security monitoring are higher.
When choosing a specific version of an operating system (or flavor with Linux-based systems), try to align to existing organizational guidance, and choose as recent of a version as possible, without conflicting with organizational support.
Globally, there are a significantly larger number of deployments of ArcGIS Enterprise on Windows than on Linux, though it is generally true that larger, more complex systems are more likely to run on Linux. This overall disparity may affect availability of experienced staff support, especially for global customers with local language support.
The system engineers that support your enterprise ArcGIS system with troubleshooting, patching, installation, and upgrades should be very familiar with the selected operating system, as each of these steps, especially troubleshooting, will be significantly faster if the staff supporting that step are comfortable with the selected OS.

Relational database provider

Most deployments of ArcGIS Enterprise that use a relational database choose either SQL Server, Oracle or PostgreSQL (with specific software install requirements provided for each type in the ArcGIS Enterprise documentation). Other supported database providers include DB2, Dameng, Teradata and SAP HANA, which are generally used in organizations who already have a significant investment in that system or provider. At a broad level, ArcGIS is designed to work equally well across each different database type as there is no single better or faster provider to select. An enterprise geodatabase can be successfully created, used, and optimized in any supported system.

In general, the best recommendation is to use a database provider that your organization already supports, especially if there are staff available to assist with DBA skill sets. Many deployments of ArcGIS, especially those with a focus on large data access or editing, require specific DBA support to assist with tuning, troubleshooting, security, and storage decisions, so aligning your choice of database provider to the availability of support is a best practice.

If your organization supports multiple database types, consider which system your team may have more experience with, or whether there is a cost or version availability constraint that might help to make the decision. Also consider the use of query layers to connect to other databases that may contain useful business data.

Data storage strategy

ArcGIS systems connect to many different types of storage, further detailed in the Data section of the ArcGIS overview. In many scenarios, data owners and publishers will need to decide whether to host data in an existing database or system or use an ArcGIS-managed component like the ArcGIS Data Store. These two components offer many similar features with several notable differences, which are covered in additional depth in the Data in ArcGIS: User Managed and ArcGIS Managed technical paper.

Additional information about data store types is also available in the ArcGIS Enterprise documentation.

Commercial cloud provider

As covered in the Working with cloud providers section, when deciding on an implementation location or provider, organizational experience is more important than specific features or preferences.

When deploying ArcGIS software to the cloud, whether this system is the first cloud deployment for an organization or their fiftieth, the experience of the staff that are involved is an important contributor to success. This means that if your Enterprise IT organization already has significant experience with AWS, it may make sense to propose your ArcGIS Enterprise deployment be based in AWS, rather than Azure. Or if your team has experience automating deployments with Azure DevOps pipelines, it works best to go along with that process so that you can benefit from their experience and best practices.

Authentication methods or providers

Similar to the topics above, selecting an authentication provider or technology should generally be guided by existing organizational preferences and policies, such as a preference for SAML or OpenID Connect, as well as a preferred provider, such as Azure AD, PingFederate or Okta. Additional recommendations include:

While web-tier authentication like Integrated Windows Authentication may work well within a network, most systems now incorporate external access or non-corporate devices, which may have a harder time with a web-tier authentication pattern.
Ensure that all of your users will be able to reach authentication endpoints when needed. For example, an organization may offer both an internal SAML and external SAML identity provider – when workflows include mobile applications, unless the devices are constantly on a VPN connection use of the external IdP is preferred.
Changes to authentication method or provider can be disruptive but are generally less disruptive when using SAML (where the user’s NameID or username can be defined through a combination of attributes).