Roles & delivery archetypes¶

The four preceding pages of this pillar each look at delivering an AI program through the lens of one method family. This capstone looks at it through the lens of who is doing the work and what shape the program has — the layer above any single method.

Two moving parts:

Roles — a method-agnostic catalog of the roles an AI program actually staffs. Each role has a mission, an accountability, a set of key decisions, and a set of handoffs. Same role, same mission, no matter which method the program adopts.
Delivery archetypes — recurring shapes AI programs take, each with a natural method fit and a natural role centre-of- gravity. The AI Transformation archetype is worked in depth as the anchor, with the AI Architect as the role spelled out in full across every archetype.

The last section is the matrix — the role × method × archetype view that ties the whole pillar together.

Sources verified 2026-08-09

Role definitions here are grounded in the framework materials cited on the four preceding pages of this pillar (Open Group TOGAF for architecture roles; PMI PMBOK + PRINCE2/PeopleCert for programme/delivery roles; Scaled Agile SAFe for ART roles; LeSS for feature-team roles), plus the industry consensus around ML/data roles reflected in the standard job families and skill frameworks used across the industry.

1. Roles catalog¶

Method-agnostic. Every one of these roles exists whether you're running TOGAF ADM, PMBOK, SAFe, LeSS, or a hybrid — the ceremony they participate in varies; the mission doesn't.

AI Architect (enterprise & solution)¶

Mission — Own the target-state architecture for the AI estate: how models, data, platform, and governance compose into a system that delivers the business KPI and passes the audit.
Accountabilities — The architecture repository (models, datasets, prompts). The AI-specific principles and standards. The Phase D technology strategy (accelerator, MLOps toolchain, serving pattern). The Phase G governance patterns (approval workflow, model risk council, cross-linked to Trust & attribution).
Key decisions — Buy vs build; hosted-frontier vs self-hosted; sync vs async serving; feature-team vs component- team ML platform ownership; the accelerator strategy.
Handoffs — Business Sponsor → Vision; Governance Lead → responsible-AI standards; ML Engineer → serving pattern; Platform Engineer → MLOps toolchain; Security/Identity Architect → workload + end-user identity chain.

ML Engineer¶

Mission — Take a modeling problem to a production-serving model that meets the KPI, at the required latency and cost.
Accountabilities — The training + eval loop; the model card; the serving path; the drift-monitoring hooks.
Key decisions — Modeling family and hyperparameters; eval metric and threshold; retrain trigger; hosted vs self-hosted serving.
Handoffs — Data Engineer → training/feature data; Data Scientist → problem framing + eval methodology; MLOps Engineer → serving deployment; AI Architect → serving pattern conformance.

Data Engineer¶

Mission — Deliver production-grade data pipelines and a reliable feature store that the ML Engineer can build on.
Accountabilities — Ingestion, cleaning, feature engineering, feature store, data contracts, lineage.
Key decisions — Batch vs streaming; feature-store technology; schema evolution policy; data-contract enforcement points.
Handoffs — Source-system owners → contracts; Data Governance → classification + retention; ML Engineer → feature availability
freshness.

Data Scientist¶

Mission — Frame the modeling problem, prove feasibility, choose the modeling family and eval methodology.
Accountabilities — The Elaboration-phase feasibility spike (see the Traditional iterative page); the eval dataset design; the "does the model actually move the KPI?" experiment.
Key decisions — Whether the problem is model-shaped at all; feature set; eval metric; ground-truth-labeling operating model.
Handoffs — Business Sponsor + Domain SME → problem framing; Data Engineer → data availability; ML Engineer → productionization of the winning approach.

MLOps / Platform Engineer¶

Mission — Operate the shared ML platform: training infra, serving infra, model registry, feature store operations, the CI/CD/CT pipeline.
Accountabilities — Platform SLAs; GPU / accelerator pool management; deployment automation; the Continuous Training stage (see the Scaled agile page); MLOps observability plane.
Key decisions — Cluster and GPU pool sizing; serving runtime; canary tooling; on-call playbooks.
Handoffs — AI Architect → platform target-state; ML Engineer → serving-runtime contract; Security/Identity → workload identity + secrets.

AI Product Owner / Product Manager¶

