Portfolio / Case Study 05

Enterprise Integration
Architecture

Cloud-Native Azure APIM Integration Layer Connecting Four D365 F&O Entities · Apex Digital

£1.85M
Programme
investment
£3.4M
Annual efficiency
gain
283%
3-year
ROI
4
D365 entities
integrated
Background

The Organisation
& The Situation

The Organisation
Apex Digital — a wholesale and distribution business serving approximately 6,000 B2B customers across UK, US, Australia, and Europe. Each region operates an independent instance of Microsoft Dynamics 365 Finance & Operations: GBSI (UK), USSI (US), AUAU (Australia), and EUAT (Europe).
The Situation
Four disconnected D365 environments had become a material operational problem. A buyer checking PO status logged into four systems. A finance director requesting a group trial balance received an Excel file assembled manually over two to three days. A credit manager had no visibility of cross-entity customer credit exposure. Integration failures were discovered when transactions failed — not when the failure occurred.
The Mandate
Build a cloud-native integration platform on Azure connecting all four D365 entities through a governed, monitored, and secured API layer
  • £2.49M annual addressable cost from manual reconciliation, data quality incidents, credit risk, and operational inefficiency
  • Single governed gateway for all D365 OData endpoints — no point-to-point connections
  • Unified React portal replacing four separate D365 logins and manual Excel files
  • Zero silent integration failures — all errors surfaced and actioned
My Role — What I Personally Owned
Programme Manager · End-to-End Delivery & Architecture Governance
  • Architecture governance — 5 ADRs authored and presented to IT Director
  • Technology decision framing — APIM vs MuleSoft vs point-to-point
  • Three specialist resource team: Azure cloud consultant, D365 architect, frontend developer
  • Fortnightly steering committee to IT Director and CFO
  • Risk management — dual SP security pattern; master data audit commissioning
  • Proposed and governed the Error-to-Incident Framework following discovery of an 11-day silent failure
Section 1

Architecture —
Five Components, One Platform

Each component solves a specific gap in the multi-entity estate. The architecture decision to use Azure APIM as the integration backbone — rather than point-to-point connections or a third-party ESB — was the most consequential design choice of the programme.

Component Technology Problem Solved
APIM
Azure API Management 		Azure APIM Premium Single governed gateway for all four D365 OData endpoints; rate limiting; JWT authentication; API versioning; audit logging; multi-entity routing via dataAreaId header policy
Portal
Headless React Portal 		React 18 + TypeScript Unified operations UI consolidating PO tracking, cross-entity inventory, customer credit exposure, trial balance, and vendor invoices — previously spread across four D365 logins and manual Excel files
Security
Dual Service Principal 		Azure Entra ID + Key Vault Read-only SP for all query operations; draft-write SP for mutations only; all secrets in Azure Key Vault with managed identity access; no credentials in code or environment variables
Validation
Master Data Validation Framework 		APIM Policy + Logic Apps 12 validation rules enforced at APIM layer before any write operation reaches D365; prevents invalid records at point of entry rather than detecting failures after the fact
Monitoring
Error-to-Incident Framework 		Log Analytics + Logic App + Azure DevOps APIM errors logged to Azure Monitor via KQL alert rules; Logic App converts threshold breaches into Azure DevOps incidents and Teams notifications; zero silent integration failures
Architecture Principle — Established at Programme Outset

"Every D365 call in the new architecture flows through APIM. There are no exceptions. This means one place to monitor, one place to version, one place to govern, and one audit log covering every entity, every call, every user."

Section 2

My Approach —
Key Decisions Made

Five Architecture Decision Records were produced during this programme. Each was driven by a business requirement — not a technology preference — and each required translating between what the business needed and what the architecture team proposed.

