Architecture Definition
Project: Developing Faculty of Computers
and artificial intelligence.
Client: Faculty of computers and artificial
intelligence.
Table of Contents
1
2
3
4
5
6
7
8
9
10
11
Purpose of this Document .................................................................................................................................... 3
Scope .................................................................................................................................................................... 4
Goals, Objectives, and Constraints ...................................................................................................................... 8
Compliance ........................................................................................................................................................ 13
Risks and Issues ................................................................................................................................................. 17
Baseline Architecture ......................................................................................................................................... 20
Rationale and Justification for Architectural Approach ..................................................................................... 44
Mapping to Architecture Repository .................................................................................................................. 45
Target Architecture ............................................................................................................................................ 49
Gap Analysis ...................................................................................................................................................... 76
Impact Assessment ............................................................................................................................................. 79
Document Information
Project Name:
Project XXX
Prepared By:
Document Version No:
Business Phase
Title:
0.1
Document Version Date:
Reviewed By:
Review Date:
Distribution List
From
To
Action*
Date
Phone/Fax/Email
Due Date
Phone/Fax/Email
* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)
Document Version History
Version
Number
Version
Date
Revised By
Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Filename
2
TOGAF™ is a trademark of The Open Group.
1
Purpose of this Document
This document serves as a delivery container for the project's main architectural
artifacts as well as crucial associated information. And to establish a business, data,
application, and technological baseline for an organization. And it aims to explain
the architects' meaning by providing a qualitative picture of the solution.
The business phase represents comprehensive, multi-dimensional business views
of capabilities, end-to-end value delivery, information, and organisational
structure, as well as the links between these business views and products, policies,
initiatives, and stakeholders.
An architectural description of a company or a business unit, an architectural
model, or the profession itself are all terms that are often used. “A blueprint of the
enterprise that gives a shared knowledge of the organization and is used to connect
strategic objectives with tactical needs," according to the Business Architecture.
The important feature of business architecture is that it depicts real-world aspects
of a company's operations as well as how they interact. It is created by a
multidisciplinary practice area dedicated to identifying and assessing issues related
to what businesses do, how they do it, how they are structured, and how they create
value.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
3
TOGAF™ is a trademark of The Open Group.
2
Scope
Architectures will only be successful if they are scoped correctly. The Enterprise
Architecture Body of Knowledge (EABOK) describes three important aspects of
scope, but another one can be added that addresses the importance of the
stakeholders in the success of the architecture program and the architectures it
creates and manages:

Management system inside the college.

System automation for registration for Student, Staff, and courses.

Companies and centre training

Labs, section, and classroom

Smart attendance system

Stakeholder Scope

Infrastructure
Description
-Management system inside the college.
Enable students to pay tuition fees and other student affairs
services online.
Make the data of all students stored on the system and enable the
staff to understand and deal with this data.
Guidance
Description
The traditional management system has become difficult to deal
with due to many errors so new system will easily help to
minimize a paper works and track the past records of students and
record the problem and violations of a student in guidance office.
-System
automation for registration for Student, Staff, and
courses.
It is very important for the faculty members to concern that
students must register for courses they would like to study before
starting study also, register their data online and enable students
to evaluate the working environment inside faculty (staff, courses,
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
4
TOGAF™ is a trademark of The Open Group.
management) also, staff will evaluate students.
Guidance
old traditional registration system causes many errors and not
efficient, so the new registration system works faster and more
efficient and enable students and staff to Look at their recordings
easily.
Description
-Companies and centre training.
Providing scholarships for students, whether online or offline,
such as ITI, as well as providing training in companies in many
fields.
Guidance
We noticed the lack of experience and communication skills
among the graduates due to the lack of training in the work
environment, and therefore the training will increase their
efficiency and experience.
Description
-Labs, section, and classroom
We need to prepare a standard lab adhere to the international
standard for example lab should contain not exceed 20 students,
connect to the internet, and has all courses students need through
the internet. We need internal and external lecturers to provide the
scientific courses for students.
Guidance
Developing labs with the latest requirements to help students
understand and encourage them to learn and innovate.
Description
-Smart attendance system.
College provides a fingerprint device to take attendants and
leaves in the faculty.
Guidance
Smart attendance system is more accurate and fast more the the
traditional one.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
5
TOGAF™ is a trademark of The Open Group.
Description
-Stakeholder Scope (Students, stuff, companies, employees).
college should provide representative to companies and making
invitation for companied to give trainings for students or sending
emails.
Guidance
It’s very important that the deliverables and objective must met
stakeholders’ concerns.
Description
-Infrastructure.
Faculty should provide labs with high capabilities such as RAMs,
Processors, and HW to provide for students the capability to make
a setup for large SW such as Big Data.
Faculty should provide an internet with high speed to motivate
students to do a good search and learn the meaning of self-study
and to let student connect to servers and use a cloud service as a
new technology that should be understand for students.
Guidance
Reference-ID
1
2
Infrastructure has a great importance in college as the whole EA
project rely on the infrastructure strength.
Title

Management
system inside the
college.

System automation
for registration for
Student, Staff, and
courses.

Companies
and
centre training

Labs, section, and
classroom

Smart
system
3
4
5
Scope
attendance
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
6
TOGAF™ is a trademark of The Open Group.
6
7

Stakeholder Scope

Infrastructure
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
7
TOGAF™ is a trademark of The Open Group.
3
Goals, Objectives, and Constraints
1. Implement enterprise architecture and ADM principles to develop the
college into smart one.
2. Enable a smart management system for staff and students and employees.
3. Making a smart System automation for student, staff, and course
registration.
4. Provide training scholarships for students to develop their skills.
5. The development of the labs and classrooms with the latest capabilities.
6. Making a smart attendance system with face recognition or fingerprint using
artificial intelligence applications.
7. The goals and objective must meet the stakeholders’ concerns.
8. The infrastructure of a college plays a vital role in the development of the
college. It is important that the colleges have very good infrastructure with
advanced laboratories.
3.1
Business and Technology Goals
 One of the basic goals of enterprise architecture is to develop business
needs.
 Provide students with international education opportunities and crosscultural experiences beyond the classroom.
 Foster partnerships between the college and other colleges and universities
(within the region, nationally and internationally) to increase business
activity.
 Provide a greater number of professional development opportunities for
faculty in the areas of advising, pedagogy, grant-writing, and technology,
and incentivize their participation.
 Create more opportunities for paid student internships.
 Establish a marketing and development fund for sponsoring scientific project
inside college.
 Make greater use of local and social media (TV and radio stations,
newspapers) to share students scientific projects.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
8
TOGAF™ is a trademark of The Open Group.
 Establishing a partnership contract with Internet companies to provide high
speed for college and laboratories.
 E-learning lab.
 Form a common team from students and professors (business team ) to
manage the whole cycle .
3.2
Objectives Derived from the Goals
 Provide students with international education opportunities and crosscultural experiences beyond the classroom. Increase student communication
skills and scientific experience.
 Foster partnerships between the college and other colleges and universities
(within the region, nationally and internationally) to increase business
activity. To support business in college and student scientific experience.

Provide a greater number of professional development opportunities for
faculty in the areas of advising, pedagogy, grant-writing, and technology,
and incentivize their participation. To achieve academic excellence. Worldclass universities rely on their faculty professional development centres for
an array of professional development programmes to support teaching,
research, and student learning.
 Create more opportunities for paid student internships. Provide a local
internships for students with certificates.
 Establish a marketing and development fund for sponsoring scientific project
inside college. Encourage students to implement scientific project ideas.
 Make greater use of local and social media (TV and radio stations,
newspapers) to share students scientific projects. Promote scientific projects
for students.
 Establishing a partnership contract with Internet companies to provide high
speed for college and laboratories. Developing the college infrastructure that
helps staff and students to achieve their interests.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
9
TOGAF™ is a trademark of The Open Group.
Concern
Does the architect understand what I (sponsor) want to be able to do with the architecture?
Description
There are two classes of architecture objective. There are objectives which are aligned to the
project delivery, for which the project manager and the sponsor are key owners. There are
also objectives which are aligned to broader strategic and enterprise goals, for which the
IMS strategy & architecture is a key owner.
A View of both classes enables the understanding of strategic versus project deliverables.
In the first class are:

Ensure the optimum approach to achieving the project goals

Reduce project costs through the adoption of appropriate products and services

Alignment with the design authority
In the second class are:
Alignment with the Business Mission and Strategy

Alignment with Business Partners and (other) business areas

Ensure consistency across all delivery projects in the organization

Reduce costs through the adoption of standards
This View is a simple selection of the architecture objectives or strategies as appropriate.
See the architecture objectives artifact template.
Guidance
Reference-ID

Title
Class
Architecture Objective/Strategy description
<<May reference the business goals and drivers documentation.>>
3.3
Stakeholders and their Concerns
 Staff .
 Employees.
 Current and graduated students.
 Partners.
 Companies.
3.4
Constraints
Concern
1- Scope
2-cost
3-time
4-quality
5-stakeholders satisfaction
6-resources
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
10
TOGAF™ is a trademark of The Open Group.
Description
1.1 the scope of a project before it begins is vital to establishing
the expectations for your outcome.
1.2 the scope of a project will refer to the specific deliverables
that have been agreed upon by key stakeholders and must be
delivered to close the project.
2.1 Cost is simply the amount of money that can be invested in a
particular activity to achieve the desired outcome.
2.2 Before putting the plan into action, it's critical to estimate the
project's costs as precisely as feasible.
3.1 The project timeline will be important to the outcome, as
failing to stay on schedule could result in the failure of the
project.
3.2 Having a well-defined project plan is one of the most crucial
strategies for effective time management.
4.1 The quality of the project will be evaluated by how closely
the outcome matches the expectations set in the planning stages.
5.1 You should be asking yourself whether the project achieves
the overarching business or customer goal.
6.1 We should take the availability of resources, both material
and human, into consideration.
Guidance
Guidance is the process which helps the students to know their
skills, interests, personality that will help students in further
career selection.
The objective of Guidance is to assist students and teachers in
making available desirable qualifications and skills rather than
achieving the goals of educational programs.
Reference-ID
Title
Architecture Constraint
Priority
Consequences
1
2
3
4
5
6
Scope
cost
time
quality
stakeholders’
satisfaction
resources
Scope
cost
resources
5
2
3
4
1
6
If we cannot
control the
necessary
constraints, we
will not be able
to reach the
desired goal.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
11
TOGAF™ is a trademark of The Open Group.
3.5
Capabilities
 Stakeholders need some capabilities to achieve their business goals.
 Must have trained employees to use the new system.
 Must have a strong infrastructure and a strong server for registration system.
 Must have public relations employees for contracting with training centers
and companies.
 Must have financial resources to develop labs and classrooms.
 Must have accurate and secure system for attendance.
 Must have website and social media team for publishing the projects.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
