Extend ArcGIS with SDKs and APIs
When designing the architecture of ArcGIS systems, the process usually starts with, or builds on a stable foundation of existing, commercial off the shelf (COTS) software. These components can be deployed in a variety of ways, configured to support workflows and requirements, and for many systems, these capabilities are sufficient. In many designs and systems, however, the option to customize functionality is often considered. 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.
Decision criteria
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 COTS-based 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 ending with 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 options is through three main approaches:
- Configure COTS apps to meet your business needs. ArcGIS provides many configurable COTS apps that support basic to advanced workflows out of the box. Using these apps requires the least effort and the lowest ongoing cost, but can be limited by what configurations are supported. ArcGIS COTS Apps include Experience Builder, Story Maps, Dashboards, Field Maps or Survey 123 are all good examples of applications in this category.
- Use low-code app builders. Esri offers a variety of app builders, including ArcGIS Experience Builder, StoryMaps, Dashboards, ArcGIS Hub, Enterprise Sites and ArcGIS Instant apps. These apps all allow for the configuration 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 support for 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 ArcGIS COTS capabilities, reducing the overhead for app development and maintenance. The ArcGIS Developers 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, 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.
- 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 COTS configurations, 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.
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 a COTS or custom solution (or most commonly a combination of the two) may be a better fit.