TOGAF® Template – Architecture Definition
Version 2.0
July 2024
Project XXXX
Client YYYY
Note: This document provides a generic template. It may require tailoring to suit a specific client and
project situation.
Document Version History
Version Version Revised By Description Filename
Number Date
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 2
Contents
1. Purpose of this Document...................................................................................................................................5
1.1 Output and Input....................................................................................................................................5
2. Architecture Definition.......................................................................................................................................6
2.1 Scope......................................................................................................................................................6
2.2 Goals, Objectives, and Constraints........................................................................................................6
2.2.1 Goals...........................................................................................................................................6
2.2.2 Objectives...................................................................................................................................6
2.2.3 Constraints..................................................................................................................................6
2.3 Architecture Principles..........................................................................................................................6
2.4 Baseline Architecture.............................................................................................................................6
2.5 Architecture Models (For Each State to be Modeled)...........................................................................6
2.5.1 Business Architecture Models....................................................................................................7
2.5.2 Data Architecture Models...........................................................................................................7
2.5.3 Application Architecture Models...............................................................................................7
2.5.4 Technology Architecture Models...............................................................................................7
3. Rationale and Justification for Architectural Approach.....................................................................................8
3.1 Rationale................................................................................................................................................8
3.2 Approach................................................................................................................................................8
4. Mapping to Architecture Repository...................................................................................................................9
4.1 Mapping to Architecture Landscape......................................................................................................9
4.2 Mapping to Reference Models...............................................................................................................9
4.3 Mapping to Standards............................................................................................................................9
4.4 Re-Use Assessment...............................................................................................................................9
5. Gap Analysis.....................................................................................................................................................10
6. Resolve Impact Across the Architecture Landscape.........................................................................................11
6.1 Impact on Pre-Existing Architectures..................................................................................................11
6.2 Recent Changes Impacting the Business Architecture........................................................................11
6.3 Opportunities.......................................................................................................................................11
6.4 Impact on Other Projects.....................................................................................................................11
7. Transition Architecture.....................................................................................................................................12
7.1 Definition of Transition States.............................................................................................................12
7.2 Business Architecture for Each Transition State.................................................................................12
7.3 Data Architecture for Each Transition State........................................................................................12
7.4 Application Architecture for Each Transition State............................................................................12
7.5 Technology Architecture for Each Transition State............................................................................12
Tracking Information
Project Name Project XXXX
Prepared By Document Version No.
Title Architecture Definition Document Version Date
Reviewed By Review Date
Distribution List
From Date Phone/Email
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 3
To Action* Due Date Phone/Email
* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 4
1. Purpose of this Document
The Architecture Definition Document is the deliverable container for the core architectural artifacts
created during a project and for important related information. The Architecture Definition Document
spans all architecture domains (Business, Data, Application, and Technology) and also examines all
relevant states of the architecture (Baseline, Transition, and Target).
A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline
and Target Architectures. Transition Architectures are used to describe transitional Target Architectures
necessary for effective realization of the Target Architecture.
The Architecture Definition Document is a companion to the Architecture Requirements Specification,
with a complementary objective:
The Architecture Definition Document provides a qualitative view of the solution and aims to
communicate the intent of the architects
The Architecture Requirements Specification provides a quantitative view of the solution, stating
measurable criteria that must be met during the implementation of the architecture
1.1 Output and Input
The TOGAF® Content Framework (see 4. Architecture Deliverables) identifies deliverables that are
produced as outputs from executing the Architecture Development Method (ADM) cycle and potentially
consumed as inputs at other points in the ADM.
This deliverable is produced, updated, and consumed by the ADM Phases:
Deliverable Output from… Input to…
Architecture Definition A, B, C, D, E, F B, C, D, E, F, G, H
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 5
2. Architecture Definition
2.1 Scope
The scope of organizations impacted. The scope is first set on the Architecture Definition draft in Phase A
and may evolve depending during the next phases and iterations.
2.2 Goals, Objectives, and Constraints
2.2.1 Goals
2.2.2 Objectives
2.2.3 Constraints
2.3 Architecture Principles
Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and
support the way in which an organization sets about fulfilling its mission.
May reference the Architecture Principles documentation.
Name <Name of Principle>
Statement
Rationale
Implications
2.4 Baseline Architecture
Develop a Baseline Description of the existing Business Architecture, to the extent necessary to support
the Target Business Architecture. The scope and level of detail to be defined will depend on the extent to
which existing business elements are likely to be carried over into the Target Business Architecture, and
on whether Architecture Descriptions exist, as described in Approach. To the extent possible, identify the
relevant Business Architecture building blocks, drawing on the Architecture Repository (see the TOGAF
Standard – Architecture Content).
2.5 Architecture Models (For Each State to be Modeled)
An “Architecture Model” is a representation of a subject of interest. A model provides a smaller scale,
simplified, and/or abstract representation of the subject matter.
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 6
2.5.1 Business Architecture Models
2.5.2 Data Architecture Models
2.5.3 Application Architecture Models
2.5.4 Technology Architecture Models
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 7
3. Rationale and Justification for Architectural Approach
3.1 Rationale
3.2 Approach
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 8
4. Mapping to Architecture Repository
4.1 Mapping to Architecture Landscape
4.2 Mapping to Reference Models
4.3 Mapping to Standards
4.4 Re-Use Assessment
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 9
5. Gap Analysis
A key step in validating an architecture is to consider what may have been forgotten. The architecture
must support all of the essential information processing needs of the organization. The most critical
source of gaps that should be considered is stakeholder concerns that have not been addressed in prior
architectural work; see Gap Analysis.
Potential sources of gaps include:
Business domain gaps:
— People gaps (e.g., cross-training requirements)
— Process gaps (process inefficiencies)
— Tools gaps (e.g., duplicate or missing tool functionality)
— Information gaps
— Measurement gaps
— Financial gaps
— Facilities gaps (buildings, office space, etc.)
Data domain gaps:
— Data not of sufficient currency
— Data not located where it is needed
— Not the data that is needed
— Data not available when needed
— Data not created
— Data not consumed
— Data relationship gaps
Applications impacted, eliminated, or created
Technologies impacted, eliminated, or created
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 10
6. Resolve Impact Across the Architecture Landscape
Once the Business Architecture is finalized, it is necessary to understand any wider impacts or
implications.
6.1 Impact on Pre-Existing Architectures
Does this Business Architecture create an impact on any pre-existing architectures?
6.2 Recent Changes Impacting the Business Architecture
Have recent changes been made that impact on the Business Architecture?
6.3 Opportunities
Are there any opportunities to leverage work from this Business Architecture in other areas of the
organization?
6.4 Impact on Other Projects
Will this Business Architecture be impacted by other projects (including those planned as well as those
currently in progress)?
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 11
7. Transition Architecture
7.1 Definition of Transition States
7.2 Business Architecture for Each Transition State
7.3 Data Architecture for Each Transition State
7.4 Application Architecture for Each Transition State
7.5 Technology Architecture for Each Transition State
TOGAF® Template – Architecture Definition TOGAF is a registered trademark of The Open Group 12