12
TOGAF™ is a trademark of The Open Group.
4
Compliance
4.1
Architecture Principles
Name
Primacy of Principles
Reference
1
Statement
Principles apply throughout the enterprise and override all other considerations when
decisions are made.
Rationale
The only way a recognized, consistent, and measurable level of operations can be provided
is if all parts of the enterprise abide by the principles when making decisions.
Implications
• Without this principle, short-term consideration, supposedly convenient exceptions, and
inconsistencies would rapidly undermine the management of information.
• Information management initiatives will not be permitted to begin until they are
examined for compliance with the principles.
• A conflict with a principle will be resolved by changing the conflicting initiative, which
could delay or prevent the initiative.
Name
Maximize Benefit to the Enterprise
Reference
2
Statement
Information management decisions are made to provide maximum benefit to the
enterprise.
Rationale
This principle embodies “service above self”. Decisions made from an enterprise-wide
perspective have greater long-term value than decisions made from any organizational
perspective. Maximum return on investment requires information management decisions
to adhere to enterprise-wide drivers and priorities. No minority group will detract from the
benefit of the whole. However, this principle will not preclude any minority group from
getting its job done.
Implications
• Achieving maximum enterprise-wide benefit will require changes in the way information
is planned and managed. Technology alone will not bring about this change. • Some
organizations may have to concede their own preferences for the greater benefit of the
entire enterprise. • Application development priorities must be established by the entire
enterprise for the entire enterprise. • Applications components should be shared across
organizational boundaries. • Information management initiatives should be conducted in
accordance with the enterprise plan. Individual organizations should pursue information
management initiatives that conform to the blueprints and priorities established by the
enterprise. The plan will be changed as needs arise. • As needs arise, priorities must be
adjusted. A forum with comprehensive enterprise representation should make these
decisions.
Name
Compliance with Law
Reference
3
Statement
Enterprise information management processes comply with all relevant laws, policies, and
regulations.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
13
TOGAF™ is a trademark of The Open Group.
Rationale
Enterprise policy is to abide by laws, policies, and regulations. This will not preclude
business process improvements that lead to changes in policies and regulations.
Implications
• The enterprise must be mindful to comply with laws, regulations, and external policies
regarding the collection, retention, and management of data.
• Education and access to the rules. Efficiency, need, and common sense are not the only
drivers. Changes in the law and changes in regulations may drive changes in processes or
applications.
Name
Available Anytime from Anywhere
Reference
4
Statement
Access must be available to those entitled to it, in real time, regardless of where they are or
what time it is.
Rationale
Support staff need to be able to support the system remotely at any time of the day or
night. Staff should be able to obtain or update information on-demand. Customers should
be able to access information to which they are entitled from wherever they are at any
time.
Implications
• Usage of the system will be improved and thereby use of other data sources discouraged.
• There is a requirement to synchronize between corporate and personal systems/devices.
Name
Business Continuity
Reference
5
Statement
Enterprise-critical systems (e.g., contractual commitments, conference registration, web,
and email) need to be available to an acceptable level of service.
Rationale
Credibility as a global organization depends upon perceived 24x7 operations.
Implications
• Dependability is a key feature of both the applications and the underlying infrastructure
on which they rely.
• Protection is critical against denial-of-service attacks, viruses, and other malicious
activities that have the potential to disrupt availability.
• Need to define an acceptable level of service. • Access to support 24x7, if needed, is
critical.
Name
De-Customization
Reference
6
Statement
Having established the requirements and found the solution of best fit, The Open Group
will amend the requirements rather than require custom amendments to the solution.
Rationale
The Open Group is not unique in many of its business processes, and industry solutions
have been invented to address them. Customization incurs cost and causes problems of
support as well as potentially opening additional security risks.
Implications
• Cost, security, business continuity.
• The business process driving the requirement will be modified to fit the solution.
Name
Painless User Experience
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
14
TOGAF™ is a trademark of The Open Group.
Reference
7
Statement
The user (customer, staff, and others entitled to use the system) experience needs to
consume no more time or difficulty than they would experience in current commercially
accessible systems.
Rationale
Customers can be lost, users frustrated, or time wasted by collecting unnecessary
information or by complexity in the system. On the other hand, valuable and appropriate
business information could be legitimately collected without being excessive as compared
with other organizations.
Implications
• Need to be aware of appropriate exchange of value.
• Need to validate information collected.
• Need to guide user through the process easily.
Name
Self-Service
Reference
8
Statement
Customers should be able to serve themselves.
Rationale
This will improve customer satisfaction, reduce administrative overhead, and potentially
improve revenue.
Implications
Need to improve ease-of-use and minimize training needs. For example, members should
be able to update their contact details, etc. and buy additional membership products online.
Name
Sharing of Information
Reference
9
Statement
The Open Group will facilitate sharing and use of knowledge throughout the company.
Rationale
There are often new or infrequent tasks to perform where the user does not possess the
immediate knowledge necessary to do the job. Also, resources are limited, so each user has
to do more than one thing.
Implications
Need to consider how to share information.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
15
TOGAF™ is a trademark of The Open Group.
4.2 Policies and Standards
The faculty adheres to an Enterprise Architecture framework and principles that
maximize the digital capabilities of the faculty.
Enterprise Architecture is a business strategy which captures, documents,
classifies, and analyses all aspects of the enterprise to make the Information
relevant for Decision makers, including business managers, business analysts and
technology specialists.
Effective Enterprise Architecture is achieved through the application of a
comprehensive and thorough process for describing a current and future structure
and behavior for the faculty’s processes, Information, applications, technology and
supporting the People Portfolio.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
16
TOGAF™ is a trademark of The Open Group.
5
Risks and Issues
5.1
Assumptions
ID
Assumption Item
Description
1
Developing labs
and classrooms
2
3
5.2
Date
Source
Owner
Financial problem
cost
Manager
System automation
System failure
infrastructure
Business
team
infrastructure
Financial problem
cost
Manager
Risks
Concern
Strategic Risk
Description
Risk that has an impact of an organisation’s ability to achieve its goals or objectives.
Guidance
Capabilities of organization must match our goals and objectives
Concern
Compliance risk
Description
Risk created by failing to follow federal, state, and local laws, regulations or university
policy that safeguards the institutions or its members from legal exposures
Guidance
We must follow local laws and federal state.
Concern
Financial risk
Description
Risk which emanates from wrong policies of financial management being pursued by
organisations resulting in financial losses to the organisation.
Guidance
We must make a good financial plan for our project.
Concern
Operational risk.
Description
Risk that affects day to day operations of the organisation including the information
security risks
Guidance
We must improve our security system to avoid any attacks.
Concern
Human resources risk.
Description
Risks arising from wrong recruitment training and retention of able human resources to
run the institution efficiently.
Guidance
We must choose human resources carefully and assign tasks according to their capabilities.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
17
TOGAF™ is a trademark of The Open Group.
5.3
Issues
Input
Date
Due
Date
Closed
Date
Meeting Notes/
Comments
ID
Issue
Status
1
Reducing
the quality
of education
at the
college.
Internal
issue
staff
-
2
The
inability of
the students
to deal with
the
developed
laboratories
Internal
issue
student
-
3
The
international
universities
cooperating
with us did
not provide
the service
required of
them in a
timely
manner or
in the
manner
agreed upon
External
issue
partners
-
4
The
companies
agreed upon
to train
students
may breach
the contract
policies,
which will
cause a
glitch in the
training
system
External
issue
companies
-
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Owner
Work
Group
Owner
18
TOGAF™ is a trademark of The Open Group.
5.4
Dependencies
Reference-ID
Title
Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Impact
Measures
Comment
19
TOGAF™ is a trademark of The Open Group.
6
Baseline Architecture
6.1
Business Architecture Models
we will define the current business architecture in our project (Developing college)
The management system still works in a primitive way, such as using paperwork
management system is very important in any college and the success of the college
depend on it. the information of the new students and papers needed to join the
college are put on files in employees’ offices and it can be lost. The students' data
is recorded on paper and this work is not secure because the loss of any of these
papers causes a problem. the registration of courses also on papers and it can be
lost, and this will cause management problem. The Finance data on students’
tuition fees is recorded on paper and this matter is not safe because if the financial
affairs officer forgets to record these data or the tuition fees receipt is lost, the
student is considered unpaid for the tuition fees, and this causes many problems.
The learning process nowadays depend on strong infrastructure as the developing
of the college depend on high internet speed and E-learning labs needs strong
infrastructure and very high internet speed and problem like corona virus leads to
learning online and online exams, so all of this depend on strong infrastructure to
avoid any obstacles to the educational process and to support the scientific projects
of students and to encourage students to learning and innovation. To develop
business architecture, we must give interest for the student’s scientific projects and
support this project with financial resources and Establish a marketing and
development fund for sponsoring scientific project inside college this will increase
business revenue. Developing of labs and classrooms with high capabilities
provide high learning process and help student to learning and innovation for his
study and scientific project we must give interest for all this.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
20
TOGAF™ is a trademark of The Open Group.
6.1.1
Conceptual Baseline Business Architecture
6.1.1.1
Baseline Business Functions
 Management system rely on papers and any process save on file in
employees offices.
 Attendance system not accurate at all as we need to use technology to avoid
impersonation.
 Registration for courses rely on papers and it causes problems and difficult
to review all this papers.
 Financial management rely on employees and papers, and it causes many
problems.
 Labs and classrooms have low capabilities to capable of the new
technologies.
 Infrastructure is very poor to capable of the learning process.
