Chapter 23. The Transformation Interface

What architecture owes portfolio governance, what it must not try to own, and the checkpoint that connects transformation work to the AI lifecycle.

23.1 Shallow by design

IRGF governs transformation shallowly and deliberately. The framework claims visibility of, not ownership over, transformation and workforce change. This is a scope decision, not an oversight, and holding the line is a condition of the framework remaining architecture governance rather than becoming an unbounded review function.

The distinction is best expressed as depth per link in the chain.

Table 60. Shallow by design

Link	Governance depth	Why
Enterprise intent and objectives	Deep	Traceability starts here
Business capability	Deep	The unit against which value is assessed
Transformation theme	Shallow	Business framing, not architecture
Portfolio	Shallow with input right	Architecture informs; portfolio decides
Initiative	Shallow with a mandatory checkpoint	TG0 is the one enforced touchpoint
Architecture and AI enablement	Deep	Squarely architecture’s remit
Delivery and organizational change	External input interface only	PMO and change management own this entirely
Outcome and benefit	Deep	Closes the traceability chain

The delivery row was relabeled during the framework’s revision from “Delivery and Organizational Change” to External Input Interface, correcting an appearance of ownership the framework never actually claimed. If your implementation finds architecture reviewing delivery plans or change management approaches, scope has crept.

23.2 The transformation lifecycle

Table 61.

Stage	Name	Architecture’s role
T0	Purpose and Strategic Alignment	Informed
T1	Capability Gap Identification	Consulted; supplies capability and readiness assessment
T2	Initiative Qualification (TG0 checkpoint)	Mandatory input on specific questions
T3	Portfolio Prioritization	Consulted on dependency conflicts; AI Governance Body concurrence for Tier 3–4
T4	Architecture and AI Enablement	Accountable; spawns S0 where AI is involved
T5	External Input Interface	None; PMO owns
T6	Benefits Realization and Review	Consulted; supplies outcome evidence
T7	Capability Re-Baseline	Consulted; loops to T1

T4 is the junction. Where a transformation initiative involves AI, T4 spawns the AI build lifecycle at S0, and the two lifecycles run in parallel from that point with the AI system governed by S0–S10 while the initiative continues through T5–T7.

23.3 The Architecture Input Package

The framework does not own prioritization. What it defines is a structured package that portfolio governance must consume, without being obliged to defer to it.

Table 62. The Architecture Input Package

Portfolio decision	Architecture supplies	Architecture does not own
Initiative prioritization	Capability gap severity and architecture readiness	The business value judgment
Investment sequencing	Dependency graph across shared platform, data, and AI components	Funding allocation and timing
Dependency identification	Explicit flags where two initiatives would build conflicting or duplicative architecture	Resolution of the conflict
Reuse	Existing patterns or platform capability an initiative could use instead of building	Whether the recommendation is accepted
Platform strategy	Assessment of build-on-existing versus justify-new	The investment decision
Technical debt	Visible register of which initiatives increase or reduce debt	The trade-off decision

The pattern is consistent: architecture surfaces structured information at each decision point and does not make the decision. Whether an input-only role is strong enough to prevent poor outcomes at portfolio level is an open question in the research, and the funding concurrence right (Chapter 20, §20.5) is the single bounded exception.

23.4 TG0 and its enforcement gap

TG0 is the initiative qualification checkpoint at T2. Architecture input is mandatory on the questions concerning architecture readiness, dependency, reuse, and AI relevance.

TG0 has a known enforcement gap: nothing in the checkpoint itself prevents an initiative from bypassing it. A team can begin building without ever appearing at T2.

The framework’s answer is retroactive detection rather than prevention: the Control Plane identifies architecture or AI System repository entries with no corresponding TG0 record, and routes the finding to the ARB (Chapter 22, §22.3). This is a detective control on a preventive gap, and it should be understood as such. Detection happens after the work has started, which limits what the response can achieve.

[Practice recommendation] Pair the detective control with a funding-side check. Where finance or portfolio systems can require a TG0 reference before releasing budget, the gap closes at the point it matters. This is outside the framework’s scope to mandate and inside most organizations’ ability to implement.

23.5 Benefits and the value scorecard

Benefits realization closes the traceability chain: an outcome measured against the baseline set at S1.

The framework tracks five metric families and deliberately does not composite them into a single index.

Table 63. Benefits and the value scorecard

Family	Examples
Business	Revenue impact, productivity, time-to-market, customer experience, operational efficiency
Transformation	Capability maturity movement, modernization progress, process simplification, adoption
Architecture	Reuse rate, interoperability, standardization, technical debt, complexity
AI	Model performance, automation benefit, human augmentation, decision quality
Risk	Incidents, violations, control effectiveness, model failures, security events

Refusing to composite is a design choice with a specific purpose: a single index lets high reuse mask low benefit realization, or strong delivery mask rising risk. Five numbers that must each be looked at produce better conversations than one number that can be optimized.