Enterprise GIS

By the late 1990s New Zealand organisations had already proved that GIS could do useful work. That success created a new problem: GIS multiplied. Councils could maintain property and infrastructure layers, government departments could manage national datasets, utilities could trace networks and assets, and scientists could analyse environmental information. More useful systems meant more users, more data, more copies, more applications and more expectations about which version was the right one. Enterprise GIS began partly as an answer to the success of the smaller systems that came before it.

A small GIS team could survive for quite a while with files on network drives, specialist workstations and a shared understanding of who was allowed to change what. That arrangement became fragile as spatial information spread through an organisation. Someone copied a dataset for a project, someone else edited an older version, another team created a differently named field, and soon the same road or property existed in several technically valid but mutually irritating forms. The problem was no longer whether GIS worked. It was how to make it work for everyone without losing control of the information underneath it.

Enterprise GIS developed gradually, and organisations used several labels and architectures. Spatial data moved into databases designed for many users. Editing became controlled. Map servers and later feature services allowed one maintained dataset to support several applications. Authentication, permissions, backup, performance, upgrades and data ownership became part of the GIS job. A mapping system was turning into organisational infrastructure.

Nige Sheed and Jamie Burmeister established Adapt Solutions in 2007 after working together on a water-billing implementation in Auckland. Sheed’s earlier experience at Timaru District Council involved moving paper asset records into computerised systems. The company brought those practical implementation experiences into asset-management software and services.

Source WEB-ADAPT-PEOPLE-2026 · Adapt Solutions founders’ history

Enterprise GIS is an organisational operating model rather than a particular product. Shared authoritative data sits in databases or controlled repositories, services publish it to several applications, and integrations connect location with property, assets, science, operations and other business systems. Identity and permissions determine who can see or edit information. Governance defines ownership, custodianship, standards and change control. Platform teams keep the system available, backed up, patched and monitored through its lifecycle.

The practical consequence is dependency. A local desktop failure affects one analyst. A shared service can affect hundreds of staff and several business processes. Enterprise GIS therefore brings spatial systems into ordinary IT disciplines: resilience, security, service management, release planning, architecture and support. New Zealand organisations reached that state through several technical lineages, including Esri, Intergraph, MapInfo, Smallworld, open-source systems and bespoke applications.

File-based GIS served many projects and organisations effectively. ARC/INFO coverages, MapInfo tables, shapefiles and other local formats could be fast, portable and perfectly suitable for particular jobs. Problems appeared when an organisation expected those files to behave like a common record. A copied file does not know that another copy exists. A network folder does not settle who owns the schema. A map layer saved for one project does not automatically become the authoritative source for the next one.

This distinction became sharper as spatial information began to connect with business processes. A council property layer might be used for rates, planning, engineering and public enquiries. A utility asset record might support design, maintenance, outage response and field inspection. A conservation boundary might appear in national planning, operational work and public information. Once several activities depended on the same geography, the organisation had to decide which dataset was authoritative and how changes would reach everyone else.

A shared database changed the model. Many users could query the same features while a smaller group of editors maintained them. Transactions, validation and permissions could replace some of the informal rules that had worked when a few specialists sat near one another. Central storage did not make bad data good, and it did not remove arguments over definitions. It made those arguments harder to ignore because more people were now depending on the answer.

Auckland Council’s four-year Geospatial Future Mode of Operation programme followed the amalgamation that took effect on 1 November 2010. Its inherited environment contained different applications, schemas and ways of maintaining geographic information. The 2016 Esri account names council geospatial manager Ingrid McClymont and Eagle project manager Nathan Heazlewood. ArcGIS and FME supported a migration that reduced 8,470 inherited geographic datasets to 2,056 and replaced 697 district-plan datasets with 25. Historic information was retained for traceability. The work also established clearer service levels and closer links with council IT, while GeoMaps and other applications broadened access to the managed data. The recorded reductions describe decisions about authoritative information and its structure as well as the movement of files.

Auckland Council GFMO case study

Downer began discussions with Eagle in 2011 about using GIS in its telecommunications design and delivery work. Eagle’s customer account identifies Graeme Henderson as the account manager recommending an ArcGIS configuration and records Ryan MacVeigh on the Downer side. It describes GRAIL as Downer’s first GIS system. A later enterprise licence agreement widened access to the ArcGIS platform. The implementation placed spatial information inside an established contractor’s design and operational work, where the usefulness of a system depended on its fit with delivery teams and their existing records.