Decision What I Decided Alternatives Considered & Why Rejected
Integration backbone (ADR-EIA-01) Azure APIM Premium — single governed gateway for all four entities MuleSoft: £280K/yr licence cost, rejected on TCO. Point-to-point: architecturally prohibited for enterprise systems of this complexity. APIM: governed, versioned, monitored without third-party dependency
Security pattern (ADR-EIA-03) Dual service principal — read SP and write SP — with Key Vault secrets Single shared SP: over-privileged, fails least-privilege requirement. Per-entity-per-operation SPs: 16+ to manage, operationally unacceptable. Dual SP: manageable (8 total) and applies least privilege where it matters
Validation enforcement point (ADR-EIA-04) APIM-layer validation — 12 rules enforced before write reaches D365 Overnight batch validation: leaves a 24-hour window for invalid records to create operational failures. D365 in-application rules: discovered after the fact. Prevention at point of entry was the right answer
Entity onboarding sequence (ADR-EIA-02) Entity-by-entity — GBSI pilot first, then USSI, AUAU, EUAT Simultaneous onboarding of all four entities: compounds APIM configuration errors across all entities at once. GBSI stabilised before each subsequent entity added — same phased logic applied in every programme
Error governance (ADR-EIA-05) Error-to-Incident Framework — every APIM error creates an Azure DevOps incident Manual monitoring: already proven to fail — an 11-day silent batch failure was discovered in the discovery phase via a customer complaint, not IT alerting. Non-negotiable from that point
Security & Governance Controls — Established Before Any Entity Went Live
Dual Service Principal Pattern
Read SP: GET requests only across all six read tools. Write SP: POST to PurchaseOrderHeaders only. Separate Azure Key Vault secrets — managed identity access, no credentials in code or config files.
APIM Validation Framework
12 validation rules enforced at gateway layer — deployed in audit (non-blocking) mode during 6-week GBSI vendor remediation, then switched to enforcement mode after 95% pass rate achieved.
Error-to-Incident Framework
KQL alert rules in Azure Monitor → Logic App → Azure DevOps incident + Teams notification. Meta-monitor added for Logic App health after it failed silently in staging — the orchestrator itself is monitored.
Full Audit Logging
Every APIM call logged to Log Analytics with entity, operation, user context, success/fail, and duration. Available for security review, audit, and forensic investigation of any integration issue.
Section 3

Programme
Delivery

Phase 1 · Mo 1–2
Architecture & Setup
Architecture design; technology decisions; 3 specialist resources onboarded; 5 ADRs issued for IT Director review
PM: Facilitated architecture workshop; issued ADRs; onboarded team
Phase 2 · Mo 3–5
APIM + GBSI
Azure APIM provisioning; GBSI entity registration; dual SP security configuration; Key Vault setup
PM: Unblocked SP registration delay with IT Security; confirmed Key Vault architecture
Phase 3 · Mo 6–9
Validation + Portal
Master data audit (GBSI); 847 vendor record remediation; Validation Framework; React portal build
PM: Commissioned master data audit; managed D365 Architect / Frontend Dev dependency
Phase 4 · Mo 10–14
USSI · AUAU · EUAT
Three remaining entity onboarding; Error-to-Incident Framework; cross-entity UAT with Operations and Finance teams
PM: Escalated AUAU admin access block to IT Director; resolved in 4 days; 1-week impact absorbed
Phase 5 · Mo 15–18
Go-Live & PIR
Phased go-live: APIM + security → portal → Error-to-Incident Framework; hypercare; post-implementation review Month 18
PM: Sequenced go-live to reduce risk; 4-week Finance parallel run managed to portal sign-off
Section 4

Challenges &
How I Resolved Them

Challenge
Impact
Resolution
D365 OData schema differences between entities — AUAU had a non-standard field name on CustomerBalanceStatistics
AUAU D365 admin access unavailable for 3 weeks — blocked by internal procurement process
34% of GBSI vendor records failing Rule 06 — incomplete vendor configuration identified in master data audit
High — AUAU entity portal data would display incorrectly without normalisation
Medium — AUAU entity onboarding at risk; timeline impact threatened
High — enforcement mode of Validation Framework would block 34% of GBSI write operations
APIM transformation policy added for AUAU endpoint only; React portal receives normalised response from all entities; documented in ADR-EIA-01
PM escalated to IT Director; IT Director contacted AUAU entity MD directly; access granted in 4 days; 1-week timeline impact absorbed by parallel validation work
Validation Framework deployed in audit mode while GBSI finance team remediated 847 vendor records over 6 weeks; enforcement mode activated after 95%+ pass rate achieved
Logic App (Error-to-Incident orchestrator) failed silently in staging — ADO API credentials expired
Finance team resistant to retiring manual Excel trial balance — 3-day Excel process was a known workflow
Medium — silent failure of the incident orchestrator would defeat the purpose of the framework
Low — portal adoption at risk post go-live
Meta-monitor added for Logic App run failures; ADO service connection set to non-expiring PAT with 1-year review cycle; discovered in staging, not production
PM held 1:1 with Finance Director; agreed 4-week parallel run (Excel + portal); Finance Director signed off portal retirement after seeing same-day trial balance vs 3-day manual process
Section 5

