Minimum Viable Architecture for a New Digital Bank
A traditional bank is launching a standalone digital bank in six months. The new entity needs a banking license, so regulators require evidence of resilient architecture, audit trails, and data protection before launch. Five product teams will build onboarding, deposits, lending, payments, and mobile. Two architects are assigned; the cloud vendor is selected. The CTO wants a minimum viable architecture to avoid over-design, but the risk team wants a full target-state architecture and a 60-page design document. The program has a fixed budget and a hard launch date tied to a marketing campaign. The existing bank's architecture is a 20-year-old core with batch processing; the new bank must integrate with it for ledger and KYC. Teams are co-located and use two-week sprints. There is no architecture runway.
1. What belongs in a minimum viable architecture for this digital bank? What do you deliberately defer?
Read the worked answer
The minimum viable architecture must cover non-negotiables that are expensive to retrofit: regulatory evidence such as audit trails, data protection, and access control; resilience and recovery for licensed banking; KYC and ledger integration contracts; and the security boundary with the existing core. It should also include a walking skeleton for the onboarding-to-ledger flow and fitness functions for those qualities. Defer internal service decomposition, UI framework choice, non-critical product features, and optimization beyond launch forecasts. The reasoning is that minimum viable is not minimum tolerable; it is the smallest architecture that satisfies irreversible regulatory and quality constraints while leaving reversible choices open. The risk team's 60-page target state conflates target architecture with launch architecture. Produce a one-page architecture vision, a decision log, and an evidence map to regulatory requirements, then evolve the target state through runway increments.
2. How would you establish an architecture runway in six months with two architects and five teams?
Read the worked answer
Build the runway as thin, shared slices that unblock multiple teams: identity and access, audit event schema, ledger integration contract, environment topology, and CI/CD guardrails for security and resilience. Timebox each slice to two to three weeks and define acceptance criteria with the teams. Use a walking skeleton to prove the onboarding-to-ledger path early. Architects embed with teams and co-create; they do not write a document and leave. Because two architects cannot cover five domains, appoint tech leads as architecture champions and use vendor reference patterns for commodity areas. Sequence by dependency: identity and audit first because every team needs them; lending and mobile can follow. The trade-off is less upfront detail, but the runway is pulled by teams and tested in code, which fits the six-month launch.
3. How do you handle the risk team's demand for a full target-state design document?
Read the worked answer
Translate the risk team's concern into evidence, not document volume. Map each regulatory requirement to a concrete control, fitness function, and decision record. Offer a joint working session to define the evidence pack: resilience test results, audit-log design, data-flow diagrams, access-control decisions, and a target-state roadmap showing what is deferred and why. A 60-page document does not prove compliance; executable guardrails and test evidence do. Still produce a concise target-state narrative for context, but keep it separate from launch approval. The reasoning is that risk teams need assurance and auditability, while architects need speed; an evidence-based minimum viable architecture satisfies both if the risk team co-owns the acceptance criteria. If they insist on the document, agree a maximum length and link it to live evidence.