Downer GRAIL case study

A revealing early New Zealand example appears in a 1999 international conference paper by Cindy Munns on object-relational databases and spatial data. One of the paper's working examples was Land Information New Zealand's Core Records System. Its goal was described as unifying government land-related activities and replacing several systems with one integrated environment for automated land transactions. The system would contain both survey and title transactions, support remote land validation and move millions of plan and title images into digital form.

The scale was already substantial. The paper described about 750 gigabytes of data, roughly 400 gigabytes of it geospatial, around fifty developers and an Internet deployment requirement. The database environment used Informix with Esri SDE. Spatial and non-spatial information could be accessed through one database interface, while server-side spatial functions and indexes reduced the amount of information that had to be moved across the network. Common queries were expected to return in less than two seconds.

Seven hundred and fifty gigabytes was substantial by 1999, and the design assumptions were already recognisably enterprise assumptions. The database had to serve many users, hold different forms of information, preserve transaction integrity, support security and prepare for access beyond a specialist GIS workstation. Spatial data was becoming part of an integrated land-information system rather than a separate collection of maps.

The Core Records System combined spatial and administrative information in the architecture supporting Landonline. It shows enterprise GIS becoming organisational infrastructure before the later expansion of web mapping. By the end of the 1990s a national agency was already treating geometry as one class of organisational information to be managed inside a large multi-user database alongside other land records.

Moving information into a shared database changes editing as much as access. When one person edits a local file, responsibility is obvious. When dozens or hundreds of users depend on a common record, an edit can have consequences far beyond the person making it. Organisations therefore had to distinguish readers from editors, define who could alter schemas, establish validation and decide how conflicts would be handled. The database was now worth more than the map on any one person’s screen, which also meant one enthusiastic edit could become everybody else’s problem.

Different technologies handled those problems in different ways. Some enterprise GIS platforms used database transactions and GIS-specific versioning. Some applications separated operational editing from published read-only datasets. Other organisations continued to move information through scheduled replication or controlled imports because real-time shared editing was unnecessary or too risky. Organisations therefore followed several maturity paths rather than one common ladder.

Authority became the issue. A shared enterprise dataset needed an answer to the question of who was responsible for it. That answer was often not the GIS team. A property group might own property information while GIS staff administered the database and services. An engineering team might own an asset schema while a platform team kept the system available. Enterprise GIS made custodianship more explicit because technical centralisation could no longer be allowed to blur business responsibility.

Christchurch City Council provides a different view of the same transition. The council's 2001/02 Corporate Plan called for further development and integration of GIS, Webmap, environmental layers, GEMs and the National Property Database within its electronic-information environment. The wording places GIS inside a wider corporate information environment rather than treating it as an isolated mapping tool. It was being developed as one part of a wider corporate information environment that brought property, environmental and geographic information together.

By February 2003 the council reported that its Corporate Webmap rollout had been completed. User numbers had increased by 35 per cent since June 2002, while the number of datasets available through the system had grown from 55 to 69. Those are modest figures by later web-platform standards, but they reveal a fundamental organisational shift. More staff could reach common spatial information through a browser without each becoming a desktop GIS specialist.

Chapter 30 treated systems such as the Christchurch Webmap as part of the first generation of browser GIS. The enterprise interpretation is different. A browser application was useful because someone behind it was maintaining the datasets, integrating corporate information and keeping a shared service available. The user saw a map. The organisation had to manage the machinery underneath it.

That machinery encouraged reuse. A property or environmental dataset maintained for one business purpose could appear in another internal application without being manually rebuilt. The same architecture also increased dependency. If the shared Webmap or its underlying data failed, the effect was no longer confined to one GIS analyst. The convenience of corporate access created an expectation of corporate availability.

The Department of Conservation described its National Enterprise GIS architecture in 2003. The Department's earlier Biodiversity Information Platform evolved into DOCgis and a wider national architecture using ArcSDE, ArcGIS and ArcIMS. The technical material describes a national geodatabase, browser applications, access to aspatial business databases and integration with GPS, ArcPad and Windows CE field technology.

