Central architecture gatekeeping at Atlas Logistics
Atlas Logistics has five product teams and a central architecture group of three people. Any new module, entity, or public action requires a design document approved by the central group. The queue is three weeks deep, and 70% of requests are for trivial changes such as adding an attribute or a new public action. Teams have responded by creating 43 duplicate utility modules and by copying entities into their own applications, which has caused inconsistent customer data across the order, billing, and tracking apps. The central group believes it is protecting the architecture; the teams believe it is a bottleneck. The CTO wants developer autonomy without losing architectural integrity and asks for a new operating model.
1. Analyze the root causes and unintended consequences of the current model.
Read the worked answer
The central group conflates architecture governance with change approval. Reviewing every attribute spends scarce architect time on low-risk decisions and creates a three-week queue. Teams then optimize locally: 43 utility modules and copied entities are rational responses to a bottleneck, not sabotage.
The consequences compound. Duplicate utilities drift in behavior; copied entities create multiple sources of truth for Customer, so order, billing, and tracking disagree. Integration cost rises because every cross-team data question becomes a reconciliation project. The central team cannot see the shadow architecture it created, so its risk model is wrong: it believes it approves everything while the most important decisions happen outside review. Ownership also disappears. No team owns a canonical entity, so nobody is accountable for its quality, documentation, or change history. The model produces the appearance of control and the reality of fragmentation.
2. Propose a federated governance model with explicit decision rights.
Read the worked answer
Centralize decisions with cross-team externalities: canonical entity definitions, integration contracts, security and authentication, platform standards, naming conventions, and cross-domain workflows. The central group owns the canonical layer and the platform.
Delegate to product teams: module internals, local entities, UI and screen logic, and public actions inside their bounded context. Teams own their transaction and end-user layers.
Operating mechanism: form an architecture guild with one architect per team plus the central lead. Publish the architecture canvas and a golden-path template. Replace pre-approval with two paths: a checklist that auto-approves trivial changes such as a new attribute on a team-owned entity, and a design review only for new canonical entities, new cross-domain dependencies, or security-relevant changes. Publish a service catalog so reusable capabilities are discoverable and forking loses its appeal.
The test of the model is whether a team can ship a local change without waiting, while a change that affects another team still gets scrutiny.
3. How would you measure whether the new operating model is working?
Read the worked answer
Measure outcomes, not review volume. Speed: lead time for architecture decisions, with targets such as two days for a standard decision and five days for cross-domain work; team cycle time from commit to production. Integrity: count of duplicate utility modules and copied entities, starting from 43 and trending down; dependency violations detected per release; cross-team data incidents per quarter. Delivery health: deployment frequency, change failure rate, and rollback rate. Adoption: percentage of changes handled through the auto-approval checklist rather than full review.
Add a quarterly autonomy survey asking teams whether they can make local changes without escalation. Avoid metrics that reward gatekeeping, such as number of reviews completed or documents produced; those would recreate the bottleneck in a new form. Review the metrics quarterly with the guild and adjust decision rights when the data shows a category of change is consistently low-risk.