Architecture Deliverables: Complete Guide for TOGAF 10 Foundation Exam

Architecture Deliverables: Complete Guide for TOGAF 10 Foundation Exam

Introduction

Architecture Deliverables are one of the most critical components of the TOGAF 10 Foundation framework. They represent the tangible outputs and work products produced during the architecture development process. Understanding what constitutes an architecture deliverable, why it matters, and how to approach related exam questions is essential for achieving success in the TOGAF 10 Foundation certification.

Why Architecture Deliverables Are Important

Architecture Deliverables serve several crucial purposes in enterprise architecture:

1. Communication and Documentation
Deliverables provide a formal mechanism to communicate architectural decisions, findings, and recommendations to stakeholders. They document the architecture in a structured way that can be understood by both technical and non-technical audiences.

2. Governance and Compliance
Deliverables establish a clear record of architectural work performed and decisions made. This supports governance processes, ensures accountability, and provides evidence of compliance with organizational and regulatory requirements.

3. Decision Support
By documenting various architectural views and analyses, deliverables provide the information needed by decision-makers to understand the implications of different architectural approaches and make informed choices.

4. Knowledge Preservation
Deliverables serve as institutional knowledge repositories that preserve architectural thinking, rationale, and decisions for future reference and organizational learning.

5. Quality Assurance
Formal deliverables enable review, validation, and quality assurance of architectural work through defined review and approval processes.

What Are Architecture Deliverables?

In TOGAF 10, Architecture Deliverables are defined as the formal work products that document the architecture, including models, views, and supporting materials that are reviewed, agreed, and signed off by stakeholders.

Key Characteristics of Architecture Deliverables:

• Formal: They are officially recognized and documented work products
• Reviewed: They undergo quality and completeness reviews
• Agreed: Stakeholders formally approve and accept them
• Signed Off: They receive formal authorization from governance bodies
• Traceable: They can be traced back to requirements and architectural decisions
• Controlled: They are subject to change management processes

Architecture Deliverables in the TOGAF Framework

The TOGAF 10 Architecture Content Framework organizes architecture deliverables into several categories:

Building Blocks
Deliverables that represent fundamental architectural components that can be combined to create solutions. These include both Architecture Building Blocks (ABBs) that represent architectural capabilities and Solution Building Blocks (SBBs) that represent concrete implementations.

Architecture Views
Formal representations of the architecture from different perspectives. Views are organized according to the stakeholder concerns they address. In TOGAF, common views include:
• Business Architecture View
• Information Systems Architecture View
• Technology Architecture View

Architecture Models
Structured representations of the architecture using specific modeling notations and standards. Models support different types of analysis and communication.

Supporting Documents
Additional materials that support the architecture including:
• Architecture Decisions
• Business Requirements
• Gaps and Overlaps
• Implementation Roadmaps
• Risk Assessments
• Impact Analyses

How Architecture Deliverables Work

The Lifecycle of Architecture Deliverables

1. Identification
At the beginning of an architecture project, the specific deliverables required are identified based on the scope, stakeholders, and objectives. The Architecture Development Method (ADM) phase being executed determines which deliverables are relevant.

2. Development
Deliverables are developed iteratively throughout the ADM phases. Architects create the content, representations, and analyses required to address the identified scope and stakeholder concerns.

3. Review
Before deliverables are finalized, they undergo quality and completeness reviews. These reviews ensure that:
• Content is accurate and complete
• Representations are correct and clear
• All stakeholder concerns are addressed
• Requirements have been adequately documented
• Traceability to requirements is maintained

4. Approval
Stakeholders review and formally approve the deliverables. This approval indicates that the deliverables accurately represent the agreed architecture and satisfy the stated requirements.

5. Baseline Establishment
Approved deliverables form the basis of the architecture baseline. This baseline becomes the foundation for further phases of the ADM and is placed under configuration management and change control.