DOCgis Version 2.0 was documented in June 2003, followed by an ArcIMS Java-client milestone in August. The Department also described using the Rational Unified Process for parts of its software and enterprise-component development. Requirements were modelled, prototypes were tested with users, and successive iterations added capability. This was no longer a case of a GIS specialist building a useful map for colleagues. It was software and information infrastructure being developed for an organisation with national and regional operations.

DOC established a national geodatabase, ArcIMS services and centrally developed components. Regional and operational teams used that platform while developing tools suited to their own work.

DOC’s enterprise system combined databases, services, applications and support. Spatial and non-spatial information were intended to work together. Browser clients widened access. Field tools could connect to national data. Different application types could use common information. The enterprise platform sat between authoritative data and the many contexts in which staff needed to use it.

Steven Li’s 2009 Massey University thesis examined systems integration in a government agency whose named applications included DOCgis and Bioweb. The system descriptions identify the Department of Conservation context. The study describes the difficulty of keeping information consistent when business data was copied or reconciled between applications. Linking a spatial record to the operational database responsible for its attributes reduced the need for separate GIS copies, while creating dependencies on identifiers, interfaces and the availability of the other system. DOCgis therefore belonged to a wider information environment in which database integration and organisational responsibility affected the quality of the map service.

DOCgis architecture and development

Connecting GIS to other organisational systems changed the enterprise environment substantially. GIS became more valuable when it stopped behaving as a separate world of layers and began linking records that the organisation already cared about. A parcel could connect to title or property information. A cable could connect to an asset record and a maintenance history. A conservation feature could link to operational or scientific databases. Geography became another route into organisational information.

Vector's early-2000s field system shows the operational consequence without needing to repeat the mobile-GIS story. In April 2002 the electricity company was deploying 40 Compaq iPAQs and six Panasonic Toughbooks to field crews. The notebooks used Vector's Smallworld GIS, while the iPAQs ran ArcPad. Vector developed translation software so data could move between ArcPad and the Smallworld environment when devices were synchronised at the office.

By 2003 contemporary reporting described staff using handheld devices and communications links to reach the corporate GIS asset register during network work. The enterprise point is not the model of PDA. The spatial asset record had become part of an operational workflow. Field work could consume organisational GIS information and return updates instead of producing paperwork that someone later re-entered at a desk.

Systems could exchange information across vendors and file formats. In fact, Vector's translation layer is a reminder that enterprise environments are often untidy. Different tools survive because they suit different jobs. The organisation's problem is to make the information move between them without losing meaning or control.

Enterprise GIS is sometimes mistakenly equated with a particular commercial platform. NIWA's mid-2000s and early-2010s work provides a useful counterexample. In 2006 NIWA practitioner Brent Wood described PostGIS being used on about half a dozen systems, with some datasets containing hundreds of millions of features. Later technical correspondence described PostGIS operating with Apache and UMN MapServer in an OGC web-mapping environment.

The 2010 Ocean Survey 20/20 Bay of Islands portal made that architecture visible to a wider audience. NIWA had carried out a large multidisciplinary marine survey and needed to publish data, reports, imagery and metadata. The solution used GeoNetwork for metadata discovery, PostGIS as the spatial database server, MapServer for OGC map and feature services, OpenLayers as the browser map client and SilverStripe as the content-management layer. The public interface combined interactive maps with searchable metadata and downloadable material.

NIWA used open-source software to support its operational requirements. Chapter 32 owns that. In enterprise terms, NIWA was assembling reusable database, metadata, service and web components around organisational scientific information. The same broad problems remained: which information was authoritative, how metadata was maintained, how services were exposed and how users could discover and reuse the data.

The NIWA case also demonstrates federation. Scientific organisations rarely fit neatly into one central schema because projects produce different kinds of observations and models. Enterprise capability can therefore mean managed connections among systems rather than forcing every dataset into one database. Shared services and metadata can provide organisational coherence even when the underlying data remains distributed.

As enterprise GIS matured, services became an important way to separate the authoritative source from the applications that consumed it. A desktop GIS no longer needed its own copy of every layer. A browser map could request a rendered map from a server. A field application could query or edit selected features. A dashboard or property application could use the same source while presenting it in a completely different interface.

This separation made Chapter 35's task-specific applications possible at scale. An application designer could focus on what the user needed to accomplish because the map and data services already existed behind the interface. The user might never know whether a property boundary came from an enterprise geodatabase, a specialist land system or a federated service. Mature GIS services allowed staff to use spatial information through their ordinary applications.