Outcomes &
Business Impact

Results measured in the 6-month period following full go-live — all four entities live on APIM; React portal in production; Validation Framework in enforcement mode; Error-to-Incident Framework active.

−82%
D365 validation error rate
−91%
Cross-entity credit incidents
0
Silent integration failures post go-live
3d→1d
Trial balance cycle — same day
Metric Result Context
Manual reconciliation effort eliminated −18 hrs/week Operations team: 12 staff × 1.5 hours/week eliminated; equivalent to £740K annual saving at loaded cost
D365 validation error rate −82% From 47 D365 transaction failures/week to 8/week within 8 weeks of Validation Framework enforcement mode activation
Cross-entity credit incidents −91% From 11 incidents in prior 6-month period to 1 post go-live; £380K credit risk avoided
Trial balance reporting cycle 3 days → same day Finance Director accesses consolidated trial balance across all 4 entities in the React portal within seconds; previously 2–3 days of manual Excel assembly
Silent integration failures 0 Error-to-Incident Framework caught all APIM errors in first 6 months; 14 incidents raised and resolved via Azure DevOps; none reached the business undetected
APIM availability (all 4 entities) 99.7% 2 planned maintenance windows; 1 unplanned incident (AUAU entity D365 maintenance overlap, resolved in 47 minutes)
Programme delivered vs budget £1.87M £20K over original £1.85M (1.1%); overrun caused by AUAU D365 admin access delay requiring 3 additional consultant days
Projected 3-year ROI 283% Based on Year 2+ annualised benefits of £3.4M vs £1.87M investment plus £275K/yr run cost
Section 6

Lessons
Learned

What Worked
ADR discipline — documenting every significant decision with context, options considered, and rationale created a shared reference that eliminated re-litigation of decisions throughout the programme.
Audit mode before enforcement mode for the Validation Framework — giving the finance team 6 weeks to remediate before blocking was the right sequencing. Enforcement without remediation would have caused business disruption.
Meta-monitoring for the Error-to-Incident Framework — adding a health check on the Logic App itself proved its value when the orchestrator failed silently in staging. The monitor that monitors the monitor.
Fortnightly IT Director steering cadence — regular executive visibility meant risk decisions were escalated and resolved quickly. The AUAU access block was resolved in 4 days because the IT Director could act immediately.
What I Would Do Differently
Master data audit in Month 1, not Month 3 — the 34% vendor record failure rate in GBSI was a surprise that created timeline pressure. Data quality assessment should be a Week 1 workstream in any multi-entity programme.
Earlier engagement with local D365 admins in USSI, AUAU, and EUAT — onboarding access issues were predictable and should have been addressed as a formal dependency in Month 2, not discovered when the entity was needed.
Finance Director in UAT from Month 8, not Month 12 — the 4-week parallel run request was foreseeable. Earlier Finance involvement in portal design would have surfaced requirements and reduced resistance at go-live.
Formal benefit tracking from go-live — results reported here were collected manually post-programme. A Power BI benefit tracker built as part of the programme would have made the post-implementation review significantly more rigorous.
Section 7

Supporting
Artefacts

The following documents were produced during this programme and are available on request. The five ADRs have been published as enterprise architecture standards within Apex Digital.

ADR-EIA-001–005
Architecture Decision Records (5 ADRs)
Covering: integration backbone (APIM), entity onboarding sequence, dual SP security pattern, Validation Framework enforcement point, and Error-to-Incident Framework design. Published as enterprise standards.
Available on request
APEX-EIA-BC-001
Business Case — Enterprise Integration Architecture
£1.85M investment case covering addressable cost analysis (£2.49M/yr), technology comparison (APIM vs MuleSoft vs point-to-point), phased benefit realisation, and 3-year ROI model.
Available on request
APEX-EIA-VALID-001
Master Data Validation Framework — 12 Rules
12 APIM-layer validation rules covering vendor, customer, product, and financial entity records. Includes audit mode vs enforcement mode deployment approach and GBSI remediation workstream documentation.
Available on request
APEX-EIA-E2I-001
Error-to-Incident Framework Design
KQL alert rule definitions, Logic App orchestration design, Azure DevOps incident template, Teams notification configuration, and meta-monitor health check for the Logic App orchestrator itself.
Available on request
Note on Confidentiality: Client name has been anonymised for portfolio use. The programme structure, architectural decisions, technology stack, and outcomes described are based on real programme experience. Financial figures are representative of actual programme scale.