Back to Top

Selecting a deployment pattern for mobile operations and offline data management systems

Mobile operations and offline data management systems are typically deployed using one of three deployment patterns:

Selecting a deployment pattern is one of the most important decisions to make in designing a GIS system for your organization.

Perhaps the most critical factor in this decision will be aligning with your organization’s IT principles, guidelines, and comfort-level in supporting different deployment approaches. For example, some organizations may prefer to standardize on SaaS-based systems and solutions. Other organizations that are investing heavily into Kubernetes-based deployments, including hiring and training staff with operational Kubernetes experience and skills, may prefer Kubernetes-based deployment patterns.

Note:

The capabilities as well as the considerations differ between deployment patterns. Review the comparisons below, along with the deployment pattern pages for additional information.

For general information and considerations around these deployment approaches see the ArcGIS products and deployment options page of the ArcGIS overview.

Capability comparison

In addition to aligning with your IT principles, guidelines, and comfort-level, it’s also important to consider the capabilities of each deployment pattern in your decision-making process. The capabilities of a mobile operations and offline data management system differ between deployment patterns. The following matrix compares the specific capabilities supported by each of the deployment pattern.

Capabilities used in a mobile operations and offline data management system, but typically provided by other systems, such as basemaps, geocoding, and other location services provided by a location services system are not listed below. Learn more about related system patterns.

Capability SaaS Windows/Linux Kubernetes
Mapping and visualization
Offline data and maps
Basemaps
Geocoding
Route and directions
Work assignment and dispatching
Location sharing
Data editing
Data import and export
Data interoperability and transformation1  
Edit tracking and auditing
Short transaction management
Long transaction management   2 2
Spatial and attribute rules   3 3
Data distribution and replication
Data archiving and history  
Advanced data validation    
Workflow management and automation 4 4,5
Hosted Python notebooks 6  
Parcel management   5
Roads and highways   5
Pipeline referencing   5
Indoor GIS7
Indoor positioning
Other industry solutions8

Full support

Partial support

  1. ArcGIS Data Interoperability for ArcGIS Pro supported in all deployment patterns ↩

  2. Supported in back office system, not on mobile devices ↩ ↩2

  3. Rules applied when data is synchronized with the back office system ↩ ↩2

  4. Requires ArcGIS Workflow Manager Server ↩ ↩2

  5. Requires some Windows/Linux infrastructure ↩ ↩2 ↩3 ↩4

  6. Requires ArcGIS Notebook Server ↩

  7. Full capability spans multiple system patterns ↩

  8. Some industry solutions only available on SaaS ↩

See the mobile operations and offline data management system capabilities for more information on each row listed above. Additionally, each of the cells above is described in more detail in the mobile operations and offline data management system deployment pattern pages.

The capabilities represented above reflect those available as of June, 2024.

General considerations

The considerations below aim to help align your organization’s business and IT needs with the appropriate mobile operations and offline data management system deployment pattern. The information presented here is not meant to be exhaustive, but rather highlights key considerations for mobile operations and offline data management systems.

  • Scalability, reliability, service level agreements (SLA), security, and the balance of responsibility between your organization and Esri tend to be major factors in selecting a deployment pattern. Please see the reliability, performance and scalability, and security pillars for more information.
  • Organizations with a moderate-to-large editor workforce or who have needs for long transactions, conflict detection and reconciliation, spatial and attribute rules, as well as archiving and advanced auditing or edit lineage tend to favor an ArcGIS Enterprise-based deployment on Windows, Linux, or Kubernetes. These two deployment patterns offer the most robust data editing and management capabilities and allow for flexible alignment with workflows and governance needs.
  • The SaaS deployment pattern using ArcGIS Online features the quickest time to market.
  • Some of the more advanced, specialized, and/or industry-specific capabilities of mobile operations and offline data management systems only exist for a subset of deployment patterns. Please review and consider the capability comparison and deployment pattern pages thoroughly in your design and decision-making process.
  • PaaS deployments of mobile operations and offline data management systems are not supported at this time, as PaaS and ArcGIS Location Platform does not currently support taking data and maps offline. For mobile workflows that don’t require offline support, and that can rely on a consistent network connection, explore other ArcGIS system patterns.
  • Mobile operations and offline data management systems rely heavily on location services provided by a location services systems. The deployment of your location services system(s) should be taken into consideration when designing a mobile operations and offline data management system. Additionally, special consideration may be required for location services intended for use offline, such as basemaps, geocoding, and routing. Learn more about offline maps, offline data, and offline applications in general.

Selecting a deployment pattern is one of the most important decisions to make in designing a GIS system for your organization. However, it is not the only one. There are many additional factors to take into consideration when designing your system, including areas like security, reliability, and integration. As such, please don’t consider the information provided here to be exhaustive. Please review the architecture practices and pillars of the ArcGIS Well-Architected Framework, as well as product documentation, in detail as part of your design process.

Top