Security & policy
Azure Policy, Defender, Key Vault, encryption and network segmentation apply across every platform boundary.
Architecture blueprint 01
Azure Target-State Architecture
A secure, observable application and insight platform with clear identity, integration, data and recovery boundaries.
- Model
- Logical target-state architecture
- Scope
- Azure / D365 / data / insight
- Status
- Illustrative target pattern
Designed outcome
A scalable foundation for internal applications, controlled integrations and embedded decision support.
Architecture in one view
A business service, not a collection of resources.
The logical flow shows the principal ownership boundaries. The detailed explorer below adds the identity, data, trust, observability and recovery decisions needed to make each hand-off safe and supportable.
Logical architecture / target state
Identity-led. API-isolated. Observable by design.
A logical Azure pattern for secure internal applications, managed integration and embedded insight. Each lane marks an ownership boundary; the control plane applies end to end.
Read left to right
People & entry: Employees & partners, Service teams, business users and approved partner personas.; Secure portal, Role-aware navigation, task entry and embedded decision support.. Identity boundary: Microsoft Entra ID, Single sign-on, lifecycle control and managed identities.; MFA & conditional access, Risk, device and location-aware access decisions.; Roles & least privilege, Group-led access to applications, APIs and governed data.. Application layer: React applications, Accessible portals, operational tools and reporting surfaces.; Azure App Service, Managed compute, release slots and autoscale boundaries.. API & workflow: API Management, Authentication, throttling, versioning and policy enforcement.; Azure Functions, Event-driven services, scheduled jobs and lightweight APIs.; Logic Apps & messaging, Durable process orchestration, queues and managed connectors.. Business platforms: Dynamics 365, Customer, service and operational business processes.; Dataverse, Governed entities, business rules and secure service access.; Integration services, Controlled connections to ERP, ecommerce and external services.. Data & insight: Azure SQL, Application data, controlled replicas and resilient services.; Azure Data Lake, Replayable history, governed zones and lineage-aware storage.; Power BI Embedded, Secure semantic models surfaced inside role-aware applications.
01 / CHANNEL People & entry
Known users enter through one controlled experience.
- ActorsEmployees & partners
Service teams, business users and approved partner personas.
- ExperienceSecure portal
Role-aware navigation, task entry and embedded decision support.
- ActorsEmployees & partners
02 / TRUST Identity boundary
Identity provides the first and persistent control plane.
- IdentityMicrosoft Entra ID
Single sign-on, lifecycle control and managed identities.
- PolicyMFA & conditional access
Risk, device and location-aware access decisions.
- AuthorisationRoles & least privilege
Group-led access to applications, APIs and governed data.
- IdentityMicrosoft Entra ID
03 / EXPERIENCE Application layer
Composable experiences keep presentation separate from capability.
- Front endReact applications
Accessible portals, operational tools and reporting surfaces.
- RuntimeAzure App Service
Managed compute, release slots and autoscale boundaries.
- Front endReact applications
04 / ORCHESTRATE API & workflow
Versioned contracts isolate applications from platform change.
- GatewayAPI Management
Authentication, throttling, versioning and policy enforcement.
- ComputeAzure Functions
Event-driven services, scheduled jobs and lightweight APIs.
- WorkflowLogic Apps & messaging
Durable process orchestration, queues and managed connectors.
- GatewayAPI Management
05 / OPERATE Business platforms
Systems of engagement retain explicit ownership boundaries.
- CRMDynamics 365
Customer, service and operational business processes.
- PlatformDataverse
Governed entities, business rules and secure service access.
- AdaptersIntegration services
Controlled connections to ERP, ecommerce and external services.
- CRMDynamics 365
06 / DECIDE Data & insight
Operational storage and analytics are deliberately separated.
- OperationalAzure SQL
Application data, controlled replicas and resilient services.
- AnalyticalAzure Data Lake
Replayable history, governed zones and lineage-aware storage.
- InsightPower BI Embedded
Secure semantic models surfaced inside role-aware applications.
- OperationalAzure SQL
Monitoring & evidence
Application Insights, Log Analytics, platform metrics and audit trails connect service health to accountable ownership.
Recovery & continuity
Tested backups, availability design, recovery objectives and runbooks protect the full business service, not isolated resources.
Logical view, not a deployment topology. Subscription design, regions, network routes, service tiers and recovery objectives should be validated against workload criticality.
Tier before topology
Critical journeys, data sensitivity, SLO, RTO and RPO determine service tiers, zones and regions—not the other way around.
Trust at every boundary
Identity, token audience, authorization and data purpose are re-evaluated whenever a journey crosses edge, API, platform or data boundaries.
Contracts absorb change
Versioned APIs, events and data products isolate portal journeys from Dynamics, Dataverse and downstream platform lifecycles.
Evidence closes the loop
SLOs, policy, traces, reconciliation and recovery exercises turn the architecture into an operable service rather than a static diagram.
Nine-stage deep dive
Follow every decision through the service.
Each stage names its Azure role, the boundary being crossed, the control gate, the assurance evidence and the trade-off being accepted. Arrow-key navigation follows the same order as the architecture flow.
Logical pattern / service and tier validation requiredBoundary lensIdentityTrustDataObservabilityRecovery
STAGE 01 / TARGET-STATE DECISION
Users & personas
Known people, explicit purpose, governed entry.
Purpose
Separate employee, service-team, partner and privileged-administrator journeys before a technology route is selected. Each persona receives only the access, data and operating path needed for its role.
Architecture decision
Use tenant identities for the workforce, governed B2B or External ID patterns for partners, and separate privileged identities for administration. Do not create application-local user stores or shared operator accounts.
Azure service mapping
Services earn a specific role
Microsoft Entra ID
Primary workforce identity and authentication authority.
Entra External ID / B2B
Controlled partner onboarding without unmanaged local credentials.
Conditional Access
Risk, device, location and authentication-strength policy.
Identity Governance & PIM
Access packages, reviews and time-bound privileged access.
Boundary crossings
Trust is re-established at every hand-off
Identity
A person becomes a trusted actor only after tenant, persona and authentication-strength checks pass.
Trust
External tenants and unmanaged devices are treated as lower-trust channels with narrower permissions.
Observability
Sign-in risk, access-package assignment and privileged activation are retained as security evidence.
Control gates
What must be true
- Phishing-resistant MFA for privileged roles and high-impact journeys
- Two monitored emergency-access accounts with a tested operating procedure
- Quarterly access reviews and joiner, mover and leaver reconciliation
- Persona-to-role mapping approved by the accountable business owner
Assurance evidence
How the decision is proved
- Persona and access matrix
- Conditional Access report-only results
- Access-review completion record
- Emergency-access exercise
STAGE 02 / TARGET-STATE DECISION
Secure portal & ingress
One governed front door; no bypass to the workload.
Purpose
Provide an accessible, role-aware entry point while containing internet, partner and corporate-network traffic at an explicit ingress boundary.
Architecture decision
Select a single WAF-protected ingress pattern by audience: Azure Front Door Premium for globally distributed internet or partner access, or Application Gateway WAF for private and regional entry. Keep the App Service origin private where the approved tier and connectivity model support it.
Azure service mapping
Services earn a specific role
Azure Front Door Premium / Application Gateway WAF
Mutually selected edge, TLS, WAF and routing control.
Azure App Service
Managed portal runtime with deployment slots and health probes.
Azure Private Link & Private DNS
Private origin and deterministic name resolution where justified.
Azure Key Vault
Certificate and cryptographic material under RBAC control.
Boundary crossings
Trust is re-established at every hand-off
Trust
TLS termination, WAF inspection, host validation and route allow-listing occur before workload traffic is accepted.
Identity
The portal starts authentication but grants no capability until the API validates token audience, issuer and role claims.
Observability
Edge request IDs, WAF actions and origin traces are correlated without logging tokens or sensitive payloads.
Recovery
DNS, certificates, WAF policy and origin routing are reproducible from code in the recovery region.
Control gates
What must be true
- Public origin access disabled when Private Link is selected
- TLS, security headers, content security policy and upload limits tested
- Separate deployment path for the SCM endpoint and private DNS records
- Synthetic probes exercise sign-in and a critical authenticated journey
Assurance evidence
How the decision is proved
- Ingress and DNS decision record
- WAF policy test output
- DAST and dependency scan results
- Synthetic-journey dashboard
STAGE 03 / TARGET-STATE DECISION
Identity control plane
Authenticate centrally; authorise at every capability.
Purpose
Turn authenticated identities into bounded application permissions and remove durable secrets from service-to-service communication.
Architecture decision
Define environment-specific app registrations, delegated scopes and application roles in Entra ID. APIs enforce authorization locally; workloads use managed identities and RBAC for Azure resources, with Key Vault reserved for credentials that cannot be eliminated.
Azure service mapping
Services earn a specific role
Entra app registrations
Token audiences, delegated scopes and application roles.
Managed identities
Secretless workload authentication to supported Azure services.
Azure RBAC & PIM
Least-privilege resource control and eligible administration.
Azure Key Vault
Controlled exception for certificates, keys and external secrets.
Boundary crossings
Trust is re-established at every hand-off
Identity
Human tokens, workload identities and deployment identities have distinct audiences, permissions and lifecycles.
Trust
Every API validates issuer, audience, expiry and required scope; the network location alone never confers trust.
Data
Claims contain identifiers and authorization context, not sensitive business data or unrestricted group inventories.
Observability
Identity events and authorization denials are correlated to a pseudonymous subject and operation ID.
Control gates
What must be true
- Separate registrations, identities and role assignments per environment
- No client secrets in source, pipeline variables or application settings
- Explicit consent and admin-consent workflow for privileged scopes
- Automated stale credential, ownerless registration and excessive-role checks
Assurance evidence
How the decision is proved
- OAuth scope and role catalogue
- Identity data-flow threat model
- Managed-identity coverage report
- Privileged role-assignment export
STAGE 04 / TARGET-STATE DECISION
Application layer
Stateless services, bounded capabilities, reversible releases.
Purpose
Host accessible React experiences and cohesive business services without coupling presentation, workflow and data-platform lifecycles.
Architecture decision
Use Azure App Service as the default managed runtime for the portal and cohesive APIs. Keep instances stateless, move long-running work to messaging, and use deployment slots, health checks and feature flags for controlled releases. Introduce another compute platform only for a measured requirement.
Azure service mapping
Services earn a specific role
Azure App Service
Managed web and API runtime, scale-out and deployment slots.
Azure App Configuration
Environment configuration and controlled feature flags.
Azure Key Vault references
Runtime retrieval for the small set of unavoidable secrets.
Application Insights
OpenTelemetry traces, dependencies, exceptions and journey health.
Boundary crossings
Trust is re-established at every hand-off
Trust
The runtime accepts traffic only from the approved ingress or API gateway and uses managed identity for dependencies.
Data
Each service owns its operational data access; the browser never connects directly to SQL, Dataverse or analytics stores.
Observability
W3C trace context follows the user journey across portal, API, queue and downstream dependency.
Recovery
Immutable artifacts, configuration-as-code and stateless instances permit rebuild in a second region.
Control gates
What must be true
- Readiness and liveness checks distinguish process health from dependency health
- No in-memory session dependency; shared state is explicit and resilient
- Zone redundancy and minimum instance count selected from the approved service tier
- Canary or slot release with automated smoke test and rollback gate
Assurance evidence
How the decision is proved
- C4 container and component views
- Software bill of materials
- Load and resilience test report
- Release and rollback record
STAGE 05 / TARGET-STATE DECISION
API, events & workflow
Contracts isolate change; queues contain failure.
Purpose
Provide a governed capability boundary for synchronous APIs, durable business workflows and event-driven integration.
Architecture decision
Publish versioned APIs through API Management. Use Service Bus for durable commands and integration events, Functions for bounded compute, and Logic Apps Standard for visible orchestration and managed connectors. Every asynchronous operation is idempotent, correlated and replayable.
Azure service mapping
Services earn a specific role
Azure API Management
OAuth enforcement, quotas, versioning, transformation and API analytics.
Azure Service Bus
Durable queues/topics, dead-lettering and workload decoupling.
Azure Functions
Event handlers, scheduled jobs and narrowly scoped compute.
Logic Apps Standard
Long-running orchestration and governed managed connectors.
Azure Event Grid
Reactive notification for lightweight platform events.
Boundary crossings
Trust is re-established at every hand-off
Trust
APIM validates OAuth scopes and rate limits at ingress; managed identity authenticates to supported back ends.
Data
Schemas are versioned, payloads are minimized and sensitive fields are excluded from gateway and workflow logs.
Observability
Correlation, causation, retry count, queue age and dead-letter reason form one operational narrative.
Recovery
APIOps/IaC rebuilds the gateway; messaging replication or replay strategy is chosen from the agreed RPO.
Control gates
What must be true
- OpenAPI and asynchronous contracts reviewed before implementation
- Timeout, retry, circuit-breaker and rate-limit policies tested together
- Poison messages quarantined with an owned replay and reconciliation runbook
- Production APIM tier and units selected against zone, region and throughput NFRs
Assurance evidence
How the decision is proved
- OpenAPI and event contract repository
- APIM policy tests
- Queue replay and dead-letter exercise
- Dependency failure-mode test
STAGE 06 / TARGET-STATE DECISION
Business platforms
Systems of record stay authoritative, not entangled.
Purpose
Connect Dynamics 365, Dataverse and external operational platforms through owned contracts while preserving system-of-record and data-stewardship boundaries.
Architecture decision
Treat Dynamics 365 and Dataverse as governed SaaS capabilities, never as databases to bypass. Encapsulate connectors in integration services, prefer platform events or supported change mechanisms, and reconcile every write path to its accountable record owner.
Azure service mapping
Services earn a specific role
Dynamics 365
Customer, service and operational business processes.
Microsoft Dataverse
Governed business entities, rules, security roles and audit.
Logic Apps connectors
Policy-controlled SaaS and line-of-business integration.
Service Bus adapters
Rate isolation, buffering and canonical integration events.
Power Platform admin centre
Environment, DLP, capacity and lifecycle governance.
Boundary crossings
Trust is re-established at every hand-off
Identity
Application users and service principals receive the smallest Dataverse security role and API scope needed.
Trust
Connectors are allowed by environment DLP policy; unsupported direct database access is prohibited.
Data
Entity ownership, lawful purpose, retention and source-of-truth rules are explicit before synchronization.
Observability
API consumption, platform throttling, reconciliation drift and failed business operations are monitored together.
Recovery
SaaS backup/restore capabilities, solution exports and downstream replay are tested as one recovery path.
Control gates
What must be true
- No production changes outside managed solution and release processes
- DLP policy separates business, non-business and blocked connectors
- API-limit budgets, backoff and change-volume tests precede cutover
- Daily reconciliation for financially or operationally critical entities
Assurance evidence
How the decision is proved
- System-of-record and entity-owner matrix
- Integration and connector catalogue
- DLP policy export
- Reconciliation exception report
STAGE 07 / TARGET-STATE DECISION
Operational & analytical data
Separate workloads; preserve lineage; prove recovery.
Purpose
Protect transactional performance while creating a replayable, governed route from source events to trusted analytical products.
Architecture decision
Use Azure SQL Database for application-owned operational state and ADLS Gen2 for immutable landing, conformed and curated analytical zones. Orchestrate ingestion with Data Factory, catalogue critical data in Microsoft Purview, and expose data through contracts rather than shared database access.
Azure service mapping
Services earn a specific role
Azure SQL Database
Resilient operational data with point-in-time recovery and optional geo strategy.
Azure Data Lake Storage Gen2
Replayable raw, conformed and curated analytical zones.
Azure Data Factory
Scheduled and event-triggered ingestion with monitored pipelines.
Microsoft Purview
Catalogue, classification, lineage and accountable data ownership.
Private Link & Key Vault
Private data-plane access and controlled cryptographic material.
Boundary crossings
Trust is re-established at every hand-off
Identity
Managed identities receive separate read, write and administration roles; analysts never inherit pipeline identities.
Trust
Firewalls, private endpoints and DNS contain the data plane, subject to tier and regional validation.
Data
Raw, conformed and curated zones have distinct ownership, retention, quality gates and consumer contracts.
Observability
Freshness, completeness, schema drift, reconciliation and lineage are first-class service signals.
Recovery
Zone redundancy, SQL failover groups or geo-restore, storage replication and tested restore points map to explicit RPO/RTO tiers.
Control gates
What must be true
- Critical entities have owner, classification, retention and quality rules
- Schema changes fail safely and require a versioned data-contract decision
- Operational databases do not serve unmanaged reporting workloads
- Restore, failover and data-reconciliation exercises run at the agreed cadence
Assurance evidence
How the decision is proved
- Data contracts and canonical definitions
- Purview lineage and classification export
- Data-quality scorecard
- SQL and lake restore evidence
STAGE 08 / TARGET-STATE DECISION
Embedded insight
One semantic truth, filtered by identity and purpose.
Purpose
Place governed, action-led insight inside the operational journey without turning browser filters or workspace membership into a security boundary.
Architecture decision
Choose the Power BI embedding model by audience: embed for the organisation for licensed internal users, or app-owns-data with a service principal for external scenarios. Enforce row- and object-level security in semantic models and generate short-lived embed tokens server-side.
Azure service mapping
Services earn a specific role
Power BI Embedded / Fabric capacity
Dedicated analytical rendering capacity selected from measured demand.
Power BI semantic models
Governed measures, row-level security and object-level security.
Microsoft Entra service principal
Scoped application identity for app-owns-data embedding.
Azure Monitor capacity metrics
Utilisation, throttling and user-experience signal.
Boundary crossings
Trust is re-established at every hand-off
Identity
Portal identity is translated to a permitted semantic role; service-principal permission is never treated as the end-user permission.
Trust
Embed tokens are issued server-side, short-lived, minimally scoped and never written to browser or telemetry logs.
Data
RLS/OLS and workspace isolation protect data; client-side JavaScript filters improve UX but are not security controls.
Observability
Capacity saturation, render latency, refresh age, RLS denials and report audit events feed service health.
Recovery
Deployment pipelines, source-controlled model definitions and a data refresh plan recreate the reporting surface.
Control gates
What must be true
- Automated RLS and OLS tests cover every persona and sensitive entity
- Workspace roles are restricted; viewers do not receive build access by default
- Capacity load tests include peak concurrency and refresh overlap
- Freshness indicators and a graceful unavailable state are visible to users
Assurance evidence
How the decision is proved
- Embedding-mode decision record
- Persona-by-RLS automated test
- Capacity and concurrency test
- Semantic model lineage and refresh SLA
STAGE 09 / TARGET-STATE DECISION
Operational control plane
Policy, telemetry and recovery apply end to end.
Purpose
Operate the architecture as one business service with preventative guardrails, traceable changes, actionable telemetry and tested recovery.
Architecture decision
Place shared policy, security posture, connectivity and observability in platform subscriptions while keeping workload teams accountable for service SLOs and runbooks. Deploy resources and alerts through Bicep, and treat recovery evidence as a release requirement.
Azure service mapping
Services earn a specific role
Azure Policy
Preventative and detective guardrails across subscriptions.
Azure Monitor, Application Insights & Log Analytics
Metrics, logs, traces, SLOs and actionable alert routing.
Microsoft Defender for Cloud
Cloud security posture and workload protection recommendations.
Microsoft Sentinel
Optional security analytics and response for the approved SOC model.
Azure Backup, Service Health & IaC
Protected recovery points, platform awareness and repeatable rebuild.
Boundary crossings
Trust is re-established at every hand-off
Identity
Platform operators, workload operators, pipelines and emergency responders have separate eligible roles.
Trust
Policy prevents public exposure, weak TLS, unapproved regions and missing diagnostic settings where the workload baseline requires them.
Data
Telemetry has a classification, redaction rule, retention period and cost owner; sensitive payload logging is prohibited.
Observability
Golden signals and business-journey SLOs drive alerts; resource health alone is insufficient.
Recovery
IaC, backups, key access, routing, runbooks and people are exercised together against the declared RTO/RPO.
Control gates
What must be true
- SLO burn-rate alerts route to an owner and link directly to a runbook
- Policy exemptions are time-bound, owned and reviewed
- Soft delete, protected recovery points and resource locks follow data criticality
- Quarterly service review covers risk, availability, capacity, cost and recovery evidence
Assurance evidence
How the decision is proved
- Policy compliance and exemption report
- SLO and alert-quality dashboard
- Restore/failover exercise record
- Operational readiness and service-acceptance pack
Use the stage buttons or the arrow keys to follow the architecture. Home and End move to the first and final control boundary.
Cross-cutting boundaries
Seven planes contain blast radius.
The stages describe flow; these planes describe containment. A production design should be able to point to the decision and evidence for every one of them.
Human and workload identity
Separates people, privileged operators, deployment pipelines and managed workload identities.
DecisionTokens and RBAC establish access; network position and application UI state do not.
ProofRole catalogue, sign-in evidence, PIM export and managed-identity coverage.
North-south ingress
Contains internet, partner and corporate traffic before it reaches portal or API runtimes.
DecisionOne WAF path, explicit origin isolation and no direct workload bypass.
ProofRoute inventory, WAF tests, DNS evidence and external attack-surface scan.
East-west capability
Separates portal, APIs, workflows, SaaS adapters and data services.
DecisionManaged identity, scoped APIs and private data-plane routes replace implicit network trust.
ProofData-flow diagram, API policy tests and dependency authorization failures.
Operational data ownership
Protects application and SaaS systems of record from unmanaged analytics and direct coupling.
DecisionWrites pass through an owned capability; change is published through a contract.
ProofSystem-of-record matrix, data contracts and reconciliation controls.
Analytical promotion
Separates raw, conformed, curated and semantic data products.
DecisionOnly quality-approved, classified and lineage-aware models cross into governed insight.
ProofPurview lineage, data-quality gates and RLS/OLS test results.
Telemetry and evidence
Correlates user journey, edge, runtime, API, queue, platform and data health.
DecisionOperation IDs cross components; sensitive payloads and credentials never enter telemetry.
ProofTrace coverage, redaction tests, SLO dashboard and alert-to-runbook drill.
Service recovery
Coordinates regional routing, rebuild, data failover/restore, messaging and human response.
DecisionRecovery tier is set per business flow and proven end to end, not inferred from individual service features.
ProofRecovery dependency map, timed exercise, reconciled data and signed exception log.
Non-functional requirements
Quality has measurable gates.
Candidate targets are organised around the Azure Well-Architected pillars. They are starting hypotheses, not contractual commitments; workload owners must validate them against business impact, region and selected service tiers.
Baseline status / validate before detailed design| Pillar | Measure | Candidate target | Architecture response | Acceptance evidence |
|---|---|---|---|---|
| Reliability | Availability | Candidate Tier-1 portal/API SLO: 99.9% monthly, measured from an authenticated critical journey. | At least two instances, supported zone-redundant tiers, dependency timeouts and graceful degradation. | Synthetic journey, SLO burn-rate dashboard and dependency-failure test. |
| Reliability | Recovery | Candidate Tier-1 RTO ≤ 4 hours and RPO ≤ 15 minutes; lower tiers documented separately. | IaC rebuild, regional data strategy, replayable messaging and rehearsed decision authority. | Timed failover/restore exercise with data reconciliation and business sign-off. |
| Security | Identity & secrets | 100% of human access under MFA/Conditional Access; managed identity first; no shared production accounts. | PIM, scoped app roles, managed identities, Key Vault exception process and access reviews. | Identity coverage report, secret scan and privileged-access export. |
| Security | Data protection | All critical data classified, encrypted, owner-assigned and access-tested; no sensitive payload telemetry. | Private data plane where justified, RBAC, Purview, RLS/OLS, retention and redaction rules. | Classification/lineage export, authorization tests and telemetry redaction test. |
| Cost optimisation | Cost control | Budget and anomaly alerts in every environment; monthly unit-cost trend per active user or transaction. | Measured service tiers, non-production schedules, retention controls and capacity thresholds. | Cost allocation dashboard, forecast variance and documented tier decisions. |
| Operational excellence | Observability | 100% of Tier-1 journeys correlated; actionable detection within 5 minutes for known critical failure modes. | OpenTelemetry, golden signals, business events, owned alerts and linked runbooks. | Trace-coverage report and game-day alert-to-response timing. |
| Operational excellence | Deployability | All production infrastructure and policy deployed from reviewed code with a tested rollback path. | Bicep modules, policy-as-code, slots/canaries, automated smoke tests and immutable artifacts. | Pipeline evidence, drift report and successful rollback exercise. |
| Performance efficiency | Latency | Candidate p95 API latency < 750 ms for standard reads; portal LCP p75 < 2.5 s on the agreed device/network baseline. | Performance budgets, caching by data sensitivity, asynchronous long work and dependency budgets. | Load test and real-user/synthetic percentile dashboard. |
| Performance efficiency | Elasticity | Sustain 3× forecast peak without data loss; absorb 30 minutes of downstream interruption where queued. | Scale tests, queue-capacity model, backpressure and protected downstream limits. | Burst, soak and recovery-to-steady-state test results. |
| Product quality | Accessibility | WCAG 2.2 AA for critical portal journeys, including keyboard, screen-reader and 200% zoom use. | Accessible component baseline, automated checks and manual assistive-technology testing. | Accessibility conformance report and remediated journey audit. |
Risks & trade-offs
Complexity must buy down a named risk.
The target state deliberately avoids “maximum Azure” as a design goal. Each control changes cost, operability or user experience; residual risk remains visible after treatment.
RSK-01Reliability / CostHigh
Multi-region before the business needs it
Trigger
A regional target is selected without an agreed RTO/RPO, dependency support or operating model.
Treatment
Start with zone resilience and tested restore where it meets the objective; add warm standby or active paths only for an evidenced business flow.
Residual trade-off
Restore-led tiers accept longer regional recovery in exchange for materially lower cost and complexity.
RSK-02Security / OperationsHigh
Private networking without operability
Trigger
Private endpoints are introduced without DNS ownership, private deployment agents, diagnostics or break-glass access.
Treatment
Validate service/tier support, define DNS and deployment routes, and prove support access before public access is disabled.
Residual trade-off
Isolation is stronger, but incident diagnosis and developer onboarding take more engineering discipline.
RSK-03Reliability / DataHigh
Eventual consistency becomes invisible drift
Trigger
Queued updates to Dataverse, ERP or analytical stores fail after the originating request is accepted.
Treatment
Use idempotency, dead-letter ownership, business-level reconciliation, replay tooling and user-visible pending states.
Residual trade-off
Users may briefly see stale state; the design favours recoverability over distributed transactions.
RSK-04Security / CostMedium
Embedding model exposes or over-provisions insight
Trigger
Client filters are mistaken for authorization, or capacity is purchased before persona concurrency is measured.
Treatment
Select embedding mode by audience, test RLS/OLS automatically and load-test realistic refresh/concurrency overlap.
Residual trade-off
Stronger tenant isolation can require more workspaces and deployment/capacity administration.
RSK-05Operations / CostMedium
Telemetry volume without decision value
Trigger
Verbose payload logging, indefinite retention and duplicate platform logs drive cost while alerts remain noisy.
Treatment
Define signal purpose, sampling, redaction, retention and owner; review alert precision and unit cost monthly.
Residual trade-off
Sampling can reduce forensic depth, so security/audit events retain a separate evidence policy.
RSK-06Operational excellenceMedium
Service sprawl outpaces team capability
Trigger
Every integration selects a new Azure service without a reusable golden path, owner or support model.
Treatment
Default to the smallest approved pattern, record exceptions in ADRs and fund platform enablement before expansion.
Residual trade-off
A deliberate default can be less locally optimal but reduces cognitive load and recovery risk across the estate.
Delivery sequence
Prove a thin path before scaling the estate.
The sequence establishes the platform guardrails, proves one end-to-end journey, then adds integration, data and resilience. Exit evidence—not elapsed time—moves the architecture forward.
- PHASE 00Mobilise
Confirm service tiers
Name critical journeys, owners, data classes, users, constraints and candidate SLO/RTO/RPO targets.
Exit gateScope, decision authority, current-state evidence and measurable NFR hypotheses approved.
- Capability map
- NFR baseline
- Risk register
- Decision log
- PHASE 01Foundation
Land the trust boundary
Subscriptions, policy, identity, ingress, DNS, private connectivity, logging and deployment identities.
Exit gateA production-like landing zone deploys from code and passes identity, route and policy tests.
- Landing-zone IaC
- Policy set
- Identity model
- Threat model
- PHASE 02Golden path
Prove one thin journey
Portal → Entra → APIM → application → SQL with traces, alert, rollback and accessible UI.
Exit gateOne end-to-end journey meets candidate latency, security, telemetry and deployment gates.
- C4 views
- OpenAPI
- Pipeline evidence
- SLO dashboard
- PHASE 03Integrate
Add durable workflows
Service Bus, Functions/Logic Apps and a single business-platform adapter with replay and reconciliation.
Exit gateDependency failure, throttling, poison message and recovery scenarios pass a game day.
- Event contracts
- Replay tooling
- DLP policy
- Reconciliation report
- PHASE 04Decide
Promote governed insight
Operational change feed → lake zones → curated model → secured embedded report.
Exit gateLineage, freshness, quality, RLS/OLS and capacity evidence satisfy the named data owner.
- Data contracts
- Purview lineage
- RLS tests
- Capacity test
- PHASE 05Assure
Exercise and transition
Load, security, accessibility, failover/restore, cost and operational-readiness validation.
Exit gateService acceptance names support owners, residual risk, recovery evidence and improvement backlog.
- Game-day record
- Runbooks
- Service acceptance
- Roadmap backlog
Evidence & artifacts
Architecture leaves an auditable trail.
These artifacts keep design, delivery and operations connected. Each has an owner, a refresh trigger and a specific claim it is expected to prove.
Architecture decision record set
Owner / Architecture ownerRefresh / At every material choice
Context, options, trade-offs, service/tier validation, decision and review trigger.
Context, container & trust-boundary views
Owner / Solution architectRefresh / Versioned with releases
Who calls what, data classification, identity, protocol, ownership and failure boundary.
Threat model & control traceability
Owner / Security leadRefresh / Design and major change
Abuse cases, mitigations, residual risks and their test or policy evidence.
API, event & data contracts
Owner / Capability ownersRefresh / Contract version
Compatibility, ownership, schema, classification, idempotency and deprecation path.
Policy, identity & exposure report
Owner / Platform teamRefresh / Continuous / monthly review
Azure Policy state, exemptions, privileged roles, public endpoints and secret inventory.
Service-level evidence pack
Owner / Service ownerRefresh / Live / quarterly review
SLO, journey health, capacity, security signal, data freshness, incidents and unit cost.
Recovery exercise record
Owner / Service owner + business ownerRefresh / At least annually; Tier-1 more often
Actual RTO/RPO, decision timing, restore/failover, key access, routing and reconciliation.
Operational readiness & acceptance
Owner / Operations leadRefresh / Before production / major change
Support model, runbooks, alerts, ownership, licensing, cost, residual risk and rollback.
Design basis
Grounded in current guidance.
Microsoft guidance informed the service roles and trade-offs. Detailed design still needs subscription, region, SKU, licensing, quota and feature validation at the time of delivery.
This is a logical reference architecture. It is not a promise that every service, private-endpoint option, availability-zone feature or recovery mode exists in every region or tier.
The authoritative delivery record is the approved ADR set plus exported configuration and test evidence. Documentation links are a design input, not production proof.
01Azure Well-Architected FrameworkFive-pillar workload quality and trade-off structure.Opens in a new browser tab02Azure landing zone design principlesSubscription, policy and platform-foundation decisions.Opens in a new browser tab03Enterprise web app patternsManaged web workload and incremental modernisation patterns.Opens in a new browser tab04Use private endpoints for Azure App ServiceInbound isolation, DNS, SCM and tier constraints.Opens in a new browser tab05Architecture best practices for Azure API ManagementGateway tiers, resilience, observability and APIOps recovery.Opens in a new browser tab06Reliability in Azure Service BusMessage-data and metadata recovery trade-offs.Opens in a new browser tab07Azure SQL HA and disaster recovery checklistZone redundancy, failover groups, geo-restore and drill evidence.Opens in a new browser tab08Power BI embed-token guidanceWorkspace isolation, RLS and short-lived embed-token security.Opens in a new browser tab09Business continuity, HA and disaster recoveryFlow-specific resilience, IaC recovery and human-inclusive drills.Opens in a new browser tab
Architecture principles
The rules that survive product change.
Technology choices can evolve. These decision rules keep the architecture coherent as delivery moves from target state to transition and operation.
Identity is the first control plane
APIs isolate business capabilities
Operational and analytical workloads are separated
Monitoring and recovery are designed in, not added later