Reference Architectures

Reference architectures give teams a shared starting point. They should show the default path, required controls, and places where teams can safely customize.

Architecture layers

What each reference should include

Each reference architecture should document:

• Use case and non-goals.
• Runtime platform and deployment model.
• Network boundaries, ingress, egress, and DNS.
• Identity, secrets, and authorization model.
• Data stores, retention, backup, and restore expectations.
• Observability signals, dashboards, alerts, and SLOs.
• Security controls and compliance evidence points.
• Cost drivers and scaling assumptions.
• Failure modes, rollback path, and operational ownership.

Common enterprise references

Maintain references for the common shapes the organization actually uses:

• Public web application.
• Internal web application.
• API service.
• Event-driven worker.
• Batch or scheduled job.
• Data pipeline.
• Shared platform service.
• Third-party integration.

Review cadence

Reference architectures should evolve. Review them after major incidents, platform migrations, new compliance requirements, or repeated exceptions. If most teams bypass a reference, the reference is probably wrong or too hard to use.