Level 1
Provide validation that the Candidate has gained knowledge of the terminology, structure, and basic concepts of TOGAF 9.1, and understands the core principles of Enterprise Architecture and TOGAF.
Level 2
Provide validation that in addition to the knowledge and comprehension of Level 1, the Candidate is able to analyze and apply this knowledge. The learning objectives at this level focus on application and analysis, in addition to knowledge and comprehension.
2. Our Vision: Business Transformation made easy – aid our customers
develop and change their organizations.
Our goal: To offer Scandinavian's best education, certifying, coaching and
consultants within Business Transformation based on international
standards and best practice.
Biner Academy Biner Consulting
3. Course purpose
Level 1
Provide validation that the Candidate has
gained knowledge of the terminology,
structure, and basic concepts of TOGAF 9,
and understands the core principles of
Enterprise Architecture and TOGAF
Level 2
Provide validation that in addition to the
knowledge and comprehension of Level 1,
the Candidate is able to analyze and apply
this knowledge. The learning objectives at
this level focus on application and analysis,
in addition to knowledge and
comprehension
COMB:M00S-
01
4. Target Audience
Individuals
– who require a deeper understanding of TOGAF 9.
Professionals
– who are working in an organization where TOGAF 9 has been adopted
and who need to participate in architecture projects and initiatives.
Architects
– who will be responsible for developing architecture artifacts.
– who wish to introduce TOGAF 9 into an architecture practice.
– who want to achieve a recognized qualification to demonstrate their
detailed knowledge of TOGAF 9.
6. Course Modules
C:M00S-03
Basic Concepts of
Enterprise
Architecture and
TOGAF
Core Concepts of
TOGAF
Preliminary Phase Architecture
Partitioning
Architecture
Repository
Architecture
Deliverables
Views, Viewpoints
& Stakeholders
Building Blocks
Content
Framework
Iteration Phase A:
Architecture Vision
ADM Guidelines
and Techniques
Stakeholder
Management
Business
Scenarios
Technique
TOGAF Reference
Models
Enterprise
Continuum and
Tools
Phase B: Business
Architecture
Phase C: Info
Systems
Architectures –
Data
Phase C: Info
Systems Arch –
Application
Phase D:
Technology
Architecture
Architecture
Requirements
Management
Phase E:
Opportunities and
Solutions
Migration Planning
Techniques
Phase F: Migration
Planning
Phase G:
Implementation
Governance
Phase H:
Architecture
Change
Management
Architecture
Governance
Architecture
Maturity Models
Architecture Skills
Framework
Guidelines for
adapting the ADM:
Security
Guidelines for
adapting the ADM:
SOA
Certification
7. Course structure
Epilogue
Adapting TOGAF Certification
Governing the change
Governing the solution projects Managing the architecture
Planning the architectural change
Identifying solutions and Opportunities Creating the migration plan
Defining the architecture
Business Architecture Data Architecture Application Architecture Technology Architecture
Initiate the architecture work
Preparing the capability to execute Defining your vision
Prologue
Practicalities Introduction
9. Detailed Agenda Day 3 & 4 Combined
COMB:M00S-07
Day 3
09:00 Recap day 2
09.30 Architecture Development B-D
10:00
11:00 Break
11:15 Requirements Management
12:00 Lunch
13:00
Phase E: Opportunities & Solutions
Migration Planning Techniques
14:00 Break
14:15 Phase F: Migration Planning
15:00 Phase G: Implementation Governance
16:00 Break
16:15 Phase H: Architecture Change Management
17:00 End
Day 4
09:00 Recap day 3
09.30 Architecture Governance
10:00
Architecture Skills Framework
Architecture Maturity Models
11:00 Break
11:15
Adapting the ADM: Security
Adapting the ADM: SOA
12:00 Lunch
13:00 Certification
14:00
14:15
15:00
16:00
16:15
17:00 End
10. What do the Exams Cover?
TOGAF 9 Part 1
Basic Concepts 3 questions
Core Concepts 3 questions
Introduction to the ADM 3 questions
The Enterprise Continuum 4 questions
and Tools
ADM Phases 9 questions
ADM Guidelines and 6 questions
Techniques
Architecture Governance 4 questions
Architecture Views, 2 questions
Viewpoints and Stakeholders
Building Blocks 2 questions
ADM Deliverables 2 questions
TOGAF Reference Models 2 questions
TOGAF 9 Part 2
Project Establishment 1 question
ADM Phases: Preliminary, A
and Requirement Management
Architecture Definition 1 question
ADM Phases: B, C and D
Transition Planning 1 question
ADM Phases: E and F
Governance 1 question
ADM Phases: G and H
Adapting the ADM 1 question
Architecture Content 1 question
Framework
TOGAF Reference Models 1 question
Architecture Capability 1 question
Framework
C:M00S-08
11. What Does it Take to Pass?
TOGAF 9 Part 1 (1 h 30 min*) Pass mark 55%
(22 or more points out of a maximum of 40). This exam comprises 40 questions in simple multiple
choice format, covering the Level 1 learning outcomes. Each correct answer scores a single
point.
TOGAF 9 Part 2 (2 h 15 min*) Pass mark 60%
(24 or more points out of a maximum of 40). This exam comprises 8 complex scenario questions,
with gradient scoring. This exam is open book and covers the complete Level 2 learning
outcomes. The correct answer scores 5 points, the second best answer 3 points, the third best
answer 1 point. The distracter scores zero points.
TOGAF 9 Combined Part 1 and 2 (3 h 45 min*)
This is a combined TOGAF 9 Part 1 and Part 2 examination for candidates who want to achieve
Level 2 certification directly in a single examination. It consists of two sections, with pass marks
as per the TOGAF 9 Part 1 and 2 examinations. Each section must be passed in order to obtain
an overall pass mark.
* The times above includes additional time for individuals for whom English is a second language.
C:M00S-09
12. Basic Concepts of
Enterprise
Architecture and
TOGAF
Core Concepts of
TOGAF
Preliminary Phase Architecture
Partitioning
Architecture
Repository
Architecture
Deliverables
Views, Viewpoints
& Stakeholders
Building Blocks
Content
Framework
Iteration Phase A:
Architecture Vision
ADM Guidelines
and Techniques
Stakeholder
Management
Business
Scenarios
Technique
TOGAF Reference
Models
Enterprise
Continuum and
Tools
Phase B: Business
Architecture
Phase C: Info
Systems
Architectures –
Data
Phase C: Info
Systems Arch –
Application
Phase D:
Technology
Architecture
Architecture
Requirements
Management
Phase E:
Opportunities and
Solutions
Migration Planning
Techniques
Phase F: Migration
Planning
Phase G:
Implementation
Governance
Phase H:
Architecture
Change
Management
Architecture
Governance
Architecture
Maturity Models
Architecture Skills
Framework
Guidelines for
adapting the ADM:
Security
Guidelines for
adapting the ADM:
SOA
Certification
Basic Concepts of Enterprise
Architecture & TOGAF
The purpose of this Learning Unit is to
introduce the basic concepts of
Enterprise Architecture and TOGAF.
C:M00S-03
13. Learning Outcomes
You should be able to:
F:M02S-01
Describe what an enterprise is
Explain the purpose of an enterprise architecture
List the business benefits of having an enterprise architecture
Define what an Architecture Framework is
Explain why TOGAF is suitable as a framework for enterprise architecture
Describe the structure of TOGAF, and briefly explain the contents of each of
the parts
Briefly explain what TOGAF is
Explain what architecture is in the context of TOGAF
List the different types of architecture that TOGAF deals with
F
14. What is Enterprise Architecture
Google search for ‘definition of enterprise architecture’ results in
39 300 qualified and 10 800 000 unqualified hits
F:M02S-02
15. What is an Enterprise
F:M02S-03
“TOGAF defines enterprise as any collection of
organizations that has a common set of goals.“
Enterprise #1
Enterprise #2
Enterprise #4
Enterprise #3
16. What is Architecture?
ISO/IEC 42010:2007 defines "architecture" as:
"The fundamental organization of a system, embodied in its components, their
relationships to each other and the environment, and the principles governing its design
and evolution.“
In TOGAF, "architecture" has two meanings depending upon the context:
F:M02S-04
A formal description of a system, or a detailed
plan of the system at component level to guide
its implementation
The structure of components, their inter-
relationships, and the principles and guidelines
governing their design and evolution over time
17. The Need for Enterprise Architecture
There are two key reasons why you need enterprise architecture
1. Critical to business survival and success
2. Enables managed innovation within the enterprise
This by:
F:M02S-05
A more efficient business operation
A more efficient IT operation
Better return on existing investment,
reduced risk for future investment
Faster, simpler, and cheaper procurement
18. Benefits from Enterprise Architecture
F:M02S-06
Business Benefits
It helps an organization
achieve its business
strategy
Faster time to market for
new innovations and
capabilities
More consistent
business processes and
information across
More reliability and
security, less risk
Shared Benefits
Better traceability of IT
costs
IT Benefits
Lower IT costs – design,
buy, operate, support,
change
Faster design and
development
Less complexity
Less IT risk
19. Benefits from Enterprise Architecture
Stakeholder Benefit type Benefit Rationale KPI
Business/IT Better
traceability of
IT costs
Enterprise
architecture provides
provides greater
understanding of the
the inter-related
nature of business,
applications, and
infrastructure assets.
Most organizations
can identify the
individual cost of an
an asset. However,
many cannot
understand the cost
cost of an asset as it
it relates within the
organization with all
all its inter-
relatedness and
Interdependencies
% of IT OPEX that
can be allocated to
specific applications
applications or
business units
F:M02S-07
Better traceability of IT
costs
20. What is an Architecture Framework?
F:M02S-08
It should describe a method for
designing a target state of the
enterprise in terms of a set of
building blocks, and for showing how
the building blocks fit together
An architecture framework is a
foundational structure, or set of
structures, which can be used for
developing a broad range of different
architectures
It should contain a set of tools and provide
a common vocabulary. It should also
include a list of recommended standards
and compliant products that can be used
to implement the building blocks
21. What is TOGAF?
TOGAF is an architecture framework –
The Open Group Architecture Framework.
TOGAF provides the methods and tools for
assisting in the acceptance, production, use,
and maintenance of an enterprise architecture.
It is based on an iterative process model
supported by best practices and a re-usable set
of existing architecture assets.
F:M02S-09
22. Why TOGAF as the Framework for EA?
TOGAF Architecture Characteristics:
Consistent
Reflects stakeholder needs
Employs best practice
Current and future requirements
considered
The TOGAF process:
Helps ”de-mystify”...
...”de-risk” complex architecture design
Provides a platform for adding value
F:M02S-10
23. Types of Architectures Addressed
F:M02S-11
Business Architecture
Data
architecture
Application architecture
Technology architecture
Defines the business strategy, governance,
organization, and key business processes.
This architecture might be described by:
organization catalogs, actor catalogs, goals,
processes flow diagrams or use case diagram
24. Types of Architectures Addressed
F:M02S-12
Business Architecture
Data
architecture
Application architecture
Technology architecture
Describes the structure of an organization's
logical and physical data assets and data
management resources.
This architecture might be described by:
data entity catalogues, data entity/business
function matrices and conceptual data diagrams
or logical data diagrams
25. Types of Architectures Addressed
F:M02S-13
Business Architecture
Data
architecture
Application architecture
Technology architecture
Provides a blueprint for the individual application
systems to be deployed, their interactions, and
their relationships to the core business
processes of the organization.
This architecture might be described by:
application portfolios, , application/organization
matrices, role/application matrices and
and application communication diagrams
26. Types of Architectures Addressed
F:M02S-14
Business Architecture
Data
architecture
Application architecture
Technology architecture
Describes the logical software and hardware
capabilities that are required to support the
deployment of business, data, and application
services.
This architecture might would be described by:
technology standards, the technology portfolio,
application/technology matrices and
and environment & locations diagram
27. Structure of the TOGAF Document
F:M02S-15
Architecture
Development Method
Architecture
Content Framework
ADM
Guidelines & Techniques
Reference
Models
Enterprise
Continuum & Tools
Architecture
Capability Framework
Introduction
29. Why the Specification was Divided
Work together as a whole but it
allows for independent usage/specialization
E.g. may wish to adopt only the ADM
F:M02S-17
30. Summary
What is an Enterprise?
“a collection of organizations that has a common set of goals”
What is Architecture?
1. A formal description for implementation
2. The structure of components for governance through their lifecycle
What benefits are received from EA?
Business / Shared / IT
Reduce e.g. risk in transformations
What type of architectures does TOGAF handle?
Business / Data / Application / Technology
F:M02S-18
Editor's Notes
The retrospect sessions are run without any specific material.
Page 5-6
KLP 1.2-2 What is enterprise architecture?
Statistics is from Google 2012-01-14
Most definitions mention processes, structure, relationships, organization and evolution.
Page 5
KLP 1.2-1 (1) What is an enterprise?
An extended enterprise nowadays frequently includes partners, suppliers, and customers. If the goal is to integrate an extended enterprise, then the enterprise comprises the partners, suppliers, and customers, as well as internal business units.
Sports teams are enterprises
Page 9
KLP 1.2-2 What is enterprise architecture?
ISO/IEC 42010:2007 defines "architecture" as:
"The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution." TOGAF embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology.
In TOGAF, "architecture" has two meanings depending upon the context:
A formal description of a system, or a detailed plan of the system at component level to guide its implementation
The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
In TOGAF we endeavor to strike a balance between promoting the concepts and terminology of ISO/IEC 42010:2007 - ensuring that our usage of terms defined by ISO/IEC 42010:2007 is consistent with the standard - and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership. For more on terminology, refer to Definitions and Part IV, Architectural Artifacts .
Page 6
KLP 1.2-3 Why do I need an enterprise architecture?
A more efficient business operation:
Lower business operation costs
More agile organization
Business capabilities shared across the organization
Lower change management costs
More flexible workforce
Improved business productivity
A more efficient IT operation:
Lower software development, support, and maintenance costs
Increased portability of applications
Improved interoperability and easier system and network management
Improved ability to address critical enterprise-wide issues like security
Easier upgrade and exchange of system components
Better return on existing investment, reduced risk for future investment:
Reduced complexity in the business and IT
Maximum return on investment in existing business and IT infrastructure
The flexibility to make, buy, or out-source business and IT solutions
Reduced risk overall in new investments and their cost of ownership
Faster, simpler, and cheaper procurement:
Buying decisions are simpler, because the information governing procurement is readily available in a coherent plan
The procurement process is faster - maximizing procurement speed and flexibility without sacrificing architectural coherence
The ability to procure heterogeneous, multi-vendor open systems
The ability to secure more economic capabilities
---------------------------
There is more information in Whitepaper W076, Why Enterprise Architecture Matters?
There are two key reasons why you need enterprise architecture, as follows:
1. Critical to business survival and success
An effective enterprise architecture is critical to business survival and
success, and is the indispensable means to achieving competitive advantage
through IT. Today’s CEOs know that the effective management and
exploitation of information through IT is the key to business success. An
enterprise architecture addresses this need, by providing a strategic context
for the evolution of the IT system in response to the constantly changing
needs of the business environment.
2. Enables managed innovation within the enterprise
An enterprise architecture enables you to achieve the right balance between
IT efficiency and business innovation. It enables managed innovation
within the enterprise. Individual business units can innovate safely in their
pursuit of competitive advantage. At the same time, the needs of the
organization for an integrated IT strategy are assured, permitting the closest
possible synergy across the extended enterprise.
----
The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.
A good enterprise architecture enables you to achieve the right balance between IT efficiency and business innovation. It allows individual business units to innovate safely in their pursuit of competitive advantage
----
Page 8
KLP 1.2-3 Why do I need an enterprise architecture?
This information comes from Whitepaper W076, Why Enterprise Architecture Matters?
KLP 1.2-3 Why do I need an enterprise architecture?
This information comes from Whitepaper W076, Why Enterprise Architecture Matters?
Page 7
KLP 1.2-4 What is an Architecture Framework?
----
An architecture framework is a foundational structure, or set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.
----
Page 9
KLP 2.1-1 What is TOGAF?
Page 7
KLP 1.2-5 Why do I need TOGAF as a framework for enterprise architecture?
----
Using TOGAF as the architecture framework will allow architectures to be developed that are consistent, reflect the needs of stakeholders, employ best practice, and give due consideration both to current requirements and to the likely future needs of the business.
Architecture design is a technically complex process, and the design of heterogeneous, multi-vendor architectures is particularly complex. TOGAF plays an important role in helping to "de-mystify" and de-risk the architecture development process. TOGAF provides a platform for adding value, and enables users to build genuinely open systems-based solutions to address their business issues and needs.
----
Page 10
KLP 2.2-1 What is architecture in the context of TOGAF?
KLP 2.3-1 What kind of architecture does TOGAF deal with?
TOGAF has defined 4 types of architecture
----
Defines the business strategy, governance, organization, and key business processes.
Describes the structure of an organization's logical and physical data assets and data management resources.
Provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization.
Describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services.
----
Page 4
KLP 1.1-1 The high-level structure of TOGAF 9, its organization, and contents as shown in Figure 1-1
KLP 1.1-2 The seven main parts to TOGAF
There are seven main parts to the TOGAF document:
PART I (Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.
PART II (Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture.
PART III (ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
PART IV (Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
PART V (Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
PART VI (TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
PART VII (Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.
Page 4
KLP 1.1-1 The high-level structure of TOGAF 9, its organization, and contents as shown in Figure 1-1
KLP 1.1-2 The seven main parts to TOGAF
There are seven main parts to the TOGAF document:
PART I (Introduction) This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.
PART II (Architecture Development Method) This part is the core of TOGAF. It describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture.
PART III (ADM Guidelines and Techniques) This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.
PART IV (Architecture Content Framework) This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts, the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.
PART V (Enterprise Continuum & Tools) This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.
PART VI (TOGAF Reference Models) This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).
PART VII (Architecture Capability Framework) This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.
Page 5
KLP 1.1-3 The intention of dividing the TOGAF specification into independent parts
As an open framework, such use is encouraged, particularly in the following situations:
Organizations that are new to TOGAF and wish to incrementally adopt TOGAF concepts are expected to focus on particular parts of the specification for initial adoption, with other areas tabled for later consideration.
Organizations that have already deployed architecture frameworks may choose to merge these frameworks with aspects of the TOGAF specification.
The intention of dividing the TOGAF specification into these independent parts is to allow for different areas of specialization to be considered in detail and potentially addressed in isolation. Although all parts work together as a whole, it is also feasible to select particular parts for adoption whilst excluding others.
Example, an organization may wish to adopt the ADM process, but elect not to use any of the materials relating to architecture capability.