Synkronyx Landing Zone & Enterprise Governance Specification

1. Executive Summary & Core Principles

This specification defines the multi-product Azure Cloud Adoption Framework (CAF) Landing Zone architecture for Synkronyx Ltd. It establishes a zero-touch, automated “Vending Machine” pattern designed to stamp out product landing zones, management groups, subscriptions, and resource groups in under 5 minutes.

Core Principles

Single Legal & Billing Anchor: One top-level Billing Account (Synkronyx Ltd) under a Microsoft Customer Agreement (MCA) and one primary Billing Profile (bp-synkronyx-primary).
Product Cost Isolation: A dedicated MCA Invoice Section per product line (e.g. Event Route Optimiser) to guarantee exact gross margin tracking. The deployment script auto-discovers an existing section (matching the product) or provisions one on the fly, falling back to Billing Profile scope when no section is available.
Strict Management Group Governance: Policy enforcement and RBAC isolation managed at the Cloud Adoption Framework (CAF) Management Group tier.
Full-Name Taxonomy Primary Rule: All environments, subscriptions, parameter files, and resource groups use unabbreviated full names (development, test, support, preproduction, production, nonproduction) unless restricted by cloud provider character length limits.
Zero-Touch Workstation Automation: Single-source local execution using .env.local keys combined with parameter-driven Bicep deployments via VS Code build tasks (Ctrl + Shift + B).

2. Enterprise Hierarchy & Topology

Microsoft Entra ID / Tenant Boundary (Synkronyx Ltd)
│
├── Billing Account: Synkronyx Ltd (Legal MCA Contract & VAT Anchor)
│   └── Billing Profile: bp-synkronyx-primary (Generates 1 Monthly GBP Invoice)
│       └── Invoice Section: Event Route Optimiser (per-product cost isolation)
│
└── synkronyx  (Synkronyx CAF Root Management Group — existing)
    │
    ├── synkronyx-platform  (Platform Management Group — existing)
    │   ├── synkronyx-platform-prod
    │   └── synkronyx-platform-nonprod  (dev / sit / uat)
    │
    ├── synkronyx-shared-services  (Shared Platform Services — existing)
    │   ├── synkronyx-shared-identity    (Entra External ID CIAM anchor, Central Key Vault)
    │   ├── synkronyx-shared-networking  (Global DNS routing: synkronyx.cloud)
    │   ├── synkronyx-shared-monitoring  (Central Log Analytics)
    │   └── synkronyx-shared-automation  (Azure DevOps billing & automation)
    │
    └── synkronyx-landingzones  (Application Landing Zones — NEW; product workloads)
        │
        ├── Product Line: Event Route Optimiser (ERO)
        │   ├── synkronyx-ero-nonprod
        │   │   ├── synkronyx-ero-dev   (policy scope)
        │   │   ├── synkronyx-ero-test  (policy scope)
        │   │   └── Subscription: sub-sknx-ero-nonproduction (DevTest Workload — placed at vend time)
        │   │       ├── Resource Group: rg-sknx-ero-development
        │   │       ├── Resource Group: rg-sknx-ero-test
        │   │       └── Resource Group: rg-sknx-ero-preproduction
        │   │
        │   └── synkronyx-ero-prod
        │       └── Subscription: sub-sknx-ero-production (Production Workload — placed at vend time)
        │           └── Resource Group: rg-sknx-ero-production
        │
        └── Product Line: Logbook Manager (LBM) / Future Products
            ├── synkronyx-lbm-nonprod
            │   └── Subscription: sub-sknx-lbm-nonproduction
            └── synkronyx-lbm-prod
                └── Subscription: sub-sknx-lbm-production

CAF alignment note: ERO does not create a parallel root. The vending machine (infra/landing-zone/main.bicep, targetScope = 'tenant') references the existing synkronyx root, creates the synkronyx-landingzones parent, and nests the ERO Management Groups beneath it. Management Group tiers follow the existing CAF abbreviation style (-nonprod / -prod), while subscriptions and resource groups retain full-name taxonomy (sub-sknx-ero-nonproduction, rg-sknx-ero-development). Each subscription is bound to its Management Group at creation via the alias additionalProperties.managementGroupId property.

Naming Mapping Matrix (Canonical vs Length-Constrained)

This matrix is authoritative for environment naming and CIAM/data demarcation. Use full, human-readable environment names by default. Apply short tokens only when a resource type has strict length constraints.

CIAM Tier / Data Demarcation	Canonical Environment	Short Token (length-constrained only)
nonproduction	development	dev
nonproduction	test	test
production	support	supp
production	production	prod

Examples:

Human-readable resources (subscription/resource group): use canonical names such as sub-sknx-ero-nonproduction, rg-sknx-ero-development.
Length-constrained resources (for example Key Vault names): use short tokens such as kv-ero-nonprod-xxxxxx or environment short tokens where applicable.

Identity layout expectation (platform subscription):

rg-sknx-identity-nonproduction hosts shared CIAM identity resources for development and test.
rg-sknx-identity-production hosts shared CIAM identity resources for support and production.

3. Public & Non-Production Domain Taxonomy

All public and non-production web traffic for Event Route Optimiser (ERO) routes through Cloudflare as the authoritative registrar and DNS manager. Azure does not host or manage public DNS zones.

Host Domain Mapping

Environment	Host Domain	Purpose & Scope
Local Inner Loop	`http://localhost:4321`	Rapid local developer iteration on workstation/laptop
Development	`https://ero-development.synkronyx.cloud`	Public cloud sandbox & agentic verification
Test	`https://ero-test.synkronyx.cloud`	Automated CI/CD PR validation
Production	`https://ero.synkronyx.cloud`	Live festival attendee PWA application

Core Governance Rules

Production Naming Standard: Live attendee-facing PWA uses the clean product domain ero.synkronyx.cloud.
Non-Production Naming Standard: All pre-production and testing tiers explicitly append the full environment name (e.g. ero-development.synkronyx.cloud, ero-test.synkronyx.cloud).
Edge Routing & SSL: SSL certificates and edge routing rules are managed automatically within the Cloudflare Edge Worker/Pages environment via custom domain bindings.