2.1: Guiding Principles & Approach

The implementation is governed by a set of core architectural and operational principles that collectively define the approach to deploying ArcGIS Enterprise 11.4 on Azure. These principles establish a modern, cloud-native foundation that treats geographical information system (GIS) services with the same rigour and practices applied to other mission-critical enterprise applications. The following principles provide the framework for all technical decisions and implementation approaches throughout this plan.

2.1.1. Azure PaaS First¶

A primary tenet of this architecture is the preferential utilisation of Azure Platform-as-a-Service (PaaS) offerings wherever feasible and appropriate. This involves leveraging Azure-managed services for databases, storage, web application hosting and other infrastructure components.

Rationale¶

Adopting PaaS significantly reduces the operational burden associated with managing underlying infrastructure. Responsibilities such as operating system patching, hardware maintenance and runtime environment updates are largely handled by Azure. This allows the technical team to focus on application-level configuration, data management and value-added services.

Application¶

• Database Tier: Azure Database for PostgreSQL will serve as the user-managed Enterprise Geodatabase.
• Web Tier: ArcGIS Web Adaptor instances will be hosted on Azure App Service (Linux runtime with Tomcat), eliminating the need for dedicated Web Adaptor Virtual Machines.
• Storage Tier: Azure Blob Storage will be used for Portal for ArcGIS content, map/image service caches (utilising optimal formats such as CompactV2), ArcGIS Server job/output directories and backups. Azure Data Lake Storage Gen2 (ADLSg2) will serve as the Raster Store. Azure Files will be used for ArcGIS Server config-store and system directories.
• This approach enhances deployment agility, promotes scalability and ensures the platform benefits from Azure's continuous innovation in its PaaS offerings.

Strategic Alignment with BFS Data & Platform Strategy¶

By leveraging Azure App Service for Web Adaptors, Azure Database for PostgreSQL for enterprise geodatabases and Azure Storage services for specialised storage needs, the project minimises the need for manual infrastructure maintenance, patching and lifecycle management, allowing technical teams to focus on activities related to application development, data management and service delivery and providing value for business.

Considerations¶

While certain core ArcGIS Enterprise components (Portal for ArcGIS, ArcGIS Server and ArcGIS Data Store) must run on virtual machines, these components will integrate with and leverage Azure PaaS services for storage, databases and web-facing components.

2.1.2. ArcGIS as a Standard Application Server¶

ArcGIS Enterprise will be treated as a standard application server, analogous to other enterprise application platforms. This principle dictates that its architecture, data flows, integration patterns, monitoring and operational management align with established modern practices for application servers.

Rationale¶

Moving away from viewing ArcGIS as an isolated "black box" promotes better integration within the enterprise IT ecosystem. It ensures that standard operational procedures, security policies and observability practices can be consistently applied.

Application¶

• The platform's components will integrate with enterprise identity management systems (via SAML/OpenID Connect).
• Monitoring and logging will be centralised using Azure Monitor and Application Insights, consistent with other enterprise applications.
• Data ingress and egress will adhere to open standards where possible.
• Deployment and configuration management will follow standard DevOps practices (OpenTofu, Configuration Management tool).

2.1.3. Open Standards & Decoupling for Inputs/Outputs¶

To foster interoperability and avoid vendor lock-in, all inputs to and outputs from the ArcGIS Enterprise platform will, where practicable, adhere to open, standardised and use cloud-native formats. This approach promotes decoupling between the GIS platform and other enterprise systems.

Rationale¶

Utilising open standards simplifies data exchange, enhances integration capabilities with non-Esri systems and provides greater flexibility for future technology choices. Decoupling ensures that changes in one system have minimal impact on others.

Application¶

• Emphasis on OGC (Open Geospatial Consortium) compliant services (e.g., WMS, WFS, WCS) for data dissemination where appropriate.
• Utilisation of cloud-optimised raster formats such as Cloud Raster Format (CRF) and Meta Raster Format (MRF) for raster data stored in Azure Data Lake Storage Gen2.
• Data exchange with external systems will favour formats such as GeoJSON, CSV, or Parquet where suitable.
• While leveraging ArcGIS's powerful capabilities, the implementation will establish practices that maintain data portability and avoid deep dependency on proprietary formats. Where proprietary elements are necessary for core functionality, they will be clearly documented with potential migration paths or alternative open-standard integration points identified.