Reuse also concentrated risk. One badly configured service could affect many applications. A schema change that looked harmless to the data custodian might break a field form, a reporting process and a public viewer at once. Enterprise GIS therefore created dependencies that small standalone systems did not have. Technical elegance was no substitute for knowing who depended on what.

Keeping those dependencies working created new kinds of geospatial work. Someone had to administer spatial databases, publish services, monitor performance, manage user access, plan upgrades, restore backups and investigate failures. Someone had to coordinate with infrastructure teams, database administrators, application developers and security staff. The GIS profession was acquiring an operational layer alongside analysis and cartography.

These responsibilities were rarely organised in exactly the same way. A large agency might separate database administration, server infrastructure and GIS application support. A council might keep several responsibilities inside a small corporate GIS team. A research organisation might combine software development and spatial-data management around projects. The common feature was that GIS availability itself had become work.

This changed professional priorities. A beautiful map can be finished. A platform is never finished in quite the same way. Databases grow, users arrive, operating systems age, certificates expire, software versions change and new applications create new dependencies. Enterprise GIS replaced some one-off production work with a continuing obligation to keep the spatial environment healthy.

The difference becomes obvious during failure. A desktop GIS crash may delay one analyst. A failed shared database or map service may remove maps from several applications at once. Field staff may lose access to assets. A browser system may stop answering property enquiries. Automated processes may fail because a service they expected to exist has disappeared.

That risk drove GIS towards ordinary information-technology disciplines. Staff needed to test that backups could be restored. Maintenance needed planning. Performance had to be monitored. Changes needed testing before they reached important users. Disaster recovery and service continuity became relevant because spatial capability had become part of normal organisational operations.

New Zealand organisations adopted formal development, test and production environments at different times. Some moved early; others used less formal controls and gradually strengthened them. As GIS was reused more widely, casual changes became harder to make safely.

Enterprise GIS often produced pressure to centralise. One database, one server environment and one set of standards promised fewer duplicates and easier support. Sometimes that worked well. Common coordinate systems, schemas, metadata, identifiers and basemaps could reduce friction across an organisation. A shared platform could also concentrate expertise and avoid every team buying its own infrastructure.

Some work was better supported by local or distributed systems. Specialist systems existed for good reasons. A network utility required topology and asset behaviour that a generic GIS might not manage well. Scientific databases contained measurements and models that did not fit a corporate feature schema. Cadastral and title systems carried legal requirements outside the scope of ordinary GIS databases. The enterprise problem was therefore often one of connection rather than conquest.

NIWA's service-based approach illustrates this, and the Digital Auckland case in the previous chapter made the same point at city scale. Information can remain with its custodian while being exposed through managed interfaces. Enterprise capability may come from agreed identifiers, standards and services rather than physical consolidation into one enormous database.

Downer began developing GRAIL in 2011 with Eagle Technology support. The surviving customer case describes it as Downer’s first GIS system. Graeme Henderson held the documented Eagle account role, with Ryan MacVeigh also named in the project record.

The case shows ArcGIS moving into operational delivery rather than remaining a specialist mapping environment. The later enterprise licence context supported wider use across the company. The evidence is a specific Downer example and should not be generalised to the contracting sector as a whole.

Read the Downer GRAIL case study.

Read the Downer GRAIL case study

Once many systems share spatial information, governance stops being a meeting-room abstraction. Someone has to decide who can create a new authoritative layer, who approves a schema change and who is allowed to publish information to a wider audience. Someone must determine which dataset wins when two systems disagree. Someone must own the response when a critical service fails.

These decisions carry organisational consequences because a platform administrator and a data owner are often different people. GIS staff may know how to keep a database running without having authority to decide what a road classification means. An asset manager may own the business definition without having the technical access to alter the enterprise schema directly. Mature enterprise GIS depends on separating those responsibilities clearly enough that the organisation knows who is accountable for each decision.

Access control adds another layer. Some spatial information is appropriate for public use. Some is suitable for staff but not publication. Other information may involve personal, property, operational or security sensitivities. Enterprise GIS therefore became part of organisational identity and permissions systems rather than a collection of open folders available to anyone who knew the path.

By the 2000s and 2010s, organisations applied ordinary access controls, change records and information-security requirements to GIS.