Financial Management
Corporate Functions
Group Risk
Human Resources
Financial Crimes
Finance
Op Risk
HR
AML
Tax and Treasury
BASEL 2
Pensions
KYC
Business Support Services
Funds Movement
Credit Risk Services
Electronic Payments
Cheques and Clearing
Portfolio Management and
Strategy Development
Physical Currency
Management
Gateways
Account Limit
Management
Customer Centric
Assessment and
Originations
Collections and
Recoveries
Document and Output Management
Product Bundling
Relationship Pricing
Document Authoring
Document Composition
and Assembly
Relationship Billing
Alert and Notifications
Document Distribution
Bulk Print
Customer Management
Relationship Management
Marketing & Strategy
Case Management
Customer Support
Sales Management
Financial Planning
Single Customer View
Contact Management
Relationship Performance
Management
Customer Identity &
Verification
Product Processing
Current Accounts
Deposit Accounts
Lending Unsecured
Lending Secured
Credit Card Issuing
Merchant Acquiring
Rewards
Credit Card Partnerships
Commercial Lending
Trade Finance
Syndicated Lending
Sales Finance
Asset Finance
Derivatives
Cash Management
FX
Protection
Investments
Customer Liquidity
Management
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
21
TOGAF™ is a trademark of The Open Group.
Business
Function
(Category)
ID
Business
Function
Category
Business Function
1
System
management
Management
system
2
System
management
Attendance system
System
management
3
Financial
management
4
Building
development
5
6
6.1.1.2
Business Function Description
Enable students to pay tuition fees and other
student affairs services online.
College provides a fingerprint device to take
attendants and leaves in the faculty
System automation
for registration.
It is very important for the faculty members to
concern that students must register for courses
they would like to study before starting study
also, register their data online
tuition fees and
other financial
services.
rely on employees and papers, and it causes many
problems.
Labs and
classrooms
Infrastructure
development Infrastructure
have low capabilities to capable of the new
technologies.
is very poor to capable of the learning process.
Baseline Business Services
• The management system is based on paper, and any process is saved on file in the
employees' offices.
• The attendance system is not very accurate because we need to use technology to
avoid impersonation.
• Course registration is based on papers, which causes issues and makes it difficult
to review all these papers.
• Financial management is heavily reliant on employees and paperwork, which
causes a slew of issues.
• Labs and classrooms have limited capacity to accommodate new technologies.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
22
TOGAF™ is a trademark of The Open Group.
• The infrastructure is inadequate to support the learning process.
Processing
Account
Opening
Scan & Index
AML/KYC Sanctions
Checks
Credit Approval
OCR/ICR Data Entry &
Repair
Validation & Completenes
Check
Account Opening
Collections
and
Recoveries
Authorisations
Customer
Servicing &
Maintenance
Product Operations
Treasury
Operations
Insurance
Operations
Investment
Operations
International
Trade
Sales and Service Management
Contact
Centre
Operations
Business
Service
(Category)
ID
Branch
Operations
Self Service
Devices
eChannels
Business
Service
Category
Business Service
Business Service Description
1
System
management
Management
system
Allow students to pay for their tuition and
other student services online.
2
System
management
Attendance system
A fingerprint device is provided by the college
to track students and departs in the faculty.
3
System
management
4
5
6
System automation
for registration.
Faculty members must be aware that students
must register for courses they want to take
before beginning their studies, as well as
register their data online.
Financial
management
tuition fees and
other financial
services.
rely on staff and paperwork, which leads to a slew
of issues.
Building
development
Labs and
classrooms
have insufficient ability to cope with emerging
technologies
Infrastructure
development Infrastructure
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
is insufficiently capable of learning.
23
TOGAF™ is a trademark of The Open Group.
Business Service
Characteristic
Business Service
Business Service Characteristic Value
Management
system
Paid tuition fees
online
Registration for
courses online
Minimize human error.
Infrastructure
High internet speed
e-Learning labs.
BS Contract
ID
Business
Service
Contract
Business
Service 1
Business
Service 2
Business Service Contract Description
1
companies
internship
High speed
internet
Internship for student and high internet
speed
6.1.1.3
Business Service Security Classification View
We must provide high security for attendance system to avoid impersonation.
ReferenceID*
1
6.1.1.4
Title*
Subject
Management
system
Attendance
system
Confidentiality
Classification
Integrity
Classification
Availability
Classification
The prevention of
unauthorized
disclosure of
information
the prevention
of unauthorized
writing or
modification of
information.
the prevention of
unauthorized
withholding of
information.
Organization Structure and Units
Organization
Unit ID
Organization
Unit
Organization
Unit Parent
Organization Unit Description
1
internship
ITI
Provide online training.
2
infrastructure
we
Provide high speed internet.
Expedition
International
university
Provide Expeditions for students.
The Arab
Contractors
Developing buildings of the college.
3
buildings
4
6.1.1.5
User Satisfaction
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
24
TOGAF™ is a trademark of The Open Group.
Business
Service
User Satisfaction
(Scale 1-10)
Notes, Specific Issues
Management
system
2
Poor management system
Attendance
system
3
Not accurate and secure
6.1.1.6
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
Logical Baseline Business Architecture
6.1.2.1
Actors
We have three categories of actors.
6.1.2.2
Human Actors
 Staff
 Student
 Companies
 partners
6.1.2.3
Computer Actors

Management system

Attendance system
Actor
Business Role
Actor 1
Actor 2
X
Role 1
X
Role 2
X
Role 4
6.1.2.4
Actor 3
Other Requirements
Students have high skills to deal with the new management system.
Staff and employees trained well to deal with the new management system.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
25
TOGAF™ is a trademark of The Open Group.
6.1.2.5
Baseline Business Architecture (Processes)
6.1.3
Physical Target Business Architecture
6.1.3.1
Process Allocation
We should allocate resources for our project to develop the college.
Location
Physical Process
Location 1
Location 2
Location 3
X
Process 1
X
Process 2
X
Process 3
X
Process 4
6.1.3.2
Physical Business Component RACI View
Business Unit
Actors
Activity
Actor 3
ThirdParty
Actors
Implementation
Actors
Actor 4
Actor 5
Actor 1
Actor 2
Activity 1
AR
C
Activity 2
AR
C
C
C
Activity 3
A
C
R
I
Actor 7
I
AR
Activity 4
Activity 5
R
C
A
Activity 6
C
C
I
6.1.3.3
Actor 6
I
C
C
AR
I
Role/Actor Allocation
We should allocate actors for our project to develop the college.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
26
TOGAF™ is a trademark of The Open Group.
Staff Type
Physical Process
Staff Type 1
Staff Type 2
Staff Type 3
X
Actor/Role 1
X
Actor/Role 2
X
Actor/Role 3
X
Actor/Role 4
6.1.3.4
Physical Organization Model
A technique through construction of models which enables a subject to be
represented in a form that enables reasoning, insight, and clarity concerning the
essence of the subject matter.
6.1.4
Cross-References within the Business Architecture
<Business Architecture Cross-References Example: This section may populate the
spreadsheet below which enables the definitions and relationships between
business function categories, business functions, business service categories, and
business services to be captured and documented.
Business Function & Service Descriptions
Business
Function
Category
Business
Function
<Business
Function
Category
Name>
<Business Function Description>
<Business
Function
Name>
Business
Service
Group
<Business Function Description>
<Business
Service
Category
Name>
6.2
Business Service
<Business Service Category Description>
<Business
Service
Name>
<Business Service Description>
<Business
Service
Name>
<Business Service Description>
<Business
Service
Name>
<Business Service Description>
Data Architecture Models
<<The purpose of this section is to define the baseline data architecture for the domain/sub-domain.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
27
TOGAF™ is a trademark of The Open Group.
Mandatory/optional: This section is optional. The data domain team will only produce a detailed set of
target data architecture documentation at the planning, conceptual, and logical levels. Thus, the relevant
domain only needs to produce relevant artifacts from those highlighted in this section as per their needs.
In terms of quality criteria, this section may make clear:

Relevant views (diagrams) at the planning level illustrating the information subject areas in scope
for the baseline data architecture, as well as the relationships between them

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

Definitions for the information subject areas (in table format) in scope for the baseline data
architecture

Descriptions of the relationships and cardinality (if relevant) between the information subject areas
(in table format) in scope for the baseline data architecture

Relevant views (diagrams) at the conceptual level illustrating the business objects in scope for the
baseline data architecture, as well as the relationships between them; these medium-level business
objects will have been derived from the high-level information subject areas

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

Definitions for the business objects (in table format) in scope for the baseline data architecture

Descriptions of the relationships and cardinality (if relevant) between the business objects (in table
format) in scope for the baseline data architecture

Relevant views (diagrams) at the logical level illustrating the logical data entities in scope for the
baseline data architecture, as well as the relationships between them. These lower-level logical data
entities will have been derived from the medium-level business objects

Description of the logical-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

Definitions for the logical data entities (in table format) in scope for the baseline data architecture

Characteristics of the logical data entities (in table format) in scope for the baseline data architecture