2.1.4. User-Managed Enterprise Data (Azure PostgreSQL with PostGIS)¶

Authoritative enterprise geospatial data will be managed within user-controlled database instances, specifically Azure Database for PostgreSQL with the PostGIS extension enabled. These databases will be registered with ArcGIS Server as Enterprise Geodatabases.

Rationale¶

This principle ensures that the Department retains full control over its critical data assets. Lifecycle management, backup procedures, versioning strategies, schema modifications and data migration activities will be performed using native Database Management System (DBMS) tools and standard database administration practices, rather than relying solely on Esri's proprietary geodatabase management tools within ArcGIS. This approach offers greater transparency, control and aligns with modern data governance practices.

Application¶

• Azure Database for PostgreSQL will be the designated platform for all enterprise geodatabases.
• The Esri-managed ArcGIS Data Store (Relational type) will have a limited role, primarily supporting Portal-hosted feature layers and the outputs of spatial analysis tools within Portal. It will not be the primary repository for authoritative enterprise data.
• Only PostGIS spatial types will be utilised within Azure Database for PostgreSQL, as the ST_Geometry library cannot be loaded to Azure's database-as-a-service offerings.

Strategic Alignment with BFS Data & Platform Strategy¶

The strategic shift towards "User-Managed Enterprise Data" and the emphasis on "Open Standards & Decoupling" are pivotal in adopting the Department's objectives of data sovereignty, improved data quality control, enhanced interoperability and reduced vendor lock-in. The use of Azure Data Lake Storage Gen2 for raster data further illustrates a commitment to utilising specialised, cloud-optimised data services. This approach positions data as a strategic asset, managed through transparent, standards-based mechanisms.

2.1.5. Automation via OpenTofu (IaC) and Configuration Management Tool¶

The entire lifecycle of the new eMap platform, from infrastructure provisioning to application configuration, will be automated.

Rationale¶

Automation is critical for achieving consistency, repeatability, speed and reliability in deployments and operational tasks. It minimises the risk of human error associated with manual configurations and enables rapid environment rebuilding or modification.

Application¶

• Infrastructure as Code (IaC): All Azure infrastructure resources (Virtual Machines, Virtual Machine Scale Sets, Storage Accounts, Azure Database for PostgreSQL instances, Azure App Services, networking components, etc.) will be provisioned and managed using OpenTofu. Esri's Cloud Builder or Azure Resource Manager (ARM) templates will not be used for this purpose.
• Configuration Management (CM) tool: will be employed to automate the configuration of Virtual Machines, including operating system setup (Ubuntu 24.04 LTS), hardening, installation of ArcGIS software components and ongoing configuration updates.
• CI/CD Pipelines: Foundational Continuous Integration/Continuous Deployment (CI/CD) pipelines (e.g., using GitHub Actions) will be established for validating and deploying IaC (OpenTofu) and CM scripts.

Strategic Alignment with BFS Data & Platform Strategy¶

Comprehensive automation coupled with the establishment of CI/CD pipelines, reflects IRD's commitment to modern DevOps methodologies. This alignment seeks to enhance deployment velocity, ensure consistency across environments, reduce manual errors and improve overall operational efficiency. Treating ArcGIS as a "Standard Application Server" further embeds it within these standardised, automated operational paradigms.

2.1.6. Azure Best Practices & Cost Optimisation¶

The new eMap architecture will adhere to modern cloud design principles and specifically leverage Microsoft Azure best practices for security, scalability, resilience and operational excellence. Cost optimisation is a significant consideration influencing all architectural and deployment decisions.

Rationale¶

Aligning with Azure best practices ensures the platform is robust, secure and performs efficiently. A conscious focus on cost optimisation ensures that cloud expenditure is managed effectively without compromising essential capabilities.

Application¶

• Strategic use of Azure PaaS to reduce management overhead and leverage Azure's economies of scale.
• Implementation of auto-scaling mechanisms for components like ArcGIS Server (VMSS) and Web Adaptors (Azure App Service) in the Production environment to match resource allocation with demand.
• Appropriate selection of Azure service tiers and VM sizes, particularly differentiating between cost-optimised configurations for DEV/UAT environments and performance-oriented configurations for PROD. This includes the use of dedicated, lower-tier and less redundant Azure PaaS resources for non-production environments.
• Utilisation of Azure Reservations or Savings Plans for predictable Production compute workloads.
• Diligent monitoring of resource consumption via Azure Cost Management + Billing, supported by comprehensive resource tagging.
• Implementation of auto-shutdown schedules for non-production environments where feasible.

