Cross-Program Decision Governance

Single-project ADRs are straightforward. Cross-program ADRs — decisions that affect multiple teams, repositories, and systems — are where governance becomes essential. "All services will use gRPC for inter-service communication" is not a single-project decision. It constrains every team in the organization. The governance structure must ensure that cross-program decisions are visible to all affected teams, that objections are heard before adoption, and that compliance is monitored after.

1. Decision Authority Matrix Define who can make which decisions. Project-level decisions: the project architect. Program-level decisions: the architecture review board with representation from affected teams. Enterprise-level decisions: the enterprise architecture function with stakeholder approval. The matrix prevents both bottlenecks (every decision escalated to enterprise review) and silos (cross-cutting decisions made unilaterally).
2. Cross-Program Review Process Cross-program ADRs follow a review period. The proposal is published to all affected teams. Teams have a defined window — typically two weeks — to review, raise objections, and propose alternatives. Silence is consent. After the review period, the decision is accepted, modified, or withdrawn based on feedback. The process adds latency to the decision but prevents the downstream conflict that an unreviewed decision creates.
3. Compliance Monitoring Cross-program decisions that are not enforced decay into suggestions. Automated compliance checks — linting rules, CI pipeline validations, architecture fitness functions — verify that implementations conform to the decisions. Non-compliance is flagged, not blocked — the team may have a valid reason for deviation, and the governance process should capture that reason as a documented exception.