Descriptions of the relationships and cardinality (if relevant) between the logical data entities (in
table format) in scope for the baseline data architecture

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the baseline data architecture>>
6.2.1
Conceptual Baseline Data Architecture
<<Data Architecture Planning-Level View Example: This section may provide one or more planninglevel views for the baseline data architecture. The diagram below provides a view of the baseline data
architecture at the planning level which consists of information subject areas and the relationships
between them. The view also shows the decomposition of information subject areas into business objects.
This particular example illustrates some example information subject areas. 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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
28
TOGAF™ is a trademark of The Open Group.
Credit Card
A/c A/c
Savings
Customer
YYYYs
Employee
Issuer
Mortgage A/c
Letter of
Credit
Investment
A/c A/c
Baseline
Rating Issuer
Guarantor
Collateral
Guarantee
Regulator
Merchant
Netting
Insurance
Line of Credit
Trading A/c
Involved
Party (IP)
Arrangemen
t (AR)
Charges
Fees and
GL&other
Costs
Balances
Basel II Metrics
Writeoff/Provision
IP Type/Role
Payment Amt
Other Amts
and
Metrics
Accounting
Unit (AU)
Electronic
Address
Telephone
Postal Address
Residential
Address
Internal
Address
Channel Type
Fee Type
Currency Code
Risk Type
IP/IP
Relationship
AR/AR
Type
Relationship
IP/LO
Type
Relationship
Type
IP/AR
Relationship
EV/AU
Type
Relationship
Trading
TypeAcct
Finance
Investment
Custodial
Trading
Classificatio
ns (CL)
Legal Address
Location
(LO)
Insurance
Deposit
Transfer
Financial
Market
Instrument
- Relationships (association
entities)
Loss Event
Rating Event
Campaign
Communicatio
n
Financial
Market
Instrument
Pricing
Suspicious
Activity
Event
(EV)
Geographic
Risk Area
Segment
Customer
Segment
AU
Balance
TypeType
Interest
Collections
Recoveries
Cash
Flows
Amt
Transaction
Credit Event
Real Estate
Chattel
Documentation
Intellectual
Property
Financial
Market
Holding
Instrument.
Reported Info.
Purchased
Asset
Resource
Item (RI)
Interest Rate
Fixed/Variable
Rate
Fee Assessed
Waived
Time Condition
Coupon Rate
Buy/Sell Rate
Limit
Control/
Interpretation
Condition
(CD)
Product
<<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.>>
Information
Subject
Area Id
Information Subject
Area
Information Subject Area Description
<<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
Relationship
ID
Information
Subject Area 1
Information
Subject Area 2
Information
Subject Area
Cardinality
Information Subject Area Relationship
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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
29
TOGAF™ is a trademark of The Open Group.
SEGMENT
MARKETING CAMPAIGN
GEOGRAPHICAL AREA
PRODUCT GROUPING
CAMPAIGN TARGET
or
MEDIA CIRCULATION
INCENTIVE OFFER
MARKETING BRIEF
MARKETING AUDIENCE CRITERION
MARKETING MEDIUM
LEG MARKETING
MEDIUM
MARKETING BRIEF ROLE
LEG MARKETING CAMPAIGN
MARKETING MESSAGE RELEASE
MARKETING MESSAGE
DELIVERY CHANNEL
LEAD SOURCE
or
or
MARKETING MATERIAL
PARTY
or
INDIRECT MARKETING MESSAGE RELEASE
LEG LEAD
SOURCE
MARKETING MESSAGE EXPOSURE
DIRECT MARKETING MESSAGE RELEASE
LEG MARKETING MESSAGE
TARGETTED PROSPECT
PROSPECT
LEG PROSPECT
or
COMMUNICATION ITEM
TASK
LEAD
<<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.>>
<<Data Architecture Conceptual-Level Artifact Definitions: This section may provide (in table format)
definitions for the business objects in scope for the baseline 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
<<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
Relationship
ID
6.2.1.1
Business
Object 1
Business
Object 2
Business
Object
Cardinality
Business Object Relationship
Description
User Satisfaction
<<Data Architecture Services User Satisfaction: This section provides a view of current user satisfaction
rates for the subject areas. It contains detailed information about complaints and positive features of the
current subject areas.>>
Information
Subject Area
User Satisfaction
(Scale 1-10)
Notes, Specific Issues
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
30
TOGAF™ is a trademark of The Open Group.
Information
Subject Area
6.2.1.2
User Satisfaction
(Scale 1-10)
Notes, Specific Issues
Data Service Security Classification View
<<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.>>
ReferenceID
Component
6.2.2
Title*
Component
Reference
ID*
Title*
Subject
Confidentiality
Classification
Integrity
Classification
Availability
Classification
Logical Baseline Data Architecture
<<Data Architecture Logical-Level View Example: This section may provide one or more logical-level
views for the baseline data architecture. The diagram below provides an example view of the baseline
data architecture at the logical level which consists of logical data entities and the relationships between
them. This particular example illustrates the logical data entities derived from the customer business
object. 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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
31
TOGAF™ is a trademark of The Open Group.
LOCATION
DO NOT USE the INVOLVED PARTY / LOCATION RLTNP for the
follow ing:IP Is Incorporated In LO
IP Is Registered In LO
IP Is Citizen Of LO
IP Has Birthplace Of LO
IP Resides At LO
as these have beent denormalised elsew here in the model
ADDRESS
ELECTRONIC ADDRESS
E-MAIL ADDRESS
GEOGRAPHIC AREA
INVOLVED PARTY
The contact information for a customer
TELEPHONIC ADDRESS
INVOLVED PARTY / E-MAIL ADDRESS RLTNP
INVOLVED PARTY / TELEPHONIC ADDRESS RLTNP
COUNTRY
ALLOCATION CENTER
INVOLVED PARTY / LOCATION RLTNP
POSTAL ADDRESS
INVOLVED PARTY / POSTAL ADDRESS RLTNP
ORGANIZATION
An ORGANISATION is a company, that may or may not be
registered at Companies House. This w ill include sole traders that
are "trading as". Attribute examples:- Trading Name, Registered
Name (if applicable), Industrial Classification
The relationship betw een tw o or more involved parties.
Relationship examples:IP is Customer Of IP
IP Acts On Behalf Of IP
Individual Ow ns Organization
Individual Is Spouse Of Individual
Individual Is Dependent Of Individual
Organization Is Subsidiary Of Organization
Individual Is Trustee For IP
IP Is Normally Responsible For IP
IP Is Currently Responsible For IP
IP Is Matched To IP (relating the same IP across different
clusters or countries)
INVOLVED PARTY / INVOLVED PARTY RLTNP
ORGANIZATION UNIT
EMPLOYEE
An ORGANISATION UNIT, such as, a division or branch.
Attribute examples:- Manager, Line Of Business
INDIVIDUAL
An INDIVIDUAL is a person. Attribute
examples: Name, Age, Gender
EMPLOYMENT POSITION
INVOLVED PARTY HIERARCHY
Filter by active customers w hen assigning an
Involved Party into a customer-level
segmentation group
GROUP
INVOLVED PARTY / GROUP RLTNP
INVOLVED PARTY GROUP
A market segment that a customer can belong
to, for example, Wealth, GRCB. Attribute
examples: Start Date, End Date
A CUSTOMER is a role played by an Involved
Party. A customer must ow n or have ow ned
a product or service offered by the group.
CUSTOMER MARKET SEGMENT
CUSTOMER
Related Data Model Patterns include:Name Pattern
Address Pattern
Individual Pattern
Employee Pattern
Relationship Manager Pattern
CUSTOMER SUMMARY
CUSTOMER / PRODUCT SUMMARY
COMPLAINT
<<Data Architecture Logical-Level View Description: This section may provide a description of the
logical-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 Logical-Level Artifact Definitions: This section may provide (in table format)
definitions for the logical data entities in scope for the baseline data architecture.>>
Logical
Data
Entity ID
Logical Data Entity
Logical Data Entity Description
<<Data Architecture Logical-Level Artifact Characteristics: This section may provide (in table format)
characteristics for the logical data entities in scope for the baseline 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 may provide (in table
format) definitions for the attributes of the logical data entities in scope for the baseline 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
Entity
Logical Data Entity
Attribute
Logical Data Entity Attribute Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
32
TOGAF™ is a trademark of The Open Group.
<<Data Architecture Logical-Level Artifact Relationships: This section may provide (in table format)
definitions and cardinality for the relationships between the logical data entities in scope for the baseline
data architecture.>>
LDE
Relationship
ID
6.2.3
Logical Data
Entity 1
Logical Data
Entity 2
Logical Data
Entity
Cardinality
Logical Data Entity Relationship
Description
Physical Baseline Data Architecture
<<This section describes the interaction between data models that cross ownership boundaries.>>
<<Data Architecture Physical-Level View Example: This section may provide one or more logical-level
views for the baseline data architecture. The diagram below provides an example view of the baseline
data architecture at the physical level which consists of physical data entities and the relationships
between them. This particular example illustrates the physical instance of logical data entities derived
from the customer business object. 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.
Determine the interaction between the data entities; select and visualize the interactions that cross logical
ownership boundaries. Determine the impact of information ownership on these interactions.>>
:Channel
Bank
employee
:Party
:Agreement
Accept Customer
Customer
FindParty
ConcludeAgreement
CreatePartyAgreementRole
<<Data Architecture Physical-Level View Description: This section may provide a description of the
physical-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 Physical-Level Artifact Definitions: This section may provide (in table format)
definitions for the physical data entities in scope for the baseline data architecture.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
33
TOGAF™ is a trademark of The Open Group.
<<Example: Is this interaction caused by the fact that the other owns the object that has caused the
interaction? Is the ownership defined correctly? If we changed ownership of one of the elements, would
that lead to a better result?
Often models like that shown below are used for this View.>>
6.2.4
Baseline Data Architecture Cross-References
<<Data Architecture Cross-References: This section provides, if necessary or when available, some crossreferences for the data architecture.>>
6.3
Application Architecture Models
<<The purpose of this section is to define the baseline application architecture for the domain/subdomain.
Mandatory/optional: If this document is to be produced, this section is mandatory. However, the domain
only needs to produce the relevant artifacts from those highlighted in this section as per their needs.
In terms of quality criteria, this section may make clear:

Relevant views (diagrams) at the conceptual level illustrating the application services and their
contracts (interactions) in scope for the baseline application architecture

Description of the conceptual-level view(s) in order to understand the architectural decisions that
have been taken and resulting key messages for the stakeholders

Definitions for the application services (in table format) in scope for the baseline application
architecture

Characteristics of the application services (in table format) in scope for the baseline application
architecture; the domains will need to decide whether characteristics are needed at the conceptual
services level, logical component level, or both

Descriptions of the contracts (interactions) between the application services (in table format) in
scope for the baseline application architecture

If required, characteristics of the contracts (interactions) between the application services (in table
format) in scope for the baseline application architecture

Relevant views (diagrams) at the logical level illustrating the logical application components and
their contracts (interactions) in scope for the baseline application architecture; these logical
application components group application services together based on common
requirements/characteristics

Description of the logical-level view(s) in order to understand the architectural decisions that have
been taken and resulting key messages for the stakeholders

Definitions for the logical application components (in table format) in scope for the baseline
information architecture

Characteristics of the logical application components (in table format) in scope for the baseline
application architecture; the domains will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both

Descriptions of the contracts (interactions) between the logical application components (in table
format) in scope for the baseline application architecture
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
34
TOGAF™ is a trademark of The Open Group.

Characteristics of the contracts (interactions) between the logical application components (in table
format) in scope for the baseline application architecture

Any relationships between the business function categories, business functions, logical application
components, and application services that are in scope for the baseline architecture

Any relationships between the business services and application services that are in scope for the
baseline architecture

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the baseline application architecture; for example,
one assumption (recommendation) that has already been stated is that the physical application
architecture is out of scope for the enterprise architecture>>
6.3.1
Conceptual Baseline Application Architecture
<<Application Architecture Conceptual-Level Example: This section may provide one or more
conceptual- level views for the baseline application architecture. The diagram below provides an example
view of the baseline application architecture at the conceptual level which consists of application services.
This particular example illustrates some of the application services, grouped by domain, within xxxx.
However, the definition of application 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.>>
Data
OLTP / Application Data
Stores
CDI
ODS
MDM Catalogs
Data Warehouse
Data Marts
Audit and Archive
Unstructured Data
Identity & Access
Management
Customer Authentication
& Authorisation
Information Security
Cryptography and Key
Management
Security Event Log
Management
Security Monitoring
<<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.>>
6.3.1.1
Baseline Application Services
<<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
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
35
TOGAF™ is a trademark of The Open Group.
conceptual services level, logical component level, or both. The domain also needs to determine which
characteristics they wish to capture.>>
Application
Service
6.3.1.2
Application
Service
Characteristic
Application Service Characteristic Value
Application Services Contracts
<<Application Architecture Conceptual Service Contracts: This section provides (in table format) the
contracts between application services and the characteristics of those contracts 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.>>
Contract
Name
6.3.1.3
Contract ID
Definition
IS Service 1
IS Service 2
User Satisfaction
<<Application Architecture Services User Satisfaction: This section provides a view of current user
satisfaction rates for the subject areas. It contains detailed information about complaints and positive
features of the current subject areas.>>
Application
Services
6.3.1.4
User Satisfaction
(Scale 1-10)
Notes, Specific Issues
Application Service Security Classification View
<<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.>>
ReferenceID*
Component
Title*
Component
Reference
ID*
Title*
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Subject
Confidentiality
Classification
Integrity
Classification
Availability
Classification
36
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.>>
LAC ID
Logical Application
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
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
37
TOGAF™ is a trademark of The Open Group.
<<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 baseline application architecture.>>
LAC
Contract
ID
LAC
Contract
Logical
Application
Component 1
Logical
Application
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 baseline application architecture. The domain needs to determine
which characteristics they wish to capture.>>
LAC Contract
6.3.3
LAC Contract
Characteristic
LAC Contract Characteristic Value
Physical Baseline Application Architecture
6.3.4
Implementation
Features
Business Importance (110)
Physical Application Component
(PAC) Description
Business Fitness Score
(1-10)
PAC
ID
Physical
Application
Component
(PAC)
Technical Fitness Score
(1-10)
<<Application Architecture Physical Applications Catalogue: This section provides a catalog of the
currently used applications.>>
Baseline Application Architecture Cross-References
<<Application Architecture Cross-References: This section provides, if necessary or when available,
some cross-references for the application architecture. Like application service and infrastructure service
cross-references or business service and application service cross-references. See the target template for
descriptions of those.>>
6.4
Technology Architecture Models
<<The purpose of this section is to provide a high-level view of the baseline technology architecture for
the domain.
Mandatory/optional: This section is optional. If produced, the domain only needs to produce the relevant
artifacts from those highlighted in this section as per their needs.
In terms of quality criteria, this section may make clear:
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
38
TOGAF™ is a trademark of The Open Group.

Relevant views (diagrams) at the conceptual level illustrating the infrastructure services and their
contracts (interactions) in scope for the baseline technology architecture

Description of the conceptual-level view(s) in order to understand the architectural decisions that
have been taken and resulting key messages for the stakeholders

Definitions for the infrastructure services (in table format) in scope for the baseline technology
architecture

Characteristics of the infrastructure services (in table format) in scope for the baseline technology
architecture; the domains will need to decide whether characteristics are needed at the conceptual
services level, logical component level, or both

Descriptions of the contracts (interactions) between the infrastructure services (in table format) in
scope for the baseline technology architecture

If required, characteristics of the contracts (interactions) between the infrastructure services (in table
format) in scope for the baseline technology architecture

Relevant views (diagrams) at the logical level illustrating the logical infrastructure components and
their contracts (interactions) in scope for the baseline technology architecture; these logical
infrastructure components group infrastructure services together based on common
requirements/characteristics

Description of the logical-level view(s) in order to understand the architectural decisions that have
been taken and resulting key messages for the stakeholders

Definitions for the logical infrastructure components (in table format) in scope for the baseline
technology architecture

