Design
The design is organized platform first, delivery surface second. Start in one of the four lanes below rather than assuming that an Azure Local entity, signal, threshold, or dependency also applies to Hyper-V.
Each lane is a separate solution-design boundary. The SCOM Management Pack and Azure Monitor Health Models for the same platform may reference common platform evidence, but they do not share runtime architecture, deployment artifacts, health state, release lifecycle, or navigation ownership.
| Platform | SCOM Management Pack | Azure Monitor Health Models |
|---|---|---|
| Azure Local | Accepted design baseline | Accepted baseline; API revalidation next |
| Hyper-V | Comprehensive proposed architecture; active evidence research | Conditional research track |
Source ownership
Accepted ADR 0030 applies the same hierarchy to product source:
| Platform | SCOM source | Azure Monitor source |
|---|---|---|
| Azure Local | src/azure-local/scom-mp/ | src/azure-local/azure-monitor/ |
| Hyper-V | src/hyper-v/scom-mp/ | src/hyper-v/azure-monitor/ (reserved until ADR 0023 records a go decision) |
Optional SquaredUp content sits under the solution it visualizes. Shared research and build tooling must not become a shared runtime product dependency.
| Solution type | Optional visualization deliverable |
|---|---|
| Azure Local SCOM MP | SquaredUp Dashboard Server |
| Azure Local Azure Monitor | SquaredUp Cloud |
| Hyper-V SCOM MP | SquaredUp Dashboard Server |
| Hyper-V Azure Monitor | SquaredUp Cloud, conditional with the solution |
Shared design
The shared-design section contains only portfolio rules and patterns that are intended to span more than one lane. Shared intent does not automatically make an accepted Azure Local topology or signal contract valid for Hyper-V; the Hyper-V research and successor ADRs must adopt it explicitly.
Shared topics include:
- platform-first ownership and delivery-surface boundaries;
- common health-state vocabulary and rollup design principles;
- stable logical naming and customization goals;
- independent SCOM runtime and packaging boundaries;
- research evidence and decision gates; and
- repository, documentation, validation, and release conventions.
Azure Local design
The Azure Local platform design map points to two committed but independent solutions:
- Azure Local SCOM Management Pack design, including the Azure Local Distributed Application; and
- Azure Local Azure Monitor Health Models design.
The existing scope and topology, signal catalog, and most of the accepted early ADRs describe Azure Local unless a page says otherwise.
Hyper-V design
The Hyper-V platform design map points to two independent solution boundaries:
- Hyper-V SCOM Management Pack design is the active first phase, includes a comprehensive architecture map, and has a required, research-refined Hyper-V Distributed Application; and
- Hyper-V Azure Monitor design remains conditional on the Arc-enabled SCVMM research and ADR 0023.
Hyper-V can reuse sound patterns, but its support matrix, topology, Network ATC/manual/SCVMM-SDN network paths, discoveries, signals, defaults, and thresholds require their own evidence.
Architecture decisions
The ADR index includes a scope map showing which platform and delivery lane owns each accepted or proposed decision. Read the scope map before applying an older Azure Local-era ADR to newer Hyper-V work.