Decision Rights in a Federated Retail Architecture
A global retailer has 22 product teams across four regions. The central architecture board meets monthly and reviews all design decisions above $50,000; average decision lead time is six weeks. Teams report that 40% of decisions are reworked after review. A shadow architecture group has emerged in the largest region, making local standards that conflict with global ones. The CIO wants faster delivery and has asked you to redesign decision-making using OAA principles. Constraints: a new EU data residency regulation takes effect in eight months; the core commerce platform is being replaced; two global architects and four regional architects are available. There is no decision log. The board is risk-averse after a prior outage caused by an unapproved change. The outage cost $2.4 million in lost sales.
1. How would you classify architecture decisions to distribute decision rights while retaining necessary control? Give a taxonomy and examples.
Read the worked answer
Classify by reversibility and blast radius, not by dollar threshold. Type 1 decisions are irreversible or global: EU data residency, core commerce platform APIs, cross-region identity, and shared event contracts. Keep these with the two global architects and a named business owner, with documented trade-offs. Type 2 decisions are reversible and local: UI patterns, service internals, local caching, and team-level API design. Delegate these to product teams within guardrails. Add a third category: guardrail decisions that set constraints for security, resilience, and data classification, owned by global architects but enforced through fitness functions. Replace the $50,000 rule because cost is a poor proxy for architectural risk. Publish a decision-rights matrix and a one-page decision record template. This gives speed on local choices and control on the few choices that are expensive to undo.
2. Design a lightweight advice process and guardrails to replace the monthly board. How do you prevent the prior outage from recurring?
Read the worked answer
Use an architecture advice process: the decision owner consults affected teams and one architect, documents options and failure modes, and decides within 48 hours; there is no approval gate unless a guardrail is breached. Guardrails should be automated where possible: resilience patterns, change-freeze rules for high-risk windows, data residency checks, and canary and rollback standards. For high-blast-radius changes, require a lightweight pre-mortem and a named rollback owner. The prior outage came from an unapproved change, so the answer is not more approvals; it is faster visibility and reversible change. Add a post-incident review that updates guardrails, and track guardrail exceptions. A weekly 30-minute sync handles cross-region conflicts. This reduces lead time while making the risky path harder to take accidentally.
3. How would you resolve the conflict between the shadow architecture group and global standards?
Read the worked answer
Treat the shadow group as a signal, not a violation. Its existence suggests the central board is too slow and regional needs are real. Convene a convergence workshop with regional and global architects to compare standards against fitness criteria: data residency, latency, cost, and operability. Where the local standard meets global guardrails, adopt it as a regional pattern and publish it in the decision log. Where it conflicts, document the trade-off and set a time-bound exception. Legitimize regional architects as federated decision-makers for Type 2 decisions. This preserves local innovation while restoring a single source of architectural truth for Type 1 decisions. Measure conflict rate and decision lead time; if the shadow group persists, decision rights are still unclear.