The team chose an event-driven integration pattern for inter-agency case updates after debating hub-and-spoke alternatives. What documentation practice best preserves that rationale?
Select an answer to reveal the explanation.
Short Explanation
Future-you will not remember why the team picked events over the hub. Write a short decision record—context, choice, consequences—so the next crew can evolve safely.
Full Explanation
Significant integration pattern choices—such as selecting event-driven updates for inter-agency case exchange after comparing hub-and-spoke alternatives—should be captured in architecture decision records. An ADR preserves context, constraints, options considered, the decision, and consequences so future municipal teams can evolve the estate safely when staff rotate or drivers change. That transparency improves onboarding, auditability of rationale, and resistance to accidental undo of sound choices. Relying only on hallway memory loses trade-offs as soon as participants leave. Hiding the choice inside a vendor quote binds rationale to a procurement artifact that future teams may not revisit or understand as architecture. Documenting only the final logo choice without constraints or rejected options records branding, not decision quality. Exam caveat: ADRs should be concise and living enough to stay useful; they are not a substitute for interface contracts or runbooks, and not every tiny tweak needs an ADR—reserve them for consequential pattern decisions. Operational check: write an ADR for the event-driven choice with context, alternatives, and consequences; store it in the architecture repository; link it from the integration catalog; and require an ADR update or new record before reversing the pattern.