Auckland Council inherited a large and inconsistent geospatial estate when the Auckland authorities amalgamated in 2010. The Geospatial Future Mode of Operation programme ran for about four years and consolidated platforms, data and support arrangements while GIS was being placed inside wider IT service-management and governance processes.

The documented technology mix included ArcGIS, FME, a central geodatabase, Portal and the GeoMaps environment. The programme reduced 8,470 inherited geographic datasets to 2,056 and rationalised 697 district-plan GIS datasets to 25. Those figures describe data consolidation rather than a claim that fewer datasets are inherently better; the point was to remove duplication, define services and establish a maintainable operating model.

Ingrid McClymont represented Auckland Council’s geospatial management during the programme. Nathan Heazlewood was the Eagle professional-services project manager. Their roles illustrate the combined customer, governance and supplier effort involved in a large enterprise consolidation.

Read the GFMO case study.

Read the GFMO case study

Shared platforms also made technology replacement more consequential. A GIS desktop could once be upgraded when an analyst was ready. An enterprise platform might contain databases, services, scripts, field workflows and public applications that all depended on a particular version or interface. Moving one component could force several others to move with it.

Migration therefore became part of GIS history. Data had to be converted. Services had to be republished. Custom applications had to be tested. Integrations had to be checked. Users needed warning when behaviour changed. The larger the platform became, the less credible it was to treat an upgrade as simply installing newer software.

Enterprise GIS continued alongside older systems where those systems remained useful. Working integrations have value. Rebuilding them costs time and introduces risk. New Zealand organisations, like their counterparts elsewhere, often accumulated mixtures of old and new components because replacing the entire spatial environment at once was rarely practical.

From 2021 NZ Transport Agency Waka Kotahi worked with Eagle on a proof of concept and implementation of ArcGIS Enterprise on Kubernetes. The architecture used a hub-and-spoke spatial-as-a-service model intended to provide governed shared services while allowing business areas to build applications around authoritative transport information.

Peter Willoughby represented the platform side of the programme and Jithen Singh the Eagle public-sector role. The documented environment includes authoritative transport data, integrations, dashboards and field workflows, with the Kubernetes platform providing a cloud-native route to scaling and resilience.

Cyclone Gabrielle in February 2023 provided an operational test. The case study records use of the platform for field survey and situational awareness. Detailed claims about benefits or performance are attributed to the NZTA/Esri customer case rather than treated as independent measurements.

Read the NZTA enterprise-platform case study.

Read the NZTA enterprise-platform case study

Enterprise GIS also turned standards from good intentions into daily operating requirements. When several teams share the same roads, parcels, addresses, assets or environmental features, differences in field names, identifiers, coordinate systems and update rules stop being local annoyances. They become integration failures. A property application cannot reliably join to a parcel layer if the identifiers are unstable, and a field workflow cannot validate an asset if the corporate database uses a different classification from the system that issued the work order. Standardisation therefore became one of the less visible forms of enterprise infrastructure.

New Zealand organisations dealt with that pressure in several ways. LINZ's Core Records System required survey, title, image and spatial information to coexist inside one national transaction environment. Christchurch was trying to bring GIS, property and environmental information into one corporate electronic-information setting. DOC's national platform connected a geodatabase, browser clients and business databases across a geographically dispersed department. NIWA's scientific infrastructure took a more federated route, but metadata and service standards were essential precisely because the underlying information came from different projects and disciplines.

Enterprise GIS worked best when organisations standardised the things that needed to cross boundaries while allowing specialist information to remain specialist. Common coordinate references, identifiers, service conventions, metadata and agreed definitions could provide enough consistency for reuse. A scientific observation, a cadastral parcel and an electricity cable could retain different data models while still participating in the same organisational environment. The difficult work was deciding which standards were genuinely organisational and which were merely convenient for the team currently administering the platform.

Publishing also became a controlled step in its own right. An editor could maintain detailed or sensitive information in an authoritative environment while a wider audience received a simpler read-only service. That separation reduced the temptation to let every application connect directly to production data and allowed organisations to present information at a level suited to the user. It also created another dependency: the published service had to be refreshed, monitored and kept consistent with its source. Enterprise GIS therefore added a lifecycle between capture and use, with authoritative data being maintained, validated, published and then consumed by several different clients.

The cumulative effect was to make GIS less tolerant of casual local changes. Renaming a field, altering a code list or moving a service endpoint might once have affected one map document. In an enterprise environment the same change could break queries, forms, reports or integrations that the person making the change had never seen. Good governance therefore required knowing the dependency chain before touching it. GIS was subject to ordinary organisational requirements for access, maintenance and accountability.

