In this chapter
12.1 Architecture needs a decision system
A diagram cannot assign authority by itself. Governance identifies who decides, who supplies evidence, who operates the outcome and who may approve an exception. The operating model must fit the institution’s people rather than reproducing the structure of a much larger technology company. In the fictional two-engineer team, several roles may be held by the same person. The responsibilities must still be distinguishable, and critical approvals need an appropriate independent check. A separate platform capability does not automatically require a separate department.
12.2 Responsibility matrix
| Decision or activity | Accountable | Responsible for delivery | Consulted |
|---|---|---|---|
| Business transition policy | Business owner | Domain engineering owner | Finance and control |
| Data definition and retention | Data owner | Data steward and custodian | Legal or policy authority |
| Release readiness | System owner | Delivery engineer | Domain and support owners |
| Architecture exception | Authorized architecture or risk owner | Proposing team | Affected consumers |
| Incident coordination | System owner | Named incident lead | Business and security owners |
| Residual-risk acceptance | Authorized institutional owner | Risk coordinator documents | Architect and operators |
Accountability is not transferred to a software vendor by leaving a cell blank. The service contract should explain which responsibilities are delegated and which the institution retains.
12.3 Architecture decision lifecycle
A decision record includes context, evidence, constraints, options, recommendation, consequences and a review trigger. Proposed, accepted, superseded and withdrawn states should be explicit. Retain the rationale when replacing a decision so future teams understand why the earlier choice was reasonable. A lightweight review may be enough for a local module change. A cross-domain contract or sensitive data destination requires broader review. Classify changes by consequence rather than demanding the same committee for every commit.
12.4 Run the service after handover
Define service hours, support route, escalation, access review, patching, backup exercises and exception ownership. Incident response must include business communication and reconciliation of uncertain outcomes, not only restarting the process. Record operational knowledge where the team can use it. A runbook should name prerequisites, permissions, actions, verification and escalation. Test it with someone other than its author where possible. Personal availability is not a durable support model.
12.5 Governance outputs
- Role and decision-rights register.
- Service catalog with operating and consumer contracts.
- Architecture records and time-bounded exceptions.
- Incident, release and recovery responsibilities.
- Periodic evidence review and improvement backlog.
The acceptance gate is a scenario walkthrough: a failed release, uncertain approval or overdue reporting job must have a decision-maker and a response. Governance is effective when that route works, not when the organizational diagram looks complete.