Skip to main content

Iwi GIS blueprint

For an iwi with established organisational and IT capability, the challenge is usually not choosing one platform. It is keeping the kaupapa, whakapapa, source context and organisational capability visible while information moves through several systems.

Enterprise architecture can help with that, but the architecture should explain the mahi rather than become the mahi.

A hybrid pattern​

Conceptual flow

The important feature is not the boxes. It is that people can explain what each environment is for, which copy is current for which purpose and how the organisation would recover or move the information later.

Organisational controls that earn their keep​

A mature iwi GIS can benefit from:

  • enterprise identity and MFA
  • clear technical administration roles
  • data/service classification that matches real use patterns
  • common provenance fields and source registers
  • named current versions for important datasets
  • separate working and public/shared derivatives where useful
  • supplier requirements and export formats
  • backup and recovery standards
  • logging for consequential systems
  • documented AI service behaviour where AI is used
  • records/archive processes
  • platform exit plans
  • visible long-term operating cost

These are ordinary ways of keeping a large system understandable. They do not replace tikanga, whakapapa or local decision processes.

Different information can live in different environments​

An iwi GIS may contain public national datasets, internal operational information, historical research, environmental observations, imagery, marae information and locally held collections. There is no technical advantage in forcing all of that into one environment merely for architectural neatness.

Likewise, a more restricted system is not automatically better for information that needs regular access by dispersed whānau or kaimahi.

Choose the environment according to the work, people, service behaviour and consequence of losing control or access.

See Cloud is not one thing and Local and hybrid GIS.

Identity is useful infrastructure​

Enterprise identity can provide named accounts, MFA, central offboarding, role-based access and auditability. That becomes particularly valuable when many people work across several GIS applications.

Keep at least two people able to recover the highest-level administration. An elegant identity design is not useful if the organisation cannot regain access after a staff or supplier change.

Technical account access and the wider relationships around Māori information are different things. The identity platform manages the former. It does not define the latter.

Supplier pattern​

For important GIS/data suppliers, a common schedule can cover:

  • account and tenant ownership
  • hosting and processing locations
  • subprocessors
  • exports and open/portable formats
  • metadata, provenance and attachments
  • AI-related processing or reuse
  • backup retention
  • logging
  • breach notification
  • termination and deletion behaviour
  • configuration/source code where relevant
  • handover and capability transfer

This saves every project rediscovering the same technical questions. See Consultants and contracts.

Keep an independent archive​

For material systems, retain a periodic independent export of whatever would be needed to understand or reconstruct the useful information:

  • main data
  • attachments
  • metadata and provenance
  • schemas
  • important configuration
  • source/readme material
  • notes about which versions served which purposes

An archive should be understandable to the next team, not merely technically complete.

Publication is a data product​

An iwi may hold hundreds of detailed layers while publishing only a small number of clear products. Treat those public products as deliberate outputs rather than exposing the working database directly.

For each publication, record:

  • what question or audience it serves
  • source/version used
  • fields included
  • location detail/generalisation used
  • explanatory context
  • date
  • how it will be updated

See Publishing Māori GIS maps.

AI as another system component​

If an AI service is used for imagery, document search, coding or feature detection, record what actually happens to prompts/files and outputs. Model training, evaluation and product improvement are separate technical uses worth checking in current provider terms.

For document-heavy kaupapa, Local AI provides a desktop workflow where candidate findings remain tied to their original sources.

Capability across the organisation​

An enterprise GIS is easier to sustain when useful knowledge is spread across:

  • GIS practitioners
  • data teams
  • whānau/hapū/business units carrying the kaupapa
  • IT and security
  • procurement
  • records/archives
  • planning/policy teams
  • people responsible for long-term investment

The GIS team does not need everyone to become a GIS analyst. It needs enough shared understanding that the organisation can make, challenge and carry forward technical choices.

Useful architecture test​

Ask whether the organisation could answer these without calling the original consultant:

  1. Where is the main copy of each important dataset?
  2. What is it used for?
  3. Where are public/shared versions generated?
  4. Who can recover the platforms and accounts?
  5. What is backed up independently?
  6. How would data be exported if the platform changed?
  7. What does the system cost to run next year and in five years?
  8. Can the next kaimahi understand the provenance and whakapapa around the important layers?

If the answers are visible, the architecture is doing useful work.

Last reviewed: 26 August 2026

Last updated on