Characteristics of the logical infrastructure components (in table format) in scope for the baseline
technology architecture; the domains will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both

Descriptions of the contracts (interactions) between the logical infrastructure components (in table
format) in scope for the baseline technology architecture

Characteristics of the contracts (interactions) between the logical infrastructure components (in table
format) in scope for the baseline technology architecture

Any relationships between the business function categories, business functions, logical infrastructure
components, and infrastructure services that are in scope for the baseline architecture

Any relationships between the business services and infrastructure services that are in scope for the
baseline architecture

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the baseline technology architecture; for example,
one assumption (recommendation) that has already been stated is that the physical technology
architecture is out of scope for the enterprise architecture>>
6.4.1
Conceptual Baseline Technology Architecture
<<Technology Architecture Conceptual-Level Example: This section may provide one or more
conceptual-level views for the baseline technology architecture. The diagram below provides a view of
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
39
TOGAF™ is a trademark of The Open Group.
the baseline technology architecture at the conceptual level which consists of infrastructure services. This
particular example illustrates some of the infrastructure services within xxxxx. However, the definition of
infrastructure 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.>>
<<Technology Architecture Conceptual-Level View Description: This section may provide a description
of the conceptual-level view(s) for the baseline technology architecture in order to understand the
architectural decisions that have been taken and resulting key messages for the stakeholders.>>
6.4.1.1
Technology Services
<<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
Service ID
Infrastructure
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
Service
Infrastructure
Service
Characteristic
Infrastructure Service Characteristic Value
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
40
TOGAF™ is a trademark of The Open Group.
6.4.1.2
Technology Services Contracts
<<Technology Architecture Conceptual Service Contracts: This section provides (in table format) the
contracts between infrastructure services and the characteristics of those contracts 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.>>
Contract
Name
6.4.1.3
Contract ID
Definition
IS Service 1
IS Service 2
User Satisfaction
<<Technology Architecture Services User Satisfaction: This section provides a view of current user
satisfaction rates for the subject areas. It contains detailed information about complaints and positive
features of the current subject areas.>>
Technology
Services
6.4.2
User Satisfaction
(Scale 1-10)
Notes, Specific Issues
Logical Baseline Technology Architecture
<<Technology Architecture Logical-Level Example: This section may provide one or more logical-level
views for the baseline technology architecture. The diagram below provides a view of the baseline
technology architecture at the logical level which consists of logical infrastructure components with their
associated infrastructure services. This particular example illustrates some of the logical infrastructure
components and associated infrastructure services within xxxx. However, the definition of logical
infrastructure 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.>>
Desktop
Citrix
Backup
Data Centre Mainframe
Integration Hub
Virtualisation
Messaging
WAN
Scheduling
Archive
Extranet
Directory
<<Technology Architecture Logical-Level View Description: This section may provide a description of
the logical-level view(s) for the baseline technology architecture in order to understand the architectural
decisions that have been taken and resulting key messages for the stakeholders.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
41
TOGAF™ is a trademark of The Open Group.
<<Technology Architecture Logical-Level Artifact Definitions: This section may provide (in table
format) definitions for the logical infrastructure components in scope for the baseline technology
architecture.>>
Logical
Infrastructure
Component (LIC)
LIC ID
Logical Infrastructure Component (LIC) Description
<<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
<<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 baseline technology architecture.>>
LIC Contract
ID
Logical
Infrastructure
Component 1
Logical
Infrastructure
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 baseline technology architecture.>>
Logical
Infrastructur
e Component
(LIC)
6.4.3
LIC Contract
LIC Contract
Characteristic
LIC Contract Characteristic Value
Physical Baseline Technology Architecture
<<Technology Architecture Physical Infrastructure Component Catalog: This section provides a
catalogue of the currently used applications.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
42
TOGAF™ is a trademark of The Open Group.
6.4.4
Business Importance
(1-10)
Implementation
Features
Business Fitness Score
(1-10)
Physical Infrastructure Component
(PIC) Description
Technical Fitness Score
(1-10)
PIC
ID
Physical
Infrastructure
Component
(PIC)
Baseline Technology Architecture Cross-References
<<Technology Architecture Cross-References: This section provides, if necessary or when available,
some cross-references for the technology architecture. See the target template for descriptions of those.>>
6.5
Security Architecture Models
security management
system
security contracting
Environment Management
ExecutionEnvironment
Environment
Execution
inter-component
security
device identity
management
penetration testing
code control
Hardware Device
fault handling
Information management
evidence management
Organisation
device
protection
host IDS
platform protection
incident management
and emergency
procedures
organisational
compliance
Software
Component
user identity
management
fault handling
User
content scanning
platform
protection
software identity
management
security testing
user audit
incident handling
user authentication
user access management
information backup
Information
personal protection
message/channel
protection
code control
Environment
Protection
zone management
network admission control
Network Zone
denial of service prevention
fault handling
network IDS
Infrastructure
Service Name
perimeter
control
Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Application
Type
Baseline Specification:
Policy Reference
43
TOGAF™ is a trademark of The Open Group.
7
Rationale and Justification for Architectural Approach
7.1
Rationale
7.2
Approach
7.3
Architecture Decisions
ID
7.4
Decision Item
Decision Made
Completion
Date
Source
Owner/Major
Contributors
Architecture Governance
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
44
TOGAF™ is a trademark of The Open Group.
8
Mapping to Architecture Repository
<<The purpose of this section is to highlight (not describe in detail) patterns, standards, products,
technologies that are relevant for or from the business architecture.
Mandatory/optional: This section is mandatory. Also, each of the sub-sections (for this section) may
either provide references to the relevant documentation that has been produced separately by the domains,
or provide the necessary information.
In terms of quality criteria, this section should make clear:

Any domain-specific, other domain-specific, or enterprise architecture-level patterns that have been
used to help define the business architecture

Any domain-specific, other domain-specific, or enterprise architecture-level patterns that can be
derived from the business architecture

Any deviance from existing patterns and the reasons why

Any domain-specific, other domain-specific, or enterprise architecture-level standards that have
been used to help define the business architecture

Any domain-specific, other domain-specific, or enterprise architecture-level standards that can be
derived from the business architecture

Any deviance from existing standards and the reasons why

Any assumptions regarding the use of patterns or standards
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
Copyright © 2010 The Open Group. All rights reserved.
45
TOGAF™ is a trademark of The Open Group.

8.2
Any assumptions regarding business architecture artifacts, or their documentation>>
Mapping to Architecture Landscape
<<The purpose of this section is to highlight any business patterns that are relevant for or from the
business architecture.
Mandatory/optional: This section is optional as there may not be any relevant business patterns. 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 business pattern(s) are described in other documentation, in terms of quality criteria, this
section should make clear:

The relevant business architecture pattern documentation

Context around any such relevant business architecture pattern documentation; e.g., validity,
ownership, purpose

Any deviance from existing business patterns and the reasons why

Any assumptions regarding business architecture patterns, 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 patterns that have
been used to help define the business architecture

Any domain-specific, other domain-specific, or xxxx enterprise architecture-level patterns that can
be derived from the business architecture

Any deviance from existing business patterns and the reasons why

Any assumptions regarding business architecture patterns, or their documentation>>
8.3
Mapping to Reference Models
<<The purpose of this section is to highlight any products and technologies that are relevant to the
baseline architecture.
Mandatory/optional: This section is optional as there may not be any relevant products and technologies.
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 product(s) and technology(s) are described in other documentation, in terms of quality
criteria, this section should make clear:

The relevant products and technologies documentation

Context around any such relevant products and technologies documentation; e.g., validity,
ownership, purpose

Any deviance from existing products and technologies and the reasons why

Any assumptions regarding the products and technologies, or their documentation
If the relevant product(s) and technology(s) are not described in other documentation, in terms of quality
criteria, this section should make clear:
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
46
TOGAF™ is a trademark of The Open Group.

Any domain-specific, other domain-specific, or xxxx enterprise architecture-level products and
technologies that have been used to help define the current architecture

Any deviance from existing products and technologies and the reasons why

Any assumptions regarding the products and technologies, or their documentation>>
8.4
Mapping to Standards
<<The purpose of this section is to highlight any business standards that are relevant for or from the
business architecture.
Mandatory/optional: This section is optional as there may not be any relevant business standards.
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 business standards(s) are described in other documentation, in terms of quality criteria, this
section should make clear:

The relevant business architecture standards documentation

Context around any such relevant business architecture standards documentation; e.g., validity,
ownership, purpose

Any deviance from existing business standards and the reasons why

