Architecture Runway vs. Emergent Design in a Payments Platform
You are lead architect at a payments company. Eight product teams are building a new merchant onboarding and settlement platform against a nine-month PCI-DSS re-certification deadline. The platform has 14 microservices, two cloud regions, and a shared event backbone. The chief architect proposes a 12-week architecture runway covering the target event schema, identity model, and multi-region failover before teams start. Product owners resist: they have 120 features queued and work in two-week sprints. The existing architecture review board meets biweekly with a 10-day lead time, and teams have begun bypassing it. Three senior architects are available, but two are already 80% allocated to a legacy decommissioning effort. The platform team is new and has not defined non-functional requirements. The CTO asks you to recommend how to balance intentional architecture with emergent design without missing the deadline.
1. How should you decide which architectural elements require intentional upfront design and which can emerge? Give a decision approach grounded in reversibility and risk.
Read the worked answer
Start by classifying candidate decisions on two axes: cost of reversal and blast radius or regulatory impact. The event schema, identity model, and multi-region failover are hard to reverse once 14 services and external merchants depend on them; PCI scope and data residency are regulatory. Those warrant an architecture runway, but not as a 12-week gate. Slice the runway: define a minimum viable contract for event schema and identity, with versioning and fitness functions, and timebox each slice to two sprints. Service-internal boundaries, UI composition, and non-critical APIs can emerge because they are cheaper to change and locally contained. Use the last responsible moment only for reversible decisions; for irreversible ones, decide early but narrowly. Co-create the runway with product teams so it is pulled, not imposed. Publish guardrails for emergent areas. This balances intentional architecture and emergent design without treating all architecture as either big design up front or none.
2. Design a lightweight governance mechanism to replace the biweekly review board. What artifacts and cadence?
Read the worked answer
Replace approval with an architecture advice process plus automated guardrails. Any team making a decision records it in a one-page decision record: context, options, trade-offs, fitness functions, and affected teams. They request advice from affected teams and an architect, with a 48-hour comment window; the decision owner decides unless a guardrail is breached. Guardrails for PCI scope, data residency, and resilience are codified as fitness functions in CI/CD and as pre-approved patterns, so most decisions need no meeting. Reserve escalation for cross-team, irreversible, or guardrail-breaking decisions; those go to a weekly 30-minute architecture sync, not a 10-day board. The three architects rotate as advisors, not approvers. Track decision lead time and bypass rate. This preserves control where risk is high and removes the bottleneck where it is not.
3. How should the three architects be allocated, given two are 80% on legacy decommissioning? What is the trade-off?
Read the worked answer
Do not create a central review team. Allocate one architect full-time for six weeks to co-create the first two runway slices, event schema and identity; allocate one at 50% to guardrails and fitness functions because automation reduces future review load; keep the third on legacy decommissioning but on call as advisor for cross-team decisions. Recruit senior engineers from product teams as architecture champions to extend capacity. The trade-off is explicit: pulling architects off legacy decommissioning may delay it, so quantify that risk and negotiate a temporary reallocation with the CTO. If legacy work has a hard regulatory date, keep the allocation and reduce runway scope instead, perhaps deferring multi-region failover to a later increment. The worst option is three part-time architects acting as a review board, which recreates the bottleneck.