Integration landscape
Purpose: Maintain a living map of every system AEM touches, with owners, SLAs and failure impact — the incident-day treasure map.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Tech leads / architects | Owners |
| All engineers | Consumers |
The map (fictional PHI example)
┌────────────┐
Rating engine ◀──sync──│ │──events──▶ Analytics platform
(premiums) │ AEM │
CRM ◀──form leads──────│ │◀──SSO──── Corporate IdP
Doc platform ──PDFs───▶│ │◀──assets── Brand portal (ext. DAM)
└────────────┘The register (the part that matters)
One row per integration, kept in version control next to the code:
| Field | Example (rating engine) |
|---|---|
| System + owner team + contact | Rating engine — Pricing team — #pricing-support |
| Direction & mechanism | Inbound sync, scheduled job 02:00, REST |
| Data + classification | Premium tables — internal, no PII |
| Freshness contract | Daily; stale-tolerable 48h with "indicative" fallback |
| Failure impact + fallback | Plan pages show cached rates + label (resilience) |
| Auth + secret location | mTLS client cert — secrets store path |
| Runbook link | rating-sync runbook |
| Environment endpoints | dev/stage/prod URLs (config, not prose) |
Governance rhythm
- New integrations enter via design review against this register's fields — if you can't fill the row, you're not ready to build.
- Quarterly review: still used? owner still right? secret rotation date? deprecations upstream?
- The register is the first artefact opened in any integration incident — its accuracy is an operational control, not documentation hygiene.