Enterprise Architecture Value Model

Level 3 deliverables are categorically different from Levels 1 and 2 in one critical dimension: the architecture function is accountable for them, not merely the team that produces them. These are not advisory outputs delivered to decision-makers who may or may not act on them. They are delivery commitments owned by the architecture function and measured by whether the program succeeds.

Typical Level 3 Deliverables

• Architectural triage reports — structured assessments of an at-risk or high-risk program’s current architectural state, identifying what is sound, what is at risk, and what is broken, with enough specificity and evidence to immediately inform a recovery strategy.

• Program-specific remediation roadmaps — actionable plans with committed timelines, named owners, and acceptance criteria for each remediation item, produced and owned by the embedded architecture team rather than delivered as recommendations.

• Architectural risk registers — continuously maintained logs of architectural risks in the program, updated at the cadence of delivery governance and reported directly to the executive sponsor and to you as the IT leader.

• Architecture decisions within program scope — not recommendations for the program team to consider, but decisions made by the embedded architect within the authority granted for the engagement. These are documented as committed architectural choices with named accountability.

• Integration architecture blueprints implemented within the program — not handed off to a delivery team as guidance, but owned through to implementation within the scope of the engagement.

• Root cause analyses of architectural failures — formal analyses of the architectural decisions, governance gaps, or dependency failures that created the program’s at-risk condition, delivered with enough specificity to inform both the program recovery and the enterprise’s future governance practices.

• Executive recovery status reports — direct reporting to program executive sponsors and to you on architectural risk status, remediation progress, and remaining risks, delivered on a defined cadence rather than in response to escalations.

• Engagement handoff documentation — formal transfer of architectural ownership from the embedded practice to the appropriate domain leaders and delivery teams upon successful program delivery, including the architectural decisions made, the rationale, and the ongoing governance obligations of the receiving team.

• At-risk program intake assessments — structured evaluations of proposed program engagements against the intake criteria that define which programs qualify for embedded architecture practice engagement, producing a formal engagement decision rather than an informal judgment.

The organizational test for Level 3 deliverables is whether the architecture function would be held accountable if they failed to produce the intended result. A triage report that led to a recovery plan that was not executed by the embedded architect is a failure of the architecture function at Level 3 — not a failure of the program team that chose not to follow the recommendation. That accountability is what makes these deliverables categorically different from everything at Levels 1 and 2.