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.
- Defining Enterprise GIS
- Scale Considerations
- Business Process Integration and Sensitivity to Organizational Context
- Functional Capabilities
- Intersection of Enterprise GIS and Information Technology
- Enterprise GIS Today
- Logical Model of Enterprise GIS Components
API: Application Programming Interface. A set of specifications for functions, objects, data structures and communications protocols that facilitate reuse of code and enable programming at a high level of abstraction. Web GIS and SOA makes extensive use of APIs.
Cloud: Someone else's computer.
Enterprise Architecture: The practice of strategic assessment and modeling of business processes, data needs and technology within the context of an organization to produce a comprehensive IT vision and implementation plan to implement the most appropriate technology solutions to help that organization meet its objectives.
Enterprise GIS: 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: Information Technology. The enabling computer and network technology upon which GIS is built. Also, ICT (Information & Communications Technology).
OGC: The Open Geospatial Consortium, a standards body for geospatial data and services.
PaaS: Platform as a Service. Compute, Storage and other low-level resources are abstracted away, but customers at this tier still operate and directly interact with discrete virtualized computing systems running on cloud infrastructure to run their workloads.
REST: Representational State Transfer, a web services specification.
SaaS: Software as a Service. A cloud implementation pattern in which an entire application is delivered to the customer as a turnkey solution; the customer has no knowledge of, or direct interaction with, any piece of the enabling technology stack below the application level.
SOA: Services oriented architecture. An approach whereby the disparate tiers of an application hierarchy are decoupled at well-demarcated interfaces, communicating via HTTP/HTTPS via protocols such as SOAP and REST.
SOAP: Simple Object Access Protocol, a web services specification.
System Architecture Design: The process and artifact of planning for, and tuning GIS system design, capacity planning, and performance to align with user requirements in the context of an Enterprise GIS implementation.
Web GIS / WebGIS: As a common noun, in the most general sense, refers to the delivery of GIS capability over HTTP Also a proper noun, coined by Esri, to summarize the capabilities of the ArcGIS Enterprise and ArcGIS Online software suite ca. ~2018
Web Services: A standard for communication between software applications in which data is exchanged over HTTP protocols.
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.
2.1 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.
2.2 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 Peters (2012).
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.”
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.
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 adopted by 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.
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:
5.1 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.
5.2 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.
5.3 Web GIS / Internet GIS Capability.
Web GIS is an implementation pattern in which mapping, analysis, data management, collection and other core functions of a GIS are delivered over the web - via HTTP(S) protocols, to browsers and a diverse array of clients (Fu & Sun, 2011). Most significantly, it is a vehicle for the dissemination of GIS information products within and outside an organization. Web GIS has been a transformative influence on the geospatial industry generally, lowing barriers to the use of GIS information products, and making them ubiquitous in society (while simultaneously abstracting away the complexities of the enabling infrastructure). This, then, may be the most visible capability achieved by an organization when it implements an Enterprise GIS, but it is an outcome of, not a substitute for, an Enterprise GIS implementation. The term “Web GIS” can be conflated with “Enterprise GIS”, but Web GIS should be properly understood as a specific set of capabilities, focusing on data dissemination and the delivery of GIS functionality over the Internet, that is enabled by Enterprise GIS-as-infrastructure, the development and architecture which was informed by Enterprise GIS-as-process.
5.4 System Integration.
Not all business processes within an organization can be supported using GIS client software or server components; in most organizations there remain a set of other non-geospatial enterprise information systems that need to provide services to, or consume services from, the Enterprise GIS. (Examples include, but are not limited to, CAD (Computer-aided design), ERP (Enterprise resource planning), BI (business intelligence), document management, and data lakes.) Peters (2012) notes that enterprise GIS implementations will likely involve a significant number of integrations with other information systems. Integrations vary by (for example) whether data is to be copied from one system to another or accessed in place, whether or not the GIS is the system of record, and the layer of the Enterprise GIS software hierarchy at which the disparate components communicate. For example, an Extract-Transform-Load (ETL) process may be used to convert CAD drawings to GIS feature classes, while a materialized view populated by a query across a database link may populate attributes associated with the ETL’d features. Some enterprise systems have RESTful APIs that can be accessed at the level of GIS web applications or server-side data harvesting tools such as the Esri GeoEvent Server. Some Business Intelligence and data analytics packages have the ability to consume web services from a GIS. Some systems have the ability to natively process and render OGC web services. The specific nature of the integrations will depend on a host of factors; suffice it to say for the current discussion that system integration is essential as an Enterprise GIS process to meet users where they are in their business process and effectively interface with the systems they use to get their work done.
5.5 Consolidation of the Enterprise GIS Function within the Organization.
Implementing and operating Enterprise GIS requires a unique skill set. Some of the required qualifications include elements of GIS subject matter expertise (the nature of spatial data, GIS software architectures, GIS client software, GIS programming APIs and tools), Information Technology (Systems administration / cloud services provisioning, performance tuning, system integration, database design and administration), and management (organizational structure and culture, business processes, policies, standards development). The stakeholders of an Enterprise GIS, frequently subject matter experts in their own right, don’t want to master all of these things just to get their work done. There is a significant economy of scale in factoring out the “GIS Server” and “Data Governance” responsibilities to a centrally supported business unit.
The emergence of the Web GIS pattern, and the Enterprise GIS infrastructures and processes that support this capability, have led to the democratization of geospatial:
- data (both access to data, as in publicly available Open Data sites, and its editing, as in crowdsourcing or Volunteered Geographic Information);
- apps (focused views of geospatial information products incorporating business logic and user experiences that meet particular needs);
- tools (geospatial analysis routines can be packaged and presented on the Web as web services, enabling geospatial professionals to deliver their models and business logic to target audiences without the need for specialized software);
- and, indeed, thinking (a “spatial turn” has emerged in many academic disciplines as lowered barriers to the use of GIS analytical processes and visualizations).
As described above, the Web GIS pattern that has caused the geospatial sciences to become pervasive and ubiquitous across many institutions of society is enabled and “powered by” Enterprise GIS infrastructure and processes
The scale considerations associated with an enterprise wide implementation of GIS necessitate it being treated as a coequal “enterprise system” within the context of an organization, and thus implementations of enterprise GIS, as well as their management and operation going forward, tend to be heavily integrated with (and sometimes part of) the information technology unit(s) that support other critical technical functions. In short, as a GIS scales up, it must be approached with the same methodology and discipline afforded any other “enterprise” system within an organization, and that introduces a number of considerations that are more in the wheelhouse of IT than of traditional GIS professionals. The reader should note that each of the dimensions of distinction below between “enterprise” GIS and its smaller-scale counterpart apply more generally outside the geospatial realm as well; these are basic considerations associated with an application or system being scaled up to an “enterprise” scope. What follows are considerations, which require a greater knowledge of and interaction with IT, than would be necessary in the context of a standalone GIS implementation.
6.1 Performance Considerations
As GIS information products are accessed by a wider audience, care must be taken to ensure that the systems supporting those workloads are appropriately sized, in terms of compute capacity, storage capacity, and network capacity. The Enterprise GIS-as-process subdiscipline of System Architecture design aligns GIS user requirements analysis with the sizing of system components (Peters, 2012) and sophisticated tools and methodologies exist to plan for sufficient CPU, memory and storage to handle anticipated workloads. Of course, it is not always possible to plan for every contingency. A key value-adding point of Platform-as-a-Service cloud providers, such as Amazon Web Services EC2, is the ability to elastically scale infrastructure to meet increasing, bursty, or unanticipated user traffic. Sizing infrastructure for performance considerations, whether an organization is purchasing hardware, stamping out a virtual machine in their datacenter or purchasing public cloud services, comes with attendant costs: either one must invest the capital expenditures up front to provision sufficiently robust infrastructure to meet anticipated demand, or else pay a variable operating expenditure to receive the elasticity benefits of a public cloud service. Uptime and reliability also become concerns in an Enterprise GIS context, and system monitoring, high-availability, and disaster recovery - all staples within enterprise information systems generally - must be considered in the GIS context.
6.2 Maintenance Considerations.
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.
6.3 Security Considerations.
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.
6.4 Integrations and Interoperability.
As previously mentioned, to be pervasive within an organization, and serve as many business processes as practical, an Enterprise GIS is probably going to need to integrate with other enterprise information systems. The design of the Enterprise GIS, from an IT perspective, can facilitate or impede such integration. Furthermore, interoperability should be considered at the outset of an Enterprise GIS implementation effort, and incorporated into the design of data models, information products, and application architectures. For example, are there standardized representations of commonly used locations, names, codes, etc. within the organization? Do applications in common use expose data through APIs? Is there a particular database software package in common use by other enterprise systems? Are there standards for data quality, currency, ownership, etc? This last point transitions into the final topic in this section.
6.5 Data Governance
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.
6.6 Enterprise Architecture
The conceptual GIS planning process outlined by Tomlinson (2005) and the technical process of System Architecture Design advanced by Peters (2012) were not formed in a vacuum; efforts to formalize this kind of intentional, thoughtful approach to system design exist elsewhere in the IT industry. The discipline of Software Engineering is keenly focused on the process layer within which a particular technology solution is deployed (it is our source for process nomenclature such as “waterfall” and “agile” models).
Furthermore, in the broader IT field, the emerging discipline of Enterprise Architecture has formalized the conceptual notions of business process modeling, data design, application architecture and technology architecture into a series of interrelated process steps resulting in a strategic, yet operational vision to enable an organization to achieve its goals (Woodard, 2017). The TOGAF Standard for Enterprise Architecture advances an “Architecture Development Method” that meticulously breaks down the process of identifying business processes (Business Architecture), developing data models (Data Architecture), identifying the applications needed to support the business needs (Application Architecture) and then developing the technical implementation plan to realize the applications (Technology Architecture) (The Open Group, 2018). As an Enterprise GIS can be improved through a more intentional alignment with an organization’s strategic objectives, and more consideration given to change and risk management (both value-adding points of Enterprise Architecture per Woodard, 2017), Enterprise GIS-as-process stands to benefit from a mapping of the classical Tomlinson process steps to an emerging consensus of best practice in the more generalized field of Enterprise Architecture.
While most of the material up until this point is written at a sufficient level of technical abstraction to remain relevant over time, a proper understanding of Enterprise GIS necessarily includes a discussion of its concrete realization as enabled by contemporary Information Technology tools and patterns. As was stated at the outset, the state of the art in Enterprise GIS advances with waves of technological innovation in IT generally.
Modern Enterprise GIS (at the time of writing, Q3 2018) is most commonly implemented using a multi-tiered, database driven, services-oriented architecture (SOA) in which maps, data, and tools are exposed as REST or SOAP endpoints over HTTP(S), and then further wrapped in customized applications. Both commercial and open-source software tends to follow this general pattern of data persisting in a relational, spatially enabled database; cartography can be done using both full-featured GIS clients and increasingly through lightweight web mapping portals; maps and functionality can be delivered on the web as services directly to other applications, or as applications targeted to the end user user cases, which often can be developed from templates with little or no programming.
Increasingly, cloud-centric patterns (Software-as-a-Service and Platform-as-a-Service) are being incorporated into Enterprise GIS implementations. In PaaS implementations, organizations run GIS software in virtual machines that they provision from the elastic, scalable compute, storage and networking capacity on public cloud providers’ infrastructure (an example of this would be Amazon Web Services or Microsoft Azure). In this pattern, the organization is still responsible for operating and maintaining all the software components of its Enterprise GIS. In a SaaS implementation, GIS functionality is delivered to an organization without said organization having any awareness of, or responsibility for, the underlying infrastructure and software components. Many, if not most enterprise GIS implementations are hybrids, incorporating, as appropriate for their particular context, on-premises infrastructure, PaaS, and SaaS cloud resources, frequently integrated with one another into a cohesive system of systems that has been architected to further that organization’s objectives.
Informed by the above, this section concludes with a summary presentation of the generalized “moving parts” within a modern Enterprise GIS. While the specific component architecture of an Enterprise GIS is driven by organizational needs, there are a number of components common to many deployments, and what’s most interesting in this context is the nature of the components’ interdependent relationships. The logical model takes us from low-level infrastructure up through the various application-layer software products typically employed in Enterprise GIS system design (at the time of writing). These components are represented here as a nested architecture, with individual components depending on those containing them and communicating through well-defined interfaces with peers at the same level. A separate client tier is identified, with which Application layer components in the Infrastructure section of the diagram communicate directly. (This graphic is most easily parsed from the bottom up.)
Figure 1. The moving parts within a modern Enterprise GIS. Source: author.
Campbell, H. J. (1999). Institutional Consequences of the Use of GIS. Geographical Information Systems: Principles, Techniques, Management and Applications. P. A. Longley, M. F. Goodchild, D. J. Maguire and D. W. Rhind: 621-631.
Esri. (2015). Enterprise GIS. In GIS Dictionary. Retrieved from https://support.esri.com/en/other-resources/gis-dictionary/term/202d8f8a-4e1a-400e-ba6 f-37791744af6b
Federal Geographic Data Committee. (2005). Guidelines for Providing Appropriate Access to Geospatial Data in Response to Security Concerns. Reston, VA, Federal Geographic Data Committee (FGDC).
Peters, D. (2012). Building a GIS : System architecture design strategies for managers (2nd ed.). Redlands, CA, ESRI Press.
Thomas, C. (2009). What's your definition? Looking at what enterprise GIS really means. ArcUser Online 12(4): 30-32.
Tomlinson, R. F. (2007). Thinking about GIS : Geographic information system planning for managers (3rd ed.). Redlands, CA, ESRI Press.
Fu, P. and Sun, J. (2011). Web GIS: Principles and Applications. Redlands, CA: ESRI Press.
The Open Group (2018). TOGAF Standard, v.9.2. Retrieved from http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html
Woodard, J. (2017). Building an Enterprise Geographic Information System from an Enterprise Architecture Foundation. (Electronic Thesis or Dissertation). Retrieved from https://etd.ohiolink.edu/
- Define Enterprise GIS in an generalized manner without reference to a specific enabling technologies.
- Explain the difference between a system and a process definition of Enterprise GIS.
- Describe the value-adding points of Enterprise GIS in an organizational setting.
- Express the importance of organizational context to the implementation and operation of an Enterprise GIS.
- Demonstrate the importance of iteratively evolving a given Enterprise GIS implementation over time.
- Identify the current implementation patterns of Enterprise GIS, based on present trends and best practices in IT.
- How does the scale of an implementation of an Enterprise GIS create demands on an organization’s IT infrastructure not present in individual or departmental GIS?
- How does Enterprise GIS relate to Web GIS?
- How does a services oriented architecture differ from a traditional client-server model, and how does this architectural pattern facilitate Enterprise GIS?
- Identify the key steps in an Enterprise GIS planning effort.
- What are some of the processes that go into the development of an Enterprise GIS?
- What are some of functional characteristics and capabilities of an Enterprise GIS that distinguish it from standalone systems?
- What security and data governance considerations are present in enterprise GISs that are not present in more narrowly scoped systems?