Mission — Own the product hypothesis, the backlog, and the stakeholder alignment. Trade off feature work against responsible-AI work in the open.
Accountabilities — The product backlog (LeSS = the backlog; SAFe = the team backlog + input to program + portfolio); the PI objectives (SAFe); the Product Description acceptance criteria (PRINCE2).
Key decisions — Backlog priority; scope trade-offs at sprint / PI / stage boundaries; go / no-go input at the model- KPI gate.
Handoffs — Business Sponsor → strategy; Data Scientist → feasibility; Governance Lead → responsible-AI acceptance criteria; Delivery Manager → schedule + risk.

Program / Delivery Manager¶

Mission — Deliver the program to its committed schedule, budget, and quality — inside whichever governance shell the org runs (PMBOK, PRINCE2, hybrid).
Accountabilities — Schedule (CPM — see the Project management page), risk register, stakeholder communication, stage-boundary artefacts, Continued-Business-Justification submission at every PRINCE2 Stage Boundary.
Key decisions — Escalation vs absorb; when to invoke the kill option; when to re-plan.
Handoffs — Sponsor + Board → business case; PO + Architect → progress + risk; all team leads → capacity.

Data Governance / Responsible-AI Lead¶

Mission — Ensure the AI estate meets its legal, ethical, and policy obligations before it meets its KPIs.
Accountabilities — The responsible-AI principles (from the Architecture method's Preliminary phase); the fairness / explainability / privacy standards; the model risk council; the data-classification policy; the gate approvals that must fire before promotion.
Key decisions — Whether a use case is in-policy at all; fairness metric + threshold; retention windows; audit-trail completeness; kill recommendation on drift or bias breach.
Handoffs — Legal + Compliance → regulatory input; AI Architect → gate implementation; PO → acceptance criteria; Business Sponsor → policy risk exposure.

Domain SME¶

Mission — Bring irreplaceable domain knowledge into the model's problem framing, eval design, and adoption plan.
Accountabilities — Ground-truth-label quality assurance; edge-case catalogue; adoption-user representation; sanity-check on model outputs against domain reality.
Key decisions — Whether the model's outputs are right, in the domain sense, not just accurate.
Handoffs — Data Scientist → problem framing; Governance Lead → domain-appropriate fairness metric; PO → user-adoption hurdles.

Security / Identity Architect¶

Mission — Own the two-identity chain for the AI estate: workload identity (who runs the code) and end-user identity (who asked for the write). Extends the Trust & attribution trust boundary to every AI service.
Accountabilities — Passwordless workload IAM; edge-auth JWT verification; least-privilege scoping; the attribution pattern used per system of record; approval-workflow enforcement.
Key decisions — OBO vs audit-column vs RLS (patterns compared); privilege boundaries for agent-initiated writes; secret rotation cadence.
Handoffs — AI Architect → cross-cutting patterns; MLOps → workload IAM implementation; Governance Lead → audit chain.

Mission — Own the value hypothesis and the business case; keep the program aligned to the strategy it was funded for.
Accountabilities — The KPI the model must move; the funding; the go/no-go authority at stage / PI boundaries.
Key decisions — Continued business justification (PRINCE2 principle #1); investment scaling; kill / re-scope decisions when the model doesn't hit the KPI.
Handoffs — PO → backlog priority; Delivery Manager → progress; Governance Lead → policy-risk exposure; Board → portfolio view.

2. Delivery archetypes¶

Not every AI program is the same shape. Five recurring shapes cover most real programs:

AI Transformation (the anchor)¶

What it is — An enterprise-wide re-shaping of how the org makes decisions, using AI across many products and functions. Multi-year, multi-product, multi-team.
Method fit — TOGAF ADM for the architecture repository and change management; Portfolio SAFe for cadence and Lean-budget governance across many teams; PRINCE2 / PMBOK governance shell at the program level with Stage-Boundary business-case reviews; Spiral risk cycling at the portfolio review.
Role centre-of-gravity — AI Architect (owns the target state), Business Sponsor (owns the value hypothesis), Data Governance / Responsible-AI Lead (owns the policy envelope). Program Manager holds the schedule; PO layer sits inside the ARTs.
Typical critical path — Foundational data platform → first flagship model in production → responsible-AI operating model in place → subsequent product ARTs on the shared platform. Skipping the first two to chase the third produces a much-lamented pattern of parallel, incompatible model stacks across the org.

This is the archetype the AI Architect exists for, and the one worked in depth in the matrix below.

AI Product Build (0 → 1)¶

What it is — A single AI product from concept to first production release. One product manager, one focused team or small ART.
Method fit — RUP Elaboration + Spiral to retire model feasibility risk before scale-out; Essential SAFe (a single product ART) or LeSS (one PO, one backlog) for delivery cadence; ADM Phases A–D at solution scope (not enterprise scope).
Role centre-of-gravity — AI PM (owns the product hypothesis), ML Engineer + Data Scientist (own feasibility and modeling), AI Architect at solution scope (owns the target architecture inside the product boundary).
Typical critical path — Feasibility spike → data readiness → first eval-passing model → serving integration → shadow → canary → GA. The Data Scientist earns their salary in the first two phases; the ML Engineer + Platform Engineer earn theirs in the last three.

ML Platform / Enablement¶

What it is — A shared ML platform (feature store, training infra, serving infra, MLOps CI/CD/CT, model registry, guardrails) built as a product that other AI teams consume.
Method fit — SAFe Large Solution with an AI Platform ART delivering to product ARTs on the same PI cadence; ADM Phase D for the technology architecture; RUP Construction disciplines for the platform-build cadence.
Role centre-of-gravity — MLOps / Platform Engineer (delivers the platform), AI Architect (target-state, contracts with consumers), Product Manager for the platform (yes — platforms need PMs, because they have consumers). LeSS's distrust of component teams is the honest counter-argument here; the AI Platform ART pattern only works if the platform team behaves as an internal product, not a gatekeeper.
Typical critical path — Feature-store MVP → training infra → model registry + serving reference stack → CI/CD/CT pipeline → guardrails plane. The order matters; skipping the CI/CD/CT step produces a platform that consumers can't safely operate on.

Embed-AI-in-existing-app¶

What it is — Add a model-powered feature into an existing system of record. The AI work is the smaller half; the integration + change-management into the legacy system is the larger half.
Method fit — PMBOK / PRINCE2 governance for the outer program (the legacy system's owners speak this language); agile delivery inside a stage; ADM Phase E–H for migration + change management; small Spiral for the integration-risk cycle.
Role centre-of-gravity — Solution AI Architect + legacy Solution Architect paired at the integration boundary; ML Engineer for the model itself; Security/Identity Architect for the cross-system trust boundary (cross-link to Trust & attribution).
Typical critical path — Model feasibility → integration contract with the legacy system → shadow-mode inside the legacy system → progressive-rollout with the legacy system's own release process → decommission of the prior decision path.

Regulated / High-assurance AI¶

What it is — An AI program in a domain (financial services, health, public sector, safety-critical) where the audit and regulatory hurdle is as steep as the modeling hurdle.
Method fit — Spiral cycles as the primary risk-decision cadence (regulators respect explicit risk retirement); PRINCE2 as the governance shell — every Stage Boundary fires a formal Continued-Business-Justification review; TOGAF ADM Phase G Implementation Governance treated as first-class, not paperwork; agile inside a stage but with tighter definition-of-done that includes the fairness / explainability / auditability criteria.
Role centre-of-gravity — Data Governance / Responsible-AI Lead (chairs the model-risk council); Security/Identity Architect (owns audit-trail integrity end to end); Delivery Manager (defends the schedule against the compliance overhead); Business Sponsor and Board have direct, frequent engagement.
Typical critical path — Regulatory-context review → policy envelope agreed → model + data-lineage + explainability approach approved by the risk council → shadow with regulator-visible metrics → controlled canary → GA under an operating regime with defined kill criteria.

3. The matrix — role × method × archetype¶

The two views below are the payoff. First: role centre-of-gravity by archetype — the roles that dominate each archetype's decisions and their primary method-family. Second: the AI Architect row — the same role, all five archetypes, worked in depth.

Role centre-of-gravity by archetype¶

Role	AI Transformation	AI Product Build	ML Platform	Embed-in-legacy	Regulated / HA
AI Architect (enterprise)	★ Chair	·	·	·	·
AI Architect (solution)	·	★ Chair	★	★	★
ML Engineer	·	★	★	★	★
Data Engineer	★	★	★	★	★
Data Scientist	·	★ Chair	·	★	★
MLOps / Platform Eng	★	·	★ Chair	·	★
AI PM / PO	· (Portfolio PMs)	★ Chair	★ (platform PM)	★	·
Program / Delivery Mgr	★ Chair	★	★	★ Chair	★ Chair
Data Governance / R-AI Lead	★ Chair	·	·	★	★ Chair
Domain SME	·	★	·	★	★
Security / Identity Arch.	★	·	★	★ Chair	★ Chair
Business Sponsor	★ Chair	★	·	★	★ Chair

Legend: ★ Chair = drives the decision at this archetype's key ceremonies; ★ = accountable, at the table; · = involved where relevant, not on the RACI as accountable.

The primary method-family per archetype¶

Archetype	Architecture method (ADM)	Traditional iterative (RUP/Spiral)	Project management (PMBOK/PRINCE2)	Scaled agile (SAFe/LeSS)
AI Transformation	Primary — enterprise ADM cycle	Spiral at portfolio review	Primary — PMBOK vocabulary, PRINCE2 stage gates	Primary — Portfolio SAFe with AI Platform ART + product ARTs
AI Product Build	ADM Phases A–D at solution scope	Primary — RUP Elaboration + Spiral for feasibility	Lightweight stage gates	Primary — Essential SAFe or LeSS
ML Platform	Primary — ADM Phase D	RUP Construction discipline	Lightweight	Primary — SAFe Large Solution AI Platform ART
Embed-in-legacy	ADM Phases E–H (migration + change)	Spiral on integration risk	Primary — legacy-org's PMBOK/PRINCE2	Agile delivery inside a stage
Regulated / HA	ADM Phase G (governance) treated first-class	Primary — Spiral cycles as the risk cadence	Primary — PRINCE2 shell with strict CBJ	Agile inside a stage with tighter DoD

The AI Architect row — same role, all five archetypes¶

	AI Transformation	AI Product Build	ML Platform	Embed-in-legacy	Regulated / HA
Scope	Enterprise (many products, many years)	One product	One platform, many consumers	Two-system integration	One product inside a regulated envelope
Owns the ADM at	Enterprise scope, running the full Preliminary → H cycle	Solution scope, Phases A–D	Solution scope, Phase D primarily	Solution scope, Phases E–H (migration)	Solution scope, Phase G especially
Chairs the architecture governance at	Enterprise Architecture Board, model risk council	Solution-scope architecture review	Platform architecture review + consumer contracts	Integration architecture review (paired with legacy Solution Architect)	Model-risk council, jointly with Data Governance Lead
Primary Trust & attribution stake	The org-wide identity + attribution chain across all AI writes (approval workflow)	Product-scope trust boundary	Platform-scope least-privilege pattern (least-privilege)	Cross-system attribution across legacy + AI (patterns compared)	Every attribution decision reviewed by the risk council
Signature deliverable	Enterprise AI target-state architecture + reference architecture per archetype	Solution architecture + PoC-gate outcome	Platform reference architecture + consumer SLAs	Integration architecture + rollback plan	Auditable architecture + explainability approach
Sits inside which SAFe / LeSS role	System Architect at Solution + Portfolio Enterprise Architect	System Architect at the ART	System Architect on the platform ART	System Architect on the delivery ART / integration team	System Architect at Solution level with direct Board access
Key failure mode to defend against	"Rebuild the platform in every product"	"Ship the model that isn't feasible on our data"	"Platform ART becomes a gatekeeper"	"AI feature that breaks the legacy contract"	"Model in production the audit trail cannot defend"

Ties everything together¶

The method chosen shapes the ceremonies each role participates in — see the four preceding pages of this pillar for the ceremony detail.
The archetype shapes which roles chair and which support — see the matrix above.
The role is method-agnostic in its mission and its handoffs — see the catalog in section 1.

A common failure mode is picking a method, staffing the roles, and skipping the archetype conversation. The result is a team running SAFe ceremonies for an Embed-in-legacy archetype problem, or a team running LeSS while genuinely doing an AI Transformation (and quietly failing the audit).

Cross-links back through the pillar¶

Architecture method — every Zachman Who cell + every ADM phase deliverable has a role from section 1 as its owner.
Traditional iterative — the Elaboration feasibility spike is the Data Scientist's + ML Engineer's phase; the Spiral risk-cycling is the AI Architect's + Governance Lead's.
Project management — the Continued-Business-Justification decision is the Business Sponsor's
Governance Lead's; the CPM schedule is the Delivery Manager's; the Uncertainty domain forces every role to make three-point estimates honestly.
Scaled agile — the AI Platform ART is the MLOps / Platform Engineer's home; PI Planning is the AI PM's biggest ceremony; the feature-team-vs-component-team choice is the AI Architect's target-state decision.
Trust & attribution — the Security/Identity Architect owns the trust boundary that every AI write must cross; the approval workflow is the Governance Lead's control surface; the AI Architect makes sure the patterns are used consistently across the AI estate.

This is the last page of the Delivery & practice pillar.