Metadata became a particularly revealing test of the enterprise and SDI ambitions. In 2003 the Department of Conservation's enterprise-GIS paper said its national geodatabase would migrate to the New Zealand Geospatial Metadata Standard when that standard was fully implemented. A June 2004 draft New Zealand Government Geospatial Metadata Standard then attempted to turn ISO 19115 into a government profile for describing spatial data consistently. On paper this made sense: if organisations could describe source, quality, extent, currency, responsibility and use constraints in the same structured way, data could be discovered and assessed beyond the team that created it.

Implementation was much less elegant. A 2007 review of the national and regional Wildfire Threat Analysis programme records that adoption of the New Zealand standard initially complicated the work because projects were using different software and there was no tool capable of reading and writing the required metadata. LINZ eventually helped produce a Microsoft Word template so the projects could comply, while existing national metadata written in another format had to be rewritten. Metadata standards still required affordable software, staff time and workable publishing processes.

The national approach changed rather than disappearing. In July 2010 the State Services Commission endorsed the ANZLIC Metadata Profile as the recommended geospatial metadata standard for government agencies. It was based on the Australia/New Zealand adoption of ISO 19115, but practical implementation increasingly relied on smaller mandatory cores, templates and tools such as ANZMet Lite rather than expecting every ordinary data custodian to confront the full structure of an international metadata schema. The 2015 revision of ISO 19115 then superseded the earlier 2005 standard and the 2007 regional profile, but the implementation problem did not magically disappear. LINZ guidance prepared in 2019 described metadata creation as complex and time-consuming, noted that tools and best-practice guidance had not yet emerged for the 2015 version, and pragmatically recommended continuing with the older profile until usable tooling caught up. The difficulty reflected a persistent gap between formal standards and the practical tools available to implement them. Standards could advance faster than the everyday software and processes needed to make them routine.

By the later 2010s, the practical route to discovery was becoming less dependent on every organisation implementing one elaborate catalogue in exactly the same way. Data.govt.nz moved towards a common catalogue schema based on DCAT and mapped to other schemes including ANZLIC, while harvesting metadata automatically from CSW catalogues, CKAN and data.json feeds including ArcGIS sources. ArcGIS Online item metadata could in turn be harvested into the national data catalogue. The original SDI objective of making distributed information discoverable and reusable remained, but the implementation was becoming an ecosystem of hosted catalogues, platform metadata, harvesting and web services rather than one uniformly implemented national metadata stack. That distinction leads into the next chapter: the standards continued, while much of the practical interoperability moved closer to the services and platforms people were actually using.

Enterprise GIS is easiest to recognise when users stop thinking about GIS. A planner opens a property application. A technician receives an asset location. A manager watches a dashboard. A scientist publishes a data portal. An analyst queries a business database that happens to contain geometry. In each case the visible interface may be only a small part of the spatial system involved.

Behind those interfaces sit the less glamorous things that make geographic information dependable: databases, services, identifiers, permissions, backups, monitoring, metadata, custodians and people who understand which system is authoritative. This is the other side of the change described in Chapter 35. There the map disappeared into the application. Here the GIS disappears into the organisation.

By the end of 2025, New Zealand organisations used several enterprise GIS architectures. Some organisations ran highly centralised platforms. Others combined specialist systems through services and integrations. Commercial and open-source components coexisted. On-premises servers remained important even as hosted and cloud services expanded. What had changed was the expectation that spatial capability could be shared, maintained and relied upon beyond the individual GIS specialist.

The commercial plumbing underneath those platforms could also come from specialist New Zealand firms that most end users never saw. John Arnerich founded Locus in 2004 around the use of FME for data integration, and the company developed into a specialist reseller and consultancy for moving, transforming and automating organisational data. That kind of work complicates any simple count of which GIS vendor an organisation used. A council could present ArcGIS applications to most staff while FME, databases, APIs and other components moved information between the systems behind them.

That expectation leads directly to the next chapter. Once databases and map services become organisational infrastructure, the next question is how those services are hosted, exposed and consumed beyond the traditional enterprise boundary. Chapter 41 follows the move into cloud platforms, hosted geospatial services and APIs, where geography increasingly travels between systems without a person opening a GIS at all.