What deliverables should TOGAF produce?

Content Framework Structure

TOGAF organizes deliverables into catalogs (lists of entities), matrices (relationships), and diagrams (visual views). Examples include business capability catalogs, application portfolio catalogs, technology standards catalogs, integration matrices, and roadmap diagrams. Deliverables combine artifacts to address specific stakeholder concerns defined in architecture views.

The content metamodel defines entity types—capability, service, process, application, data entity—and relationships architects maintain in repositories. Not every entity requires exhaustive documentation; populate based on decision criticality.

Deliverables are not ends in themselves—they support ADM phase outcomes. If a matrix does not inform prioritization or design, omit it until needed.

Deliverable templates should include worked examples from prior approved programs—new teams learn faster from concrete good samples.

Phase-by-Phase Essential Outputs

Preliminary: architecture governance framework, tailored architecture method, principles catalog. Phase A: architecture vision, stakeholder map, high-level target concept. Phase B: business capability models, organization maps, gap analysis. Phase C: data and application catalogs, interface matrices, gap analysis. Phase D: technology standards, platform roadmap, gap analysis.

Phase E: opportunity identification, project list with dependencies. Phase F: implementation and migration plan, work packages, cost estimates. Phase G: architecture compliance assessments, updated baseline descriptions. Phase H: change request evaluations, architecture updates triggering new cycles.

Minimum viable EA for many organizations: principles, capability map, application inventory, technology standards, integration principles, and sequenced roadmap—expanded as maturity grows.

Accessibility and plain-language executive summaries accompany technical catalogs—multilingual firms may localize summaries for regional boards.

Tailoring Deliverables to Stakeholders

Executives need concise vision, roadmaps, and investment cases—avoid technical diagrams in board packs unless decision-specific. Developers need standards, reference implementations, and API guidelines. Operations needs deployment patterns and service catalogs. Security needs data flows and control mappings.

ISO/IEC/IEEE 42010 viewpoints formalize this tailoring—same architecture, multiple views. TOGAF deliverables map to viewpoints when organized thoughtfully.

Larkinized LLC defines deliverable templates per initiative tier—enterprise, program, project—so teams produce appropriate depth without one-size-fits-all bureaucracy.

Deliverable dependencies graph shows which outputs require which inputs—preventing teams from starting Phase F without gap analysis quality check.

Repository and Tooling Considerations

Modern repositories generate catalogs and matrices from metamodel data rather than manual PowerPoint maintenance. Integrations with CMDB, cloud APIs, and agile tools keep deliverables fresh. Stale deliverables erode trust faster than missing ones.

Version control and publication workflows treat architecture assets like code—review, approve, release. Link deliverables from developer portals and portfolio tools for discoverability.

Automated architecture drift reports become living Phase G deliverables comparing deployed assets to approved models.

Automated generation of diagrams from repository reduces manual drift between catalog data and Visio prettiness.

Anti-Patterns and Success Metrics

Anti-patterns include deliverable factories producing binders never read, duplicate diagrams diverging from repository truth, and matrices with placeholder data creating false confidence.

Success metrics: deliverables referenced in funding decisions, compliance assessments completed within SLA, repository query usage, reduction in ad hoc architecture questions to central teams.

Quality beats quantity—one accurate capability map driving portfolio cuts outweighs fifty orphan Visio files.

Retention policies archive superseded deliverables with watermark—avoid stakeholders acting on outdated roadmap versions.

Minimum Viable TOGAF Deliverable Set

Larkinized LLC recommends initial deliverable set: principles catalog, capability map level 1–2, application inventory with lifecycle states, technology standards summary, integration principles, eighteen-month roadmap diagram, architecture board charter. Add matrices and detailed catalogs when specific decisions require them—merger integration, regulatory audit, platform replacement.

Deliverable quality criteria include owner, last review date, decision links, and known gaps flagged—not pretend completeness. Honest metadata builds trust.

Sunset deliverables when unused—quarterly usage analytics from repository show which views stakeholders open. Archive orphan templates rather than maintaining zombie documents confusing search.

Deliverable Automation Roadmap

Prioritize automating highest-churn deliverables first—application inventory, cloud resource catalog—before static strategy documents.

Assign deliverable owners with SLAs for refresh—orphan documents violate ISO 42010 currency expectations implicitly.

User analytics on deliverable access guide simplification—merge redundant views confusing search.

Deliverable retirement announcements prevent teams referencing deprecated roadmap versions.

Practical Guidance from Larkinized LLC

Larkinized LLC defines deliverable tiers per initiative risk—enterprise transformation receives full catalogs; low-risk incremental changes receive checklist against principles and standards with explicit tailoring notes.

Worked examples from approved internal programs accelerate quality—new teams mimic good samples faster than blank templates from training courses alone.

Automated repository generation keeps diagrams synchronized with catalogs—manual Visio drift undermines trust within weeks of publication.

Executive summaries accompany technical deliverables—multilingual firms localize summaries for regional boards while maintaining single technical truth in repository.

