TOGAF 9 Template - Architecture Definition
TOGAF 9 Template - Architecture Definition
TOGAF 9 Template - Architecture Definition
Project XXXX
Client YYYY
<<Note: This document provides a generic template. It may require tailoring to suit a specific client and
project situation.>>
Table of Contents
1 Purpose of this Document.....................................................................................................................................3
2 Scope.....................................................................................................................................................................4
3 Goals, Objectives, and Constraints........................................................................................................................5
4 Compliance............................................................................................................................................................8
5 Risks and Issues.....................................................................................................................................................9
6 Baseline Architecture...........................................................................................................................................10
7 Rationale and Justification for Architectural Approach......................................................................................35
8 Mapping to Architecture Repository...................................................................................................................36
9 Target Architecture..............................................................................................................................................40
10 Gap Analysis........................................................................................................................................................67
11 Impact Assessment..............................................................................................................................................70
Document Information
Project Name: Project XXX
Prepared By: Document Version No: 0.1
Title: Architecture Definition Document Version Date:
Reviewed By: Review Date:
Distribution List
From Date Phone/Fax/Email
* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)
3.4 Constraints
Concern Do the constraints represent the agreed limitations?
Are they stated clearly and in such a way that design decisions can be made appropriately?
Description A constraint is a basic rule or statement that MUST be followed to ensure that the
organizational and IT strategy/aspirations and the architectural objectives can be met.
Constraints are similar to principles but they have no weighting. Constraints cannot be
violated, they must all be met, so there cannot be a trade-off mechanism to evaluate
conflicting constraints. If the constraints conflict, then a solution alternative or a design
decision is not possible and the constraints must be revisited to identify if any can be
removed.
Guidance Constraints must be unambiguous and have certain attributes. This View is a simple
selection of the architecture constraints. See the architecture constraints artifact template
for a list of attributes.
3.5 Capabilities
<<The purpose of this section is to identify the capabilities <<the client>> needs to have to achieve their
business goals. Capabilities include both business services and application services.
In terms of quality criteria, this section should make clear:
The capabilities and their descriptions
The priority of the capabilities in a list>>
5.2 Risks
Concern Are the risks clearly described and communicated?
Do agreed mitigations exist for all stated risks?
Description A risk is a description of an issue or problem that may arise related to the architecture
development. Risks that are related to the architecture result are mandatory here; project
risks are out of scope.
A risk that has arisen or been realized must be described as an issue (for the project)
and/or a constraint (within the architecture as an artifact).
Guidance This View is a simple selection of the architecture risks.
The number of risks being documented within the architecture should reduce during the
lifetime of an architecture project.
Reference Mitigation
ID Title Description Impact Measures Plan
5.3 Issues
Work
Input Due Closed Group Meeting Notes/
ID Issue Status Date Date Date Owner Owner Comments
5.4 Dependencies
Reference-ID Title Description Impact Measures Comment
<<Business Architecture Function View Example: This section needs to provide one or more business
function views for the baseline business architecture. The diagram below provides a view of the baseline
business function categories and business functions. This particular example illustrates some of the
possible business function categories and business functions. However, the definition of business function
categories and business functions can only be confirmed during the architectural analysis for each
domain. Text describing the key concepts and notation used within the diagram will also need to be
included so that users can easily read and understand the view.>>
<<Business Architecture Conceptual Level View Example: This section needs to provide one or more
conceptual-level views for the current business architecture. The diagram below provides a view of the
current business architecture at the conceptual level which consists of business services categories and
business services. This particular example illustrates some of the business services within XXXX.
However, the definition of business services can only be confirmed during the architectural analysis for
each domain. Text describing the key concepts and notation used within the diagram will also need to be
included so that users can easily read and understand the view.>>
<<Business Architecture Conceptual-Level Artifact Characteristics: This section may provide (in table
format) characteristics for the business services in scope for the current business architecture.>>
Business Service
Business Service Characteristic Business Service Characteristic Value
<<Business Service Security Classification View Example: This section may provide one or more views
of security classification for the baseline business services.>>
<<Business Service Security Classification View Description: Business services have attributes that can
describe various functional and non-functional aspects. Among these attributes is the security
classification. The context within which a business service operates can be derived from the information
objects, as these objects can have a CIA classification.
The definition of the business service security should be carried out before a project is initiated as part of
a Business Impact Analysis.
Project architecture documents must take the security classifications of the artifacts that will be impacted
by the project and ensure both that the intended solution is using appropriately secure artifacts and that it
will not have a negative impact on the security of those artifacts.>>
Reference- Confidentiality Integrity Availability
ID* Title* Subject Classification Classification Classification
<<Business Architecture Organization View Example: This section may provide one or more views of
organizational structure and units for the baseline business architecture.>>
<<Business Architecture Organization View Description: This section needs to provide a description of
the organizational structure and units view(s) for the baseline business architecture in order to understand
the key messages for the stakeholders.>>
<<Business Architecture Organization Definitions: This section needs to provide (in table format)
definitions for the organizational structure and units in scope for the baseline business architecture.>>
TOGAF 9 Template: Architecture Definition 16
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Organization Organization Organization
Unit ID Unit Unit Parent Organization Unit Description
6.1.1.5 Roles
<<The purpose of this section is to describe the roles in the baseline architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human (system) roles in the baseline architecture
Computer (system) roles in the baseline architecture>>
6.1.2.1 Actors
<<The purpose of this section is to describe the system users/actors in scope for the target architecture.
System actors/users are those users who interact with a system. They can be human or a system/computer.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human (system) actors in scope for the baseline architecture
Computer (system) actors in scope for baseline architecture
Any other system actor oriented requirements in scope for the target architecture>>
<<The purpose of this section is to define the human actors in scope for the target architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human actors in scope for the target architecture>>
<<The purpose of this section is to define the computer actors in scope for target architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Computer actors and roles in scope for target architecture>>
Actor
Business Role Actor 1 Actor 2 Actor 3
Role 1 X
TOGAF 9 Template: Architecture Definition 17
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Role 2
Role 3
Role 4
<<Business Architecture Process View Example: This section may provide one or more logical-level
views for the baseline business architecture. These views will illustrate the business processes in the
baseline business architecture. Text describing the key concepts and notation used within the diagram(s)
will also need to be included so that users can easily read and understand the view.>>
<<Business Architecture Process View Description: This section may provide a description of the
business process view(s) in scope for the baseline business architecture in order to understand the key
messages for the stakeholders.>>
<<Business Architecture Process Definitions: This section may provide (in table format) definitions for
the business processes in scope for the baseline business architecture.>>
<<Logical Business Top-Level View Example: This section may provide one or more top-level logical
views for the target business architecture.>>
<<Logical Business Top-Level View Description:
Concern: What are the highest-level structuring principles we have to obey?
Description: Defines and shows the highest aggregation level to be used for the business architecture,
often the business domains, based on a high-level structuring of services delivered to the outside world by
the business. Often one level more detailed than the context diagram.
Guidance: This view helps ensure correct sponsor communication of the architecture. It demonstrates the
products and/or services that the business is delivering to the customers grouped per business domain.
This is often one level more detailed than the context diagram.>>
Purpose : Mendaftarkan Pasien yang akan menjalani Pelayanan Rumah Sakit (Gawat Darurat/Rawat Jalan/Rawat
Inap)
TOGAF 9 Template: Architecture Definition 18
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Owner :
Pasieen
Baru ?
Cetak Kartu
Tentukan Dokter
Tujuan Unit Pelayanan
Tindakan Pelayanan
Boundaries:
Start-point: Pasien mendaftar di Bagian Pendaftaran End-point: Pasien mendapat layanan dari unit
pelayanan yang ditujunya
Includes: Excludes:
<<View that demonstrates the accountability and responsibility of physical business components,
containing business services by business areas or other external organizational units.
The presented Information can be very sensitive. This scope and circulation of this view must be agreed
in advance.>>
Third-
Business Unit Party Implementation
Actors Actors Actors
Activity Actor 1 Actor 2 Actor 3 Actor 4 Actor 5 Actor 6 Actor 7
Activity 1 AR C
Activity 2 AR C C C I
Activity 3 A C R I
Activity 4 AR
Activity 5 R C A I C
Activity 6 C C I C AR I
<<Data Architecture Planning-Level View Description: This section may provide a description of the
planning-level view(s) for the baseline data architecture in order to understand the architectural decisions
that have been taken and resulting key messages for the stakeholders.>>
<Data Architecture Planning Level Artifact Definitions: This section may provide (in table format)
definitions for the information subject areas in scope for the baseline data architecture.>>
Informatio
n Subject Information Subject
Area Id Area Information Subject Area Description
Fungsi Entitas
Pengembangan Lahan Unit Organisasi
Personil
Rencana Kerja Pengembangan
Sumber Daya Pengembangan
Informasi Lahan
Dokumentasi Potensi Lahan
Area Pengembangan
<<Data Architecture Planning-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the information subject areas in scope for the
baseline data architecture.>>
ISA Information
Relationship Information Information Subject Area Information Subject Area Relationship
ID Subject Area 1 Subject Area 2 Cardinality Description
<<Data Architecture Conceptual-Level View Example: This section may provide one or more conceptual
level views for the baseline data architecture. The diagram below provides a view of the baseline data
architecture at the conceptual level which consists of business objects and the relationships between them.
This particular example illustrates the business objects within the marketing information subject area.
Text describing the key concepts and notation used within the diagram will also need to be included so
that users can easily read and understand the view.>>
<<Data Architecture Conceptual-Level View Description: This section may provide a description of the
conceptual -level view(s) for the baseline data architecture in order to understand the architectural
decisions that have been taken and resulting key messages for the stakeholders.>>
Business
Object ID Business Object Business Object Description
<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the business objects in scope for the baseline data
architecture.>>
Business
Object ID Business Object Business Object Description
<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the business objects in scope for the baseline data
architecture.>>
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
Menentukan
Unit Organisasi Area Pembibitan
Menampung
Menugaskan
Mengelola
Mengelola
Personil Bibit Tanaman
Memerlukan
Mengelola
Menggunakan
Menanam
Mengelola
Menghasilkan
Mengirim Mengirim
Pabrik Alat Transportasi
Hasil Tanaman
Menggunakan
Business
Object ID Business Object Business Object Description
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
Menugaskan
Mengelola
Personil
Mensortir
Hasil Tanaman
Menghasilkan
Menghasilkan
Produk
Menghasilkan Persediaan
Produk
Business
Object ID Business Object Business Object Description
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
Mengoperasikan
Personil
Memproses
Verifikasi
Delivery Order Persediaan
Menentapkan
Dokumen
Pelanggan
Pengiriman
Memuat
Mengirim
Alat Transportasi
Business
Object ID Business Object Business Object Description
<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the business objects in scope for the baseline data
architecture.>>
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
6.2.1.6 Pemasaran
Unit Organisasi
Memproses Instruksi
Pengiriman
Mengirim
Menugaskan Riset
Personil Informasi Pasar
Mendasari
Mengelola
Mitra Pemasaran
Menetapkan
Rekomendasi Menghasilkan
Perhitungan PI
Penjualan
Memberikan
Pembeli Bukti Bayar
Memberikan
Pesanan
<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the business objects in scope for the baseline data
architecture.>>
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
Menghasilkan Dokumentasi
Solusi Layanan
Layanan
Membutuhkan
Sumber Daya
Layanan
<<Data Architecture Conceptual-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the business objects in scope for the baseline data
architecture.>>
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
<<Data Service Security Classification View Example: This section may provide one or more views of
security classification for the baseline data services.>>
<<Data Service Security Classification View Description: Data services have attributes that can describe
various functional and non-functional aspects. Among these attributes is the security classification. The
context within which a data service operates can be derived from the information objects, as these objects
can have a classification.
The definition of the data service security should be carried out before a project is initiated as part of a
Data Impact Analysis.
Project architecture documents must take the security classifications of the artifacts that will be impacted
by the project and ensure both that the intended solution is using appropriately secure artifacts and that it
will not have a negative impact on the security of those artifacts.>>
Confiden-
Reference- tiality Integrity Availability
ID Title* Reference Classi- Classi- Classi-
Component Component ID* Title* Subject fication fication fication
<<Application Architecture Conceptual-Level View Description: This section may provide a description
of the conceptual-level view(s) for the baseline application architecture in order to understand the
architectural decisions that have been taken and resulting key messages for the stakeholders.>>
<<Application Architecture Conceptual-Level Artifact Definitions: This section may provide (in table
format) definitions for the application services in scope for the baseline application architecture.>>
Application
Service ID Application Service Application Service Description
<<Application Architecture Conceptual-Level Artifact Characteristics: This section may need to provide
(in table format) characteristics for the application services in scope for the baseline application
architecture. However, the domain will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both. The domain also needs to determine which
characteristics they wish to capture.>>
Application
Application Service
Service Characteristic Application Service Characteristic Value
<<Application Service Security Classification View Example: This section may provide one or more
views of security classification for the baseline application services.>>
<< Application Service Security Classification View Description: Application services have attributes that
can describe various functional and non-functional aspects. Among these attributes is the security
classification.
Project architecture documents must take the security classifications of the artifacts that will be impacted
by the project and ensure both that the intended solution is using appropriately secure artifacts and that it
will not have a negative impact on the security of those artifacts.>>
Confiden-
Reference- tiality Integrity Availability
ID* Title* Reference Classi- Classi- Classi-
Component Component ID* Title* Subject fication fication fication
TOGAF 9 Template: Architecture Definition 35
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
6.3.2 Logical Baseline Application Architecture
<<Application Architecture Logical-Level Example: This section may provide one or more logical-level
views for the baseline application architecture. The diagram below provides a view of the baseline
application architecture at the logical level which consists of logical application components (although
without their associated application services). However, the definition of logical application components
can only be confirmed during the architectural analysis for each domain. Text describing the key concepts
and notation used within the diagram will also need to be included so that users can easily read and
understand the view.>>
<<Application Architecture Logical-Level View Description: This section may provide a description of
the logical-level view(s) for the baseline application architecture in order to understand the architectural
decisions that have been taken and resulting key messages for the stakeholders.>>
<<Application Architecture Logical-Level Artifact Definitions: This section may provide (in table format)
definitions for the logical application components in scope for the baseline application architecture.>>
Logical Application
LAC ID Component (LAC) Logical Application Component (LAC) Description
<<Application Architecture Logical-Level Artifact Characteristics: This section may need to provide (in
table format) characteristics for the logical application components in scope for the baseline application
architecture. However, the domain will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both. The domain also needs to determine which
characteristics they wish to capture.>>
Logical
Application
Component LAC
(LAC) Characteristic LAC Characteristic Value
<<Technology Architecture Conceptual-Level Artifact Definitions: This section may provide (in table
format) definitions for the infrastructure services in scope for the baseline technology architecture.>>
Infrastructure Infrastructure
Service ID Service Infrastructure Service Description
<<Technology Architecture Conceptual-Level Artifact Characteristics: This section may need to provide
(in table format) characteristics for the infrastructure services in scope for the baseline technology
architecture. However, the domain will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both. The domain also needs to determine which
characteristics they wish to capture.>>
Infrastructure
Infrastructure Service
Service Characteristic Infrastructure Service Characteristic Value
<<Technology Architecture Logical-Level Artifact Characteristics: This section may provide (in table
format) characteristics for the logical infrastructure components in scope for the baseline technology
architecture.>>
Logical
Infrastructure
Component LIC
(LIC) Characteristic LIC Characteristic Value
Business Importance
(1-10)
Physical
Infrastructure
PIC Component Physical Infrastructure Component Implementation
ID (PIC) (PIC) Description Features
Baseline Specification:
Service Name Description Type Policy Reference
7.2 Approach
8.1 Artifacts
<<The purpose of this section is to describe the artifacts that are relevant for or from the business
architecture.
Mandatory/optional: This section is optional as there may not be any used artifacts. However, if they are
relevant, this section may either provide references to the relevant documentation that has been produced
separately by the domains, or provide the necessary information.
If the relevant artifact(s) are described in other documentation, in terms of quality criteria, this section
should make clear:
The relevant business architecture artifact documentation
Context around any such relevant business architecture artifact documentation; e.g., validity,
ownership, purpose
Any deviance from existing business artifacts and the reasons why
Any assumptions regarding business architecture artifacts, or their documentation
If the relevant business pattern(s) are not described in other documentation, in terms of quality criteria,
this section should make clear:
Any domain-specific, other domain-specific, or xxxx enterprise architecture-level artifacts that have
been used to help define the business architecture
Any domain-specific, other domain-specific, or xxxx enterprise architecture-level artifacts that can
be derived from the business architecture
Any deviance from existing business artifacts and the reasons why
TOGAF 9 Template: Architecture Definition 43
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Any assumptions regarding business architecture artifacts, or their documentation>>
<<Business Architecture Function View Example: This section needs to provide one or more business
function views for the target business architecture. The diagram below provides a view of the target
business function categories and business functions. This particular example illustrates some of the
business function categories and business functions within xxxx. However, the definition of business
function categories and business functions can only be confirmed during the architectural analysis for
each domain. Text describing the key concepts and notation used within the diagram will also need to be
included so that users can easily read and understand the view.>>
<<Business Architecture Function View Description: This section needs to provide a description of the
business function view(s) for the target business architecture in order to understand the key messages for
the stakeholders.>>
TOGAF 9 Template: Architecture Definition 48
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
<<Business Architecture Function Definitions: This section needs to provide (in table format) definitions
for the business function categories and business functions in scope for the target business architecture.>>
Business
Function Business
(Category) Function
ID Category Business Function Business Function Description
<<Business Architecture Conceptual-Level View Example: This section needs to provide one or more
conceptual-level views for the target business architecture. The diagram below provides a view of the
target business architecture at the conceptual level which consists of business service categories and
business services. This particular example illustrates some of the business services within XXXX.
However, the definition of business services can only be confirmed during the architectural analysis for
each domain. Text describing the key concepts and notation used within the diagram will also need to be
included so that users can easily read and understand the view.>>
<<Business Architecture Conceptual-Level View Description: This section needs to provide a description
of the conceptual-level view(s) for the target business architecture in order to understand the architectural
decisions that have been taken and resulting key messages for the stakeholders.>>
<<Business Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table
format) definitions for the business service categories and business services in scope for the target
business architecture.>>
<<Governance Services: The services must cover the complete scope of the architecture, including
governance and service management. Additional services can be identified by considering how the main
services, when implemented, will be instantiated, started up, shut down, configured, monitored, and how
faults will be diagnosed, users maintained, new business configuration items added (e.g., products) and so
on. For more technical services, management functions such as provisioning, key management, identity
management, backup, recovery, and business continuity should be considered.>>
TOGAF 9 Template: Architecture Definition 49
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Business
Service Business
(Category) Service
ID Category Business Service Business Service Description
<<Business Services Capability Mapping: This table provides a mapping between the capabilities and the
business services.>>
Capability ID Capability Business Service
<<Business Architecture Conceptual-Level Artifact Characteristics: This section may provide (in table
format) characteristics for the business services in scope for the target business architecture.>>
Business Business Service
Service Characteristic Business Service Characteristic Value
<<Business Service Security Classification View Example: This section may provide one or more views
of security classification for the target business services.>>
<<Business Service Security Classification View Description: Business services have attributes that can
describe various functional and non-functional aspects. Among these attributes is the security
classification. The context within which a business service operates can be derived from the information
objects, as these objects can have a CIA classification.
The definition of the business service security should be carried out before a project is initiated as part of
a Business Impact Analysis.
Project architecture documents must take the security classifications of the artifacts that will be impacted
by the project and ensure both that the intended solution is using appropriately secure artifacts and that it
will not have a negative impact on the security of those artifacts.>>
Reference- Confidentiality Integrity Availability
ID* Title* Subject Classification Classification Classification
<<Target Architecture Organization View Example: This section may provide one or more views of
organizational structure and units for the target business architecture.>>
<<Target Architecture Organization View Description: This section needs to provide a description of the
organizational structure and units view(s) for the target business architecture in order to understand the
key messages for the stakeholders.>>
<<Target Architecture Organization Definitions: This section needs to provide (in table format)
definitions for the organizational structure and units in scope for the target business architecture.>>
Org. Comp
Business Service Org. Comp 1 Org. Comp 2 Org. Comp 3
BS 1 X
BS 2
BS 3
BS 4
9.1.1.5 Roles
<<The purpose of this section is to describe the roles in the baseline architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human (system) roles in the baseline architecture
Computer (system) roles in the baseline architecture>>
9.1.2.1 Actors
<<The purpose of this section is to describe the system users/actors in scope for the target architecture.
System actors/users are those users who interact with a system. They can be human or a system/computer.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human (system) actors in scope for the baseline architecture
Computer (system) actors in scope for baseline architecture
Any other system actor oriented requirements in scope for the target architecture>>
<<The purpose of this section is to define the human actors in scope for the target architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Human actors in scope for the target architecture>>
<<The purpose of this section is to define the computer actors in scope for target architecture.
Mandatory/optional: This section is optional.
TOGAF 9 Template: Architecture Definition 51
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
In terms of quality criteria, this section should make clear:
Computer actors and roles in scope for target architecture>>
Actor
Business Role Actor 1 Actor 2 Actor 3
Role 1 X
Role 2
Role 3
Role 4
<<Logical Business Top-Level View Example: This section may provide one or more top-level logical
views for the target business architecture.
<<Logical Business Top-Level View Description:
Concern: What are the highest-level structuring principles we have to obey?
Description: Defines and shows the highest aggregation level to be used for the business architecture,
often the business domains, based on a high-level structuring of services delivered to the outside world by
the business. Often one level more detailed than the context diagram.
Guidance: This view helps ensure correct sponsor communication of the architecture. It demonstrates the
products and / or services that the business is delivering to the customers grouped per business domain.
This is often one level more detailed than the context diagram.>>
<<The purpose of this section is to outline the environment and process models that are in scope for the
target architecture.
Mandatory/optional: This section is mandatory.
In terms of quality criteria, this section should make clear:
Business processes that are in scope for the vision
Business and technology environment in scope for the vision
Users who interact with the business process
Information flows for the business processes>>
<<The purpose of this section is to outline the business processes that are in scope and thus impacted by
the target architecture.
Mandatory/optional: This section is mandatory.
In terms of quality criteria, this section should make clear:
Business processes that are in scope for the vision
If required, high-level diagram(s) of business processes
Descriptions for the business process diagrams>>
<<The purpose of this section is to cross-reference the business processes, in scope, to the business and
technology environments.
Mandatory/optional: This section is mandatory.
In terms of quality criteria, this section should make clear:
Business environment in scope for the vision
Technology environment in scope for the vision>>
Process Comp
Environment Process Comp 1 Process Comp 2 Process Comp 3
Environment 1 X X
Environment 2 X
Environment 3 X
Environment 4 X
<<The purpose of this section is to cross-reference the business processes to business actors; i.e., business
users. Business actors/users are those users who interact with a business process.
Mandatory/optional: This section is mandatory.
In terms of quality criteria, this section should make clear:
Business users involved with the business processes in scope>>
Process Comp
Business Users Process Comp 1 Process Comp 2 Process Comp 3
User 1 X X
User 2 X
User 3 X
User 4 X
<<The purpose of this section is to describe the information flows that correspond to the business
processes in scope for the target architecture.
Mandatory/optional: This section is mandatory.
In terms of quality criteria, this section should make clear:
Information flows for the business processes in scope>>
<<Business Architecture Process View Example: This section may provide one or more logical-level
views for the target business architecture. These views will illustrate the business processes in the target
business architecture. Text describing the key concepts and notation used within the diagram(s) will also
need to be included so that users can easily read and understand the view.>>
<<View that demonstrates the accountability and responsibility of physical business components,
containing business services by business areas or other external organizational units.
The presented information can be very sensitive. This scope and circulation of this view must be agreed in
advance.>>
Third-
Party
Business Unit Actors Actors Implementation Actors
Activity 1 AR C
Activity 2 AR C C C I
Activity 3 A C R I
TOGAF 9 Template: Architecture Definition 54
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Activity 4 AR
Activity 5 R C A I C
Activity 6 C C I C AR I
Process Comp
Business Service Process Comp 1 Process Comp 2 Process Comp 3
BS 1 X X
BS 2 X
BS 3 X
BS 4 X
<<Data Architecture Planning-Level View Description: This section needs to provide a description of the
planning-level view(s) for the target data architecture in order to understand the architectural decisions
that have been taken and resulting key messages for the stakeholders.>>
<<Data Architecture Planning-Level Artifact Definitions: This section needs to provide (in table format)
definitions for the information subject areas in scope for the target data architecture.>>
<<Governance Subject Areas: The subject areas must cover the complete scope of the architecture,
including governance and service management. Additional areas can be identified by considering how the
main areas, when implemented, will be instantiated, started up, shut down, configured, monitored, and
how faults will be diagnosed, users maintained, new business configuration items added (e.g., products),
and so on.>>
Information
Subject Area Information Subject
ID Area Information Subject Area Description
<<Data Architecture Planning-Level Artifact Relationships: This section needs to provide (in table
format) definitions and cardinality for the relationships between the information subject areas in scope for
the target data architecture.>>
<<Data Architecture Conceptual-Level View Example: This section needs to provide one or more
conceptual-level views for the target data architecture. The diagram below provides a view of the target
data architecture at the conceptual level which consists of business objects and the relationships between
them. This particular example illustrates the business objects within the marketing information subject
area. Text describing the key concepts and notation used within the diagram will also need to be included
so that users can easily read and understand the view.>>
<<Data Architecture Conceptual-Level View Description: This section needs to provide a description of
the conceptual-level view(s) for the target data architecture in order to understand the architectural
decisions that have been taken and resulting key messages for the stakeholders.>>
<<Data Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table
format) definitions for the business objects in scope for the target data architecture. An optional attribute
is information classification. With this attribute it is possible to classify the business objects.>>
Business
Object ID Business Object Business Object Description
BO Business
Relationship Business Business Object Business Object Relationship
ID Object 1 Object 2 Cardinality Description
<<Data Service Security Classification View Example: This section may provide one or more views of
security classification for the target data services.>>
<<Data Service Security Classification View Description: Data services have attributes that can describe
various functional and non-functional aspects. Among these attributes is the security classification. The
context within which a data service operates can be derived from the information objects, as these objects
can have a classification.
The definition of the data service security should be carried out before a project is initiated as part of a
Data Impact Analysis.
Project architecture documents must take the security classifications of the artifacts that will be impacted
by the project and ensure both that the intended solution is using appropriately secure artifacts and that it
will not have a negative impact on the security of those artifacts.>>
Confiden-
Reference tiality Integrity Availability
ID* Title* Reference Classi- Classi- Classi-
Component Component ID* Title* Subject fication fication fication
<<Data Architecture Logical-Level Artifact Characteristics: This section needs to provide (in table
format) characteristics for the logical data entities in scope for the target data architecture. The domain
needs to determine which characteristics they wish to capture.>>
Logical Data Entity
Logical Data Entity Characteristic Logical Data Entity Characteristic Value
<<Data Architecture Logical-Level Artifact Attribute Definitions: This section needs to provide (in table
format) definitions for the attributes of the logical data entities in scope for the target data architecture. A
separate table may be produced per logical data entity. An optional attribute is information classification.
With this attribute it is possible to classify the Logical Data Entities.>>
Logical
Data Logical Data Entity
Entity Attribute Logical Data Entity Attribute Description
<<Application Services Capability Mapping: This table provides a mapping between the capabilities and
the business services.>>
TOGAF 9 Template: Architecture Definition 62
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Capability
ID Capability Business Service Application Service
<<Application Architecture Conceptual-Level Artifact Characteristics: This section may need to provide
(in table format) characteristics for the application services in scope for the target application architecture.
However, the domain will need to decide whether characteristics are needed at the conceptual services
level, logical component level, or both. The domain also needs to determine which characteristics they
wish to capture. They may wish to include additional characteristics. Governance and service
management characteristics should be included here.>>
Application
Application Service
Service Characteristic Application Service Characteristic Value
Unit Organisasi
Informasi Lahan
Area Pengembangan
Hasil Survey
Obyek Kegiatan
Dokumentasi Kegiatan
Dokumentasi Pemeliharaan
Spesifikasi Teknis
Fungsi & Proses Bisnis L L L O L O O O O L O S S S L
Pere
C
R U
R
1.1.2 Pengumpulan Informasi
C
R R U
R
1.1.3 Dokumentasi Potensi Lahan
R R
U
R
R
1.1.5 Persetujuan Survey Lahan
C C
R R U R U
R R
1.2.1 Persiapan Survey
C
Survey R U
R
1.2.2 Pelaksanaan Survey
C
R R R R R R U
R
1.2.3 Pelaporan
Pelaksanaan Pengembangan
C
R R R U
R
1.3.1 Penguasaan lahan dan ganti rugi
U
R
R
1.3.2 Penyiapan lahan
1.3.3 Pelaporan R R R C
Evaluasi R R R R R
C
R R R U
R
2.1.1 Penyusunan Rencana Kerja
C
R U
R
2.1.2 Pengajuan Rencana
Perencanaan Teknik
U
R
R
2.1.3 Persetujuan
C
R U
R
2.1.4 Sosialisasi
C
M R U
R
2.2.1 Permintaan Sumber Daya
U
Pengadaan Teknik M
R
2.2.2 Realisasi Sumber Daya
M R
2.2.3 Pelaporan
Operasional Teknik 2.3.1 Persiapan Operasional M R R
C
U U
M R R U
R R
R
2.3.3 Pemeliharaan Fasilitas
Evaluasi M R R
2.4 Evaluasi
Pengelolaan Tanaman
L R
3.1.3 Persetujuan L
3.1.4 Sosialisasi L
Pembibitan
C
U
R
3.2.1 Persiapan Pembibitan L
3.2.2 Realisasi Sumber Daya L
3.2.5 Evaluasi M
Panen
3.6.2 Penimbangan H
3.6.3 Pemuatan Produk H
4.1.3 Persetujuan M
4.1.4 Sosialisasi M
Penerimaan Hasil Kebun
4.2.2 Penimbangan H
4.2.3 Penyortiran H
4.2.4 Pelaporan & Evaluasi H
Pelaksanaan Produksi
4.4.1 Identifikasi H
4.4.3 Dokumentasi H
4.4.4 Disposisi Limbah H
5.1.1 Penerimaan DO M
5.1.3 Verifikasi DO M
Pemeriksaan Kendaraan
5.2.1 (Transporter) M
Perencanaan Pemasaran
6.1.4 Perhitungan PI M
Pelaksanaan Tender
Penerimaan Pesanan
R R
7.1.3 Persetujuan M
7.1.4 Sosialisasi M
<<Application Service Security Classification View Example: This section may provide one or more views of security classification for the target
application services.>>
<<Application Service Security Classification View Description: Application services have attributes that can describe various functional and non-
functional aspects. Among these attributes is the security classification.
Project architecture documents must take the security classifications of the artifacts that will be impacted by the project and ensure both that the
intended solution is using appropriately secure artifacts and that it will not have a negative impact on the security of those artifacts.>>
Confiden-
Reference tiality Integrity Availability
ID Title* Reference Classi- Classi- Classi-
Component Component ID* Title* Subject fication fication fication
<<Application Architecture Logical-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the logical
application components in scope for the target application architecture. However, the domain will need to decide whether characteristics are
needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to
capture.>>
<<Application Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e.,
interactions/relationships) between the logical application components in scope for the target application architecture.>>
LAC Logical Logical
Contract LAC Application Application
ID Contract Component 1 Component 2 LAC Contract Description
<<Application Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the
contracts (i.e., interactions/relationships) between the logical application components in scope for the target application architecture. The domain
needs to determine which characteristics they wish to capture.>>
LAC Contract
LAC Contract Characteristic LAC Contract Characteristic Value
<<This section provides a list with relevant suppliers and brands for providing the physical components and the considerations for selecting or
using them.>>
Vendor/Product Component Considerations
<<Technology Architecture Conceptual-Level View Description: This section needs to provide a description of the conceptual-level view(s) for the
target technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the
stakeholders.>>
<<Technology Architecture Conceptual-Level Artifact Definitions: This section needs to provide (in table format) definitions for the infrastructure
services in scope for the target technology architecture.>>
<<Governance Services: The services must cover the complete scope of the architecture, including governance and service management.
Additional services can be identified by considering how the main services, when implemented, will be instantiated, started up, shut down,
configured, monitored, and how faults will be diagnosed, users maintained, new business configuration items added (e.g., products), and so on.
For more technical services, management functions such as provisioning, key management, identity management, backup, recovery, and business
continuity should be considered.>>
Infrastructure Infrastructure
Service ID Service Infrastructure Service Description
<<Technology Architecture Conceptual-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the
infrastructure services in scope for the target technology architecture. However, the domain will need to decide whether characteristics are needed
at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to
capture..>>
Infrastructure
Infrastructure Service
Service Characteristic Infrastructure Service Characteristic Value
<<Technology Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e.,
interactions/relationships) between the logical infrastructure components in scope for the target technology architecture.>>
CIS Logical Logical
Contract CIS Infrastructure Infrastructure
ID Contract Component 1 Component 2 LIC Contract Description
<<Technology Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the
contracts (i.e., interactions/relationships) between the conceptual infrastructure services in scope for the target technology architecture. The
domain needs to determine which characteristics they wish to capture.>>
CIS Contract
CIS Contract Characteristic CIS Contract Characteristic Value
<<Technology Architecture Logical-Level View Description: This section needs to provide a description of the logical-level view(s) for the target
technology architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders.
More than one logical component architecture can be created by an architecture project, and then the different options evaluated and a
recommended option chosen. If more than one option is considered, the document structure for the logical technology architecture should be
repeated for each option. In addition, a section to evaluate the options must be added and a section containing the recommendations. This applies
to unbranded and branded architectures.>>
<<Technology Architecture Logical-Level Artifact Definitions: This section needs to provide (in table format) definitions for the logical
infrastructure components in scope for the target technology architecture.>>
Logical
Infrastructure
LIC ID Component (LIC) Logical Infrastructure Component (LIC) Description
<<Technology Architecture Logical-Level Artifact Characteristics: This section may need to provide (in table format) characteristics for the logical
infrastructure components in scope for the target technology architecture. However, the domain will need to decide whether characteristics are
needed at the conceptual services level, logical component level, or both. The domain also needs to determine which characteristics they wish to
capture.>>
TOGAF 9 Template: Architecture Definition 83
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Logical
Infrastructure
Component LIC
(LIC) Characteristic LIC Characteristic Value
<<Technology Architecture Logical-Level Artifact Contracts: This section may provide (in table format) descriptions of the contracts (i.e.,
interactions/relationships) between the logical infrastructure components in scope for the target technology architecture.>>
LIC Logical Logical
Contract LIC Infrastructure Infrastructure
ID Contract Component 1 Component 2 LIC Contract Description
<<Technology Architecture Logical-Level Artifact Contract Characteristics: This section may provide (in table format) characteristics of the
contracts (i.e., interactions/relationships) between the logical infrastructure components in scope for the target technology architecture. The
domain needs to determine which characteristics they wish to capture.>>
LIC Contract
LIC Contract Characteristic LIC Contract Characteristic Value
<<This section provides a list with relevant suppliers and brands for providing the physical components and the considerations for selecting or
using them.>>
Vendor/Product Component Considerations
Target Specification:
Service Name Description Type Policy Reference
11.4 Conclusions
<<The purpose of this section is to draw conclusions about the architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
Overall conclusions that can be drawn>>
11.5 Recommendations
<<The purpose of this section is make recommendations about the architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:
TOGAF 9 Template: Architecture Definition 89
Copyright 2010 The Open Group. All rights reserved. TOGAF is a trademark of The Open Group.
Recommendations for implementing this architecture>>