Skip to content

Architecture Decision Records — azurelocal-scom-mp

Lightweight, numbered, immutable records of architectural decisions that govern the SCOM Management Pack and Azure Monitor Health Model design for Azure Local.

These are project-scoped ADRs. Org-wide platform standards live in AzureLocal/platform/decisions/.

Index

# Title Status
0001 Scope & topology — Azure Local infrastructure (3 layers, ~27 entities) ✅ Accepted
0002 Primary signal source — Azure Local PowerShell APIs + ARM/Resource Graph ✅ Accepted
0003 Health rollup policy — worst-state default with documented exceptions ✅ Accepted
0004 SCOM discovery strategy — PowerShell Discovery (not WMI) ✅ Accepted
0005 SCOM class hierarchy + hosting relationships (3-layer model) ✅ Accepted
0006 Azure Monitor entity model alignment (mirrors SCOM 1:1) ✅ Accepted
0007 Naming convention — cross-track parity ✅ Accepted
0008 Customization strategy — sealed MP + override pack tiers; Bicep params + tiers ✅ Accepted
0009 Alert vs health-state separation policy ✅ Accepted
0010 Cloud-side prerequisites contract (HCI Insights, AMA, DCMA, Service Group, RBAC, networking) ✅ Accepted
0011 L3 Azure-side scope: agent-local Arc health checks (Tier A) vs. management server ARM probes (Tier B) ✅ Accepted
0012 Azure Monitor Workspace vs Log Analytics Workspace: metrics routing for the health model (dual-topology support) ✅ Accepted
0013 Azure Monitor Health Model deployment strategy — Bicep-first, portal-bootstrap ✅ Accepted
0014 CI/CD pipeline strategy — GitHub Actions, OIDC, release-please ✅ Accepted
0015 Testing strategy — 5-layer pyramid, cross-track parity gate ✅ Accepted
0016 Signing & secrets management — two-key MP signing, OIDC SPNs ✅ Accepted
0017 Versioning & release policy — single repo SemVer, Conventional Commits, mike docs ✅ Accepted
0018 Self-observability — monitor the monitoring pipeline as a parallel root branch ✅ Accepted
0019 Cost, scale, and data retention — per-tier ingestion envelopes, sharding, retention policy ✅ Accepted

When to write an ADR

  • Any architectural choice that affects how the SCOM MP or Azure Monitor health model is built
  • Any decision that creates a constraint on Phases 3–6
  • Any cross-track parity decision
  • Any decision the next maintainer would otherwise have to re-litigate

Format

See template.md. Numbered sequentially, ZERO-padded to four digits. Filename is NNNN-kebab-case-title.md. Once an ADR is Accepted it is immutable — supersede it with a new ADR rather than editing it in place.

Workflow

  1. Open a PR adding the ADR with status Proposed
  2. Discuss and refine in PR review
  3. Merge with status Accepted once consensus reached
  4. If later overturned, write a successor ADR and mark this one Superseded by ADR XXXX