6. Usage and Evolution
Deliverables are used throughout the organization to guide implementation activities, assess compliance, and make architectural decisions. As circumstances change, deliverables are updated through formal change management processes.

Key Deliverables by ADM Phase

Phase A: Architecture Vision
• Architecture Vision document
• Business Scenarios
• Statement of Architecture Work
• Stakeholder Map and Analysis
• Architecture Charter

Phase B: Business Architecture
• Business Reference Model
• Business Capability Map
• Business Process Models
• Organizational Structure Diagrams
• Business Service/Function Definitions

Phase C: Information Systems Architecture
• Data Architecture deliverables (data models, entity relationship diagrams)
• Application Architecture deliverables (application portfolio, application interaction diagrams)
• System Interfaces and Integration diagrams

Phase D: Technology Architecture
• Technology Reference Models
• Technology Standards Catalog
• Technology Infrastructure diagrams
• System and Technology Matrix

Phase E: Opportunities and Solutions
• Implementation and Migration Strategy
• Project and Portfolio Roadmap
• Benefits Analysis
• Solution Architecture Building Blocks

Phase F: Migration Planning
• Migration and Implementation Plan
• Detailed Implementation Roadmap
• Risk and Issue Management Plans

Phase G: Implementation Governance
• Architecture Compliance Framework
• Architecture Compliance Reviews
• Contract and Procurement Documentation

Phase H: Architecture Change Management
• Architecture Change Management Charter
• Architecture Evolution Documentation
• Change Impact Assessments

Important Distinctions

Architecture Deliverables vs. Architecture Content
While related, these are not identical:
• Architecture Content refers to all the architecture models, views, building blocks, and supporting materials created during the architecture process
• Architecture Deliverables specifically refers to the formalized, reviewed, and approved work products that are formally delivered to stakeholders and placed under governance control
Not all architecture content becomes a formal deliverable—some may be interim work or analysis that supports deliverable development but is not itself formally delivered.

Deliverables vs. Work Products
In TOGAF terminology:
• Work Products are broader in scope and include all outputs from architecture activities
• Deliverables are a subset of work products that have been formally reviewed, approved, and delivered to stakeholders

The Importance of Architecture Viewpoints and Views

Architecture Viewpoints and Views are central to architecture deliverables. A Viewpoint is a specification of conventions for constructing and using a view. A View is a concrete application of a viewpoint presenting selected aspects of the architecture.

Key viewpoint concepts for exam preparation:
• Viewpoints are reusable standards for representing architecture
• Views are specific instances of viewpoints addressing stakeholder concerns
• Multiple views may be derived from a single viewpoint
• Different stakeholders require different views of the architecture

Architecture Deliverables Quality Criteria

When evaluating or developing architecture deliverables, they should meet the following criteria:

Completeness
Deliverables must contain all necessary information to address the identified scope and stakeholder concerns. Missing elements reduce the deliverable's value and utility.

Accuracy
All content must be accurate and current. Inaccurate information can lead to poor implementation decisions and failed architecture initiatives.

Clarity
Deliverables must be clearly presented so that intended audiences can understand them. This includes appropriate use of diagrams, notation standards, and supporting explanations.

Consistency
Deliverables must be internally consistent and consistent with other architecture work. Contradictions between deliverables create confusion and hinder decision-making.

Traceability
Each significant element in deliverables should be traceable to requirements or architectural decisions, and forward to implementation artifacts.

Stakeholder Alignment
Deliverables must address the concerns and meet the needs of identified stakeholders. Regular stakeholder consultation during development ensures alignment.

Exam Tips: Answering Questions on Architecture Deliverables

Tip 1: Understand What Makes Something a Deliverable
Key exam insight: Not all architecture work products are deliverables. Deliverables are specifically those that are:
• Formally documented
• Reviewed and validated
• Approved by stakeholders
• Placed under governance and change control

When exam questions ask about deliverables, they're asking about these formal, approved outputs—not draft documents or interim working papers.

