Back to Top

Using system patterns

The ArcGIS system patterns are abstractions of geospatial systems commonly implemented with ArcGIS software and services. They are not systems themselves and should not be deployed and used as is.

To reinforce this point, let us consider a different type of pattern: a sewing pattern for pants. In designing a pair of pants, you might start with a proven or popular pattern. You probably then pick out a fabric, and scale it to the target size. Using the pattern, you then tailor the pants to target user, and adjust some of the finer design elements like pockets, closures, and belt loops. In the end the pants you’ve designed bear little resemblance to the original pattern, though a trained eye might recognize that one was derived from the other.

ArcGIS system patterns are similar. Instead of fabric you’re choosing infrastructure. Instead of tailoring the legs to fit a person, you’re tailoring the system to fit the business and IT needs. There are many choices to make in designing systems based on system patterns, much as there are when designing pants from sewing patterns. Some decisions you may expect to make in designing your system include (but are not limited to):

  • Selecting a deployment pattern that aligns with your organization’s business and IT needs.
  • Tailoring the system design to meet the organization’s non-functional requirements in areas like reliability, security, performance, and scalability.
  • Planning for and designing integrations between the new system and other, existing systems.
  • Selecting architecture components and supporting infrastructure, such as cloud providers, operating systems, and data stores,
  • Designing a physical architecture aligned to your infrastructure choices, including compute, storage, network, security, and others.
  • Planning for automation needs for system deployment and operations.

For more on the system and solution architecture process see architecture practices of the ArcGIS Well-Architected Framework.

Working with multiple system patterns

In many cases a single system pattern can be used as the basis for a system. This is true for the data editing and management system examples shown earlier, as well as most examples presented in the system pattern overview pages. But there are also cases where the needs of a system cannot be met by one system pattern alone; the capabilities from multiple system patterns are required.

As we begin to explore this concept, let us consider the three primary approaches to realizing systems from system patterns:

Working with multiple system patterns

  1. System. Create a system from a single system pattern. This the main approach described throughout the system patterns section of the ArcGIS Well-Architected Framework.
  2. Systems integration. Leverage the capabilities of more than one system pattern by implementing multiple systems, each derived from its own system pattern, and then integrating those systems. A common example of this is a system providing enterprise-wide capabilities, for example a location services system, that is implemented as a singleton system that provides location services to other GIS systems via services-level integration. There are numerous integration options that can used with this approach, including shared identities and content synchronization using partnered and distributed collaboration. For more information, please see the integration pillar of the ArcGIS Well-Architected Framework.
  3. System composition. Implement a single system that includes capabilities from more than one system pattern by incorporating components from each system pattern into the system architecture. In composing systems there are components or infrastructure that are shared between system patterns, consequently this approach typically only applies to Windows, Linux, and/or Kubernetes-based system. This approach is described in more detail below.

The system integration and system composition approaches are used when the capabilities of multiple system patterns are required. The decision to implement and integrate two systems or implement a single, composite system may involve many factors, including, but not limited to, reuse of capabilities across the enterprise, deployment, infrastructure, and physical architecture considerations, as well as IT governance practices within the organization.

Related resources:

Additional resources

Once you’ve identified one or more system and deployment patterns of interest, consider the following resources to learn more:

Top