Atlas Bank: Tiered Governance and Fitness Functions at Scale
Atlas Bank's architecture review board meets weekly and reviews every solution design above a €200,000 cost threshold. With 120 application teams, the queue averages two weeks, and 60% of submissions are approved with only editorial comments. The board has 14 standard patterns, but teams frequently deviate; three of the last twelve production incidents were traced to undocumented deviations from the encryption and logging standards. The regulator requires evidence that architecture controls are designed and operating. The bank is migrating 300 workloads to a public cloud over three years. One payments team has requested Kafka for event streaming, although the standard messaging product is IBM MQ. The exception process takes six weeks and requires a chief architect signature. The CIO wants faster delivery without weakening control, and has asked for a governance redesign that uses fitness functions rather than more meetings.
1. Redesign architecture governance so it scales to 120 teams while preserving regulatory evidence. Specify review tiers, decision rights, and fitness functions.
Read the worked answer
Diagnose the failure mode
The board reviews by cost threshold, which is a poor proxy for architectural risk. Most submissions are low-risk and receive editorial comments, consuming the board's attention. Deviations are invisible until an incident, and the exception process is slower than the delivery cycle, so teams route around it.
Tier by risk and reversibility
- Tier 0, self-service: low-risk, reversible changes that pass automated guardrails. No board meeting.
- Tier 1, domain review: changes within one domain that affect a shared interface or a standard pattern. Peer review by domain architects.
- Tier 2, architecture board: cross-domain, irreversible, regulated, or high-cost changes, and exceptions to standards.
Decision rights must be explicit: the platform team owns shared patterns; domain architects own local designs; the board owns cross-cutting exceptions and standards changes. The board should not re-review compliant Tier 0 work.
Fitness functions
Automate checks for encryption at rest and in transit, logging schema, network policy, tagging, backup, dependency rules, and latency budgets. Run them in the pipeline and record results as regulatory evidence. A failed check blocks deployment or creates an exception record; it does not disappear into a meeting minute.
Make standards executable
Publish patterns as code, templates, and policy-as-code. The 14 patterns should have owners, versions, and deprecation dates. This reduces the need to review the same decision repeatedly.
Preserve evidence
Every automated check, exception, and board decision is timestamped and linked to the control it supports. That is stronger evidence than a weekly meeting.
2. The payments team requests Kafka. Walk through the decision process, including the exception path, and state what you would record.
Read the worked answer
Start with the use case
Ask what quality attributes Kafka is meant to satisfy: throughput, ordering, replay, retention, fan-out, or cloud-managed operations. If the requirement is simple request/reply over IBM MQ, Kafka adds operational cost without benefit. If the team needs durable replay for event sourcing or high fan-out, the case may be strong.
Evaluate against criteria
Compare IBM MQ and Kafka on throughput, ordering guarantees, retention, operational skills, cloud managed service availability, security integration, cost, and regulatory fit. Include the platform team's ability to support another product. Consider a managed Kafka service to reduce operational burden.
Exception path
If Kafka is justified, use a time-boxed exception: named owner, risk assessment, compensating controls, pilot scope, exit criteria, and review date. The pilot should prove operational readiness, security controls, and cost. If it fails, the team reverts to IBM MQ. If it succeeds, the board updates the standard pattern rather than granting permanent one-offs.
Record
Write an architecture decision record with context, decision, alternatives, consequences, risks, owner, and review date. Link it to the exception register and to the relevant fitness functions. Publish the outcome so other teams do not repeat the debate.
Avoid
Do not decide by technology preference or by escalation. The decision must trace to requirements and evidence, and the exception must not become a silent second standard.
3. Which metrics would show whether the new governance model is working, and what would trigger a redesign?
Read the worked answer
Outcome and leading metrics
Track review cycle time, percentage of changes handled at Tier 0, board hours per week, exception count and age, and pattern reuse. Track compliance pass rate on automated fitness functions. Track delivery outcomes: lead time, change failure rate, and incidents caused by undocumented deviations.
Regulatory evidence metrics
Measure the percentage of controls with current evidence, the time to produce an audit evidence pack, and the number of manual evidence requests. A falling manual request count suggests automation is working.
Triggers for redesign
- Compliance pass rate below 95% on critical controls.
- More than one incident per quarter caused by a governance gap.
- Median exception age above 30 days.
- Tier 2 review cycle time above five days.
- Board time dominated by low-risk submissions.
- Pattern reuse falling while exceptions rise.
Interpret with care
A fast review that approves unsafe designs is not success. Pair speed metrics with control effectiveness and incident data. Review the metrics quarterly and publish them to teams. If a threshold is breached, diagnose whether the tiering rules, the fitness functions, or the standards are wrong before adding meetings.