Modernizing Enterprise Appian Platform on Azure

Background

The platform had been built by addition. Every new requirement got a new service, everything sharing one Azure subscription, with no thought given to isolation, security, or what the environment would look like in three years.

What started as an architecture review turned into something much bigger. Once the actual state of the environment was visible, the conversation shifted quickly from "what do we fix first?" to "we need to rebuild the foundation." The objective moved from patching individual issues to starting from the ground up.

The Challenge

Four structural problems, each making the others worse.

Security Exposure

The most pressing concern was the attack surface:

• No Web Application Firewall — Appian endpoints were exposed directly to inbound traffic
• No centralized firewall for inspecting or filtering network flows
• Backend VMs reachable from the internet with no ingress layer in front
• Weak identity controls — no MFA enforcement, no least-privilege model

For a government workload processing sensitive operational data, this wasn't a theoretical risk — it was an active one.

Environment Segmentation

All environments — development, QA, and production — shared a single Azure subscription:

• No policy isolation between environments
• Production changes could be inadvertently applied to live workloads
• Cost attribution was impossible — no way to track spend by environment or team
• Compliance reporting required manual separation of resources

Operational Inefficiency

Day-to-day operations were entirely manual:

• Appian services were started and shut down by hand
• Deployments had no pipeline — changes were applied directly by engineers
• No monitoring or alerting was configured
• Incident response depended entirely on human availability

Governance Gaps

Without any governance framework:

• No naming conventions — resources were named inconsistently or not at all
• No tagging strategy — ownership, cost centre, and environment were untracked
• Roles and responsibilities were undefined
• Access reviews had never been conducted

Architecture

The transformation was structured around four core layers: ingress security, network isolation, application resilience, and governance.

Azure Landing Zone

The foundation was a multi-subscription landing zone aligned with Microsoft's Cloud Adoption Framework:

Tenant Root
  Platform Subscriptions
    Connectivity  (hub network, firewall, DNS)
    Identity      (AAD, RBAC, MFA policies)
    Management    (monitoring, logging, automation)
  Workload Subscriptions
    Development
    QA / Testing
    Production

Each workload subscription is isolated by policy and network boundary. Shared services (firewall, DNS, Bastion) live in the hub and are consumed by all spokes via VNet peering.

Centralized Traffic Management

Azure Application Gateway was deployed as the single ingress point for all Appian traffic:

• Layer 7 HTTP/HTTPS routing with SSL termination
• URL-based and host-based routing rules
• DNS integration for domain resolution
• Backend pools pointing to the Appian cluster, never directly exposed

Direct internet access to backend VMs was removed entirely.

Defense-in-Depth Security

Two additional security layers sit alongside the Application Gateway:

WAF (Web Application Firewall)

• OWASP Core Rule Set 3.2 enabled in Prevention mode
• Custom rules for government-specific traffic patterns
• Real-time threat detection with logging to Log Analytics

Azure Firewall

• All outbound traffic inspected and policy-filtered
• Network Security Groups at subnet level for east-west control
• No lateral movement permitted between workload tiers

High Availability Cluster

The Appian deployment was re-architected as a 3-node cluster:

Automation scripts replaced manual service management:

• Scheduled startup/shutdown sequences
• Graceful failover handling
• Health check monitoring with automated alerting

Identity and Access Management

A least-privilege IAM model was enforced across the platform:

• RBAC roles defined for four personas: Developers, DevOps Engineers, Platform Admins, Support
• MFA enforced via Conditional Access policies for all privileged roles
• Service accounts replaced by Managed Identities where supported
• Quarterly access reviews scheduled and documented

DevOps and Automation

CI/CD pipelines were introduced for all deployment activity:

• Infrastructure changes deployed via pipeline with approval gates
• Application releases versioned and promoted through Dev → QA → Production
• Infrastructure-as-Code for all reproducible components
• No direct access to production for deployment purposes

Governance Framework

A governance-first model was embedded into the platform rather than layered on afterward.

Resource Governance

• Naming convention enforced via Azure Policy (audit and deny effects)
• Mandatory tags: environment, owner, cost-centre, application
• Tag compliance reported weekly via Azure Resource Graph

Access Governance

• RACI matrix defined for all platform operations
• Privileged Identity Management (PIM) for admin roles
• Access review cadence established

Operational Governance

• Centralised Log Analytics workspace for all diagnostic logs
• Azure Monitor alerts for availability, performance, and security events
• Audit trails retained for compliance requirements

Results

The platform went from a single ungoverned subscription to a structured, policy-enforced landing zone. New workloads can land without architectural rework — which matters more than it sounds when adoption accelerates. The governance framework isn't a one-time deliverable. It's how the environment stays clean over time.