Nine Architects, Eight Squads, and Four Event-Streaming Variants

Separate the cadences rather than forcing one to match the other.

• Split the practice's output into two layers. Enterprise-level work - principles, standards, target architecture, roadmaps, reference patterns - runs at a slow cadence and serves the whole organisation. Delivery-level work - solution shaping, decisions, option analysis - runs at squad cadence. One team attempting both at the same cadence produces quarterly packs that arrive after the decisions were made.
• Allocate the nine architects explicitly. For example two on enterprise-level content, six embedded with or assigned to squads, one owning governance, the repository and the advice process. An unallocated architect defaults to producing documents.
• Define the architecture runway concretely. It is intentional, prioritised architecture work done ahead of squad need, expressed as enablers that squads pull into their backlogs. It is not a document. Each runway item names what squad it unblocks and when, which forces architects to negotiate priority with delivery rather than publish.
• Keep the ADM, change the granularity. Short cycles scoped to an epic or a segment feed a slower enterprise cycle; Phase H continuously feeds changes back. This is ordinary ADM tailoring, not a departure from it.
• Shift the role from gatekeeper to enabler. The three-week review exists because architecture is positioned as a checkpoint. If architects sit with squads, most reviews disappear because the decision was made together.

Replace gates with guardrails - but keep the ability to say no.

Mechanisms:

• A published set of guardrails: principles, standards, approved patterns and reference implementations, with the reasoning attached so squads can apply them without asking.
• A lightweight architecture advice process with a service level - for example a forty-eight-hour response, with a default answer of 'proceed' if architecture does not respond in time. A gate that blocks delivery will be routed around, as the four variants demonstrate.
• Decision records in the Architecture Repository, so decisions are visible to the next squad and to the Board.
• Automated fitness checks in the pipeline where the guardrail can be tested (API standards, data classification, dependency rules). Checks that run in seconds beat reviews that run in weeks.
• Reserve the Architecture Board for exceptions, dispensations and cross-tribe conflict - that is its proper role, and it will be used more, not less.

The four event-streaming variants: This is the predictable result of a slow review, and the response should not be a retroactive mandate that stops delivery. Publish one pattern as the reference implementation and make it the cheapest path to production - supported, instrumented, with a template. Then add convergence of the other three to the roadmap with a time box and a funded migration, prioritised by the cost of maintaining four. Mandate only if the variants create real operational or regulatory risk.

Treat it as an architecture change driver, not a delivery backlog item.

1. Enter through Phase H. A regulatory change is an Architecture Change Management input. Assess its impact on the current target architecture and identify which building blocks are affected - in a telco, likely anything touching subscriber data, analytics, and the event streams currently in production.
2. Run a targeted, enterprise-level mini-cycle. Data residency is cross-cutting; it cannot be delegated to eight squads independently or you will get eight interpretations. Scope a short Phase A–C on the residency concern: a principle and standards defining where data may reside, how it is classified, and what must change.
3. Convert the answer into things squads can build against. Acceptance criteria, fitness functions in the pipeline (for example a deploy-time check on region), and enablers in the runway. An architecture position that cannot be tested will not be implemented in a fortnightly cadence.
4. Sequence with Transition Architectures keyed to the five-month deadline - what must be compliant by month two, month four, five - aligned to release boundaries rather than to a single big-bang cutover.
5. Use the Board for exceptions, because some squads will find that immediate compliance breaks a release. Bounded dispensations with remediation dates are the correct instrument; silent non-compliance is the alternative.
6. Feed it back into the guardrails, so that the next squad starting work on event streaming inherits the constraint by default rather than by review.