Enterprise GIS is the implementation of GIS infrastructure, processes and tools at scale within the context of an organization, shaped by the prevailing information technology patterns of the day. It can be framed as an infrastructure enabling a set of capabilities, and a process for establishing and maintaining that infrastructure. Enterprise GIS facilitates the storage, sharing and dissemination of geospatial information products (data, maps, apps) within an organization and beyond. Enterprise GIS is integrated into, and shaped by the business processes, culture and context of an organization. Enterprise GIS implementations require general-purpose IT knowledge in the areas of performance tuning, information security, maintenance, interoperability, and data governance. The specific enabling technologies of Enterprise GIS will change with time, but currently the prevailing pattern is a multi-tiered services-oriented architecture supporting delivery of GIS capabilities on the web, democratizing access to and use of geospatial information products.
[12/11, 1:09 PM] teqportecloud: Enterprise GIS is the implementation of GIS infrastructure, processes and tools at scale within the context of an organization, shaped by the prevailing information technology patterns of the day. In common use, the term “Enterprise GIS” describes both the process to establish GIS as a scalable function within an organization that supports its particular needs, and also the technological artifacts of such an implementation. In the present context, we will consider both these dimensions of Enterprise GIS.
The conceptual foundations of Enterprise GIS, including its objectives, rationale and desired outcomes, as well as the planning processes necessary to establish it within an organization, have remained fairly durable over time, but the technical nature of a particular implementation of Enterprise GIS, as defined by programming patterns, hardware and software tools, and architectures will change, sometimes dramatically, co-evolving with advances in the enabling technologies.
As a Noun, Enterprise GIS is “A geographic information system that is integrated through an entire organization so that a large number of users can manage, share, and use spatial data and related information to address a variety of needs, including data creation, modification, visualization, analysis, and dissemination.” (ESRI 2007). This definition necessarily encompasses the people, processes and technology by which geospatial data, maps, apps, and tools are integrated into and deployed within the context of an organization. As it describes a system implementation pattern, this definition is (or should be) both technology and vendor-neutral. As such, an enterprise GIS is not a product that can be purchased, but rather organically established within an organization via the “process” focused framing of the term as described below.
As a Process, Enterprise GIS encompasses the planning, management, and iterative improvement steps that are undertaken in the context of an organization to identify the functional requirements of an organization, translate business needs into geospatial information products, build a well-performing technical infrastructure to deliver and disseminate those products, and integrate it into an organization’s business processes and culture. In this sense, “Enterprise GIS” is something that GIS Managers and System Architects do, not just build. The “canonical” descriptions of a process oriented approach to GIS are found in Tomlinson (2005) and expanded by
Dr. Roger Tomlinson (2005) offers a planning methodology for GIS in the context of an organization, divided into 9 discrete, mostly sequential steps.
Consider the strategic purpose.
Plan for the planning.
Conduct a Technology seminar.
Describe the information products.
Define the system scope.
Create a data design.
Choose a logical data model.
Determine system requirements.
Benefit-cost, migration and risk analysis.
Make an implementation plan.
This process resembles the “waterfall” approach familiar in Software Engineering, insofar as it prescribes the identification of business use cases and processes as a prerequisite to operational definition of geospatial artifacts to create and technical specification of a system for their delivery. Although subsequent cultural shifts in information technology and programming have tended towards more iterative, agile approaches, this planning method has been the touchstone reference for many Enterprise GIS implementation projects, and the presence of, or adherence to such a process is one determinant differentiating “GIS” from “Enterprise GIS.“ Tomlinson’s methodology underscores the point of securing buy-in from projects stakeholders and eliciting functional requirements in order to properly situate a GIS implementation in an organizational context.
In “Building a GIS,” Peters (2012) expands upon the technical GIS system design phase of the Enterprise GIS implementation process (the eighth step in Tomlinson’s GIS planning methodology), with a particular focus on Esri GIS software, and on the performance of Enterprise GIS database, web and application server-tier infrastructure layers. Conceptually, he argues for an integrated approach encompassing concurrent user needs assessment and system design,which he refers to as “System Architecture Design.”
3. Scale Considerations
Roger Tomlinson (1933-2014), widely considered to be the “father of GIS” and a visionary in the field of planning for GIS implementations within an organization, describes the breadth and reach of an Enterprise GIS within an organization as follows:
“Enterprise-wide systems are broader in scope, allowing employees to access and integrate data across all departments of the organization. Here, fully aligned with the organization’s mission, GIS takes a more versatile, active role. The objective is for GIS to boost an already active strategic direction, supporting the entire organization over the long haul. Enterprise GIS addresses the business needs of many or all departments, becoming a powerful tool inside the organization as a whole.” (Tomlinson, 2007, 3)
From this framing, we may identify both breadth of scope, as well as embeddedness within the organizational context, as technology-neutral defining characteristics of an enterprise GIS. While Dr. Tomlinson situates the “Enterprise” scale as an implementation context bookended by “Departmental” and “Community/Federated systems,” for the purpose of expositional clarity, “Enterprise” GIS in the present discussion shall be taken to mean all GIS implementations above the departmental scale.
4. Business Process Integration and Sensitivity to Organizational Context
Perhaps the single attribute of an “enterprise” GIS setting it apart from local or departmental implementations is its level of integration with the business processes of an organization. Indeed, this emphasis on organizational context and embeddedness within the culture – a level of buy-in and investment from all relevant stakeholders – is the core of the definition adopte Thomas (2009). In his formulation, GIS has reached the “enterprise” level when it bridges divides between organizational silos, and through its pervasive application has increased the extent to which the user base internalizes a “we” as joint owners of the system.
A value-adding and defining point of an enterprise GIS is to provide geospatial information products to disparate information systems. This interoperability requires both an understanding of extant business processes (where are the systems of record?) and an ability to bridge both organizational and technological silos to meet users “where they are” with the information products they need. A successful Enterprise GIS is organically cultivated within an organizational context, responsive to its needs, and co-evolves with its mission and purpose, as well as keeping pace with changes in the enabling technology.
Underlying the enterprise GIS-as-process stream of thinking is the concept, eloquently framed by Campbell (1999), that the success of a GIS implementation is conditional upon factors specific to the organizational context in which it is undertaken. Using a “social interactionist” framing of the experience of GIS adoption within an organization, Enterprise GIS implementations are strongly influenced by organizational cultures and technological solutions are molded by context (Campbell, 1999). This theoretical perspective indeed informs the prevailing wisdom of the GIS planning process, advanced by Tomlinson and his contemporaries, that user requirements and business processes must be well understood to properly operationalize and secure buy-in for a GIS to become successful at the Enterprise level.
5. Functional Capabilities
Organizations implement Enterprise GIS because they need access to a certain set of capabilities not enabled by standalone GIS, or GIS with limited interoperability. These capabilities are a function of system scale, sophistication, and interconnection, and they include, but are not limited to:
Centralized Storage of Geospatial Data.
This “back end” component of an Enterprise GIS enables organizations to consolidate data that may have been previously distributed across functional areas into a highly available system of record. Advantages to this pattern include increased data durability and availability, support for multi user editing, ease of backup and recovery, and facilitated compliance with service-level agreements (SLAs) or regulations pertaining to data locality and security controls.
Securing Sharing and Dissemination of geospatial data, maps, apps and tools.
An Enterprise GIS can be more easily integrated into centralized identity management infrastructure than a loose federation of disparate systems of record. This is true at all logical tiers of the application layer architecture: database, middleware, application server, and web. Depending on the implementation pattern, interdepartmental data sharing may occur at the database level, at the level of web services, at a portal tier, or the application level. Best practice IT remains, and has been for some time, to defer to central identity management authorities such as Single Sign On, eliminating the need for a component of the Enterprise GIS to handle sensitive credential information and from the users’ standpoint, eliminating an extra credential. This is far more easily facilitated in an Enterprise GIS setting.
An Enterprise GIS infrastructure, once designed and implemented, is not a static set of technology artifacts. Operating system and application software must be updated as needed, and often times advances in technology or major version updates to GIS application software will necessitate the re-architecting of part, or perhaps all, of the Enterprise GIS. Hardware (physical or virtual) will have to be upgraded periodically, and the planning for the Enterprise GIS needs to accommodate such lifecycles while minimizing disruption. Additionally, configuration management, infrastructure as code, and other patterns and practices under the conceptual umbrella of “devops” can help the operators of an Enterprise GIS increase the resiliency of their systems and avoid the inordinate complications of periodic maintenance, and frequently, deferred upgrades, associated with one-off “snowflake” systems.
Certainly, the scaling-up of any information system to the “enterprise” scope increases its profile, and less fortunately, its attack surface. While a full treatment of the myriad of security best practices surrounding Enterprise GIS is beyond the scope of the current discussion, security needs to be considered from the initial stages of system planning all the way through its lifecycle. Generally, security guidance can be grouped into the (fairly industry standard) set of best practices for securing operating systems, GIS application-specific security considerations, and finally access control for an organization’s data. This last item is likely to be the foremost concern of an organization’s leadership and data steward community, as the exposure of sensitive data can be associated with physical or reputational harm. Access control policies and standard operating procedures should be formalized (this is also a data governance consideration – see below) and the tools and processes to implement these procedures (Single sign on, end-to-end encryption, protection or redaction of sensitive data, etc) should be leveraged. An additional concern when using cloud services is the concept of data locality *(where the data resides) which is distinct from information security *(the controls we place on information and systems irrespective of where they reside). Depending on the data, certain security controls may be prescribed by regulation or law.
Perhaps the most frequently neglected topic associated with the ongoing health of an Enterprise GIS is data governance – the processes, standards, and delegation of responsibilities associated with the preservation of the integrity, access, and quality of data. This is a well-trod area within ERP and other enterprise system domains, but receives less consideration in the geospatial domain, owing in part to the fact that, in many organizations GIS data collection began in siloed departments, and the obscurity of the data, or an air gap between it and the rest of the organization’s systems, precluded consideration of how that data should be shared and safeguarded in an Enterprise GIS context, where the technical capability exists to share the data within and beyond the organization. Standards and policies need to be built around the technical capabilities of an Enterprise GIS, in order to formalize and operationalize the extant business procedures for the management of data, or create them if none have been explicitly considered. Such policies might include formal assignment of data stewardship responsibility to functional areas, a standard for what constitutes “sensitive” data, change management processes, and standard operating procedures for safeguarding data (a great example of this is found in FGDC, 2005). In short, the “policy layer” is a critical component of an Enterprise GIS, enabling it to faithfully mirror organizational policy, and preserve the trust and buy-in of stakeholders concerned about data quality, integrity and access control.