Retention policies watermark superseded roadmaps—prevent teams executing against last year’s version after strategy pivot announced verbally but not archived formally.

Deliverable access analytics guide simplification—merge redundant views confusing search and maintenance without reducing decision-grade content executives require.

Deliverable quality rubrics score completeness, traceability, and executive readability before acceptance—prevents teams checking boxes with empty templates.

Larkinized LLC connects guidance on what deliverables should togaf produce to named portfolio decisions within the current fiscal year so architecture work is legible in funding systems executives already use. Workshop outputs publish to the repository within two weeks with owners assigned, preventing loss of context when facilitators rotate or consultants depart after initial engagement.

Cross-functional participation includes operations staff who execute daily processes—not only senior leaders whose high-level views omit workarounds that define real performance. Their input grounds models in operational truth and reduces downstream rejection when delivery teams claim architecture ignored how work actually happens.

Education scales beyond central architects through micro-learning for product owners, procurement staff, and engineers, reducing exceptions driven by ignorance rather than genuine strategic conflict. Office hours and internal communities of practice keep guidance current as cloud, agile, and AI practices evolve faster than annual training cycles.

Measurement pairs business KPIs—cycle time, cost per transaction, error rates, regulatory findings—with architecture metrics such as repository usage, review SLA compliance, and portfolio alignment scores. Improvements tied to architecture interventions build executive trust more reliably than model counts alone.

Regulatory and audit stakeholders increasingly expect traceability; viewpoint-specific views linked to repository entities produce evidence in days rather than weeks during examinations. Proactive documentation reduces fire drills, punitive findings, and leadership distraction from core transformation priorities.

M&A, divestiture, and market expansion stress-test architecture assets—scenario playbooks updated annually let leadership pivot with cost and timeline estimates instead of panic discovery after announcements. Capability maps and application inventories become due diligence assets before deals close, not afterthought spreadsheets.

Governance forums for what deliverables should togaf produce should meet on a predictable cadence tied to portfolio and release planning—not ad hoc when crises force attention. Larkinized LLC recommends standing architecture review slots with published intake criteria, SLA targets, and escalation paths so delivery teams know how to engage without treating architecture as unpredictable gatekeeping that rewards political access over merit of design.

Traceability from strategy statements to capability or architecture elements to funded initiatives to deployed solutions closes the loop executives expect when they approve EA funding. Without traceability, architecture remains a parallel documentation universe. Link charters, requirements, design records, and operational inventories in one searchable repository so auditors, product managers, and engineers retrieve consistent answers instead of conflicting spreadsheets maintained in silos.

Risk management benefits when what deliverables should togaf produce practices identify concentration risks—single vendor platforms, fragile integrations, key-person dependencies, regions without failover—and map mitigations into migration plans with owners and dates. Risk registers integrated with architecture repositories beat oral tradition during incidents when leadership demands answers within hours and teams cannot afford heroic manual discovery across dozens of systems.

Innovation programs need explicit guardrails within what deliverables should togaf produce so experiments proceed safely: sandbox environments, data masking rules, time-boxed pilots, and kill criteria before production commitments. Architecture enables innovation velocity by stating what teams may try without enterprise approval versus what requires board-level review because customer data, financial reporting, or safety-critical operations are affected.

Global enterprises localizing what deliverables should togaf produce should tier standards: mandatory worldwide, recommended regional, optional local—documented in governance charters to prevent both harmful divergence and rejection of valid regional regulatory requirements. Regional architects on a council synchronize proposals before they become de facto standards that conflict with enterprise principles approved by executive sponsors accountable to the board.

Quality assurance for architecture artifacts includes peer review, automated validation where schemas exist, and executive readability checks before publication. Larkinized LLC teaches teams to reject diagrams that look complete but lack definitions, owners, and measures—hallmarks of documentation theater that erodes trust faster than publishing fewer, higher-quality views updated on schedule.

Stakeholder onboarding for what deliverables should togaf produce never ends; annual refreshers for new leaders, rotating product managers, and engineers hired from acquisitions prevent repeated violations caused by ignorance rather than defiance. Micro-learning, office hours, and annotated examples in repositories scale literacy without requiring week-long courses that busy executives and engineers will not attend consistently.

Ultimately what deliverables should togaf produce succeeds when leaders reference architecture evidence in routine decisions—funding, hiring, vendor selection, incident response—not only during transformations. Larkinized LLC measures cultural adoption through decision log sampling: what percentage of major investments cited architecture assets in approval packets last quarter? Rising percentages indicate durability; flat or falling percentages signal sponsorship or relevance problems requiring honest retrospective, not additional templates.

Larkinized LLC closes each engagement on What deliverables should TOGAF produce with a written adoption plan: owners, refresh dates, metrics, and executive checkpoints—so architecture value persists after consultants depart and survives leadership changes that otherwise reset informal progress.

References & Further Reading

• The Open Group, TOGAF Standard — Architecture Content Framework
• The Open Group, TOGAF Standard — Deliverables by ADM Phase
• Gartner, Minimum Viable EA Artifact Set