Today, we are seeing explosive growth in computing platform(s). The goal of a platform is to allow developers to design and build software applications to support unique workflows out of ready-made components, functions, and content available from a platform. Any discussion about trends in computing will include mention of a platform. But, this is not really new for GIS. The basic characteristics of a platform have existed in Esri® GIS for many years and are leveraged by Cityworks.
In 1987, I was tasked with researching GIS software and choosing the GIS that should be adopted by the University of Utah Department of Geography’s DIGIT Lab to support instruction and research. At that time, there were many GIS choices. It was not yet clear that Esri would become the dominant GIS platform. I spent nine months learning about various GIS. I gravitated towards Arc/Info® because it contained a high-level macro language called AML (ARC Macro Language) that end users could use to create applications.
AML provided the ability to create on-screen menus, use and assign variables, control statement execution, and get and use maps. I believed the ability to extend Arc/Info to meet specific end-user workflow needs was a critical characteristic necessary for an organization to realize maximum benefits from their investment in GIS. In the late 80s and during the 90s, federal, state, and local government agencies used AML extensively to create applications that supported workflows for their unique needs.
At the most basic level, what set Arc/Info apart from other GIS was what we now call platform qualities. “A computing platform is, in the most general sense, whatever pre-existing environment a piece of software is designed to run within, obeying its constraints, and making use of its facilities.” Using AML, software developers designed applications that ran within the pre-existing Arc/Info environment to call command line routines that obeyed constraints and extended its capabilities for specific end-user workflow needs—a platform.
From 1991–1992 we used AML at the University of Utah DIGIT Lab to create one of the first interfaces between a work order system and Arc/Info for Salt Lake City Public Utilities. Soon, we were asked to do the same for other organizations. In late 1995 and early 1996, ArcView 2.1 was released as a beta software. It contained an extensible framework using Avenue scripts. We realized that a basic framework existed for creating a maintenance management system as an extension of ArcView®, with the geodatabase as the asset inventory; that is, Esri GIS as a platform could be extended to become an integral tool to help local governments manage their assets. Cityworks and the GIS-centric approach was born.
The Cityworks GIS-centric approach uses ArcGIS for more than just application development. The GIS-centric approach utilizes the ArcGIS geodatabase as the authoritative data and system of record for local government assets without redundancies, constraints, or proprietary claims. In other words, Cityworks is configured to use the geodatabase as the asset inventory. ArcGIS provides tools necessary to maintain an inventory of local government assets and to use geography for analysis. Cityworks provides tools for managing and tracking the work that regulates local government assets. This approach delivers immediate and tangible benefits, including simplifying the process to maintain an asset inventory and eliminating the need for data-syncing interfaces and associated data normalization challenges.
Just as ArcGIS has grown, Cityworks has grown to become a platform. The Cityworks platform works in tandem with the ArcGIS platform to manage local government assets—a platform-on-platform design. Application developers can access ArcGIS and Cityworks to design and build applications that support unique end-user workflows. Access to the Cityworks platform happens with APIs (Application Program Interface), often referred to as Web APIs because accessibility to the APIs is through web communication protocols. Most commonly, Web APIs are accessed by URL (Universal Resource Locator) and HTTP (Hypertext Transfer Protocol) request-response. The client, a browser or mobile device, submits a URL-HTTP request to an API residing on the platform server located on-premises or in the cloud. The platform server provides resources such as data content and functions, returning a response.
Today, we are seeing explosive growth in computing platforms and parallel rapid growth in the GIS-centric platform. Application development using the GIS-centric platform approach can send requests for resources and receive responses from ArcGIS, Cityworks, and any other system. To be part of the GIS-centric platform, the asset data used by the organization and by the application must reside in the Esri geodatabase. The geodatabase is the authoritative data and system of record for local government assets without redundancy, constraints, or proprietary claims. This assures that all of the systems have equal and unfettered access to the same asset data.
Developers are designing and building software applications to support unique workflows out of ready-made components, functions, and content available from ArcGIS, Cityworks, and other systems. Trimble, Esri Canada, Freeance, Innovyze, GeoCortex, CompassCom, Sedarū, and CitySourced are some of the Cityworks and Esri partners using the GIS-centric platform. There is no limitation to how the GIS-centric platform can be enhanced with content, functions, or ready-made components, including using Esri’s ArcGIS Online content and applications to add even more value to any on-premises implementation. The GIS-centric platform is real and providing platform-on-platform unique application solutions for particular workflow needs.