Extend ArcGIS with SDKs and APIs

ArcGIS systems are usually built on a stable foundation of existing, well-understood software components. These components can be deployed in a variety of ways, configured to support workflows and requirements, and for many systems, the existing applications, services, tools and features are sufficient. In other cases, the requirements or design criteria may require software or workflow customization to achieve, and the ArcGIS platform provides a variety of software development kits (SDKs), scripting and automation engines, and application development interfaces (APIs) that can help to achieve these goals. The Esri Developer site provides comprehensive documentation and guidance on some of these APIs and SDKs, along with documentation of the other REST APIs and features of the foundational ArcGIS components.

Some projects and teams might start a design process with a clear idea of the role of software development or customization, where other design processes may highlight the need for customization through the review of requirements or later steps in the design process. In either case, a clear approach is important to deciding how, and where to extend ArcGIS.

Decision criteria for application customization

The decision to add custom software development to a project has a range of implications, advantages, and considerations. It is best to think of the role of development in ArcGIS systems as a spectrum with valuable options throughout – ranging from primarily out-of-the-box systems which are lightly configured through popup configurations, Arcade scripts, or other techniques, through Python-enabled workflows for data movement or geoprocessing, to extensible low-code apps that support adding Arcade, CSS and HTML to the interface, and leading to fully customized systems with a carefully designed frontend, custom web services and significant data and process automation.

This spectrum can be broken down many ways, but one way to look at it is through three main approaches:

• Configure apps to meet your business needs. ArcGIS provides a set of configurable apps that support basic to advanced workflows with straightforward, browser-based configuration experiences. Using these apps requires the least effort and the lowest ongoing cost but can be limited by what configurations are supported. Apps in this category include Instant Apps, Story Maps, Dashboards, Field Maps or Survey 123.
• Use low-code app builders. Esri offers a variety of app builders that include a low-code experience, including ArcGIS Experience Builder, StoryMaps, Dashboards, ArcGIS Hub, Enterprise Sites and ArcGIS Instant apps. These apps all allow for the configuration of some degree of custom HTML and CSS, along with different implementations or profiles of Arcade, and can be used to build carefully tailored, brand-aligned applications that have the look and feel of a fully customized application while retaining the option for quick changes or adjustments to functionality. Experience Builder also allows for the creation of custom widgets, which can be developed and then made available for use across multiple different applications.
• Fully customize apps using ArcGIS SDKs. Esri builds SDKs for a variety of programming environments and languages, each of which provides robust support for building map and data-driven applications containing ArcGIS layers, UI interactions, secure authentication, and complex mapping functionality. Because you don’t have to code each of these specific parts yourself, you can build business-focused apps to take advantage of the ArcGIS capabilities available in your organization, reducing the overhead for app development and maintenance. The Esri Developer site provides comprehensive information on the selection of SDKs that are available along with common workflows, functionality descriptions and sample code. Esri also provides a series of app components to ease web development through standardized UI approaches.

There is no single best choice along this spectrum from configuration to full development, the decision should be based on the capacity of the team for development, the organization’s architectural philosophy towards customization, and the understanding for the long-term implications for any decisions made in this area.

Common software development motivators and factors

With a wide spectrum of customization and software development options, it is important to also understand some of the motivations for pursuing one of these options, each of which can contribute to a different set of decision-making criteria about what customization or extension approach might be suitable.

• Functionality and integration motivations primarily relate to lack of specific functionality in an existing app or workflow, or a need to support an integration with another system which an existing app does not exist for. Another motivator is the desire to bring multiple sets of functionality into a single unified interface.
• Performance and scalability. If the performance of existing services, interfaces or workflows doesn’t meet your requirements, it’s possible that a customized option may introduce new options to achieve the desired level of service or bring in a shortcut to a process that saves significant time and improves user satisfaction.
• Design. If an application needs to be branded beyond what the styling and theme offerings of existing ArcGIS apps support, a custom application may be able to achieve the specific interfaces or design goals of the organization. The Esri Calcite Design System is one common foundation for well-designed and usable interfaces.
• Audience and user experience. Usability is a key success criteria for most application design efforts, and understanding the different needs that different user groups have for functionality is an important step. Guided workflows can help even experienced users find their way from opening the app to being productive as quickly as possible.
• Organizational culture and capability. Your organization may have preferences or a tendency towards certain ways that development is used in the application design process. Leadership, project management, and technical teams may have preferences, muscle memory, or relevant experience making a decision about customization options, and may use this to inform decision making for a new opportunity. Carefully considering the capacity of the organization to take on a customization, and the maintenance of that work, as well as the not insignificant maintenance of heavily-configured apps, will ensure that intentional choices are made that set your application up for future success.
• Cost. No process of building an application happens without cost, and it is important to not default to an expectation that customization has a higher cost – a fit for purpose app may have a longer and more successful lifespan than a configured application, depending on the configured application lifespan, required functionality and expected changes. Cost considerations should take into account the initial build costs but also the ongoing maintenance and any risks introduced by the decision.
• Lifespan. Apps should not be designed to be used forever – a healthy replacement interval, where other options or approaches are considered, ensures that new application options are not ignored, and an existing app is not allowed to continue on indefinitely when a better option may exist. In some cases, updating a custom application is a simple as pulling in a new version of an SDK, but other updates may be more significant or may lead to a larger investment depending on the timing of the initial app development and the life cycle of the SDK used to build it.

Best practices for working with SDKs and APIs

When software development will play a role in the creation of an application or the construction of a system, a few best practices can be applied to most scenarios:

• Use tools that are familiar to the team – your organization or team of collaborators may have experience with specific languages, software development methodologies, or ways of building applications, and it is beneficial to follow these existing patterns in most scenarios. This supports efficiency by relying on existing skills, learning from previous experiences, and not asking the team to take on new technology simply for the sake of novelty.
• Stay current with the latest release – like the foundational software components, ArcGIS SDKs and APIs are updated regularly, and it is a best practice to stay aligned to the latest releases of any of these products, as they incorporate new functionality alongside security enhancements and performance improvements. With each release, Esri carefully documents new features and any breaking changes to help developers stay on the lates releases with as little disruption as possible.
• Develop with the Architecture Pillars in mind – the architecture pillars described in this section are equally relevant to software development-driven systems as they are to more out of the box systems. Consider the importance of security, performance, scalability and observability as you develop a new application or feature, to ensure that the resulting application can be supported and effectively operated by the team for its intended lifespan.

Summary

Extending ArcGIS, either through customization of existing interfaces or building new applications with ArcGIS Maps SDKs, provides an excellent option for achieving some of the goals above. During the design process of an enterprise system, carefully considering the relevance of extending and customizing to the solution at hand can have a significant impact on the future delivery and cost of the system. When in doubt, consider organizational capabilities and readiness, as to whether an existing experience or custom solution (or most commonly a combination of the two) may be a better fit.