Tip 2: Know the Phase-to-Deliverable Mapping
Exam questions often ask which deliverables are produced in a specific ADM phase. Create a mental map of key deliverables for each phase:
• Phase A produces the Architecture Vision and Statement of Architecture Work
• Phases B, C, D produce architecture definitions (business, information systems, technology)
• Phase E produces implementation strategy and roadmaps
• Later phases produce governance and change management artifacts

Understanding this mapping helps you answer questions about what should be delivered when.

Tip 3: Distinguish Between Views and Viewpoints
Exam questions frequently test your understanding of this distinction:
• Viewpoint: The standard, the specification, the template (typically one per architecture dimension)
• View: The actual instantiation, the concrete representation addressing specific stakeholder concerns (multiple views may come from one viewpoint)

When a question mentions "creating a new view," it's about applying an existing viewpoint to show a specific aspect of architecture.

Tip 4: Remember the Approval and Sign-Off Process
Questions about deliverable management often emphasize that deliverables must be:
• Reviewed for completeness and accuracy
• Approved by stakeholders
• Formally signed off by governance bodies
• Placed under configuration control

If an exam question describes a scenario where architectural work hasn't been formally reviewed and approved, it's not yet a formal deliverable—it's still a work product in development.

Tip 5: Understand Deliverable Evolution Through ADM Phases
Deliverables aren't created once and forgotten. Many deliverables evolve through multiple phases:
• Early phases create higher-level, more abstract deliverables
• Later phases create more detailed, concrete deliverables
• Each phase may refine or expand earlier deliverables

Questions may test whether you understand how a deliverable from Phase A relates to and informs deliverables in Phase E.

Tip 6: Know the Content of Key Deliverables
Exam preparation should include familiarity with what specific deliverables contain. For example:
• Statement of Architecture Work: Contains scope, objectives, business drivers, constraints
• Architecture Reference Models: Define generic architectures for the domain
• Architecture Roadmap: Shows target state architecture and the path to achieve it
• Implementation and Migration Plan: Details how to transition from current to target state

Tip 7: Focus on the "Why" Behind Deliverables
Exam questions often test whether you understand why specific deliverables are necessary:
• Why must we have both current state and target state deliverables?
• Why do different stakeholders need different views of the same architecture?
• Why must deliverables be formally approved before implementation begins?

When you understand the purpose of a deliverable, you can answer questions about its content and use more effectively.

Tip 8: Recognize Stakeholder Concerns in Deliverable Design
A common exam theme is matching deliverables to stakeholder concerns:
• A CFO needs to understand financial implications (benefits analysis deliverable)
• Operations teams need implementation roadmaps
• IT staff need technology architecture specifications
• Business leaders need business capability maps

Questions may present a stakeholder need and ask which deliverable would best address it.

Tip 9: Understand the Concept of Architecture Governance
Deliverables are central to architecture governance. Governance questions often involve deliverables:
• What governs the creation of deliverables? (The Architecture Governance Framework)
• Who approves deliverables? (The Architecture Board)
• How are changes to deliverables managed? (Change management processes)
• What ensures compliance with deliverables? (Architecture compliance reviews)

The relationship between deliverables and governance is frequently tested.

Tip 10: Practice Traceability Questions
Exam questions test your understanding of traceability relationships:
• Requirements → Architecture decisions → Deliverable content → Implementation artifacts
• Being able to trace "why" something appears in a deliverable (what requirement drove it) demonstrates deep understanding

Tip 11: Remember That Views Are for Stakeholders
A critical concept: Architecture Views exist because different stakeholders have different information needs:
• Business executives need business capability views
• CIO needs technology infrastructure views
• Project managers need implementation roadmap views
• Architects need comprehensive architecture models

When questions discuss views, remember that view selection should be driven by stakeholder concerns.

Tip 12: Study the Building Blocks Deliverable Concept
Building blocks are a specific type of architecture deliverable that deserves attention:
• Architecture Building Blocks (ABBs): Represent required capabilities at the architecture level
• Solution Building Blocks (SBBs): Represent concrete implementations of ABBs
• Building block definitions should be clear enough that multiple solutions can implement the same ABB
• Building blocks support reusability and modularity

