Enterprise Architecture Value Model

Level 2 deliverables are more contextual and more connected to specific delivery work than Level 1 deliverables — but they remain advisory outputs rather than accountable ones. The test for whether a deliverable is Level 2 rather than Level 3 is whether the architecture function owns the outcome it is advising toward.

Typical Level 2 Deliverables

• Program-specific architecture assessments — detailed evaluations of a specific delivery program’s architectural approach, produced early enough in the program lifecycle to be actionable rather than retrospective.

• Solution design reviews and recommendations — architecture team input on specific solution designs, delivered as recommendations that the program team can accept, adapt, or reject without formal consequence.

• Technology selection analyses — comparative assessments of technology options for a specific use case, with trade-off analysis and a recommended option, typically delivered in response to a delivery team’s request.

• Integration architecture guidance — recommended integration patterns, interface designs, and data flow approaches for specific programs, with enough specificity to be useful but without the authority to override program team decisions.

• Cloud migration architecture recommendations — guidance on cloud adoption approaches, landing zone design, and workload migration sequencing, typically advisory rather than binding.

• Security architecture advisory reports — identification of security architectural risks and recommended mitigations, delivered to program teams who retain the decision authority on which recommendations to implement.

• Proof-of-concept evaluation reports — assessments of technology options based on limited hands-on evaluation, produced by the architecture team but not owned through to production deployment.

• Architecture options analyses — structured comparisons of two or three architectural approaches for a specific decision, with recommendation and rationale, delivered as input to a decision that the program team or its governance body will make.

• Design pattern guidance documents — curated collections of architectural patterns applicable to recurring design problems, published and referenced in advisory engagements but not embedded in tooling or platforms.

• Active APM and TPM advisory engagement — participating in portfolio review conversations, recommending Rationalization Postures and Strategic Dispositions, advising on technology deprecation timelines — all without owning the execution of the resulting portfolio decisions.

Level 2 deliverables are genuinely more useful than Level 1 deliverables because they are specific, contextual, and timed to be actionable. Their organizational limitation is not their quality. It is that their impact depends entirely on the degree to which the delivery teams receiving them choose to act on them — which is a function of trust, credibility, and the degree of delivery pressure those teams are under at the moment they receive the advice.