Any assumptions regarding the business architecture standards, or their documentation
If the relevant business standards(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 standards that
have been used to help define the business architecture

Any domain-specific, other domain-specific, or xxxx enterprise architecture-level standards that can
be derived from the business architecture

Any deviance from existing business standards and the reasons why

Any assumptions regarding the business architecture standards, or their documentation>>
8.5
Re-Use Assessment
<<The purpose of this section is to highlight any re-usable aspects of the business architecture.
Mandatory/optional: This section is optional as there may not be any re-usable aspects of the business
architecture.
If there are re-usable aspects, in terms of quality criteria, this section should make clear:

Drivers for re-use in different business areas

Any re-usable artifacts that have been used to help define the business architecture

Any re-usable artifacts that can be derived from the business architecture

Extensions to existing artifacts in order to make them re-usable

Any non-usage of re-usable artifacts and the reasons why

Deployment options for re-use which an indication of priorities
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
47
TOGAF™ is a trademark of The Open Group.

Any assumptions regarding re-usability>>
8.5.1
Use of Existing Components
<<Brief summary of how the solution architecture proposes to re-use existing components (if any).
Include re-use of licences, infrastructure, support services (e.g., DR) as well as software components.>>
8.5.2
Opportunities for Re-Use
<<Summarize those components that have been designed for re-use.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
48
TOGAF™ is a trademark of The Open Group.
9
Target Architecture
9.1
Business Architecture Models
<<The purpose of this section is to define the target business architecture that is in scope for this exercise.
Note: This section may be refined once the business architecture team has been set up.
Note 2: The level of granularity at which the artifacts need to be defined is dependent on the level of
detail that is required from the business architecture, and thus is a decision for the individual domains.
Mandatory/optional: This section is optional as the domain may only wish to produce a current business
architecture. Also, a degree of flexibility exists when documenting each of the sub-sections within this
section. The domain only needs to produce the relevant artifacts from those highlighted in this section as
per their needs. They do not need to produce all the artifacts, views, tables, etc. presented in this section.
In terms of quality criteria, this section may make clear:

Any other relevant business architecture documentation

Context around any such relevant business architecture documentation; e.g., validity, ownership,
purpose

Any assumptions regarding the business architecture documentation

Relevant views (diagrams) illustrating the business functions in scope for the target business
architecture

Description of the business function view(s)

Definitions for the business functions (in table format) in scope for the target business architecture

Relevant views (diagrams) illustrating the organization structure and units in scope for the target
business architecture

Description of the organization structure and units view(s)

Definitions for the organization structure and units (in table format) in scope for the target business
architecture

Relevant views (diagrams) at the conceptual level illustrating the conceptual business services and
their contracts (interactions) in scope for the target business architecture

Description of the conceptual- level view(s) in order to understand the architectural decisions that
have been taken and resulting key messages for the stakeholders

Definitions for the conceptual business services (in table format) in scope for the target business
architecture

Characteristics of the conceptual business services (in table format) in scope for the target business
architecture

Descriptions of the contracts (interactions) between the conceptual business services (in table
format) in scope for the target business architecture

If required, characteristics of the contracts (interactions) between the business services (in table
format) in scope for the target business architecture

Relevant views (diagrams) at the logical level illustrating the business processes in scope for the
target business architecture
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
49
TOGAF™ is a trademark of The Open Group.

Description of the logica- level view(s) in order to understand the architectural decisions that have
been taken and resulting key messages for the stakeholders

Definitions for the business processes (in table format) in scope for the target business architecture

Any relationships between the business function categories, business functions, business service
categories, and business services that are in scope for the target business architecture

Any assumptions that have been used to define the target business architecture>>
9.1.1
Conceptual Target Business Architecture
9.1.1.1
Target Business Functions
<<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.>>
Financial Management
Corporate Functions
Group Risk
Human Resources
Financial Crimes
Finance
Op Risk
HR
AML
Tax and Treasury
BASEL 2
Pensions
KYC
Business Support Services
Funds Movement
Credit Risk Services
Electronic Payments
Cheques and Clearing
Portfolio Management and
Strategy Development
Physical Currency
Management
Gateways
Account Limit
Management
Customer Centric
Assessment and
Originations
Collections and
Recoveries
Document and Output Management
Product Bundling
Relationship Pricing
Document Authoring
Document Composition
and Assembly
Relationship Billing
Alert and Notifications
Document Distribution
Bulk Print
Customer Management
Relationship Management
Marketing & Strategy
Customer Support
Sales Management
Financial Planning
Single Customer View
Case Management
Contact Management
Relationship Performance
Management
Customer Identity &
Verification
Current Accounts
Deposit Accounts
Lending Unsecured
Lending Secured
Credit Card Issuing
Merchant Acquiring
Rewards
Credit Card Partnerships
Commercial Lending
Trade Finance
Syndicated Lending
Sales Finance
Asset Finance
Derivatives
Cash Management
FX
Investments
Customer Liquidity
Management
Product Processing
Protection
<<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
Copyright © 2010 The Open Group. All rights reserved.
50
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
(Category)
ID
9.1.1.2
Business
Function
Category
Business Function
Business Function Description
Target Business Services
<<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.>>
Processing
Account
Opening
Collections
and
Recoveries
Scan & Index
AML/KYC Sanctions
Checks
Credit Approval
OCR/ICR Data Entry &
Repair
Validation & Completenes
Check
Account Opening
Authorisations
Customer
Servicing &
Maintenance
Product Operations
Treasury
Operations
Insurance
Operations
Investment
Operations
International
Trade
Sales and Service Management
Contact
Centre
Operations
Branch
Operations
Self Service
Devices
eChannels
<<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
Copyright © 2010 The Open Group. All rights reserved.
51
TOGAF™ is a trademark of The Open Group.
Business
Service
(Category)
ID
Business
Service
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
Service
Business Service
Characteristic
Business Service Characteristic Value
<<Business Architecture Conceptual-Level Artifact Contracts: This section may provide (in table format)
descriptions of the contracts (i.e., interactions/relationships) between the business services in scope for the
target business architecture.>>
BS
Contract
ID
Business
Service
Contract
Business
Service 1
Business
Service 2
Business Service Contract Description
<<Business Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide
(in table format) characteristics of the contracts (i.e., interactions/relationships) between the business
services in scope for the target business architecture. The domain needs to determine which
characteristics they wish to capture.>>
Business Service
Contract
9.1.1.3
Business Service
Contract Characteristic
Business Service Contract Characteristic Value
Business Service Security Classification View
<<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.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
52
TOGAF™ is a trademark of The Open Group.
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.>>
ReferenceID*
9.1.1.4
Title*
Subject
Confidentiality
Classification
Integrity
Classification
Availability
Classification
Organization Structure and Units
<<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.>>
Organization
Unit ID
Organization
Unit
Org. Comp
Business Service
Organization
Unit Parent
Org. Comp 1
Organization Unit Description
Org. Comp 2
Org. Comp 3
X
BS 1
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
Logical Target Business 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.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
53
TOGAF™ is a trademark of The Open Group.
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>>
9.1.2.2
Human Actors
<<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>>
9.1.2.3
Computer Actors
<<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
X
Role 1
Role 2
Role 3
Role 4
9.1.2.4
Other Requirements
<<The purpose of this section is to define any other actor-oriented requirements in scope for the target
architecture.
Mandatory/optional: This section is optional.
In terms of quality criteria, this section should make clear:

Any other actor-oriented requirements in scope for the target architecture>>
9.1.2.5
Logical Business Top-Level View
<<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.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
54
TOGAF™ is a trademark of The Open Group.
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.>>
9.1.2.6
Target Business Architecture (Processes)
<<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>>
9.1.2.7
Process Outline
<<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>>
9.1.2.8
Process Steps Mapped to Environment
<<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
Environment 1
Process Comp 1
Process Comp 2
X
X
Environment 2
X
Environment 3
X
Environment 4
9.1.2.9
Process Comp 3
X
Process Steps Mapped to People
<<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.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
55
TOGAF™ is a trademark of The Open Group.
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
User 1
Process Comp 1
Process Comp 2
X
X
User 2
X
User 3
X
User 4
Process Comp 3
X
9.1.2.10 Information Flows
<<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>>
9.1.2.11 Business Architecture Process View
<<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.>>
<<Business Architecture Process View Description: This section may provide a description of the
business process view(s) in scope for the target 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 target business architecture.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
56
TOGAF™ is a trademark of The Open Group.
9.1.3
Physical Target Business Architecture
9.1.3.1
Process Allocation
<<Key locations can be represented geographically, functionally, or structurally. The choice of
representation depends on the key point(s) of the model. A text-based template is provided.>>
Location
Physical process
Location 1
Location 2
Location 3
X
Process 1
Process 2
Process 3
Process 4
9.1.3.2
Physical Business Component RACI 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.>>
Business Unit Actors
Activity
Actor 1
Actor 2
Actor 3
ThirdParty
Actors
Implementation Actors
Actor 4
Actor 5
Actor 6
Activity 1
AR
C
Activity 2
AR
C
C
C
Activity 3
A
C
R
I
I
AR
Activity 4
Activity 5
R
C
A
Activity 6
C
C
I
9.1.3.3
Actor 7
I
C
C
AR
I
Role/Actor Allocation
<<The assignment of roles and responsibilities to staff is a very sensitive issue. For this reason this View
is rarely included within an architecture document, but it is sometimes required as an additional View that
will be circulated under a separate cover. Such Views will always require the involvement of the HR
department and senior managers and such stakeholders are often the sponsors for the extra document that
contains the View.>>
Staff Type
Physical Process
Actor/Role 1
Staff Type 1
Staff Type 2
Staff Type 3
X
Actor/Role 2
Actor/Role 3
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
57
TOGAF™ is a trademark of The Open Group.
Staff Type
Physical Process
Staff Type 1
Staff Type 2
Staff Type 3
Actor/Role 4
9.1.3.4
Physical Organization Model
<<The creation of a physical organizational model is a very sensitive issue. For this reason this View is
rarely included within an architecture document, but it is sometimes required as an additional View that
will be circulated under a separate cover. Such Views will always require the involvement of the HR
department and senior managers and such stakeholders are often the sponsors for the additional
documentation.>>
9.1.4
Cross-References within the Business Architecture
<<Business Architecture Cross-References Example: This section may populate the spreadsheet below
which enables the definitions and relationships between business function categories, business functions,
business service categories, and business services to be captured and documented.>>
Business Function & Service Descriptions
Business
Function
Category
<Business
Function
Category
Name>
Business
Function
Business
Service
Group
Business Service
<Business Function Description>
<Business
Function
Name>
<Business Function Description>
<Business
Service
Category
Name>
Process Comp
Business Service
BS 1
<Business Service Category Description>
<Business
Service
Name>
<Business Service Description>
<Business
Service
Name>
<Business Service Description>
<Business
Service
Name>
<Business Service Description>
Process Comp 1
Process Comp 2
X
X
BS 2
X
BS 3
X
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Process Comp 3
58
TOGAF™ is a trademark of The Open Group.
Process Comp
Business Service
Process Comp 1
Process Comp 2
BS 4
9.2
Process Comp 3
X
Data Architecture Models
<<The purpose of this section is to define the target data architecture for the domain/sub-domain.
Mandatory/optional: This section is mandatory as all the domain teams need to produce a target data
architecture for their respective domains. However, a degree of flexibility exists when documenting the
target data architecture. The data domain team will produce a detailed set of data architecture
documentation at the planning, conceptual, and logical levels, whereas the other domain teams will
produce views and define information artifacts at one or more of the stated three levels depending on their
requirements. The other domain teams may decide to just copy views and definitions and relationships
from the master data architecture documentation.
In terms of quality criteria, this section should make clear:

Relevant views (diagrams) at the planning level illustrating the information subject areas in scope
for the target data architecture, as well as the relationships between them

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

Definitions for the information subject areas (in table format) in scope for the target data
architecture

Descriptions of the relationships and cardinality (if relevant) between the information subject areas
(in table format) in scope for the target data architecture

Relevant views (diagrams) at the conceptual level illustrating the business objects in scope for the
target data architecture, as well as the relationships between them; these medium-level business
objects will have been derived from the high-level information subject areas

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

Definitions for the business objects (in table format) in scope for the target data architecture

Descriptions of the relationships and cardinality (if relevant) between the business objects (in table
format) in scope for the target data architecture

Relevant views (diagrams) at the logical level illustrating the logical data entities in scope for the
target data architecture, as well as the relationships between them; these lower-level logical data
entities will have been derived from the medium-level business objects

Description of the logical-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

Definitions for the logical data entities (in table format) in scope for the target data architecture

Characteristics of the logical data entities (in table format) in scope for the target data architecture

Descriptions of the relationships and cardinality (if relevant) between the logical data entities (in
table format) in scope for the target data architecture
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
59
TOGAF™ is a trademark of The Open Group.

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the target data architecture; for example, one
assumption (recommendation) that has already been stated is that the physical data architecture is
out of scope for the enterprise architecture>>
9.2.1
Conceptual Target Data Architecture
<<Data Architecture Planning Level View Example: This section needs to provide one or more planning-level views for the target data architecture. The diagram below provides a view of the target data
architecture at the planning level which consists of information subject areas and the relationships
between them. The view also shows the decomposition of information subject areas into business objects.
This particular example illustrates some of the information subject areas that exist. 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.>>
Credit Card
A/c A/c
Savings
Customer
YYYYs
Employee
Issuer
Mortgage A/c
Letter of
Credit
Investment
A/c A/c
Baseline
Rating Issuer
Guarantor
Collateral
Guarantee
Regulator
Merchant
Netting
Insurance
Line of Credit
Trading A/c
Arrangemen
t (AR)
Charges
Fees and
GL&other
Costs
Balances
Basel II Metrics
Writeoff/Provision
Collections
Recoveries
Cash
Flows
Amt
Payment Amt
Other Amts
and
Metrics
Accounting
Unit (AU)
Electronic
Address
Telephone
Postal Address
Residential
Address
Internal
Address
Legal Address
Location
(LO)
Involved
Party (IP)
IP Type/Role
Customer
Segment
AU
Balance
TypeType
Interest
Loss Event
Rating Event
Campaign
Communicatio
n
Financial
Market
Instrument
Pricing
Suspicious
Activity
Event
(EV)
Geographic
Risk Area
Segment
Channel Type
Fee Type
Currency Code
Risk Type
IP/IP
Relationship
AR/AR
Type
Relationship
IP/LO
Type
Relationship
Type
IP/AR
Relationship
EV/AU
Type
Relationship
Trading
TypeAcct
Classificatio
ns (CL)
Finance
Investment
Custodial
Trading
Insurance
Deposit
Transfer
Financial
Market
Instrument
- Relationships (association
Transaction
Credit Event
Real Estate
Chattel
Documentation
Intellectual
Property
Financial
Market
Holding
Instrument.
Reported Info.
Purchased
Asset
Resource
Item (RI)
Interest Rate
Fixed/Variable
Rate
Fee Assessed
Waived
Time Condition
Buy/Sell Rate
Limit
Control/
Interpretation
Condition
(CD)
Product
entities)
Coupon Rate
<<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
ID
Information Subject
Area
Information Subject Area Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
60
TOGAF™ is a trademark of The Open Group.
Information
Subject Area
ID
Information Subject
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.>>
ISA
Relationship
ID
Information
Subject Area 1
Information
Subject Area
Cardinality
Information
Subject Area 2
Information Subject Area
Relationship Description
<<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.>>
SEGMENT
MARKETING CAMPAIGN
GEOGRAPHICAL AREA
PRODUCT GROUPING
CAMPAIGN TARGET
or
MEDIA CIRCULATION
INCENTIVE OFFER
MARKETING BRIEF
MARKETING AUDIENCE CRITERION
MARKETING MEDIUM
LEG MARKETING
MEDIUM
MARKETING BRIEF ROLE
LEG MARKETING CAMPAIGN
MARKETING MESSAGE RELEASE
MARKETING MESSAGE
DELIVERY CHANNEL
LEAD SOURCE
or
or
MARKETING MATERIAL
PARTY
or
INDIRECT MARKETING MESSAGE RELEASE
LEG LEAD
SOURCE
MARKETING MESSAGE EXPOSURE
DIRECT MARKETING MESSAGE RELEASE
LEG MARKETING MESSAGE
TARGETTED PROSPECT
PROSPECT
LEG PROSPECT
or
COMMUNICATION ITEM
TASK
LEAD
Figure 1 Example Data Architecture
<<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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
61
TOGAF™ is a trademark of The Open Group.
<<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
<<Data Architecture Conceptual-Level Artifact Relationships: This section needs to provide (in table
format) definitions and cardinality for the relationships between the business objects in scope for the
target data architecture.>>
BO
Relationship
ID
9.2.1.1
Business
Object 1
Business
Object
Cardinality
Business
Object 2
Business Object Relationship
Description
Data Service Security Classification View
<<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.>>
Reference
ID*
Component
9.2.2
Title*
Component
Reference
ID*
Title*
Subject
Confidentiality
Classification
Integrity
Classification
Availability
Classification
Logical Target Data Architecture
<<Data Architecture Logical-Level View Example: This section needs to provide one or more logicallevel views for the target data architecture. The diagram below provides a view of the target data
architecture at the logical level which consists of logical data entities and the relationships between them.
This particular example illustrates the logical data entities derived from the customer business object.
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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
62
TOGAF™ is a trademark of The Open Group.
Clusters based on
Functional affinity –
related to objective.
LIC Structure Model
Information objectsService type Customer
Service type
Customer
RSR
Request
Request
RSR
DC
Proposal
Agreement
Proposal
OS
OS
CPC; DRP,
FP
Service
OS
Agreement
Service
NC, MC
MC
NC, MD
MP, MD
AHR, PD.
CDK, MD
These are LIC relations
MC
Resource
Assignation
Input area
Resource Assignation
Customer
request
management
MD
MD
MD
AHR
DC, MD,
AHR
Agreement
management
AHR
AHR
MD
Engagement
management
Engagement
content
management
Engagement
resource
management
These are potential data stores.
<<Data Architecture Logical-Level View Description: This section needs to provide a description of the
logical-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 Logical-Level Artifact Definitions: This section needs to provide (in table format)
definitions for the logical data entities in scope for the target data architecture.>>
Logical
Data
Entity ID
Logical Data Entity
Logical Data Entity Description
<<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
Entity
Logical Data Entity
Attribute
Logical Data Entity Attribute Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
63
TOGAF™ is a trademark of The Open Group.
<<Data Architecture Logical-Level Artifact Relationships: This section needs to provide (in table format)
definitions and cardinality for the relationships between the logical data entities in scope for the target
data architecture.>>
LDE
Relationship
ID
9.2.3
Logical Data
Entity 1
Logical Data
Entity 2
Logical Data
Entity
Cardinality
Logical Data Entity Relationship
Description
Physical Target Data Architecture
<<This section describes the interaction between data models that cross ownership boundaries.>>
<<Data Architecture Physical-Level View Example: This section may provide one or more logical-level
views for the target data architecture. The diagram below provides an example view of the target data
architecture at the physical level which consists of physical data entities and the relationships between
them. This particular example illustrates the physical instance of a logical data entities derived from the
customer business object. 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.
Determine the interaction between the data entities, select and visualize the interactions that cross logical
ownership boundaries. Determine the impact of information ownership on these interactions.>>
:Channel
Bank
employee
:Party
:Agreement
Accept Customer
Customer
FindParty
ConcludeAgreement
CreatePartyAgreementRole
<<Data Architecture Physical-Level View Description: This section may provide a description of the
physical-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 Physical-Level Artifact Definitions: This section may provide (in table format)
definitions for the physical data entities in scope for the target data architecture.>>
<<Example: Is this interaction caused by the fact that the other owns the object that has caused the
interaction? Is the ownership defined correctly? If we changed ownership of one of the elements, would
that lead to a better result?
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
64
TOGAF™ is a trademark of The Open Group.
Often models like shown below are used for this View>>
9.2.4
Target Data Architecture Cross-Reference
<<Data Architecture Cross-References: This section provides, if necessary, some cross-references for the
data architecture.>>
9.3
Application Architecture Models
<<The purpose of this section is to define the target application architecture for the domain/sub-domain.
Mandatory/optional: This section is mandatory as all the domain teams (excluding the data and
infrastructure domains) need to produce a target application architecture at the conceptual and logical
levels for their respective domains.
In terms of quality criteria, this section should make clear:

Relevant views (diagrams) at the conceptual level illustrating the application services and their
contracts (interactions) in scope for the target application architecture

Description of the conceptual-level view(s) in order to understand the architectural decisions that
have been taken and resulting key messages for the stakeholders

Definitions for the application services (in table format) in scope for the target application
architecture

Characteristics of the application services (in table format) in scope for the target application
architecture; the domains will need to decide whether characteristics are needed at the conceptual
services level, logical component level, or both

Descriptions of the contracts (interactions) between the application services (in table format) in
scope for the target application architecture

If required, characteristics of the contracts (interactions) between the application services (in table
format) in scope for the target application architecture

Relevant views (diagrams) at the logical level illustrating the logical application components and
their contracts (interactions) in scope for the target application architecture; these logical application
components group application services together based on common requirements/characteristics

Description of the logical-level view(s) in order to understand the architectural decisions that have
been taken and resulting key messages for the stakeholders

Definitions for the logical application components (in table format) in scope for the target
information architecture

Characteristics of the logical application components (in table format) in scope for the target
application architecture; the domains will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both

Descriptions of the contracts (interactions) between the logical application components (in table
format) in scope for the target application architecture

Characteristics of the contracts (interactions) between the logical application components (in table
format) in scope for the target application architecture

Any relationships between the business function categories, business functions, logical application
components, and application services that are in scope for the target architecture
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
65
TOGAF™ is a trademark of The Open Group.

Any relationships between the business services and application services that are in scope for the
target architecture

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the target application architecture; for example, one
assumption (recommendation) that has already been stated is that the physical application
architecture is out of scope for the enterprise architecture>>
9.3.1
Conceptual Target Application Architecture
<<Application Architecture Conceptual-Level Example: This section needs to provide one or more
conceptual-level views for the target application architecture. The diagram below provides a view of the
target application architecture at the conceptual level which consists of application services. This
particular example illustrates some of the possible application services, grouped by domain. However, the
definition of application 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.>>
Data
OLTP / Application Data
Stores
CDI
ODS
MDM Catalogs
Data Warehouse
Data Marts
Audit and Archive
Unstructured Data
Identity & Access
Management
Customer Authentication
& Authorisation
Information Security
Cryptography and Key
Management
Security Event Log
Management
Security Monitoring
<<Application Architecture Conceptual-Level View Description: This section needs to provide a
description of the conceptual-level view(s) for the target 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 needs to provide (in table
format) definitions for the application services in scope for the target application 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.>>
Application
Service ID
Application Service
Application Service Description
<<Application Services Capability Mapping: This table provides a mapping between the capabilities and
the business services.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
66
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
Service
Characteristic
Application
Service
Application Service Characteristic Value
<<Application Architecture Conceptual-Level Artifact Contracts: This section may provide (in table
format) descriptions of the contracts (i.e., interactions/relationships) between the services in scope for the
target application architecture.>>
CAS
Contract
ID
CAS
Contract
Logical
Application
Service 1
Logical
Application
Service 2
CAS Contract Description
<<Application Architecture Conceptual-Level Artifact Contract Characteristics: This section may provide
(in table format) characteristics of the contracts (i.e., interactions/relationships) between the application
services in scope for the target application architecture. The domain needs to determine which
characteristics they wish to capture.>>
CAS Contract
9.3.1.1
CAS Contract
Characteristic
CAS Contract Characteristic Value
Application Service Security Classification View
<<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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
67
TOGAF™ is a trademark of The Open Group.
Reference
ID
Component
9.3.2
Title*
Component
Reference
ID*
Title*
Confidentiality
Classification
Subject
Integrity
Classification
Availability
Classification
Logical Target Application Architecture
<<Application Architecture Logical-Level Example: This section needs to provide one or more logicallevel views for the target application architecture. The diagram below provides a view of the target
application architecture at the logical level which consists of logical application components with their
associated application services. This particular example illustrates some of the possible logical application
components and 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.>>
Party information
Management
Life Insurances Collective Pensions
Party LISC 1
Document Handling
GetPartiesOnAgreement/13
Occurrence: NL_INTERM_NN_PENS_PARTICIP
Fiches
Handling
LISC 2
Uitvallijst
Collective
Pensions
LISC 1
IFSA
Standard File Transfer
Verwerkte polisnummers
(veegronde)
Standard File Transfer
Polisinfo
Standard File Transfer
Interface
Manager
LISC 2
IFSA
ComposeAndProduceDocument
Document
Handling
LISC 1
Archive Document
Document
presenter
LISC 3
<<Application Architecture Logical-Level View Description: This section needs to provide a description
of the logical-level view(s) for the target application 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 application 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.>>
<<Application Architecture Logical-Level Artifact Definitions: This section needs to provide (in table
format) definitions for the logical application components in scope for the target application
architecture.>>
LAC ID
Logical Application
Component (LAC)
Logical Application Component (LAC) Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
68
TOGAF™ is a trademark of The Open Group.
<<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.>>
Logical
Application
Component
(LAC)
LAC
Characteristic
LAC Characteristic Value
<<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
Contract
ID
LAC
Contract
Logical
Application
Component 1
Logical
Application
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
9.3.3
LAC Contract
Characteristic
LAC Contract Characteristic Value
Physical Target Application Architecture
<<Application Architecture Physical-Level View Description: This section can provide, if necessary, a
description of the physical-level view(s) for the target application architecture in order to understand the
architectural decisions that have been taken and resulting key messages for the stakeholders. This section
should follow the same structure as the logical target application architecture.>>
9.3.3.1
Vendor Consideration List
<<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
9.3.4
Component
Considerations
Target Application Architecture Cross-Reference
<<Business Function and Business Service Cross-References: This section needs to provide (in table
format) any relationships between the business function categories, business functions, logical application
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
69
TOGAF™ is a trademark of The Open Group.
components, and application services that are in scope for the target architecture. It thus enables the
assessment of the application landscape across business functions.>>
<<Business Service and Application Service Cross-References: This section needs to provide (in table
format) any relationships between the business services and application services that are in scope for the
target architecture. It thus provides traceability between the business and application architectural
domains which allows the impact of change in the business architecture domain to be assessed in the
application architecture domain and vice versa.>>
<<Application Service and Infrastructure Service Cross-References: This section needs to provide (in
table format) any relationships between the application services and infrastructure services that are in
scope for the target architecture. It thus provides traceability between the application and technology
architectural domains which allows the impact of change in the application architecture domain to be
assessed in the technology architecture domain and vice versa.>>
<<Application Component and Infrastructure Component Cross-References: This section needs to
provide (in table format) any relationships between the application components and infrastructure
components that are in scope for the target architecture. It thus provides traceability between the
application and technology architectural domains which allows the impact of change in the application
architecture domain to be assessed in the technology architecture domain and vice versa.>>
9.4
Technology Architecture Models
<<The purpose of this section is to either provide references to the relevant technology architecture
documentation that complements the target architecture and/or this document, or to provide a high-level
view of the technology architecture if it has not been defined in the technology architecture
documentation.
Mandatory/optional: This section is mandatory as this section will either provide references if the relevant
technology architecture is described in other documentation or a description of the technology
architecture if the relevant technology architecture is not described in other documentation.
If the relevant technology architecture is described in other documentation, in terms of quality criteria,
this section should make clear:

The relevant technology architecture documentation

Context around the relevant technology architecture documentation; e.g., validity, ownership,
purpose

Any assumptions regarding the technology architecture documentation
However, if the relevant technology architecture is not described in other documentation, in terms of
quality criteria, this section should make clear:

Relevant views (diagrams) at the conceptual level illustrating the infrastructure services and their
contracts (interactions) in scope for the target technology architecture

Description of the conceptual-level view(s) in order to understand the architectural decisions that
have been taken and resulting key messages for the stakeholders

Definitions for the infrastructure services (in table format) in scope for the target technology
architecture

Characteristics of the infrastructure services (in table format) in scope for the target technology
architecture; the domains will need to decide whether characteristics are needed at the conceptual
services level, logical component level, or both
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
70
TOGAF™ is a trademark of The Open Group.

Descriptions of the contracts (interactions) between the infrastructure services (in table format) in
scope for the target technology architecture

If required, characteristics of the contracts (interactions) between the infrastructure services (in table
format) in scope for the target technology architecture

Relevant views (diagrams) at the logical level illustrating the logical infrastructure components and
their contracts (interactions) in scope for the target technology architecture; these logical
infrastructure components group infrastructure services together based on common
requirements/characteristics

Description of the logical-level view(s) in order to understand the architectural decisions that have
been taken and resulting key messages for the stakeholders

Definitions for the logical infrastructure components (in table format) in scope for the target
technology architecture

Characteristics of the logical infrastructure components (in table format) in scope for the target
technology architecture; the domains will need to decide whether characteristics are needed at the
conceptual services level, logical component level, or both

Descriptions of the contracts (interactions) between the logical infrastructure components (in table
format) in scope for the target technology architecture

Characteristics of the contracts (interactions) between the logical infrastructure components (in table
format) in scope for the target technology architecture

Any relationships between the business function categories, business functions, logical infrastructure
components, and infrastructure services that are in scope for the target architecture

Any relationships between the business services and infrastructure services that are in scope for the
target architecture

Any additional viewpoints and thus views that are required for this section due to new stakeholder
requirements; these views will then be followed by descriptions for the views and definitions for the
view artifacts

Any assumptions that have been used to define the target technology architecture; for example, one
assumption (recommendation) that has already been stated is that the physical technology
architecture is out of scope for the Reference Architecture.>>
9.4.1
Conceptual Target Technology Architecture
<<Technology Architecture Conceptual-Level Example: This section needs to provide one or more
conceptual-level views for the target technology architecture. The diagram below provides a view of the
target technology architecture at the conceptual level which consists of infrastructure services. This
particular example illustrates some of the infrastructure services within xxxx. However, the definition of
infrastructure 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.>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
71
TOGAF™ is a trademark of The Open Group.
Network Services
Storage / Archive
WAN
Telephony
Archive
Replication
Extranet
Dial Up
Backup
Storage Access Network
System Management
Monitoring
Scheduling
Data Centre
Software Distribution
Inventory Management
Virtualisation
Asset Management
Configuration
Management
Directory
Power & Cooling
Messaging
<<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
Service ID
Infrastructure
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
Service
Infrastructure
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
Contract
ID
CIS
Contract
Logical
Infrastructure
Component 1
Logical
Infrastructure
Component 2
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
LIC Contract Description
72
TOGAF™ is a trademark of The Open Group.
<<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
9.4.2
CIS Contract
Characteristic
CIS Contract Characteristic Value
Logical Target Technology Architecture
<<Technology Architecture Logical-Level Example: This section needs to provide one or more logicallevel views for the target technology architecture. The diagram below provides a view of the target
technology architecture at the logical level which consists of logical infrastructure components with their
associated infrastructure services. This particular example illustrates some of the logical infrastructure
components and associated infrastructure services within xxxx. However, the definition of logical
infrastructure 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.>>
Desktop
Citrix
Backup
Data Centre Mainframe
Integration Hub
Virtualisation
Messaging
WAN
Scheduling
Archive
Extranet
Directory
<<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.>>
LIC ID
Logical
Infrastructure
Component (LIC)
Logical Infrastructure Component (LIC) Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
73
TOGAF™ is a trademark of The Open Group.
Logical
Infrastructure
Component (LIC)
LIC ID
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.>>
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
Contract
ID
LIC
Contract
Logical
Infrastructure
Component 1
Logical
Infrastructure
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
9.4.3
LIC Contract
Characteristic
LIC Contract Characteristic Value
Physical Target Technology Architecture
<<Technology Architecture Physical-Level View Description: This section can provide, if necessary, a
description of the physical-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. This section
should follow the same structure as the logical target technology architecture.>>
9.4.3.1
Vendor Consideration List
<<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
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
74
TOGAF™ is a trademark of The Open Group.
9.4.4
Target Technology Architecture Cross-Reference
<<Technology Architecture Cross-References: This section provides, if necessary, some cross-references
for the technology architecture. The IS-TI services and components cross-references are included in the
application architecture.>>
9.5
Security Architecture Models
security management
system
security contracting
Environment Management
ExecutionEnvironment
Environment
Execution
inter-component
security
device identity
management
penetration testing
code control
Hardware Device
fault handling
Information management
evidence management
Organisation
device
protection
host IDS
platform protection
incident management
and emergency
procedures
organisational
compliance
Software
Component
user identity
management
fault handling
User
content scanning
platform
protection
software identity
management
security testing
user audit
incident handling
user authentication
user access management
information backup
Information
personal protection
message/channel
protection
code control
Environment
Protection
zone management
network admission control
Network Zone
denial of service prevention
fault handling
network IDS
Infrastructure
Service Name
perimeter
control
Description
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
Application
Type
Target Specification:
Policy Reference
75
TOGAF™ is a trademark of The Open Group.
10
Gap Analysis
<<The purpose of this section is to define the gap between the current (as-is) and target (to-be) state
business architectures.
Mandatory/optional: This section is optional as not all the domain teams need to produce a business
architecture for their respective domains. However, it can also be used by the domains that do not produce
a full (current and target) or current state business architecture but still want to know the (priority) areas
on which to concentrate, and thus minimise effort.
In terms of quality criteria, this section should make clear:

Description of the gap between the current (as-is) and target (to-be) state business architectures. This
difference, or delta, defines the scope of work that needs to be undertaken in order to transition from
the current to the target business architecture. This scope is thus the scope of the program(s) or
project(s) that need to be completed in order to reach the target business architecture.
The suggested steps are as follows:

Draw up a matrix with all the Architecture Building Blocks (ABBs) of the baseline architecture on
the vertical axis, and all the ABBs of the target architecture on the horizontal axis.

Add to the baseline architecture axis a final row labeled ‘‘New’’, and to the target architecture axis a
final column labeled ‘‘Eliminated’’.

Where an ABB is available in both the baseline and target architectures, record this with
‘‘Included’’ at the intersecting cell.

Where an ABB from the baseline architecture is missing in the target architecture, each must be
reviewed. If it was correctly eliminated, mark it as such in the appropriate ‘‘Eliminated’’ cell. If it
was not, an accidental omission in the target architecture has been uncovered that must be addressed
by reinstating the ABB in the next iteration of the architecture design – mark it as such in the
appropriate ‘‘Eliminated’’ cell.

Where an ABB from the target architecture cannot be found in the baseline architecture, mark it at
the intersection with the ‘‘New’’ row as a gap that needs to filled, either by developing or procuring
the building block.
When the exercise is complete, anything under ‘‘Eliminated’’ or ‘‘New’’ is a gap, which should either be
explained as correctly eliminated, or marked as to be addressed by reinstating or developing/procuring the
function.
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
76
TOGAF™ is a trademark of The Open Group.
Potential sources of gaps include:



Business domain gaps:
o
People gaps (e.g., cross-training requirements)
o
Process gaps (e.g., process inefficiencies)
o
Tools gaps (e.g., duplicate or missing tool functionality)
o
Information gaps
o
Measurement gaps
o
Financial gaps
o
Facilities gaps (buildings, office space, etc.)
Data domain gaps:
o
Data not of sufficient currency
o
Data not located where it is needed
o
Not the data that is needed
o
Data not available when needed
o
Data not created
o
Data not consumed
o
Data relationship gaps
Applications impacted, eliminated, or created
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
77
TOGAF™ is a trademark of The Open Group.

Technology impacted, eliminated, or created>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
78
TOGAF™ is a trademark of The Open Group.
11
Impact Assessment
<<The purpose of this section is to assess and document the impact (on the organization) of the change
required in order to transition from the current to the target state business architectures.
Mandatory/optional: This section is optional as not all the domain teams need to assess the organizational
impact of change within their respective domains.
In terms of quality criteria, this section should make clear:

Description of the organizational impact at a level that enables the organization to determine the
change management requirements for program(s)/project(s)>>
11.1 Reference to Specific Requirements
11.2 Stakeholder Priority of the Requirements To-Date
11.3 Phases to be Revisited
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:

Recommendations for implementing this architecture>>
TOGAF™ 9 Template: Architecture Definition
Copyright © 2010 The Open Group. All rights reserved.
79
TOGAF™ is a trademark of The Open Group.