Strategic Alignment with BFS Data & Platform Strategy¶

The architecture incorporates cost optimisation as a fundamental consideration. Strategies such as employing lower-cost SKUs and LRS/simplified PaaS configurations for DEV and UAT environments, leveraging Azure PaaS efficiencies, implementing auto-scaling directly contribute to the BFS goal of maximising the value derived from cloud investments and controlling operational expenditure.

2.1.7. Zero Trust Security Model¶

All eMap 2.0 components will reside on Azure Virtual Networks (VNets) that are, by design, accessible from the public internet. Security will be enforced through a Zero Trust model, assuming no implicit trust based on network location.

Rationale¶

A Zero Trust approach enhances security by requiring verification for every access request, regardless of its origin. While services are publicly accessible, multiple layers of security controls protect them.

Application¶

• A Web Application Firewall (WAF) will inspect all incoming HTTP/S traffic for threats.
• An Application Delivery Controller (ADC) will manage ingress traffic, perform SSL/TLS termination and enable path-based routing.
• Network Security Groups (NSGs) will be meticulously configured to implement micro-segmentation, allowing only necessary communication between defined application tiers and components based on the principle of least privilege.
• Authentication will be managed through modern protocols (SAML/OpenID Connect) integrated with the enterprise Identity Provider (IdP).
• Azure Managed Identities will be used for Azure resource authentication and Azure Key Vault will secure secrets.

Strategic Alignment with BFS Data & Platform Strategy¶

Deploying robust security controls such as Web Application Firewalls, Application Delivery Controllers, meticulous Network Security Group configurations and modern authentication protocols enable the adoption of "Zero Trust" security model and implementing a "Defence-in-depth" security approach, aligning the project with contemporary security best practices designed and enhancing the Department's security posture.

2.1.8. Phased Approach to High Availability / Disaster Recovery (HA/DR)¶

The implementation of High Availability (HA) and Disaster Recovery (DR) capabilities will follow a phased, iterative approach, starting with foundational resilience and progressively enhancing it.

Rationale¶

Implementing full HA/DR from the outset can be complex and resource-intensive. A phased approach allows for foundational capabilities to be established and validated first, with more advanced resilience features built upon this base as the platform matures and requirements become clearer.

Application¶

• The initial base deployment (MVP) will focus on establishing core functionality in the primary Azure region (Australia Southeast - Melbourne).
• Subsequent stages will introduce intra-region HA for components within Melbourne (e.g., active-passive Portal, primary-standby ArcGIS Data Store, zone-redundant PaaS services).
• Finally, inter-region DR to the secondary Azure region (Australia East - Sydney) will be implemented, leveraging a pilot light model and global traffic management.
• This incremental strategy allows for controlled complexity, risk mitigation and alignment of investment with evolving resilience needs.

Strategic Alignment with BFS Data & Platform Strategy¶

The architecture's design for scalability and the phase approach to project delivery emphasises building resilient, adaptable systems. The iterative delivery model, starting with a Minimum Viable Product (MVP) and progressively enhancing capabilities, allows for risk mitigation, continuous learning and alignment of investment with evolving business needs.

2.1.9. Linux as Standard VM Operating System¶

All Azure Virtual Machines hosting ArcGIS Enterprise components will utilise Ubuntu 24.04 LTS (Long-Term Support) as the standard operating system.

Rationale¶

Standardising on a specific, supported OS version simplifies configuration management, patching and ensures consistency across the VM fleet. Ubuntu 24.04 LTS is fully supported by Esri for ArcGIS Enterprise 11.4 and offers a stable, secure and widely adopted platform.

Application¶

• VM configurations will be automated using Configuration Management tool, incorporating Esri and Canonical best practices for setup, hardening and maintenance of Ubuntu 24.04 LTS.
• Configuration Management scripts for components such as ArcGIS Server VMSS will be based on this standard OS.

2.1.10. Conformance to ArcGIS Reference Implementation¶

The deployment will strictly adhere to and where appropriate exceed, Esri's published minimum software and hardware requirements for ArcGIS Enterprise 11.4 components.

Rationale¶

Meeting these requirements is essential for ensuring platform stability, performance and eligibility for Esri support.

Application¶

