This article walks the handoff artefacts the AITE-SAT architect maintains, the operating-model patterns common at different organisation sizes, and the RACI that keeps the architect effective without becoming a bottleneck.
Why handoff matters
A system without a documented architect handoff deteriorates through the familiar pattern: decisions whose rationale is forgotten get reversed, rebuilt, or worked around; ADRs go unread and are eventually disowned; new teams reinvent patterns that already existed; incident responses slow down as institutional memory leaks away. The architect who cares about the system’s long-run health invests in handoff even when no handoff is imminent.
The goal is not that any successor could rebuild the system blindfolded; it is that a qualified architect joining the team can reach working proficiency in weeks rather than months and that their decisions during that period are informed rather than random.
The handoff artefact set
A complete architect-handoff artefact package for a running AI system or platform:
1. Architecture runway catalogue
A one-page-per-capability catalogue of what the platform provides. For each capability: description, API surface, consumer list, SLO, on-call owner, escalation path, roadmap summary. Described in Article 24 in its build-phase; in handoff its role is different — a newcomer reads the catalogue to orient.
2. Reference architecture diagram (current)
The Article 1 five-plane diagram, updated to reflect current reality. Annotated with the major production systems that instantiate each plane. Cross-linked to the ADR corpus where decisions are recorded.
3. ADR corpus
The full ADR set, indexed by topic and sorted by decision type. Superseded ADRs are linked forward. For a multi-year system the ADR corpus can run to 50–200 records; an index makes it navigable.
4. System cards
System cards per deployed AI system — descriptive, detailed, living. Extended Model Cards pattern per Mitchell et al.1 Cover intended use, data used, evaluation results, known limits, update history.
5. Runbook library
Operational runbooks per system: incident runbook (Article 20), deployment runbook (Article 19), promotion checklist, kill-switch drill procedure, disaster recovery plan. Runbooks are tested — untested runbooks are not assets, they are liabilities.
6. Decision log
A chronological log of significant decisions taken outside the ADR process. Some decisions do not warrant an ADR but still warrant a record: a vendor negotiation outcome, a staffing change that affected architecture, a deferred technical decision. The decision log catches these.
7. Evidence pack
For high-risk systems, the current EU AI Act evidence pack (Article 22). Cross-linked to its source artefacts so it is reproducible.
8. Office-hours archive
If the architect runs office hours (below), the archive of past sessions — questions asked, decisions made, topics discussed. An archive turns repeated conversations into searchable memory.
9. Onboarding document
The document the architect hands a newcomer. Not a reproduction of every artefact; a curated reading order, context, and known quirks. Typical length is three to eight pages.
10. Roadmap and backlog
Where the architecture is going next. What is scheduled, what is being considered, what has been declined. A successor reads this to know what commitments are in flight.
Operating-model patterns
Different organisations structure the architect function differently. Five patterns cover most of the space.
Pattern 1 — Single architect, small organisation
Up to roughly 100 engineers and a single AI programme. One architect owns everything. Handoff matters more, not less, because there is no safety net. The risk is bus-factor failure.
Discipline: the single architect invests in documentation as if preparing for handoff continuously; office hours are lightweight but scheduled; a named deputy exists even if that deputy is part-time.
Pattern 2 — Architect team, mid-size organisation
Roughly 100 to 1,000 engineers, multiple AI programmes. A small architect team (two to six people) covers product teams. Architects specialise (platform architect, one or two product architects, security architect). Handoff is easier because work is distributed; the new risk is internal inconsistency.
Discipline: a weekly or fortnightly architects’ guild meeting; shared ADR corpus with conventions; code-review style rotation on significant ADRs; a platform architect who owns cross-cutting decisions.
Pattern 3 — Centre of Excellence (COE) plus product-team architects
Larger organisations, typically over 1,000 engineers. A Centre of Excellence sets standards, owns the platform, and runs the architect guild. Product teams have their own architects who consume COE services. The operating model balances consistency with product-team autonomy.
Discipline: COE publishes opinions and templates but resists becoming a review gatekeeper for every decision; product architects follow COE opinions by default but can escalate on-case where their context justifies deviation; the COE sponsors office hours and training.
Pattern 4 — Federated architecture with strong platform
Large organisations with many autonomous product teams. Each product team has full architectural ownership; the central platform team provides shared services but not mandate. Works when the platform is compelling enough to earn voluntary adoption.
Discipline: the platform must earn its keep every quarter; cross-team consistency is lower but product-team velocity is higher; governance pressure (EU AI Act, sector regulation) is met through platform services rather than mandates.
Pattern 5 — Consultancy-style architects
Some organisations run an internal architect consultancy: architects are a shared resource drawn into programmes as needed. Gives flexibility at the cost of deep system ownership. Works best in combination with one of the other patterns rather than as the sole model.
Discipline: careful engagement scoping; handover from the consultancy-architect to the product team must be complete; risk of architect knowledge remaining trapped with the consulting architect if not deliberately transferred.
The architect’s RACI
A working architect RACI for AI systems across the COMPEL stages:
| Activity | Architect role | Product team | Platform team | Security | Compliance | Executive |
|---|---|---|---|---|---|---|
| Reference architecture | A, R | C | C | C | I | I |
| ADR authorship | A, R (product decisions); R (platform decisions) | C | C | C | I | I |
| Stage-gate readout | R | C | C | C | C | I (sponsor) |
| Threat model | A | R | C | R | I | I |
| Eval plan | C | R | C | I | I | I |
| Incident response | C | R | R | R | I | I (sev-1) |
| Cost model | A | R | C | I | C | I |
| Regulatory evidence pack | A | C | C | C | R | I |
| Platform roadmap | C (product architect); A (platform architect) | C | R | C | C | I |
| Retirement decision | A | C | C | C | C | C |
RACI tables are never exactly right. The one above is a starting point; teams adapt. The principle is that the architect is accountable for architecture decisions and responsible for architecture artefacts but is not the person who pushes the deploy button or writes every line of code.
The office-hours protocol
Office hours are the architect’s most cost-effective scaling tool. A weekly 60-minute block where any product team can bring a question, a design, a risk, or a concern. Run well, office hours:
- Surface problems early, before they become incidents.
- Spread architectural judgment across the organisation.
- Build the architect’s relationship with product teams (the meetings happen before there is a problem).
- Produce decision log entries automatically as a by-product.
Run badly, office hours become a stream of trivial questions or, worse, a forum where the architect unilaterally decides things that should have been part of a more considered decision process. The architect chairs deliberately — some questions are answered on the spot, some are deferred to an ADR, some are escalated to a scheduled review.
A practical office-hours template: 10 minutes of platform updates; 30 minutes of queue items with 5-minute time-boxes per item; 15 minutes of walk-in questions; 5 minutes of follow-up action capture.
Transition planning
When the architect leaves (promotion, different team, different company), the handoff discipline intensifies. A 30-day transition plan:
- Week 1: identify successor; arrange shadowing on all active reviews.
- Week 2: walk the successor through the artefact set; assign reading order; flag active decisions in flight.
- Week 3: successor takes primary ownership of reviews; outgoing architect supports; pair on decisions.
- Week 4: successor runs independently; outgoing architect available for questions; final handoff document prepared.
The plan is rarely executed perfectly. A successor who reaches reasonable proficiency in 60 days is doing well; 90 days is common; longer than 90 days signals handoff discipline failure that has to be repaired.
Scaling the architect function
As the AI portfolio grows, the architect function grows with it — not linearly. A sensible ratio:
- 1 architect per 5–10 product teams in the early phase.
- 1 architect per 10–20 product teams once the platform is mature and conventions are established.
- 1 platform architect for the platform team regardless of product-team count.
The ratio tightens if the portfolio includes high-risk regulated systems; it loosens if the systems are low-risk and the platform is well-adopted. A platform that shifts architectural load onto itself (through opinionated defaults) requires fewer architects per product; a platform that is optional requires more.
Worked example — ING Bank engineering organisation
ING Bank has publicly described its engineering organisation model including its approach to enterprise architecture.2 The model emphasises autonomous product squads and a thin architect function that provides standards, reviews, and cross-cutting discipline rather than design-every-system attention. The pattern is Pattern 4 (federated with strong platform) in terms above, adapted for a regulated-industry setting.
A lesson for AITE-SAT architects from the ING example: the architect function at scale is measured not by decisions taken but by decisions correctly anticipated. An architect who has published the opinions product teams need before they need them has scaled well; one who is paged on every decision has not.
Worked example — ThoughtWorks Technology Radar
ThoughtWorks publishes its Technology Radar roughly twice a year as a public artefact of its internal architecture function.3 The Radar is both an organisational tool (it surfaces current thinking) and an external communication (clients and the community consume it). As a pattern it demonstrates how an architect function can produce a visible, time-stamped expression of its current opinions without freezing those opinions.
AITE-SAT architects working inside enterprises benefit from similar discipline: a public (internal) artefact that says “here is our current view on vector stores” or “here is our current view on orchestration frameworks” saves countless one-off conversations and clarifies the organisation’s stance.
Anti-patterns
- The indispensable architect. An architect whose absence would stop the team is not scaling; they are a bottleneck. The handoff artefact discipline is how the architect fights this pattern.
- Documentation that documents everything. A thousand-page architecture wiki is not handoff-ready; a curated 20-page onboarding document is.
- Office hours that run once and then lapse. Consistency matters. Weekly office hours for three years is worth more than daily office hours for three months.
- Architect function detached from production. An architect who has not been paged for an incident in 18 months has likely lost touch with operational reality. On-call rotation, even light, is healthy.
- Handoff as a one-time event. Handoff is continuous. If the artefacts are kept current, the transition is less dramatic because every week is already a small handoff.
- No named deputy. Even in small organisations, a named deputy architect protects against bus-factor risk. Someone on the team has to be able to pick up the architect role if needed.
Governance integration
The handoff discipline connects to regulation indirectly but strongly. EU AI Act Article 11 technical documentation requires that a system’s documentation remain current through its lifecycle; a system whose architect has rotated without handoff is systematically at risk of documentation drift.4 ISO/IEC 42001 clauses on competence (7.2), documented information (7.5), and communication (7.4) map directly to the handoff artefact set. NIST AI RMF GOVERN 1.2 (roles and responsibilities) is satisfied by a clear RACI and a named accountable architect.
Summary
An AI system outlives its architect if the handoff artefact set is maintained. The ten artefacts (architecture runway catalogue, reference architecture, ADR corpus, system cards, runbook library, decision log, evidence pack, office-hours archive, onboarding document, roadmap) are the continuity layer. Operating-model patterns range from single architect to Centre of Excellence plus product architects to federated with strong platform; the right pattern depends on organisation size and regulatory context. RACI discipline and office-hours consistency scale the architect function. The architect who cares about long-run system health invests in all of this continuously.
Key terms
Architect handoff Architecture runway catalogue Decision log Operating model (architecture function) Office-hours protocol
Learning outcomes
After this article the learner can: explain the handoff artefact set; classify five operating models by fit to organisation size; evaluate an operating-model design for clarity and bus-factor risk; design a RACI for a specific architect role.
Further reading
Footnotes
-
Mitchell et al., “Model Cards for Model Reporting” (FAccT 2019). ↩
-
ING Bank engineering blog and public talks on engineering organisation (multiple years). ↩
-
ThoughtWorks Technology Radar archives (twice-yearly publication). ↩
-
Regulation (EU) 2024/1689 (AI Act), Article 11; ISO/IEC 42001 clauses 7.2, 7.4, 7.5; NIST AI 100-1 GOVERN 1.2. ↩