Questions may ask about the relationship between ABBs and SBBs, or how building blocks relate to other deliverables.

Common Exam Question Patterns

Pattern 1: "Which of the following is a deliverable of Phase X?"
Answer Strategy: Recall the specific deliverables produced in that phase. Don't confuse deliverables from different phases. Remember that some deliverables span multiple phases.

Pattern 2: "What is the primary purpose of deliverable X?"
Answer Strategy: Remember that deliverables serve stakeholder communication, governance, and decision support purposes. Link the specific deliverable to these purposes.

Pattern 3: "Which stakeholder needs would be addressed by deliverable X?"
Answer Strategy: Think about what information each deliverable provides and which stakeholder roles would need that information.

Pattern 4: "What should happen before a work product becomes a deliverable?"
Answer Strategy: The answer typically involves review, approval, and sign-off. Formal governance processes must be completed.

Pattern 5: "How many views might be derived from a single viewpoint?"
Answer Strategy: Multiple views—stakeholder concerns drive the creation of specific views from the same viewpoint.

Common Misconceptions to Avoid

Misconception 1: All architecture work products are deliverables
Reality: Only formally reviewed, approved, and signed-off work products are deliverables. Interim analysis and working papers are not.

Misconception 2: Viewpoints and views are the same thing
Reality: Viewpoints are reusable standards; views are specific instantiations addressing stakeholder concerns.

Misconception 3: Deliverables are created once and remain static
Reality: Deliverables evolve through ADM phases and are updated through change management processes.

Misconception 4: All stakeholders need the same views of the architecture
Reality: Different stakeholders need different views based on their concerns and information needs.

Misconception 5: Architecture governance only applies after deliverables are complete
Reality: Governance frameworks guide deliverable creation and must be in place before formal deliverables are produced.

Quick Reference: Key Deliverable Attributes

Formal Deliverables Must Be:
✓ Documented in writing
✓ Reviewed for accuracy and completeness
✓ Approved by relevant stakeholders
✓ Signed off by governance authorities
✓ Placed under change control
✓ Traceable to requirements and decisions
✓ Maintained as organizational assets

Architecture Viewpoints Should Specify:
✓ What concerns they address
✓ Who the intended audience is
✓ What modeling notation to use
✓ What content elements to include
✓ How to evaluate correctness
✓ How to review and approve views

Final Preparation Recommendations

To excel on exam questions about Architecture Deliverables:

1. Create a Deliverables Matrix
Make a table showing each ADM phase and its associated deliverables. Use this to test yourself on phase-to-deliverable mapping.

2. Study Example Deliverables
If possible, review templates or examples of actual architecture deliverables. This helps you understand what they contain and why they're organized that way.

3. Understand the Rationale
For each major deliverable, be able to explain why it's necessary and what stakeholder concerns it addresses.

4. Practice Scenario Questions
Work through scenarios that ask what deliverables would be needed in specific situations. This tests practical understanding beyond memorization.

5. Review Change Management Concepts
Since deliverables are subject to change management, ensure you understand how architecture governance and change management apply to deliverables.

6. Link Deliverables to Implementation
Understand how deliverables guide and control implementation activities. This connection is frequently tested.

Conclusion

Architecture Deliverables are core to the TOGAF 10 Foundation framework. They represent the formal outputs that communicate architectural decisions, support governance, and guide implementation. Success on the certification exam requires understanding not just what deliverables are, but why they exist, how they're created and approved, how they evolve through the ADM, and how different stakeholders use them.

By mastering the material in this guide and following the exam tips provided, you'll be well-prepared to answer questions about Architecture Deliverables confidently and correctly. Remember that the key concepts are formality, approval, governance, stakeholder alignment, and traceability—these themes appear repeatedly in exam questions about deliverables.