• VM sizing for DEV and UAT environments will meet minimum specifications for each component, with Portal for ArcGIS, ArcGIS Server and ArcGIS Data Store deployed on separate, lower-SKU virtual machines per environment to ensure architectural consistency with Production while optimising costs.
• PROD environment VMs and VMSS instance types will be selected to meet or exceed recommended specifications based on anticipated load.
• System-level configurations, such as file handle and process limits on Linux VMs, will be configured according to Esri guidelines (e.g., file handles: 65,535; process limits: 25,059).
• All ArcGIS Enterprise components (Portal, Server, Data Store, Web Adaptors) will be deployed at version 11.4 to ensure compatibility.

Strategic Alignment with BFS Data & Platform Strategy¶

The standardisation on Linux, adherence to ArcGIS's reference deployment architecture and standardised environment contribute to operating a more manageable, predictable and supportable platform. This consistency simplifies operations and aligns with the IRD's goal of reducing unnecessary complexity in its technology landscape.

2.1.11. Base ArcGIS Enterprise Deployment In-house¶

The scope of this implementation is focused on deploying what Esri terms a "base" ArcGIS Enterprise configuration. To align with existing know-how and IRD's cloud maturity levels, deploying ArcGIS Enterprise in Kubernetes was excluded from considerations. Similarly, to conform with the Department's data sovereignty principles and conformance with data hosting requirements, adopting Esri's Software-as-a-Service (SaaS) offerings such as ArcGIS Online as core platform components was excluded from the scope of the project.

Rationale¶

Focusing on a base deployment simplifies the initial implementation, reduces complexity and allows the team to master foundational cloud deployment patterns for ArcGIS Enterprise before considering more advanced or alternative architectures.

Application¶

• The core components deployed will be Portal for ArcGIS, ArcGIS Server (including a hosting server site), two ArcGIS Web Adaptor instances per environment (hosted on Azure App Service) and the relational ArcGIS Data Store (with a minimal role supporting the hosting server).
• Advanced server roles (e.g., GeoEvent Server, Image Server beyond the basic Raster Store configuration) may be considered in future phases but are not part of this initial scope.

2.1.12. Standardised Environments (DEV, UAT, PROD)¶

Three distinct, standardised environments will be established: Development (DEV), User Acceptance Testing (UAT) and Production (PROD).

Rationale¶

Segregated environments are crucial for a structured development lifecycle, enabling safe testing, quality assurance and robust production operations. Standardisation, achieved through automation, ensures consistency and reduces environment-specific issues.

Application¶

• DEV & UAT: Core ArcGIS Enterprise components (Portal for ArcGIS, ArcGIS Server and ArcGIS Data Store) will be deployed on separate, dedicated Azure Virtual Machines per component within each environment. These VMs will utilise lower Azure SKUs compared to Production to meet minimum system requirements and optimise costs, while maintaining architectural parity. ArcGIS Web Adaptors will run on lower-tier Azure App Service plans. These non-production environments will not feature the High Availability (intra-region) or Disaster Recovery (inter-region) configurations planned for the Production environment, focusing instead on functional parity and cost-effectiveness.
• PROD: A multi-tier architecture will be implemented for performance, scalability and resilience. Portal for ArcGIS, ArcGIS Data Store and ArcGIS Server (via VMSS) will reside on dedicated compute resources. Azure PaaS services will be fully dedicated, high-tier and configured with appropriate redundancy (e.g., Zone-Redundant Storage, Geo-Redundant Storage).
• The Production environment will be replicated across two Azure regions: Australia Southeast (Melbourne) as the primary active region and Australia East (Sydney) as the passive disaster recovery region. A Global Server Load Balancer (GSLB) will manage automatic failover.

The core principles outlined above will guide all aspects of the ArcGIS Enterprise implementation on Azure, ensuring a modern, maintainable and robust platform that aligns with enterprise architecture standards while delivering the required GIS capabilities. These principles establish clear boundaries and expectations for the technical approach, providing a framework for decision-making throughout the implementation process.

The architecture adopted for this project is a practical manifestation of IRD's data & platform strategy. It moves beyond a simple lift-and-shift, transforming the GIS platform into a modern, cloud-native service that embodies key strategic imperatives such as operational efficiency, data democratisation, robust security and cost-effective scalability. This alignment ensures that investment in GIS modernisation propels the broader organisational journey towards cloud maturity.