TOGAF9FC

TOGAF® 9
Foundation and Certified.
Visit
your learning portal
QA.COM /login
TOGAF 9® Foundation and Certified
TOGAF® 9 Foundation and Certified
Contents
Introduction 1
Basic Concepts 4
Core Concepts and Reference Models 12
Introduction to the ADM 21
The Enterprise Continuum 27
Architecture Repository 31
Architecture Content Framework 35
Content Metamodel 38
Preliminary Phase 44
Governance 57
Business Scenarios 65
Architecture Views and Viewpoints 67
Stakeholder Management 70
Building Blocks 73
Phase A – Architecture Vision 76
Phase B – Business Architecture 87
Phase C – Information Systems Architecture 96
Phase C – Data Architecture 99
Phase C – Application Architecture 104
Phase D – Technology Architecture (and TRM/III-RM) 110
Technical Reference Model – TRM 115
Integrated Information Infrastructure Reference Model – III-RM 117
Phase E – Opportunities and Solutions 120
Phase F – Migration Planning 127
Phase G – Implementation Governance 135
Phase H – Change Management 140
Architecture Requirements Management 145
Architecture Partitioning 149
Adapting the ADM 152
Architecture Maturity Models 159
Architecture Skills Framework 162
Includes extracts from the TOGAF® Framework, Version 9.2 copyright © 2018 The Open Group
TOGAF® is the registered trademark of The Open Group in the United States and other countries
Introduction
General Information
 Safety
 Security
 Course times
 Breaks
 Rooms
About You
 Name
 Company
 Role and responsibilities
 Architecture experience
 Objectives for attending course
 Other courses attended
Objectives
 The key objective of this course is to introduce delegates to the TOGAF ® Framework, and to provide
sufficient information for them to gain Foundation and Certified status, by taking the necessary exams.
 Note: Exams can be taken at the convenience of the delegate via Pearson VUE.
1
Topics to Cover
 Course Introduction
 Basic Concepts
 Core Concepts and Reference Models
 An Introduction to the ADM
 The Enterprise Continuum
 The Architecture Repository
 The Architecture Content Framework
 The Architecture Metamodel
 The Preliminary Phase
 Architecture Governance
 Business Scenarios
 Architecture View and Viewpoints
 Stakeholder Management
 Building Blocks and the ADM
 Phase A: Architecture Vision
 Phase B: Business Architecture
 Phase C: Information System Architecture
 Phase C – Data Architecture
 Phase C – Application Architecture
 Phase D: Technology Architecture
 Phase E: Opportunities and Solutions
 Phase F: Migration Planning
 Phase G: Implementation Governance
 Phase H: Architecture Change Management
 Requirements Management
 Architecture Partitioning
 Adapting the ADM
 Maturity Models
 Skills Framework
 Exam Preparation
2
Course Material
 The content of the course has been guided by a syllabus published by The Open Group
 The material has been through, and passed, a formal accreditation process undertaken by The Open
Group
 It consists of:
o Course Manual
o Reference Cards
o Selected Extracts from Framework
o Sample Foundation and Certified Exams
o Additional Sample Questions
o Case Study for use during course
o Sample Answer to Case Study
Exam Process
 The Combined Exam is included as part of the course fee
 The exams are managed by Pearson VUE
 The exam consists of two parts – Foundation (Part 1) and Certified (Part 2)
 Part 1 – duration 60 minutes consisting of 40 multiple choice questions (closed book). One point is awarded
for a correct answer, zero points for all other answers. Pass mark is 22
 Part 2 – duration 90 minutes consisting of 8 complex scenario-based multiple choice questions (open
book). Each question has four possible answers. Five points are awarded for the correct answer, three
points for the next best answer, one point a barely correct answer, and zero points for the remaining
answer. Pass mark is 24
 The booking process: please email TOGAFvoucher@qa.com, providing your Name and Booking Number
(information found in your joining instructions), when ready to take exam. You will receive a Voucher
Number as well as full instructions on how to book your exam.
3
Basic Concepts
Session Objectives
We will look at the following:
 The Open Group and its evolution
 The Enterprise, purpose and business benefits of Enterprise Architecture
 What Architecture is, and its main types
 What an Architecture Framework is, and why the TOGAF® Framework is so suitable
 The TOGAF® Library
 An overview of Certification Programme
The purpose of this module is to introduce the basic concepts of Enterprise Architecture and the TOGAF®
Framework.
This module covers Key Learning Points that are part of the Level 1 (Foundation) Certification.
The Open Group

 Vendor- and technology-neutral, not-for-profit consortium started in 1996
 They own the UNIX and TOGAF trademarks PLUS ArchiMate, Open FAIR, IT4IT
 500+ organisations are members, including QA
 70,000+ Individual Foundation or Certified Architects
 300,000+ downloads/purchases of TOGAF® Framework PDF/Book
 Certification started in 2003
 Vision: “Boundaryless Information Flow™”
The TOGAF® Framework Evolution
4
What is an Enterprise?
An enterprise is a collection of organisations that share a common set of goals.
Enterprises come in many shapes and forms:
 A whole corporation or a division of a corporation
 A government agency or a single government department
 A chain of geographically distant organisations linked together by common ownership
 Chain of dispersed organisations linked by common ownership
 Groups of countries or governments working together to create common or shareable deliverables or
infrastructures
 Partnerships and alliances of businesses working together, such as a consortium or supply chain
And there is the Extended Enterprise that encompasses other organisations who do business with you.
Enterprise Architecture – What is its Purpose?

 Complex organisations (enterprises) have complex systems
 Enterprise Architecture is about integrating those systems... Why?
o To support the business strategy
 EA provides a strategic context for system evolution, in response to the constantly changing business
environment, particularly Digital Transformation
 It creates an environment where IT efficiency is balanced against business need
What are the Business Benefits?

Other traditional benefits of an Enterprise Architecture are:
 A more efficient business operation:
o Lower business operation costs
o More agile organisation
o Business capabilities shared across the organisation
o Lower change management costs
o More flexible workforce
o Improved business productivity
 A more efficient IT operation:
o Lower software development, support and maintenance costs
o Increased portability of applications
o Improved interoperability and easier system and network management
o Improved ability to address critical enterprise-wide issues like security
o Easier upgrade and exchange of system components
 Better return on existing investment, reduced risk for future investment:
o Reduced complexity in the business and IT
o Maximum return on investment in existing business and IT infrastructure
o The flexibility to make, buy, or outsource business and IT solutions
o Reduced risk overall in new investments and their cost of ownership
5
 Faster, simpler, and cheaper procurement:

o Buying decisions are simpler, because the information governing procurement is readily available
in a coherent plan
o The procurement process is faster – maximising procurement speed and flexibility without
sacrificing architectural coherence
o The ability to procure heterogeneous, multi-vendor open systems
o The ability to secure more economic capabilities
What is a [System] Architecture?

“The fundamental concepts or properties of a system in its environment embodied in its elements, relationships and
in the principles of its design and evolution.”
Source: ANSI/IEEE 1471 – 2000, now superseded by ISO/IEC/IEEE 42010:2011, called “Systems and software
engineering – Architecture description”
Definition in the framework
“The structure of components, their interrelationships, and the principles and guidelines governing their design and
evolution over time.”
The Different Types of Architecture
6
What is an Architecture Framework?

The answer is many things, such as...
 Like any framework, it is a lot of good advice that’s been developed over years
 Guidance on designing the “Building Blocks” of an architecture
 A set of tools (vocabulary, techniques) to help in this process
 The standardisation necessary to attract vendor-based tools to help architects in their work
You need the TOGAF® Framework to give you a “kick-start” in any architecting activities undertaken.
So why is the TOGAF® Framework so suitable?

 Because it has evolved over many years to deliver this toolset
 It is “best practice” used by and supported by many architects
 The TOGAF® Framework really comes to the fore when considering more complex systems in complex
organisations, by addressing the problems often encountered in these situations
 It has a process and toolset that is...
o Focused on aligning IT and business
o Based on “codified common sense” and best practices
o The product of many experienced architects
o An open standard, therefore free
o Supported by tool vendors and others
o Widely adopted
o Usable in a wide variety of circumstances
7
The TOGAF® Framework Parts
Part I – Introduction – overview and summary of the Standard, including key definitions
Part II – The Architecture Development Method: a process for undertaking Enterprise Architecture
Part III – ADM Guidelines and Techniques: this contains many established techniques. It is the most valuable
toolkit, addressing topics such as Governance (principles), Stakeholder Management, Business Scenarios, Gap
Analysis, Migration Planning Techniques, Risk Management, and more.
Part IV – Architecture Content Framework: puts structure into the sort of documents architects deal with, and more
importantly perhaps, a Metamodel that describes architectural entities and their relationships.
Part V – The Enterprise Continuum: despite its rather enigmatic title this area provides some fundamental and
substantial help on how to both visualise and organise both Architecture definitions (Building Blocks), and the
associated processes.
Part VI – Architecture Capability Framework: this final section has some important aspects, not least guidance on
Architecture Governance, and a Skills Framework.
8
TOGAF® Framework Capabilities
TOGAF® Library
Organised into four sections (linked to the Enterprise Continuum):
1. Foundation Documents
2. Generic Guidance and Techniques
3. Industry-Specific Guidance and Techniques
4. Organisation-Specific Guidance and Techniques
Library resources further classified as:
 Dependent: explicitly refer to “anchor points” in the Framework
 Supporting: useful guides to using the Framework
 EA General: general resources not linked to Framework
9
Certification Program
Exam Paths
Note: This slide shows images of an optional Badges scheme that is available through The Open Group with the
badge-provider “Acclaim”. The top image shows the badge associated with a “Credential”, issued to show that the
delegate has updated their knowledge via a 3 hour course and passed a 20 question online exam. It is likely that in
time The Open Group may introduce other smaller-scale training options to achieve other Credentials.
The other images reflect the standard certification status achieved once the appropriate exam has been passed.
10
Summary
We have learnt that:
 The Open Group is a well-established, vendor-neutral consortium
 An enterprise is a collection of organisations that share the same goal
 Enterprise Architecture’s purpose is to integrate and simplify corporate systems to better support long-term
business strategy
 Enterprise Architecture Business Benefits are quicker, cheaper, more efficient systems
 An “architecture” is a collection of related components (BBs) whose design and evolution needs governing
 The main domains of architecture covered by the TOGAF® Framework are Business, Application, Data and
Technology – but don’t forget “Enterprise Architecture”
 An Architecture Framework is best architecture practice
 The TOGAF® Framework is so suitable because it provides advice on governing, doing, designing and
generally evolving systems
 The structure of the TOGAF® Framework is in six parts
11
Core Concepts and Reference Models

Session Objectives
 The Architecture Development Method
 The Architecture Content Framework
 The Enterprise Continuum
 The Architecture Repository
 Architecture Capability
 Using TOGAF® with other frameworks
 The TRM and III-RM
The purpose of this module is to explain the core concepts of the TOGAF® Framework.
This module covers Key Learning Points that are part of the Level 1 (Foundation) certification.
12
The Architecture Development Method
13
The Architecture Content Framework
What we’re getting here is some solid advice on the type of documents to produce and the information that goes in
them. All that is needed now is some idea of how people want this data to be represented – this is where Views
and Viewpoints come in. We’ll look at this later.
14
The Enterprise Continuum
This term may be slightly arcane, but this whole concept is critical to describe how IS/IT “Architectures” are
composed. We will look at this in more detail later.
On its Y-axis, it addresses the need to initially describe architecture in a high-level way, which is then used to guide
and/or support the final detailed specification.
On its X-axis it plots the continuum itself which starts (if you look at the right-hand side first) with the very specific
architectures that are an intrinsic part of your organisation, and moves out eventually to a very general area that is
populated by Frameworks (TOGAF, etc.), Languages (ECMA-script, Java, etc.), Basic Patterns of Architecture
(MVC, Point-to-point, etc.).
15
The Architecture Repository
16
Architecture Capabilities
Enterprise architects live in a complex environment. They have to interrelate with the Business, Programme and
Project Managers.
From an operational perspective they may need to deal with the following:
 Financial Management: dealing with numbers associated with the Architecture Practice (budgeting,
forecasting)
 Performance Management: showing how the architecture function is performing
 Service Management: of the architectural services provided, and the current project “pipeline”
 Risk Management: of the threats that may impede realising goals/plans
 Resource Management: of the people in the Architecture practice
 Communications and Stakeholder Management: managing the needs of stakeholders, and ensuring
effective communication with them
 Quality Management: the quality of the architecture practice, perhaps measured by plans, review
processes, documentation
 Supplier Management: of the products and services provided to the practice
 Configuration Management: of the baseline architecture specifications, and intellectual property
 Environment Management: of the facilities, tools and equipment used by the practice
17
Using TOGAF® with other Frameworks
MSP: Managing Successful Programmes

PRINCE2: Projects in Controlled Environments
ITIL: The Information Technology Infrastructure Library
COBIT: Controlled Objectives for Information and Related Technology
18
Technical Reference Model
Integrated Information Infrastructure RM
19
Summary
We have seen that:
 The Architecture Development Method is a set of architecture processes
 The Architecture Content Framework suggests documents and entities that describe architecture
 The Enterprise Continuum explores how to conceptualise and categorise architecture
 The Architecture Repository is a place to store architecture assets
 Architecture Capability describes relationships with others and core competencies of the Architecture
Practice
 Using TOGAF with other frameworks is vital, to coordinate with PMO, PO and Governance
 The TRM and III-RM are two Reference Models; part of the TOGAF® Series
20
Introduction to the ADM

Session Objectives
 What is the ADM, and its key points?
 Phases A – D, typical steps and Document Versioning
 Relationships between the ADM and other parts of the TOGAF® Framework
 Guidelines and techniques for use
 Adapting the ADM
 ADM Governance and Information
 Scope, its limitations and dimensions
 Architecture Integration
The purpose of this module is to help understand the ADM cycle, briefly explain the objective of each phase in the
cycle, and how to adapt and scope the ADM for use.
21
The ADM and Key Points
Definition process – Phases A to D
22
ADM Relationships
Guidelines and Techniques
Guidelines (not shown in diagram) are provided to enable different process styles, such as iteration between ADM
phases and architecture engagement, or adoption of specialist architectures such as SOA and Security. Also
addresses the different levels of granularity.
23
– Strategic, Segment or Capability – the Architecture Landscape.

The TOGAF® Framework is designed to be flexible and it can be used with various architectural styles. Further
information can be found in the following guides:
• Integrating Risk and Security Within a TOGAF® Enterprise Architecture
• TOGAF® Series Guide: Using the TOGAF® Framework to Define and Govern Service-Oriented
Architectures
Adapting the ADM
ADM Governance and Information
24
Architecture Scope
Architecture Integration
As organisations address common themes (such as Service-Oriented Architecture (SOA), and integrated
information infrastructure), and universal data models and standard data structures emerge, integration toward the
25
high end of the spectrum will be facilitated. However, there will always be the need for effective standards
governance to reduce the need for manual coordination and conflict resolution.
Summary
We looked at the following:
 What is the ADM, and its key points’ intuitive, generic use alongside...
 Phases A – D, typical steps they contain and Document Versioning models, baseline, target, gaps,
timeframe, impact, checkpoint, finalisation, documentation
 Relationships between the ADM and other parts of the framework highly integrated
 Guidelines and techniques for use in the architects toolbox
 Adapting the ADM to suit large and small, internal and external development, nature of the business
 ADM Governance and Information is important, to control and audit documentation and processes
 Scope, its limitations and dimensions many different influences on architectural activity
 Architecture Integration in order to harmonise architectures to standards and reference architectures
26
The Enterprise Continuum

Session Objectives
 The Enterprise Continuum – what is it and how is it used?
 The constituent parts of the Enterprise Continuum
 Explain how the Enterprise Continuum relates to other parts of TOGAF
The purpose of this module is to understand the concept of the Enterprise Continuum, its purpose and constituent
parts.
Definitions
Continuum: “a continuous sequence in which adjacent elements are not perceptibly different from each other, but
the extremes are quite distinct”
Imperceptible: “so slight, gradual, or subtle as not to be perceived”
Source: Oxford Dictionary
What is the Enterprise Continuum?

 A CLASSIFICATION SYSTEM...
 ...which can therefore assist in identifying reusable assets
 A way of “idealising” (considering the design/architecture) and “realising” (considering the solution)
 A communications aid, for use internally and externally (extended enterprise)
 An aid to (software) engineering and/or making effective use of COTS packages
Reuse
 Reference Models
 Patterns
 Building Blocks
 Frameworks
 Specifications
 Existing Architecture Assets
BUT YOU NEED SOMEWHERE TO STORE AND ACCESS THIS INFORMATION – A “REPOSITORY”
27
Main Constituents
Main Graphic
28
Architecture Continuum
When you “idealise” about architecture you should:

 Use reference models wherever possible:
o Examples: TRM (Foundation) and III-RM (Common System) published as Series Guides
 Reuse existing logical (architectural) Building Blocks
 Think right to left
Solutions Continuum
When you “realise” an architecture you should:

 Derive from existing architectural assets
 Implement a physical solution
o i.e. Architecture Asset is a Framework, Solution Asset could be IT4IT
 Control that solution uses SLAs
29
Relationship with the ADM
Summary
We have looked at:
 The Enterprise Continuum – a classification system
 The constituent parts of the Enterprise Continuum
 Architecture and Solution Continuums
 Explain how the Enterprise Continuum relates to other parts of the TOGAF® Framework – particularly
during definition phases
30
Architecture Repository
Session Objectives
 What is the Architecture Repository?
 Describe the purpose of the main repository areas
The purpose of this module is to help understand the purpose of the Architecture Repository, its constituent parts,
and its relationship to other parts of the TOGAF® Framework.
Overview
 An effective Architecture Practice will generate a large output of documents, diagrams, etc.
 A structured framework for classifying this output
 It should be regarded as part of an overall Enterprise IT Repository, consisting of
o Detailed design
o Deployment
o Service Management areas
Observation – the Enterprise Repository is seen by many newcomers to the TOGAF ® Framework as an “entry
point”.
The Architecture Repositories
31
Classes of Repository Information

 The Architecture Metamodel describes the organisationally tailored application of an architecture
framework, including a method for architecture development and a Metamodel for architecture content
 The Architecture Capability defines the parameters, structures, and processes that support governance of
the Architecture Repository
 The Architecture Landscape presents an architectural representation of assets in use, or planned, by the
enterprise at particular points in time
 The Standards Information Base captures the standards with which new architectures must comply, which
may include industry standards, selected products and services from suppliers, or shared services already
deployed within the organisation
 The Reference Library provides guidelines, templates, patterns, and other forms of reference material that
can be leveraged in order to accelerate the creation of new architectures for the enterprise
 The Governance Log provides a record of governance activity across the enterprise
 The Architecture Requirements Repository provides a view of all authorised architecture requirements
which have been agreed with the Architecture Board
 The Solutions Landscape presents an architectural representation of the Solution Building Blocks (SBBs)
supporting the Architecture Landscape which have been planned or deployed by the enterprise
 The Enterprise Repository – there are a considerable number of enterprise repositories that support the
architecture both inside and outside of the enterprise, such as development repositories, specific operating
environments, instructions, and configuration management repositories
Enterprise Continuum and the Repository
32
Architecture Landscape
Strategic Architectures: provide a longer term (high-level) roadmap towards achieving strategic business goals.
Segment Architectures: are the next level down, represent major business domains or even systems/capabilities
(the classification is up to the organisation), but still at the higher level.
Capability Architectures: represent the “ground level” of architecting. They represent packages or projects that are
part of transitionary or incremental plans. This is where the Solution Building Blocks live.
Standards Information Base
33
Summary
We have looked at the following:
 What is the Architecture Repository?
o A framework for classifying architecture output
 How does it relate to the Enterprise IT Repository?
o It fits alongside other repositories for development, deployment and support
 Describe the purpose of the main repository areas:
o The Architecture Metamodel organises an architectural framework and models content
o The Architecture Capability supports governance of the repository
o The Architecture Landscape contains views of the architecture at a particular point in time
o The Solutions Landscape contains Solution Building Blocks
o The Standards Information Base captures standards
o The Reference Library provide guidelines
o The Governance Log records enterprise governance activity
34
Architecture Content Framework

Session Objectives
This chapter will:
 Explain the purpose of the Architecture Content Framework
 Describe the main components of the Content Metamodel
 Describe the relationship between the Content Metamodel and the ADM
The purpose of this module is to help understand the TOGAF Architecture Content Framework.
Overview
 A significant new feature to Version 9
 Like any classification system
o Aids consistency of terminology
o Mapping items to other frameworks, such as Zachman
 Key parts are:
o Architecture Deliverables
o Architectural Artifacts
o Building Blocks
o Content Metamodel
Content Framework Items

 Deliverable
o Contractually specified work product, formally reviewed, agreed and signed-off by the stakeholders
 Artifact
o A more granular work product describing architecture from a specific view and viewpoint. Classified
as:
 Catalogues (lists)
 Matrices (relationships between lists) and
 Diagrams
 Building Block
o A potentially reusable component of business, IT or architectural capability. Combined with other
BBs, delivers:
 Architecture BBs describe capability
 Solutions BBs implement that capability
Deliverable
Contractually specified, formally reviewed, agreed and signed-off by the stakeholders. At end of project it will either
be archived or transitioned into the Architecture Repository as a Reference Model, Standard or snapshot of the
Architecture Landscape at a point in time.
35
Key Relationships
Example Deliverable
36
The Content Metamodel

 Definition of all Building Blocks that may exist within an architecture
 Combined with the Work Products, provides a comprehensive way to describe Architecture
 Its classification is closely mapped to the ADM, and will be used extensively within the Inputs and Outputs
particularly during the “definition” phases (A – E)
Summary
In this chapter we have:
 Explained the purpose of the Content Framework which provides a consistent platform for describing
architecture
 Described the main components of the Content Metamodel which are the work products and the
Metamodel
 Described the relationship between the Content Metamodel and the ADM where the Metamodel is closely
mapped to main ADM phases
37
Content Metamodel
Session Objectives
This chapter will:
 Describe the core Metamodel concepts
 Describe the key concepts related to the Core Part
 Explain why the Metamodel is divided into Core and Extension Parts
 Describe briefly the Extension Parts
The purpose of this module is to help understand the TOGAF Content Metamodel.
Core Concepts
 Core and Extension Content
o Basic version with a set of extensions covering additional considerations
 Core Metamodel Entities
o Showing the purpose of each entity
o Key relationships that support architectural traceability
Core and Extension Content provides an introduction to the way in which TOGAF employs a basic core metamodel
and then applies a number of extension modules to address specific architectural issues in more detail.
Core Metamodel Entities introduces the core TOGAF Metamodel entities, showing the purpose of each entity and
the key relationships that support architectural traceability.
Catalogue, Matrix, and Diagram Concept describes the concept of catalogues, matrices, and diagrams.
38
Core Entity Diagram
39
Core and Extension Parts
40
Full Diagram with Extensions
41
Associated Artifacts
42
Summary
In this chapter we have:
 Described the core Metamodel concepts to provide a formal and consistent set of terms for use in ADM
 Described the key concepts related to the Core Part – Actor, Application Component, Business Service,
Data Entity, Function, Organisation, Platform Service, Process, Role, Technology Component
 Explained why the Metamodel is divided into Core and Extension Parts – Core provides key basic
definitions, and the Extension looks at specific aspects in more detail
 Described briefly the Extension Part which addresses Governance, Services, Process Modelling, Data,
Infrastructure Consolidation, Motivation
43
Preliminary Phase
Session Objectives
This module focuses on the Preliminary Phase’s
 Objectives
 Approach
 Main inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Preliminary Phase contributes to the success of
Enterprise Architecture.
The order of the five objectives is significant (and this will be repeated in all phases). From an exam perspective,
“Objectives” and “Approach” relate to the Foundation (Level 1) exam and are therefore dealt with together as a unit.
An awareness of the remaining three items is assumed for the Certified (Level 2) exam. In the version 9.1
document this order of items was used. But for version 9.2, it was felt by the Architecture Forum that order of items
should be changed so the “Approach” is now the final item in each phase.
Phase Objectives
1. Determine the Architecture Capability desired by the organisation:
o Review the organisational context for conducting Enterprise Architecture
o Identify and scope the elements of the enterprise organisations affected by the Architecture
Capability
o Identify the established frameworks, methods, and processes that intersect with the Architecture
Capability
o Establish Capability Maturity target
2. Establish the Architecture Capability
o Define and establish the Organisational Model for Enterprise Architecture
o Define and establish the detailed process and resources for architecture governance
o Define the Architecture Principles
o Select and implement tools that support the Architecture Capability
Approach
 Define the Enterprise inc. scope, stakeholders, extent
 Identify key drivers and elements in the Organisational Context inc. commercial models/budgets,
stakeholders, intentions, management processes, baseline, skills, capabilities and corporate culture
 Define the requirements for architecture work inc. business need, cultural aspiration, organisation intents,
strategic intent, financial forecasts
 Define the architecture principles that guide the development of architecture, and cross-ref to business
principles, goals and drivers
 Understand which management frameworks to be used inc. business capability, project and programme
management, operations and solution development
 Define the relationships between management frameworks – see next slide
 Evaluate the Enterprise Architecture maturity by means of capability maturity models such as NASCIO and
ACMM
44
Relationship Between Frameworks
Inputs
Reference Materials External to the TOGAF® Framework
 The TOGAF® Library
 Other Architecture Framework(s) if required
Non-architectural
 Board strategies, business plans, business strategy, IT strategy,
business principles, business goals, and business drivers
 Major Frameworks operating in the business
 Governance and Legal Frameworks
 Architecture Capability
 Partnerships and contract agreements
Architectural
 Organisational Model
 Existing Architecture Framework, if any
45
Further Input Considerations

 Other Architecture Frameworks may be required or mandated
o Such as PRINCE2, ITIL, or industry-specific, i.e. MoDAF
 Business principles, business goals, and business drivers
o All part of the Business Motivation, or Organisational Context
Other Architecture Frameworks may be required or mandated, such as xGEAF, MoDAF, FEAF, DoDAF. In these
cases TOGAF can be used alongside.
Business principles, business goals, and business drivers – all part of the Business Motivation, or Organisational
Context.
Steps
1. Scope the enterprise organisations
impacted
2. Confirm governance and support
frameworks
3. Define and establish Enterprise
Architecture team and organisation
4. Identify and establish architecture
principles
5. Tailor TOGAF® and, if any, other selected
Architecture Frameworks
6. Implement architecture tools
Step Summary
1. Scope the Enterprise
Identify Core parts of the enterprise, those indirectly affected, the extended enterprise, stakeholders involved and
any associated governance.
2. Confirm Governance
Often Enterprise Architecture activity can have a profound effect on governance – and this should be ascertained
and acted upon when dealing with governance processes and documents.
3. Establish Team and Organisation
See future slide.
4. Establish Principles
See future slide.
5. Tailor Architecture Frameworks
See future slide.
6. Implement Architecture Tools
Reflects formality required by stakeholders. The stakeholders' articulation of requirements will enable more
effective and rapid decision-making by stakeholders. It should encompass management techniques, decision
management, workshop techniques, business modelling, detailed infrastructure modelling, office products,
languages and repository management as well as more formal architecture tools.
46
Establish EA Team and Organisation
 Determine existing enterprise and business capability

 Conduct an Enterprise Architecture/business change maturity assessment
 Identify gaps in existing work areas
 Allocate key roles and responsibilities
 Define change requests:
o Inform existing Enterprise Architecture and IT Architecture work of
stakeholder requirements
o Request assessment of impact on their plans and work
o Identify common areas of interest
o Identify any critical differences and conflicts of interest
o Produce requests for change to stakeholder activities
 Determine constraints on Enterprise Architecture work
 Review and agree with sponsors and board
 Assess budget requirements
47
Identify Principles
 Principles are enduring rules
 They enable decision-making (management)
 Enterprise Principles inform and help the organisation to fulfil its mission
 Architecture principles...
o Govern the evolution of systems
o Govern the implementation of architecture
Defining Principles
 An important process that should be handled by the Chief, or most senior [Enterprise] Architect
 Other senior stakeholders should be closely involved:
o Architecture Board Members, that may well include:
o Other key stakeholders (business, operations, commercial, legal etc.)
o CIO, if applicable
 Each principle must be related to some form of goal, or driver
48
List of Principles
Business Primacy of Principles

Maximise Benefit to the Enterprise
Information Management is Everybody’s Business
Business Continuity
Common Use Applications
Service Orientation
Compliance with Law
IT Responsibility
Protection of Intellectual Property
Data Data is an Asset

Data is Shared
Data is Accessible
Data Trustee
Common Vocabulary and Data Definitions
Data Security
Application Technology Independence

Ease-of-Use
Technology Requirements-based Change

Responsive Change Management
Control Technical Diversity
Interoperability
49
Principle Template
Name Should both represent the essence of the rule as well

as be easy to remember. Specific technology
platforms should not be mentioned in the name or
statement of a principle.
Statement Should succinctly and unambiguously communicate

the fundamental rule. For the most part, the principle’s
statements for managing information are similar from
one organisation to the next. It is vital that the
principle’s statement be unambiguous.
Rationale Should highlight the business benefits of adhering to

the principle, using business terminology. Points to the
similarity of IS and IT principles to the principles
governing business operations. Also describes the
relationship to other principles and intentions regarding
a balanced interpretation. Describes situations where
one principle would be given precedence or carry
more weight than another for making a decision.
Implications Should highlight the requirements, both for the

business and IT, for carrying out the principle – in
terms of resources, costs and activities/tasks. It will
often be apparent that current systems, standards, or
practices would be incongruent with the principle upon
adoption. The impact to the business and
consequences of adopting a principle should be clearly
stated. The reader should readily discern the answer
to: ‘‘How does this affect me?’’ It is important not to
oversimplify, trivialise, or judge the merit of the impact.
Some of the implications will be identified as potential
impacts only and may be speculative rather than fully
analysed.
50
Example Principle (#1)
Name Primacy of Principles
Statement Principles of information management apply to all organisations within the

enterprise.
Rationale The only way we can provide a consistent and measurable level of quality
information to decision-makers is if all organisations abide by the principles.
Implications • Without this principle, exclusions, favouritism and inconsistency would

rapidly undermine the management of information
• Information management initiatives will not begin until they are examined
for compliance with the principles
• A conflict with a principle will be resolved by changing the framework of
the initiative
Example Principle (#2)
Name Service Orientation
Statement The architecture is based on a design of services which mirror real-world

business activities comprising the enterprise (or inter-enterprise) business
processes.
Rationale Service orientation delivers enterprise agility and Boundaryless Information

Flow.
Implications • Service representation utilises business descriptions to provide context

(i.e. business process, goal, rule, policy, service interface and service
component) and implements services using service orchestration
• Service orientation places unique requirements on the infrastructure, and
implementations should use open standards to realise interoperability and
location transparency
• Implementations are environment-specific; they are constrained or
enabled by context and must be described within that context
• Strong governance of service representation and implementation is
required
• A “Litmus Test”, which determines a “good service”, is required
51
Qualities of Principles
Understandable The underlying tenets can be quickly grasped and understood by individuals
throughout the organisation. The intention of the principle is clear and
unambiguous, so that violations, whether intentional or not, are minimised.
Robust Enable good quality decisions about architectures and plans to be made, and
enforceable policies and standards to be created. Each principle should be
sufficiently definitive and precise to support consistent decision-making in
complex, potentially controversial situations.
Complete Every potentially important principle governing the management of information

and technology for the organisation is defined. The principles cover every
situation perceived.
Consistent Strict adherence to one principle may require a loose interpretation of another
principle. The set of principles must be expressed in a way that allows a balance
of interpretations. Principles should not be contradictory to the point where
adhering to one principle would violate the spirit of another. Every word in a
principle statement should be carefully chosen to allow consistent yet flexible
interpretation.
Stable Principles should be enduring, yet able to accommodate changes. An

amendment process should be established for adding, removing, or altering
principles after they are ratified initially.
52
Tailoring the Framework

 Terminology Tailoring
 Process Tailoring – the TOGAF® Framework is likely to have to integrate with:
o Project and Service portfolio management processes
o Project lifecycle
o Operations handover processes
o Operational management processes (including configuration
management, change management and service management)
o Procurement processes
 Content Tailoring – aligning architecture description to the Content Framework or
other content frameworks (Zachman, Metis)
Outputs
 Organisational model for Enterprise Architecture
 Tailored Architecture Framework, including architecture principles
o The final architecture processes and list of principles
 Initial Architecture Repository
 Restatement of, or reference to, business principles, business goals and
business drivers
 Request for [Enterprise] Architecture Work
 Architecture Governance Framework
o Established after taking into account the organisation and integration
with other frameworks
Request for Architecture Work

 Organisation sponsors  External constraints, business constraints
 Organisation's mission statement  Current business system description
 Business goals (and changes)  Current architecture/IT system description
 Strategic plans of the business  Description of the organisation developing
 Time limits the architecture
 Changes in the business environment  Description of resources available to the

organisation developing the architecture
 Organisational constraints
 Budget information, financial constraints
53
Security/Risk Big Picture
This diagram will be discussed fully in the Security Section towards the end of the course. Suffice to say both
Security and Risk must be considered as an integral part of Enterprise Architecture in this and other phases.
Detailed extracts are provided from the TOGAF® Series Guide: Integrating Risk and Security within a TOGAF®
Security
The Preliminary Phase establishes the security context required to guide the Security Architecture design. To build
the security context, the following security artifacts need to be determined during this phase. These artifacts can be
integrated into existing architecture documentation:
 Business Drivers/Objectives
 Security Principles
 Risk Appetite
 Key Risk Areas/Business Impact Analysis
 Security Resource Plan
 Identify required security resources
 Establish role and mandate of security architect
 Establish security governance process
 Ensure security and risk embedded as an integral part of architecture in all domains
54
5.1.1 Business Drivers/Business Objectives

Location in the Architecture Framework: This is the subset of the TOGAF® Framework business drivers affecting
security, presented as an integral part of the overall architecture business drivers (TOGAF 9.1 §36.2.9).
In O-ISM3 [9], this is called the business objectives. Every organisation exists for specific purposes that require it to
set goals and meet certain obligations. Business objectives, ranging from aspirational goals to regulatory
compliance, may originate internally, or be imposed by an external party such as the government. Their
achievement depends on many factors, one being information security. Some examples of business objectives are:
• Paying the payroll on the 1st of every month
• Paying all incoming invoices within a certain timeframe
5.1.2 Security Principles
Location in the Architecture Framework: Security Principles are the subset of Business Principles addressing
Security Architecture. This is presented as an integral part of the overall Architecture Principles deliverable
(TOGAF 9.1 §36.2.4).
Security Principles, like other Architecture Principles, will provide valuable guidance to making business decisions
to comply with the enterprise’s risk appetite. In essence, the usage of Security Principles does not differ from the
usage of Architecture Principles. Examples of Security Principles will be given in the Security Architecture
Practitioners Guide.
5.1.3 Risk Appetite
Location in the Architecture Framework: Enterprise Security Architecture: ERM.
Risk appetite describes the enterprise’s attitude towards risk and provides decision-making guidance to the
organisation to balance the amount of risk taken to achieve an expected outcome. The risk appetite could be
expressed as, for example, a boundary on a risk/business impact and likelihood grid, profit, and loss measures or
qualitative measures (zero tolerance for loss of life or regulatory compliance breaches). Risk appetite can also be
represented by suitably worded Security Principles, or produced as a stand-alone deliverable if a key stakeholder
exists who needs to approve it specifically. It defines both the level of risk the organisation is willing to accept as
well as its strategy in defining this level. For risks above this acceptable level, it defines the strategy used for
mitigation (transference, avoidance).
5.1.4 Key Risk Areas/Business Impact Analysis
Note: Risk classification is described in TOGAF 9.1 §31.2 and §31.3 and is focused on risk of the architecture
projects. This Guide extends the concepts of Risk and Risk Assessment.
During the Preliminary Phase, addressing key risk areas provides a context for architecture projects. During an
architecture project in Phase A, this should be confirmed.
The business impact analysis can be applied in all domains and against the architecture roadmap, and is a
powerful tool for determining fitness of the architecture and roadmap. A business impact analysis points out the
potential damage (or profit) to the business that can be expected if inappropriate and insufficient information
security is applied. It (only) defines what kind of impact is relevant to the business process and should be avoided,
not the likelihood of this impact occurring. The deliverable is a list of the key risk areas within the architecture
scope. This information is input to the risk assessment.
5.1.5 Security Resource Plan
Location in the Architecture Framework: TOGAF 9.1, ADM, Preliminary Phase and Phase A.
Resource planning for architecture work for the entire architecture team is addressed in the Preliminary Phase
when the Enterprise Architecture team is defined and established. In Phase A it is addressed where the capability
of the architecture team is assessed against the architecture project.
Based on the scope of the Enterprise Architecture team’s responsibility and the scope of any architecture project, it
will identify the required security resources to deliver the security elements of the architecture.
A key part of defining the Enterprise Architecture team is establishing the expected role and mandate of the
Security Architect. Best practice Security Architecture integrates security and risk within all domains. Integral to this
is establishing the governance process for the Security Architecture within the context of the Enterprise
Architecture governance process.
55
Answering the following questions will assist in identifying the security and risk resources required in the team, and
on an architecture project:
• What are the common security or risk-related concerns?
• Do key and influential security or risk-related stakeholders exist who require specific security views?
• Does the architecture address high-risk areas, or is the risk appetite low?
• Can security support be requested on an as-needed basis from an existing security team or are dedicated
Security Architecture resources required as part of the overall architecture team?
During the Preliminary Phase it is decided which security artifacts are really needed in the Enterprise Architecture
and which will be created by whom. It might not be necessary to deliver all security artifacts in order to address
security properly. The reverse applies too: delivering all artifacts does not guarantee that security is taken care of
properly – more artifacts may be required.
For enterprise-level architectures, the artifacts need to be created based on discussions with key stakeholders;
preliminary assessments carried out by the architecture team; and assessing relevant statutes, applicable
jurisdictions, legislation, and regulations.
For capability-level architectures, existing sources might be available. For instance, an enterprise-level security
policy or risk assessment describes the security principles, risk appetite, and key risk areas for a particular context.
Summary
The Preliminary Phase prepares an organisation to undertake successful Enterprise Architecture projects.
56
Governance
Session Objectives
 Explain the nature and concepts of Architecture Governance, and a Governance Framework
 Describe the Architecture Board
 Explain the need for and meaning of Architecture Compliance
 Explain the purpose and describe Compliance Reviews
 Explain the benefits and list Key Success Factors
 Discuss the role, setting up and operating an Architecture Board
The purpose of this module is to help understand how to apply Architecture Governance in development of an
Overview
Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures
are managed and controlled at an enterprise-wide level.
Operates within a hierarchy of governance structures typically made up (in larger organisations) of:
 Corporate Governance
 Technology Governance
 IT Governance
57
Architecture Governance Framework – Conceptual Structure
Policy Management and Take-On
All architecture amendments, contracts, and supporting information must come under governance through a formal
process in order to register, validate, ratify, manage, and publish new or updated content. These processes will
ensure the orderly integration with existing governance content such that all relevant parties, documents, contracts,
and supporting information are managed and audited.
Compliance
Compliance assessments against Service-Level Agreements (SLAs), OLAs, standards, and regulatory
requirements will be implemented on an ongoing basis to ensure stability, conformance, and performance
monitoring. These assessments will be reviewed and either accepted or rejected depending on the criteria defined
within the governance framework.
Dispensation
A Compliance Assessment can be rejected where the subject area (design, operational, service level, or
technology) are not compliant. In this case the subject area can:
1. Be adjusted or realigned in order to meet the compliance requirements
2. Request a dispensation
Where a Compliance Assessment is rejected, an alternate route to meeting interim conformance is provided
through dispensations. These are granted for a given time period and set of identified service and operational
criteria that must be enforced during the lifespan of the dispensation. Dispensations are not granted indefinitely, but
are used as a mechanism to ensure that service levels and operational levels are met while providing a level of
flexibility in their implementation and timing. The time-bound nature of dispensations ensures that they are a major
trigger in the compliance cycle.
Monitoring and Reporting
Performance management is required to ensure that both the operational and service elements are managed
against an agreed set of criteria. This will include monitoring against SLAs and OLAs, feedback for adjustment, and
reporting.
58
Internal management information will be considered in Environment Management.
Business Control
Business Control relates to the processes invoked to ensure compliance with the organization’s business policies.
Environment Management
This identifies all the services required to ensure that the repository-based environment underpinning the
governance framework is effective and efficient. This includes the physical and logical repository management,
access, communication, training, and accreditation of all users.
All architecture artifacts, service agreements, contracts, and supporting information must come under governance
through a formal process in order to register, validate, ratify, manage, and publish new or updated content. These
processes will ensure the orderly integration with existing governance content such that all relevant parties,
documents, contracts, and supporting information are managed and audited.
The governance environment will have a number of administrative processes defined in order to effect a managed
service and process environment. These processes will include user management, internal SLAs (defined in order
to control its own processes), and management information reporting.
Organisation Structure
59
Architecture Governance Benefits

 Links IT processes, resources, and information to organisational strategies and objectives
 Integrates and institutionalises IT best practices
 Aligns with industry frameworks such as COBIT (planning and organising, acquiring and implementing,
delivering and supporting, and monitoring IT performance)
 Enables the organisation to take full advantage of its information, infrastructure, and hardware and software
assets
 Protects the underlying digital assets of the organisation
 Supports regulatory and best practice requirements such as auditability, security, responsibility, and
accountability
 Promotes visible risk management
Key Success Factors

Best practices for the submission, adoption, reuse, reporting and retirement of architecture policies, procedures,
roles, skills, organisational structures and support services.
Organisational responsibilities and structures to support the architecture governance processes and reporting
requirements.
Integration of tools and processes to facilitate the take-up of the processes, both procedurally and culturally.
Criteria for control of the architecture governance processes, dispensations, compliance assessments, SLAs, and
OLAs.
Internal and external requirements for the effectiveness, efficiency, confidentiality, integrity, availability, compliance,
and reliability of all architecture governance-related information, services and processes.
Need for Architecture Board

 Oversees implementation of Enterprise Architecture governance strategy
 Should represent all key stakeholders in architecture, therefore…
 Should be cross-organisational
 Board comprised of:
 Local (domain experts, line responsibility)
 Global (organisation-wide responsibility)
 Each board will have established…
 Responsibilities and decision-making capabilities
 Remit and authority limits
60
Architecture Board Responsibilities

 Consistency between sub-architectures
 Identifying reusable components
 Flexibility of Enterprise Architecture:
o To meet changing business needs
o To capitalise on new technologies
 Enforcement of Architecture Compliance
 Improving the maturity level of architecture discipline within the organisation
 Ensuring that the discipline of architecture-based development is adopted
 Providing the basis for all decision-making with regard to changes to the architectures
 Supporting a visible escalation capability for out-of-bounds decisions
Setting Up an Architecture Board

Likely triggers are:
 New CIO
 Merger or acquisition
 Consideration of a move to newer forms of computing
 Recognition that IT is poorly aligned to business
 Desire to achieve competitive advantage via technology
 Creation of an Enterprise Architecture program
 Significant business change or rapid growth
 Requirement for complex, cross-functional solutions
Likely size:
 4 – 10 depending on size and complexity of organisation
 Other related bodies include Design Authorities and Working Parties
Operation of the AB – Board Meetings

 Supporting the production of quality governance material and activities
 Providing a mechanism for formal acceptance through consensus and authorised publication
 Providing a fundamental control mechanism for ensuring effective implementation of the architectures
 Establishing and maintaining the link between architecture and strategy of the business
 Identifying divergence from the contract and planning activities to realign with the contract through
dispensations or policy upgrades
61
Architecture Contracts
 Are formal agreements between
o Architecture Design and Development Partners (who could be internal or external)
o Architecting Function and Business Users
 A contract is a Governance Control that can be used to establish responsibility and test compliance
 Can be used to ensure:
o A system of continuous monitoring
o Adherence to the principles, standards, and requirements
o Identification of risks
o A set of processes and practices that ensure accountability, responsibility and discipline related to
architecture artifacts
o A formal understanding of the governance organisation, its authority and scope of architecture
Need for Architecture Compliance

To ensure compliance of individual projects with the Enterprise Architecture:
 The Architecture function prepares the project architectures
 The IT Governance Function will define a formal Compliance Review process
Architecture Compliance – Definitions
62
Purpose of Compliance Reviews

• First and foremost, catch errors in the project architecture early, and thereby reduce the cost and risk of
changes required later in the lifecycle. This in turn means that the overall project time is shortened, and
that the business gets the bottom-line benefit of the architecture development faster.
• Ensure the application of best practices to architecture work
• Provide overview of compliance to a mandated enterprise standard
• Identify where the standards themselves may require modification
• Identify services currently application-specific that could be provided as part of the enterprise infrastructure
• Document strategies for collaboration, resource sharing, and other synergies across multiple architecture
teams
• Take advantage of technology advances
• Communicate to management the technical readiness of the project
• Identify key criteria for procurement activities (e.g. for inclusion in Commercial Off-The-Shelf (COTS)
product RFI/RFP documents)
• Identify and communicate significant architectural gaps to product and service providers
Compliance Review Process
63
Architecture Governance and Capability

Governance is part of the Architecture Practice that can be represented as a “system” with the following
architectures:
 Business Architecture (processes, organisation, etc.)
 Data Architecture (repository/continuum)
 Application Architecture (functionality)
 Technology Architecture (platform support)
Business Architecture of the architecture practice that will highlight the architecture governance, architecture
processes, architecture organisational structure, architecture information requirements, architecture products, etc.
Data Architecture that would define the structure of the organisation’s Enterprise Continuum and Architecture
Repository.
Application Architecture specifying the functionality and/or applications services required to enable the architecture
practice.
Technology Architecture that depicts the architecture practice’s infrastructure requirements and deployment in
support of the architecture applications and Enterprise Continuum.
Summary
Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures
are managed and controlled at an enterprise-wide level.
TOGAF provides guidance on aspects of Architecture Governance in the Architecture Capability Framework.
The Governance Board plays a critical role, especially at the operational level.
64
Business Scenarios
Session Objectives
 Defining and describing the Business Scenario technique
 Developing and validating Business Scenarios
Overview
A technique to validate, elaborate and/or change “the premise behind an architecture effort”
Conducted principally in the following phases:
 Preliminary (as part of the establishment of an Architecture Practice)

 Phase A (to understand key drivers and requirements)
 Phase B (further understand business needs)
 Other phases if necessary
Its purpose is to gather information such as:
 Real business problems

 The business and technology environment in which those problems occur
 Value chains enabled by capabilities
 The desired outcome(s) of proper execution
 The human and computing components (the “actors”) who provide the capabilities
There is now a free-standing Series Guide on Business Scenarios in the TOGAF ® Library.
65
The Business Scenario Process
General Guidelines
The stakeholders (e.g. business managers, end users) will tell you what they want, but as an architect you must still
gain an understanding of the business, so you must know the most important actors in the system. If the
stakeholders do not know what they want:
• Take time, observe, and record how they are working today
• Structure information in such a way that it can be used later
• Uncover critical business rules from domain experts
• Stay focused on what needs to be accomplished, and how it is to be accomplished
This effort provides the anchor for a chain of reason from business requirements through to technical solutions. It
will pay off later to be diligent and critical at the start.
Goals
One of the first steps in the development of an architecture is to define the overall goals and objectives for the
development. The objectives should be derived from the business goals of the organisation, and the way in which
IT is seen to contribute to meeting those goals.
Every organisation behaves differently in this respect, some seeing IT as the driving force for the enterprise and
others seeing IT in a supporting role, simply automating the business processes which already exist. The essential
thing is that the architectural objectives should be very closely aligned with the business goals and objectives of the
organisation.
Summary
A technique to validate, elaborate and/or change “the premise behind an architecture effort”.
66
Architecture Views and Viewpoints

Session Objectives
 Define and explain the terms Stakeholder, Concern, View and Viewpoint
 Creating Views
The purpose of this module is to help understand the concepts of views and viewpoints, and their role in
communicating with stakeholders as well as applying them to the Architecture Development Cycle. Also how to
apply the Stakeholder Management technique using Stakeholder Maps.
Overview
Views and Viewpoints are the crucial elements that determine how you represent Architecture.
ISO 42010:2011
67
 System is a collection of components organised to accomplish a specific function or set of functions

 Stakeholders are individuals, teams, or organisations who have key roles in, or concerns about, the
system; for example, as users, developers, or managers. Different stakeholders with different roles in the
system will have different concerns
 Concerns are the key interests that are crucially important to the stakeholders in the system, and determine
its acceptability. Concerns may pertain to any aspect of the system’s functioning, development, or
operation, including considerations such as performance, reliability, security, distribution and evolution
capability
 View is a representation of a whole system from the perspective of a related set of concerns – “what you
actually see”
 Viewpoint defines the perspective from which a view is taken – “what you want to see” – a template lists
interested stakeholders, their concerns, and an indication of how the view can be represented
Example Viewpoint and View
68
Creating Views
 Excellent guidance available in ISO/IEC 42010: 2007, formerly ANSI/IEEE 1471 – 2000 (although neither is
mandated)
o Refer to existing Viewpoint Library (the TOGAF® Framework defines 66 “Artifacts”)
o Select Architecture Viewpoint based on stakeholder’s concerns
o Generate views
 Develop new Viewpoints only when necessary
 OR develop new views, then retro-fit it to a Viewpoint!
 A View MUST have a Viewpoint
Summary
Views and Viewpoints are the crucial elements that determine how you represent Architecture.
69
Stakeholder Management
Session Objectives
 Define and explain the terms Stakeholder and Concerns
 Creating Views and their benefits
 Stakeholder Maps
The purpose of this module is to help understand the concepts of views and viewpoints, and their role in
communicating with stakeholders as well as applying them to the Architecture Development Cycle. Also how to
apply the Stakeholder Management technique using Stakeholder Maps.
Overview
Stakeholders have concerns about architecture that can be addressed by these Views and Viewpoints.
A critical part of being an Architect is to manage Stakeholders:
 Early identification of the most powerful stakeholders means their input can help shape the architecture,
and attract their support
 Support from powerful stakeholders can help win more resource thus increasing the chance of success
 Early and frequent communication with stakeholders ensures full understanding of the benefits, and can
lead to greater support
 Full awareness of stakeholders can help architects anticipate their reaction to the architecture. Action can
then be taken to capitalise on positive reaction, and avoid negative reaction
Stakeholders are initially identified in Phase A; however others will become apparent as the ADM process
continues.
Tailoring the views of the architecture to address the concerns of these stakeholders is what it’s all about!
Identifying Stakeholders
Investigate who will become a stakeholder and once identified, consider:
 Who gains and who loses from this change?
 Who controls change management of processes?
 Who designs new systems?
 Who will make the decisions?
 Who procures IT systems and who decides what to buy?
 Who controls resources?
 Who has specialist skills the project needs?
 Who has influence?
70
Stakeholder Categories
Stakeholder Power Grid
71
Creating Views
 Excellent guidance available in ISO/IEC 42010: 2007, formerly ANSI/IEEE 1471 – 2000 (although neither is
mandated)
o Refer to existing Viewpoint Library (the TOGAF® Framework defines 66 “Artifacts”)
o Select Architecture Viewpoint based on stakeholder’s concerns
o Generate views
 Develop new Viewpoints only when necessary
 OR develop new views, then retro-fit it to a Viewpoint!
 A View MUST have a Viewpoint
Stakeholder Map
Summary
Stakeholders have concerns about architecture that can be addressed by these Views and Viewpoints.
72
Building Blocks
Session Objectives
 What is a Building Block and what makes a good one?
 Architecture and Solution Building Blocks
 Using Building Blocks with the ADM
 Architecture Patterns
The purpose of this module is to help understand the concept of Building Blocks within TOGAF.
Overview
 A Building Block is a package of functionality defined to meet the business needs across an organisation
 A Building Block usually has a type that corresponds to the enterprise’s content Metamodel (such as actor,
business service, application, or data entity)
 A Building Block has a defined boundary and is generally recognisable as "a thing" by domain experts
 A Building Block may interoperate with other, interdependent Building Blocks
 A good Building Block has the following characteristics:
o It considers implementation and usage, and evolves to exploit technology and standards
o It may be assembled from other Building Blocks
o It may be a subassembly of other Building Blocks
o Ideally a Building Block is reusable and replaceable, and well specified
The way in which assets and capabilities are assembled into Building Blocks will vary widely between individual
architectures. Every organisation must decide for itself what arrangement of Building Blocks works best for it.
Architecture Building Blocks

Characteristics
 Capture architecture requirements, e.g. business, data, application and technology requirements
 Direct and guide the development of SBBs
Specification content
 Fundamental functionality and attributes: semantic, unambiguous, including security, capability and
manageability
 Interfaces: chosen set, supplied
 Interoperability and relationship with other Building Blocks
 Dependent Building Blocks with required functionality and named user interfaces
 Map to business/organisational entities and policies
73
Solution Building Blocks

Characteristics
 Define what products and components will implement the functionality
 Define the implementation
 Fulfil business requirements
 Are product- or vendor-aware
Specification Content
 Specific functionality and attributes
 Interfaces
 Required SBBs used with required functionality and names of the interfaces used
 Mapping from the SBBs to the IT topology and operational policies
 Specifications of attributes shared across the environment (not to be confused with functionality) such as
security, manageability, localisability, scalability
 Performance, configurability
 Design drivers and constraints, including the physical architecture
 Relationships between SBBs and ABBs
Building Blocks and the ADM
74
Patterns
 A pattern is a technique for putting Building Blocks into context; for example, to describe a reusable
solution to a problem. Building Blocks are what you use: patterns can tell you how you use them, when,
why, and what trade-offs you have to make in doing so
 A pattern is ‘‘an idea that has been useful in one practical context and will probably be useful in others’’
[Analysis Patterns—Reusable Object Models]
 Used to describe the context of how BBs could be used, i.e. “an e-commerce system”
 Architecture Pattern: fundamental organisation of a software system
 Design Pattern: describes the commonly recurring structure of communicating components
 Idiom: low-level pattern specific to programming language
An excellent reference source on this…

http://www.ibm.com/Search/?q=patterns&v=16&en=utf&lang=en&cc=zz&Search=Search
Summary
We have discovered that:
 The concept of Building Blocks is central to the approach recommended for designing a system
architecture
 A Building Block is a package of functionality
 Comparing Baseline and Target Building Blocks allows identification of the gaps in architecture
 Architecture BBs are used to describe concepts and logic. Solution BBs describe physical solutions
 The way in which Building Blocks are assembled will vary widely between individual architectures. Every
organisation must decide for itself what arrangement of Building Blocks works best for it
75
Phase A – Architecture Vision

Session Objectives
This module focuses on the Architecture Vision Phase’s
 Objectives
 Approach
 Main inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Architecture Vision Phase contributes to the success of
Phase Objectives
 Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of
the proposed Enterprise Architecture
 Obtain approval for a Statement of Architecture Work that defines a program of works to develop and
deploy the architecture outlined in the Architecture Vision
Approach
 Creating the Architecture Vision
Creating an Architecture Vision

 Provides a first-cut, high-level description of the Baseline and Target Architectures. Used to establish a
consensus with the sponsoring organisation
 Effort is needed to understand/clarify the context. A business assessment will help with this, possibly using
Business Scenarios
 Covers “BDAT” domains and potentially others if appropriate, such as Security, Information, Digital,
Services, Network Management
 Fundamental business concepts should also be examined, including:
o Business Capabilities
o Value Streams
o Organisation Maps
 Integral to the Architecture Vision is an understanding of emerging technologies and their potential impact
on industries and enterprises, without which many business opportunities may be missed
76
Inputs
Reference Materials External to the Enterprise
 Architecture Reference Material
Non-architectural
 Request for Architecture Work
 Business principles, goals, drivers
Architectural
o Scope of organisations impacted
o Maturity assessment, gaps, and resolution approach
o Roles and responsibilities for architecture team(s)
o Constraints on architecture work
o Reuse requirements
o Budget requirements
o Requests for change
o Governance and support strategy
 Tailored Architecture Framework (including tailored method, deliverables,
principles and tools)
 Populated Architecture Repository
Consists of existing architectural documentation:
 Framework description
 Architectural descriptions
 Baseline descriptions
 Architectural Building Blocks
 Solution Building Blocks
77
Steps
1. Establish the architecture project
2. Identify stakeholders’ concerns and requirements
3. Confirm and elaborate business goals, business drivers and constraints
4. Evaluate business capabilities
5. Assess readiness for business transformation
6. Define scope
7. Confirm and elaborate architecture principles, including business principles
8. Develop Architecture Vision
9. Define the Target Architecture KPIs
10. Identify Business Transformation Risks and mitigation activities
11. Develop Enterprise Architecture plans and Statement of Architecture Work;
secure approval
Step Summary
1. Establish the project
Enterprise Architecture is a business capability; each cycle of the ADM should normally be handled as a project
using the project management framework of the enterprise. Architecture activity should be planned and managed
using accepted practices for the enterprise.
2. Identify stakeholders’ concerns, and business requirements
See future slide.
3. Confirm and elaborate business goals
Identify goals, drivers. If none exist go back to stakeholder and get them. Also gather information on constraints.
4. Evaluate capabilities
This includes a wide range of capabilities, as well as the ability of the enterprise to develop the Enterprise
Architecture itself.
5. Assess readiness
See future slide.
6. Define scope
Breadth or coverage, level of detail, partitioning characteristics, specific domains to be covered, time period,
existing architecture assets.
7. Confirm and elaborate principles
A process started in the preliminary phase.
8. Develop Architecture Vision
Create high-level view of baseline and target architecture. Business scenario useful for doing this. Should establish
scope. Policy development and strategic decisions need to be captured in this phase to enable the subsequent
work to be quantified; for example, rationalisation decisions and metrics, revenue generation, and targets which
meet the business strategy.
9. Define the Target Architecture Value Propositions and KPIs
78
Develop a business case, produce review and agree value proposition for each stakeholder, define procurement
requirements, assess business risk.
10. Identify Business Transformation Risks
See future slide.
11. Develop Enterprise Architecture Plans and SOW
Establish performance metrics for required work. Then identify new work products, provide direction, identify
impact, determine level of detail, consider resources and build roadmap, build a communications plan, review and
get agreement for plan.
Stakeholders – Concerns and Requirements

Here we need to identify:
1. Candidate vision components and requirements

2. Candidate scope boundaries
3. Stakeholder concerns, issues and cultural factors
4. *The concerns and viewpoints that are relevant to this project
5. *The stakeholders that are involved with the project
6. *The key roles and responsibilities within the project
*These items can be identified in a Stakeholder Matrix, see “Stakeholder Management”.
79
Business Transformation Readiness

Is the business (especially the people) ready for the new system? This assessment is
based on understanding a series of readiness factors.
Initiated in Phase A, kept under review during Definition Phases and then used in
Phases E/F.
The process involves:
 Determining the readiness factors
 Presenting them using Maturity Models
 Rating those readiness factors
 Relating them to risk, and considering mitigation
 Blending these in during Phases E/F
Suggested Readiness Factors

 Vision  Accountability
 Need  Workable Approach and
 Desire, Willingness, and Execution Model
Resolve  IT Capacity to Execute
 Business Case  Enterprise Capacity to
 Funding Execute
 Sponsorship and  Enterprise Ability to

Leadership Implement and Operate
 Governance
80
Sample Readiness Factor Scorecard
Risk Management
Initiated in Phase A, reviewed during definition and critical to the Planning Phases E/F
Full Process involves:
 Identifying risk
 Assessing Initial Risk, considering
o Effects – Catastrophic, Critical, Marginal, Negligible
o Frequency – Frequent, Likely, Occasional, Seldom, Unlikely
o End risk – Extremely High (E), High (H), Moderate (M), Low (L)
 Risk Mitigation and Residual Risk Assessment
 Risk Monitoring
81
Risk Impact Classification Scheme
82
Outputs
 Approved Statement of Architecture Work defines scope and approach used to
complete an architecture development cycle. The SOW is typically the document
against which successful execution of the architecture project will be measured and
may form the basis for a contractual agreement between the supplier and consumer
of architecture services
 Refined statements of business principles, business goals,
and business drivers
 Architecture principles
 Capability assessment – of the Enterprise, IT Function, Architecture Function; what
gaps exist
 Tailored Architecture Framework
 Architecture Vision to provide key stakeholders with a formally agreed outcome
 Draft Architecture Definition Document including:
o Baseline Business Architecture (v0.1) o Target Business Architecture (v0.1)
o Baseline Data Architecture (v0.1) o Target Data Architecture (v0.1)
o Baseline Application Architecture (v0.1) o Target Application Architecture (v0.1)
o Baseline Technology Architecture (v0.1) o Target Technology Architecture (v0.1)
 Communications Plan – effective communication of targeted information to the right stakeholders at the
right time is a Critical Success Factor (CSF) for Enterprise Architecture. Developing a Communications
Plan for architecture allows this communication to be carried out within a planned and managed
process
 Additional content populating the Architecture Repository
May include some or all of the following artifacts:
Matrices Diagrams
 Stakeholder Map Matrix  Business Model Diagram
 Business Capability Map
 Value Stream Map
 Value Chain Diagram
 Solution Concept Diagram
83
Capability-based Planning
 Capability-based Planning focuses on Business Outcomes and the delivery of strategic business
capabilities to the Enterprise
 Increase focus on shared capabilities
 Capabilities are concerned with:
o Skills
o Resources
o Training and
o Maturity-measured capability/processes
 The Business Scenario can be used to discover and refine these capabilities
Capabilities
84
Capability-based Planning
 Relationship Between Capabilities, Enterprise Architecture, and Projects
Interoperability
The ability to share information and services:
 Phase A: the nature and security considerations of the information and service exchanges are first revealed
within the business scenarios
 Phase B: the information and service exchanges are further defined in business terms
 Phase C – Data: the content of the information exchanges are detailed using the corporate data and/or
information exchange model
 Phase C – Applications: the way that the various applications are to share the information and services is
specified
 Phase D: the appropriate technical mechanisms to permit the information and service exchanges are
specified
 Phase E: the actual solutions (e.g. Commercial Off-The-Shelf (COTS) packages) are selected
 Phase F: the interoperability is logically implemented
Reconciling Interoperability Requirements

 The Enterprise Architect ensures there are no interoperability conflicts, especially if reusing existing SBBs
and/or COTS
 The most significant issue is business interoperability. Most SBBs or COTS have their own business
processes embedded. Changing them often requires so much work that the advantages of reuse is lost.
There are numerous examples of this in the past
 There is the workflow aspect between the various systems that has to be taken into account. The
Enterprise Architect will have to ensure that any change to the business interoperability requirements is
signed off by the Business Architects and architecture sponsors in a revised Statement of Architecture
Work
85
Security
Ensure sufficient security-specific design is carried out to:
 Satisfy the security stakeholders that the end-state does not represent any unknown or unacceptable risk
and aligns with corporate policies, standards, and principles
 Satisfy business stakeholders – in particular those who control the budget – that the Security Architecture
is instrumental in enabling and supporting the overall architecture required to deliver the business
opportunities and benefits identified with the right balance between risk, compliance, and business benefits
Summary
The Architecture Vision phase is about project establishment and initiates an iteration of the architecture
development cycle, setting the scope, constraints, and expectations for the iteration. It is required in order to
validate the business context and to create the approved Statement of Architecture Work.
86
Phase B – Business Architecture

Session Objectives
This module focuses on the Business Architecture Phase’s
 Objectives
 Approach
 Main inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Business Architecture Phase contributes to the success
of Enterprise Architecture.
Phase Objectives
 Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve
the business goals, and respond to the strategic drivers set out in the Architecture Vision, in a way that
addresses the Statement of Architecture Work and stakeholder concerns
 Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target
Business Architectures
Approach
 General – pre-req for other domains, demonstrate business value, utilise existing business strategies or
create new ones, Business Scenarios useful (now a free-standing guide), scope determined by architecture
vision
 Developing the Baseline Description – may have been used in Phase A. If no descriptions exist a baseline
model should be developed
 Applying Business Capabilities – utilise business capability maps developed in Vision; other heat maps
based on maturity, effectiveness, performance, value
 Applying Value Streams – base on Vision; map value streams to capabilities
 Applying the Organisation Map – show how business units map to capabilities and value streams
 Applying Modelling Techniques – Activities, Use Cases, Class models; used to expand models mentioned
above
 Architecture Repository – Industry Reference Models (see OMG, TmF), Enterprise-specific Business
Architecture views, Enterprise-specific Building Blocks, standards
Business Architecture is a representation of holistic, multi-dimensional business views of capabilities, end-to-end
value delivery, information, and organisational structure; and the relationships among these business views and
strategies, products, policies, initiatives, and stakeholders.
Business Architecture relates business elements to business goals and elements of other domains.
87
Inputs
 Architecture Reference Material
Non-Architectural
 Business principles, goals, drivers
 Capability Assessment
 Communications Plan
Architectural
 Approved Statement of Architectural Work
 Architecture Principles
 Enterprise Continuum
 Architecture Repository
 Architecture Vision
 Draft Architecture Definition Document
Business Principles, Goals, Drivers

Contextual Business Information – goals, strategy, drivers
Business Principles:
 Primacy of Principles
 Maximise Benefit to the Enterprise
 Information Management is Everybody's Business
 Business Continuity
 Common Use Applications
 Service-orientation
 Compliance with Law
 IT Responsibility
 Protection of Intellectual Property
88
Steps
1. Select reference models, viewpoints, and tools
2. Develop Baseline Business Architecture Description
3. Develop Target Business Architecture Description
4. Perform Gap Analysis
5. Define Candidate Roadmap Components
6. Resolve impacts across the Architecture Landscape
7. Conduct formal stakeholder review
8. Finalise the Business Architecture
9. Create Architecture Definition Document
The level of detail addressed in Phase B will depend on the scope and goals of the
overall architecture effort.
New models characterising the needs of the business will need to be defined in
detail during Phase B. Existing business artifacts to be carried over and supported
in the target environment may already have been adequately defined in previous
architectural work, but, if not, they too will need to be defined in Phase B.
Step Summary
Business modelling and strategy assessments are effective techniques for framing the target state. Identify
Services, Business Building Blocks, Matrices, Diagrams, Requirements
See future slides.
2. Develop Baseline Architecture Description
See future slides.
3. Develop Target Architecture Description
Repeat step 2, this time focusing on the Target Architecture.
See future slides.
This is built up during the definition period. It is initially a general estimate on timing, but which can be used later
when formulating detailed implementation plans during Phase E (and then F).
Impacts could be on pre-existing architecture and/or other projects.
Critical to keep stakeholders fully up to speed.
8. Finalise the Architecture
This includes selecting standards, documenting Building Blocks, cross-checking architecture against business
goals and requirement (traceability), map with the Architecture Repository, finalise all work products.
See future slides.
89
Modelling Techniques
Business Capability Mapping: identifies, categorises, and decomposes the business
capabilities required for the business to be able to deliver value to one or more
stakeholders.
Organisation Mapping: a representation of the organisational structure of the business
(including third-party domains), depicting business units, the decomposition of those units
into lower-level functions, and organisational relationships (unit-to-unit and mapping to
business capabilities, locations, and other attributes).
Value Stream Mapping: the breakdown of activities that an organisation performs to create
the value being exchanged with stakeholders. Value stream maps illustrate how an
organisation delivers value and are in the context of a specific set of stakeholders, and
leverage business capabilities in order to create stakeholder value and align to other
aspects of the Target Business Architecture.
Structured Analysis: identifies the key business functions within the scope of the
architecture, and maps those functions onto the organisational units within the business.
Use Case Analysis: the breakdown of business-level functions across actors and
organisations allows the actors in a function to be identified and permits a breakdown into
services supporting/delivering that functional capability.
Process Modelling: the breakdown of a function or business service through process
modelling allows the elements of the process to be identified, and permits the identification
of lower-level business services or functions.
Business Modelling Examples

BPMN
90
UML
ArchiMate®
91
Gap Analysis
Technique compares Baseline and Target Building Blocks. Suggested gap types are:
 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
 Technologies impacted, eliminated or created
Gap Analysis Matrix
The matrix diagram is a slight adaptation of the framework example. The Building Blocks used here are based on
the TRM Network Services definitions.
92
Building Blocks
Building Blocks are packages of functionality
Suggested Building Blocks at the Business level (based on Content Metamodel) are:
 Organisations
 Actors
 Drivers, Goals and Objectives
 Roles
 Business Services
 Business Functions
 Locations
 Processes/Events/Controls/Products
 Contracts and measures
Outputs
 Refined and updated versions of the Architecture Vision phase
deliverables, where applicable, including:
o Statement of Architecture Work; Validated context;
Principles
 Draft Architecture Definition Document, including:
o Baseline Architecture
o Target Architecture including:
 Organisation Structure, Business – Goals,
Functions, Services, Processes, Roles, Data
Model, Organisation/Function correlation
 Draft Architecture Requirements Specification, including:
o Gap Analysis Results, Technical Requirements, updated
Business Requirements
 Business Architecture components of an Architecture Roadmap
Catalogues Matrices Diagrams
 Value Stream  Value Stream/Capability  Business Model

 Business Capabilities  Strategy/Capability  Business Capability Map
 Value Stream Stages  Capability/Organisation  Value Stream Map
 Organisation/Actor  Business Interaction  Organisation Map
 Actor/Role  Business Footprint
 Driver/Goal/Objective
 Role  Business
Service/Information
 Business Service/Function
 Functional Decomposition
 Location
 Product Lifecycle Diagram
 Process/Event/Control/
Product  Goal/Objective/Service
 Contract/Measure  Business Use Case
 Organisation
Decomposition
93
Phase B Security Considerations

The security elements of Phase B: Business Architecture comprise business-level trust, risk, and controls,
independent from specific IT or other systems within the specific scope of the architecture engagement:
 Security Policy Architecture
 Security Domain Model
 Trust Framework
 Risk Assessment
 Business Risk Model/Risk Register
 Applicable Law and Regulation Register
 Applicable Control Framework Register
Extract from TOGAF® Series Guide: Integrating Risk and Security within a TOGAF® Enterprise Architecture
5.3.1 Security Policy Architecture
Location in the Architecture Framework: Enterprise Security Architecture: ISM.
The Security Policy Architecture (or Framework) contains a set of security policies that express the security
strategy. It assigns ownership and accountability for security and risk management. It also addresses the linkage
and hierarchy of operational risk management in general with the various security aspects such as business
continuity, information security, system security, and physical security.
5.3.2 Security Domain Model
Location in the Architecture Framework: TOGAF 9.1 §A.40 (Information Domain). Complete text: “Grouping of
information (or data entities) by a set of criteria such as security classification, ownership, location, etc. In the
context of security, information domains are defined as a set of users, their information objects, and a security
policy.”
Note: The concept of information domain corresponds with the definition of a security domain below. A security
domain represents a set of assets that could be described by a similar set of business attributes. In other words,
the security domain groups the assets with the same security level that fall under the jurisdiction of one security
policy. In addition, the security domain model helps in defining responsibility areas where responsibility is
exchanged with external parties. It can also be used to distinguish between areas of different security or trust
levels. A security policy authority is responsible for setting and implementing the security policy within the domain.
If the business model of the organisation does encompass federation with other organisations, the extent of the
security federation should be established at this point in the process. This is the case when organisations have
data objects or activities in common. Contractual federation agreements should be examined for their security
implications and agreements. It may be necessary to establish joint architecture meetings with other members of a
federation if they belong to the same security domain.
5.3.3 Trust Framework
Trust relationships are the basis for doing business with other parties. The trust framework describes trust
relationships between various entities in the architecture domain and on what basis this trust exists. Trust
relationships can be unidirectional, bidirectional, or non-existent. The onus for assessing trust is the responsibility
of those choosing to enter into the contracts and their legal counsel. It is important to note that technology (e.g.
digital certificates) cannot create trust, but can only convey in the electronic world the trust that already exists in the
real world through business relationships, legal agreements, and security policy consistencies.
5.3.4 Risk Assessment
Although TOGAF 9.1 §31.4 (Initial Risk Assessment) describes one method of administrating the result of a risk
assessment, the actual act of assessing risk and the ways to do that are not described. Therefore, this concept is
augmented by this document for use with the TOGAF 9.1 standard.
A risk assessment is the activity of determining the risks that are relevant to an asset or objective. A qualitative risk
assessment delivers a listing of relevant risk scenarios with a high-level prioritisation (high-medium-low), whereas a
94
quantitative approach seeks for numeric determination of the risk. This is commonly based on identified threats,
their likelihood of materialising, and the impact of an incident. A deliverable of a risk assessment is the Business
Risk Model.
5.3.5 Business Risk Model/Risk Register
The Business Risk Model is a Risk Register. It determines the cost (both qualitative and quantitative) of asset
loss/impact in failure cases. It is the result of a risk assessment, based on identified threats, likelihood of
materialising, and impact of an incident. Business impact should be aligned with the definitions in the Business
Attribute Profile, which act as pseudo-assets. Security classification should be carried out at this stage based on
the risks identified. The business risk model is a detailing of the risk strategy of an organisation. The classification
of the information determines the maximum risk the business is willing to accept, and the owner of the information
decides what mitigation is enough for his/her information.
5.3.6 Applicable Law and Regulation Register
The Applicable Law and Regulation Register contains the specific laws and regulations that apply within the scope
of the Enterprise Architecture engagement, based on the business function inventory. It is kept up-to-date,
following legal and regulatory changes. This register is important for compliance purposes.
Whether the business function is subject to regulation depends upon the functionality of the system as a whole and
the data collected or maintained. In addition, the jurisdiction where the supporting systems or services are
deployed, where the users reside, etc. is relevant information. It may be wise to obtain legal counsel regarding
these obligations at the outset of activities.
5.3.7 Applicable Control Framework Register
The Applicable Control Framework Register contains the suitable set of control frameworks that best satisfy the
requirements and address the risks related to the engagement scope and context. Control frameworks contain
requirements and/or mandatory security measures. Examples of control frameworks are ISO/IEC 27001:2013 [4],
ISO/IEC 27002:2013 [5], COBIT [10], PCI-DSS, Common Criteria, etc.
Factors that drive the selection of control frameworks are:
• Mandatory certifications, due to the nature of the business process or the industry
• Way of working of the internal ISM process – this is often inspired by ISO/IEC 27001:2013 but might
mandate additional control frameworks as well
• Marketing objectives – customers may ask for specific control framework certifications
• Support for security audits
Summary
Business Architecture documents the fundamental organisation of a business, embodied in its business processes
and people, their relationships to each other and the environment, and the principles governing its design and
evolution.
It should show how the organisation meets its business goals.
95
Phase C – Information Systems Architecture

Session Objectives
This module focuses on the Information Systems Architecture Phase’s
 Objectives
 Approach
 Steps
 Inputs
 Outputs
The purpose of this module is to help understand how the Information Systems Architecture Phase contributes to
the success of Enterprise Architecture.
Phase Objectives
The purpose of this composite phase is to:
 Develop the Target Information Systems (Data and Application) Architecture, describing how the
enterprise’s Information Systems Architecture will enable the Business Architecture and the Architecture
Vision, in a way that addresses the Request for Architecture Work and stakeholder concerns
Information Systems (Data and Application) Architectures
Approach
To develop the Data and/or Applications Architectures in either order.
Although advocates exist for a:
 Data-driven approach, such as Steven Spewak’s Enterprise Architecture Planning
 Application-driven approach, when introducing a new Package (particularly one of major importance such
as an ERP Application), it is sometimes preferred to focus on the implementation and integration issues
first
Detailed descriptions for Phase C are given separately for each architecture domain:
 Phase C: Information Systems Architectures — Data Architecture
 Phase C: Information Systems Architectures — Application Architecture
Assets residing in the repository should be considered:
Data Application
 ARTS (retail)  TeleManagement Forum
 Energistics (energy industry) (telecomms)
 OMG software models, and MDA
(Model-driven Architecture)
96
Inputs, Outputs and Steps

Inputs/Outputs will be dealt with in the detailed sections that follow.
Steps are:
 Develop the Data Architecture
 Develop the Application Architecture
Security
The security elements of Phase C: Information Systems Architectures comprise functional security services and
their security classification. The artifacts are:
 Security Services Catalogue
 Security Classification
 Data Quality
5.4.1 Security Services Catalogue
Note: The TOGAF standard has a Business Services Catalogue that is a list of the enterprise's business services
and their functional and non-functional requirements. It is used to analyse the functional and non-functional
requirements. The Security Services Catalogue stores and provides more kinds of information about each service,
so this needs to be introduced.
The Security Services catalogue is a list of services that provide security-specific functionality as part of the overall
architecture. Unlike control frameworks that contain requirements, the Security Services catalogue describes
security Building Blocks that actually realise the security goals. It provides a common terminology and reference
framework for the domain of security management. The Security Services catalogue contains conceptual
definitions of the services, as well as operational information about implementation and usage.
Examples of security services are:
• Identity & Access Management
• Continuity Management
• Security Intelligence
• Digital Forensics
• Security Analytics
• Audit, Network Monitoring
• Compliance Management
• Training & Awareness Programs, etc.
This is the area of security that most security practitioners will recognise. One of the main advantages of the
Security Services catalogue is that it is a common terminology and reference framework for the domain of security
management allowing better cooperation between the parties concerned.
5.4.2 Security Classification
Security classification is a label attached to an asset, according to a classification scheme. In most cases, this
scheme is defined and described in the corporate information security policy and the classification is based on one
or more characteristics of the asset.
97
Keep in mind that the asset can be any relevant component of the architecture. Assets include business service, a
capability, information, an information system service, physical data component, or physical technology
component. The security classification determines the security requirements that apply to the asset; for example,
regarding access control, confidentiality, or availability. It is a means to implement the security policy.
5.4.3 Data Quality
Note: From an Enterprise Security Architecture perspective, data quality requirements are an integral part of the
security requirements and so are the related risk assessment and selection of measures.
Data quality is a key factor in operational risk management. Some of the key attributes that contribute to data
quality are accuracy, relevance, timeliness, currency, completeness, consistency, availability, and accessibility.
Safeguarding data quality starts with a clear overview on the datasets in question. For each dataset, ownership and
responsibility for the quality of data needs to be assigned. The owner authorises people or processes that are
trusted for a certain activity on the data under certain circumstances. It might also be necessary to change
information systems in order to handle the data properly. Finally, each of the key attributes should be measured
based on log and performance data.
Summary
The purpose of this composite phase is to:
 Define the types and sources of data needed to support the business, and do so in a way that can be
understood by stakeholders
 Define the kinds of application systems necessary to process the data, and what they do to support the
business
98
Phase C – Data Architecture

Session Objectives
This module focuses on the Data Architecture Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Data Architecture Phase contributes to the success of
Phase Objectives
 Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision,
while addressing the Statement of Architecture Work and stakeholder concerns
 Identify candidate Architecture Roadmap components based upon gaps between the Baseline and
Target Data Architectures
Approach
Key considerations are:
 Data Management
 Data Migration
 Data Governance
Data Management
 Definition of which application components in the landscape will serve as the system of record/reference for
enterprise master data
 Will there be an enterprise-wide standard that all application components, including software packages,
need to adopt (in the main packages can be prescriptive about the data models and may not be flexible)?
 Understand how data entities are utilised by business functions, processes and services – data
dissemination
 Understand how and where enterprise data entities are created, stored, transported, and reported
 Level and complexity of data transformations required to support the information exchange needs between
applications?
 Requirement for software in supporting data integration with the enterprise’s customers and suppliers (e.g.
use of ETL tools during the data migration, data profiling tools to evaluate data quality, etc.)?
99
Data Migration
When migrating data:
 Identify affected data items
 Consider how much transformation, weeding and cleansing may be required
 Ensure an enterprise-wide common data definition is established
Data Governance
The key areas are:
 Structure and standards within the organisation to manage data
 Management Systems and data-related programmes that govern data throughout its lifecycle
 People, in the form of appropriately skilled Data Architects and formal data roles
Inputs
 Architecture Reference Material
Non-architectural
Architectural
 Data Principles
 Statement of Architectural Work
 Draft Architecture Requirement Specification
Business Architecture Components of an Architecture Roadmap
Data Principles
 Data is an asset
 Data is shared
 Data is accessible
 Data trustee
 Common vocabulary and data definitions
 Data security
100
Steps
2. Develop Baseline Data Architecture description
3. Develop Target Data Architecture description
5. Define candidate roadmap components
8. Finalise the Data Architecture
Step Summary
See future slides.
Bearing in mind the scope and level or detail, identify baseline Data Building Blocks.
Repeat Step 2 focusing on the Target Architecture Building Blocks.
Using the Gap Analysis technique, identify gaps between Baseline and Target.
See future slides.
101
Selecting Reference Models

Modelling techniques: Entity Relationship Diagrams, Class Diagrams.
Data Models: Energistics – Data Exchange Standards for the Upstream Oil & Gas
Industry; National Information Exchange Model (US Government); The ARTS
Operational Data Model and the ARTS Data Warehouse Model (Retail)
Modelling process includes:
 Collect data-related models from existing Business Architecture and
Application Architecture materials
 Rationalise data requirements and align with any existing enterprise data
catalogues and models; this allows the development of a data inventory and
entity relationship
 Update and develop matrices across the architecture by relating data to
business service, business function, access rights, and application
 Elaborate Data Architecture views by examining how data is created,
distributed, migrated, secured, and archived
Outputs
 Refined and updated Statement of Architecture Work and
Principles
 Draft Architecture Definition Document, containing:
o Baseline Data Architecture
o Target Data Architecture
o Data Architecture views of key stakeholder concerns
o Gap Analysis results
o Data interoperability requirements
o Relevant technical requirements
o Constraints on the Technology Architecture
o Updated business (and application) requirements
 Data Architecture components of an Architecture Roadmap
 Data Entity/Data Component  Data Entity/Business Function  Conceptual Data

 Application/Data  Logical Data
 Data Dissemination
 Data Security
 Data Migration
 Data Lifecycle
102
Data Architecture in the ADD

 Baseline Data Architecture, Version 1.0, if appropriate
 Target Data Architecture, Version 1.0
o Business data model
o Logical data model
o Data management process models
o Data Entity/Business Function matrix
o Views corresponding to the selected viewpoints addressing key stakeholder concerns
Data Architecture in the ARS

 Gap Analysis results
 Data interoperability requirements
 Relevant technical requirements that will apply to this evolution of the architecture development cycle
 Constraints on the Technology Architecture about to be designed
 Updated business requirements, if appropriate
 Updated application requirements, if appropriate
Summary
The Data Architecture phase defines the types and sources of data needed to support the business, and does so in
a way that can be understood by stakeholders.
103
Phase C – Application Architecture

Session Objectives
This module focuses on the Application Architecture Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Application Architecture Phase contributes to the
success of Enterprise Architecture.
should be changed so the “Approach” is now the final item in the Framework itself.
Phase Objectives
 Develop the Target Application Architecture that enables the Business Architecture and the Architecture
Vision, while addressing the Statement of Architecture Work and stakeholder concerns
Application Architectures
Approach
Application Repository
 TeleManagement Forum (telecomms), which includes:
o TeleManagement Forum – a set of application models in Telecomms sector (TAM)
 OMG software models, and MDA (Model-driven Architecture)
 IT4IT, a detailed application architecture reference model for the IT Segment of organisations
 Integrated Information Infrastructure Reference Model (III-RM), now a Series Guide in the TOGAF® Library
104
Inputs
Non-architectural
Architectural
 Application Principles
 Business and Data Architecture Components of an Architecture Roadmap
Application Principles
 Technology Independence
 Ease-of-Use
Steps
1. Select reference models, viewpoints, and tools.

2. Develop Baseline Application Architecture Description.
3. Develop Target Application Architecture Description.
4. Perform Gap Analysis.
5. Define candidate roadmap components.
6. Resolve impacts across the Architecture Landscape.
7. Conduct formal stakeholder review.
8. Finalise the Application Architecture.
9. Create Architecture Definition Document.
105
Step Summary
See future slides.
Bearing in mind the scope and level or detail, identify baseline Application Building Blocks.
See future slides.
106
Selecting Reference Models, Viewpoints and Tools

 Check external sources such as TmF, OMG, Application Vendors
 Consider the following process:
o Understand the list of applications or application components that are
required
o Simplify complicated applications by decomposing them into two or more
applications
o Ensure that the set of application definitions is internally consistent, by
removing duplicate
o Functionality as far as possible, and combining similar applications into
one
o Identify logical applications and the most appropriate physical
applications
o Develop matrices across the architecture
o Elaborate a set of Application Architecture views by examining how the
application will function
107
Outputs
Principles
 Draft Architecture Definition Document, containing:
o Baseline Application Architecture
o Target Application Architecture
o Application Architecture views of key stakeholder
concerns
o Application interoperability requirements
o Constraints on the Technology Architecture
o Updated business and data requirements
 Application Architecture components of an Architecture
Roadmap
 Application Portfolio  Application/Organisation  Application Communication

 Interface  Role/Application  Application and User
 Application/Function Location
 Application Interaction  Application Use-Case

 Enterprise Manageability
 Process/Application
Realisation
 Software Engineering
 Application Migration
 Software Distribution
108
Application Architecture in the ADD

 Baseline Application Architecture, Version 1.0, if appropriate
 Target Application Architecture, Version 1.0
o Process systems model
o Place systems model
o Time systems model
o People systems model
Application Architecture in the ARS

 Applications interoperability requirements
 Relevant technical requirements that will apply to this evolution of the architecture development cycle
 Constraints on the Technology Architecture about to be designed
 Updated business requirements, if appropriate
 Updated data requirements, if appropriate
Summary
In this section we have looked at how to develop a Target Application Architecture that enables the Business
Architecture and the Architecture Vision, while addressing the Request for Architecture Work and stakeholder
concerns.
109
Phase D – Technology Architecture (and TRM/III-RM)

Session Objectives
This module focuses on the Technology Architecture Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
This module also includes an examination of the TRM and III-RM.

The purpose of this module is to help understand how the Technology Architecture Phase contributes to the
Phase Objectives
 Develop the Target Technology Architecture that enables the logical and physical application and data
components and the Architecture Vision, addressing the Statement of Architecture Work and stakeholder
concerns
Technology Architectures
Approach
 Emerging Technologies
 Evolution of Technology, a major driver for change
 Digital innovations must be embraced
 Solution development methods are evolving
 ADM flexibility allows technology change to become a strategic resource. Thus Technology
Architecture may drive business capabilities and simultaneously respond to Information System
requirements
 Using the Architecture Repository consider:
 Existing IT services as documented in the IT repository or IT service catalogue
 Technical Reference Model (TRM) (now a Series Guide in TOGAF ® Library)
 Generic technology models relevant to the organisation’s industry “vertical” sector
 Technology models relevant to Common Systems Architectures
110
Inputs
 Product information on candidate products
Non-architectural
Architectural
 Technology Principles
 Business, Data and Application Architecture
 Components of an Architecture Roadmap
Technology Principles
 Requirements-based Change
 Responsive Change Management
 Control Technical Diversity
 Interoperability
111
Steps
1. Select reference models, viewpoints, and tools.

2. Develop Baseline Technology Architecture Description.
3. Develop Target Technology Architecture Description.
4. Perform Gap Analysis.
5. Define Candidate Roadmap Components.
6. Resolve impacts across the Architecture Landscape.
7. Conduct formal stakeholder review.
8. Finalise the Technology Architecture.
9. Create Architecture Definition Document.
Step Summary
See future slides.
Bearing in mind the scope and level or detail, identify baseline Technology Building Blocks.
See future slides.
112
Outputs

Principles
o Baseline Technology Architecture (detailed), if appropriate
o Target Technology Architecture (detailed)
 Views corresponding to selected viewpoints addressing key

stakeholder concerns
 Draft Architecture Requirements Specification
 Technology Architecture components of an Architecture Roadmap


 Technology Standards  Application/Technology  Environments and Locations
 Technology Portfolio  Platform Decomposition
 Processing
 Networked
Computing/Hardware
 Network and Communications
113
Technology Architecture in the ADD

 Technology Components and their relationships to information systems
 Technology platforms and their decomposition, showing the combinations of technology required to realise
a particular technology “stack”
 Environments and locations – a grouping of the required technology into computing environments
(e.g. development, production)
 Expected processing load and distribution of load across technology components
 Physical (network) communications
 Hardware and network specifications
Technology Architecture in the ARS

 Requirements output from Phases B and C
 Updated technology requirements
Security
In most cases, the development of specific Technology Architecture security artifacts is not necessary, as long as it
incorporates the relevant security controls and mechanisms defined in earlier phases. The Security Architect must
ensure that the required controls are included in the Technology Architecture and verify whether the controls are
used in an effective and efficient way. This includes the technology for the provision and regulation of system
resources, such as electric power, processing capacity, network bandwidth, and memory.
Summary
Develop the Target Technology Architecture that enables the logical and physical application and data components
and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns.
114
Technical Reference Model – TRM

Overview
 Describes a Foundation Architecture – an architecture of generic services and functions on which more
specific architectures or components can be built. Consists of:
o A taxonomy
o The TRM Graphic
 At its highest level, two qualities are emphasised (that in combination enable better integration within and
between enterprises):
o Application Portability, via the Application Platform Interface – identifying the set of services that
are to be made available in a standard way to applications via the platform
o Interoperability, via the Communications Infrastructure Interface – identifying the set of
Communications Infrastructure services that are to be leveraged in a standard way by the platform
o Both of these goals are essential to enable integration within the enterprise and trusted
interoperability on a global scale between enterprises
TRM Views
Main Categories
 Application Software
o Business Applications (customer facing, “front office”)
o Infrastructure Applications (utilities, usually COTS-based, i.e. transfers services, mail clients,
groupware, “office packages”, software engineering)
 Application Platform Interface promotes application portability especially for those sharing a programmatic
interface, protocol and data structure
 Application Platform a single generic concept of a platform providing all possible services to the software.
Particularly provides support to Infrastructure Software
 Communications Infrastructure Interface
 Communications Infrastructure provides the basic services to interconnect systems and provide the basic
mechanisms for the opaque transfer of data
 Qualities such as manageability, security and general non-functional based performance
115
Application Platform Service Categories

 Graphics and Imaging
 Data Management
 Data Interchange
 User Interface
 International Operation
 Location and Directory
 Transaction Processing
 Security
 Software Engineering
 System and Network Management
Application Platform Service Qualities

 Availability
o Manageability
o Serviceability
o Performance
o Reliability
o Recoverability
o Locatability
 Assurance
o Security
o Integrity
o Credibility
 Usability
o International Operation
 Adaptability
o Interoperability
o Scalability
o Portability
o Extensibility
Tailoring the TRM

 TRM based on TAFIM (Technical Architecture Framework for Information Management, which originated in
the 80s), but updated to emphasise interoperability and portability
 However other models could be used:
o Legacy models
o Alternative models derived from the TRM but with suitable variations in categories
 The TRM graphic could also be adjusted
 Each “box” within the TRM could be regarded as representing [foundation] “Building Blocks”. Each BB
should comply/conform with standards
116
Integrated Information Infrastructure Reference

Model – III-RM
Boundaryless Information Flow
 “Getting information to the right people at the right time in a secure, reliable manner”. Those people could
be inside or outside the organisation (extended enterprise)
 Boundaryless doesn’t necessarily mean “no boundaries” – more that any boundaries should be
“permeable”
 “Permeability” is achieved by
o Integrated Information
o Integrated access to information
 Solution – an “Integrated Information Infrastructure”
III-RM High Level Structure

The III-RM is a subset of the TOGAF TRM in terms of its overall scope, but it also expands certain parts of the TRM
– in particular, the business applications and infrastructure applications parts – in order to provide help in
addressing one of the key challenges facing the enterprise architect today: the need to design an integrated
information infrastructure to enable Boundaryless Information Flow.
117
III-RM High-level Structure
Components
 Business Applications
o Information Provider Applications – that are connected to the data or servers
o Information Consumer Applications – that deliver content to the user
o Brokering Applications – that manage link between requestor (consumer) and responder (provider)
 Infrastructure Applications
o Development Tools to model, design and construct the apps above
o Management Utilities to understand, operate, tune and manage run-time systems
 Application Platform supply supporting services (see TRM)
 Interfaces: APIs, formats, protocols
 Qualities: see TRM
118
III-RM Detailed Structure
Summary
Develop the Target Technology Architecture that enables the logical and physical application and data components
and the Architecture Vision, addressing the Request for Architecture Work and stakeholder concerns.
We have also looked at the TRM and III-RM. Together they look at the concept of a Foundation Architecture,
and the way Applications communicate with each other.
119
Phase E – Opportunities and Solutions

Session Objectives
This module focuses on the Opportunity and Solutions Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Opportunity and Solution Phase contributes to the
Phase Objectives
 Generate the initial complete version of the Architecture Roadmap, based upon the Gap Analysis and
candidate Architecture Roadmap components from Phases B, C, and D
 Determine whether an incremental approach is required, and if so identify Transition Architectures that will
deliver continuous business value
 Define the overall solution Building Blocks to finalise the Target Architecture based on the Architecture
Building Blocks (ABBs)
Approach
Based on the gaps identified in previous phases, and a review of requirements, readiness and constraints, consider
how to develop the target architecture by documenting:
 An architecture listing individual work packages in a timeline that will realise the Target Architecture
 Work packages identifying logical groups of changes necessary to realise the Target Architecture
 A Transition Architecture describing the enterprise at an architecturally significant state between the
Baseline and Target Architectures. Transition Architectures provide interim Target Architectures upon
which the organisation can converge
 An Implementation and Migration Plan providing a schedule of the projects that will realise the Target
Architecture
The Architecture Roadmap will also refer to all stakeholders that have contributed requirements.
Phase E concentrates on how to deliver the architecture. It takes into account the complete set of gaps between
the Target and Baseline Architectures in all architecture domains, and logically groups changes into work packages
within the enterprise’s portfolios. This is an effort to build a best-fit roadmap that is based upon the stakeholder
requirements, the enterprise’s business transformation readiness, identified opportunities and solutions, and
identified implementation constraints. The key is to focus on the final target while realizing incremental business
value.
120
Inputs

 Product Information
Non-architectural
 Planning Methodologies
Architectural
 Governance Model
 Change Requests for existing business programs and projects
 Candidate Architecture Roadmap components from Phases B, C, and D
Steps
1. Determine/confirm key corporate change attributes.

2. Determine business constraints for implementation.
3. Review and consolidate Gap Analysis (from Phases B-D).
4. Review consolidated requirements across functions.
5. Consolidate and reconcile interoperability requirements.
6. Refine and validate dependencies.
7. Confirm readiness and risk for business transformation.
8. Formulate high-level Implementation and Migration Strategy.
9. Identify and group major work packages.
10. Identify Transition Architectures.
11. Create Architecture Roadmap and Implementation/Migration Plan.
121
Step Summary
1. Determine/Confirm key corporate change attributes
Use Implementation Factor Assessment and Deduction matrix to assess change.
2. Determine business constraints for implementation
Constraints include drivers, plans, and a review of Enterprise Architecture Maturity.
3. Review and consolidate Gap Analysis results from Phases B to D
See future slide.
4. Review IT requirements from a functional perspective
Look to rationalise and simplify Functional Requirements with a view to providing shared services.
5. Consolidate and reconcile interoperability requirements
Interoperability considerations are initiated in Phase A. Pay particular attention to Business Process
interoperability, where differences in process can sometimes run counter to principles such as reuse.
6. Refine and validate dependencies
This includes Business, Information, Workflow, IT and Foundation dependencies.
7. Confirm readiness and risk for business transformation
Return to the Business Transformation Readiness and Risk Assessment techniques initiated in Phase A.
8. Formulate high-level Implementation and Migration Strategy
See future slide.
9. Identify and group major work packages
See future slide.
10. Identify Transition Architectures
See future slide.
11. Create Architecture Roadmap and Implementation/Migration Plan
A project/portfolio charter consists of capabilities delivered, included work packages, business value, RAID (risk,
assumptions, issues, dependencies) – i.e. outcomes delivered, their value and risk. From this create the transition
architecture and update overall architecture. The narrower the scope, the more definitive the list of targeted
capabilities should be.
122
Determine and Confirm Key Corporate Change Attributes
 How the EA can best be implemented to take advantage of business culture

 Use the Implementation Factor Assessment and Deduction Matrix:
Review and Consolidate Gap Analysis
Using the Consolidated Gaps, Solutions and Dependencies Matrix:
123
Implementation and Migration Strategy

 Overall strategic approach could be:
o Greenfield start from the beginning
o Revolutionary radical, big-bang, re-engineer
o Evolutionary convergence strategy needed, phased, process
improvement
 Implementation Approach could include:
o Quick Win
o Achievable Target
o Value Chain Method
Identify and Group Work Packages
 The need is to organise the Work Packages to account for:

o Strategic implementation direction and approach, as outlined in the
Implementation Factor Assessment and Deduction matrix
o Dependencies, as outlined in the Consolidated Gaps, Solutions and
Dependencies matrix. Consider each gap, and decide on moving
towards:
 New Development
 Reuse or purchase
 The resulting work packages could be grouped as
o Mainstream Systems
o Contain Systems (replaceable within three years)
o Replace Systems (replaceable shortly)
124
Transition Architectures
Use the Architecture Definition Increments Table:
Outputs
 Statement of Architecture Work, updated if necessary
 Architecture Vision, updated if necessary
 Draft Architecture Definition Document, including content updates for:
o Transition Architecture, number and scope, if any
 Draft Architecture Requirements Specification, updated if necessary
 Capability Assessment, including content updates for:
o Business and IT Capability
 Architecture Roadmap, including
o Work Package Portfolio
o Identification of Transition Architectures, if any
o Implementation recommendations
 Outline Implementation and Migration Plan and strategy
 May include some or all of the following artifacts:
o Project Context Diagram
o Benefits Diagram
125
Security
Ensure the stakeholders’ security and risk concerns are addressed in the analysis.
Confirm that risk owners are consulted. The value expected to be delivered by work packages should include
measures related to security and risk value to ensure the roadmap addresses the complete set of business goals
and drivers.
The security Building Blocks defined in the previous phases become SBBs in this phase so that more specific
implementation-oriented requirements and specifications are defined. A whole solution design might be needed at
this stage.
The Security Services Catalogue of the Baseline Security Architecture probably contains existing security services
or security Building Blocks that meet the requirements.
The efficacy of existing security services and controls earmarked for reuse must be verified to ensure that the end-
state contains security measures, which work and integrate well.
Note: In TOGAF 9.1, risk mitigation is done for transition risks, but it is not explained how this should be created
or what possible risk mitigation strategies there are, so this Guide provides additional guidance about this issue.
The Risk Mitigation Plan contains activities to mitigate risks. It is the implementation of the risk mitigation strategy
which could aim to increase the level of control, transfer the risk to another party, avoid the risk by changing the
business activity, delay the risk, compensate for the risk, etc.
The broader sense of risk is addressed by the ERM process in this phase. The scope includes the latest
information security risks as identified during the risk assessments that are done earlier in the ADM (in Phase B).
This is where the risks get “solutioned” or “treated”. The Risk Mitigation Plan should also consider risks that appear
as a result of the new architecture.
Summary
Generate the initial complete version of the Architecture Roadmap, based upon the Gap Analysis and candidate
Architecture Roadmap components from Phases B, C, and D.
126
Phase F – Migration Planning

Session Objectives
This module focuses on the Migration Planning Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Migration Planning Phase contributes to the success of
Phase Objectives
 Finalise the Architecture Roadmap and the supporting Implementation and Migration Plan
 Ensure that the Implementation and Migration Plan is coordinated with the enterprise's approach to
managing and implementing change in the enterprise's overall change portfolio
 Ensure that the business value and cost of work packages and Transition Architectures is understood by
key stakeholders
Approach
 This is the place where detailed planning is needed, particularly focusing on:
o Dependencies
o Costs and Benefits
o Risks
 This will inevitably require coordination with management activities such as:
o Project
o Programme
Phase E provides an incomplete Architecture Roadmap and Implementation and Migration Plan that address the
Statement of Architecture Work. In Phase F this Roadmap and the Implementation and Migration Plan are
integrated with the enterprise’s other change activity.
127
Inputs

Non-architectural
Architectural
 Governance Model
 Change Requests for existing business programs and projects
 Architecture Roadmap
Steps
1. Confirm management framework interactions for the Implementation and

Migration Plan
2. Assign a business value to each work package
3. Estimate resource requirements, project timings, and availability/delivery vehicle
4. Prioritise the migration projects through the conduct of a cost/benefit assessment
and risk validation
5. Confirm Architecture Roadmap and update Architecture Definition Document
6. Complete Implementation and Migration Plan
7. Complete development cycle and document lessons learnt
128
Step Summary
1. Confirm management framework interactions for Implementation and Migration Plan
See future slide.
2. Assign a business value to each project
See future slide.
3. Estimate resource requirements, project timings, and availability/delivery vehicle
Resources/Costs include people, office/IT infrastructure, training, operations, and maintenance. Project timings
should take account of each SBB timing (set in step 5 of phases B-D). Delivery vehicle could be provided internally,
externally by contract, or a mixture.
4. Prioritise the migration projects through the conduct of a cost/benefit assessment and risk validation
See future slide.
5. Confirm Architecture Roadmap and update Architecture Definition Document
See future slide.
6. Complete Implementation and Migration Plan
Confirm Enterprise Architecture evolution and state; create the detailed Implementation and Migration plan.
7. Complete development cycle and document lessons learnt
Lessons learnt will be used in connection with influencing Architecture Capability.
Management Framework Interaction

The key frameworks where interaction may be required are:
 Business Planning (including Business Transformation)
 Enterprise Architecture (and IT planning)
 Portfolio/Project Management
 Operations Management
129
Business Value
 Consider criteria for establishing business value:
o Performance Evaluation Criteria used to approve and monitor progress of
architecture transformation
o Return on Investment
o Business Value
o Critical Success Factors
o Measures of effectiveness which can be expressed as performance criteria
o Strategic fit based on overall Enterprise Architecture
 Use Business Value Assessment Technique
o Create a value-index (compliance to principles, value as above) and a risk
index (size, complexity, technology, organisational capacity and impact of
failure). Then perform a Business Value and Risk Assessment...
Business Value Assessment Technique
130
Prioritise Migration Projects
1. Derive Cost Benefit Analysis for the Migration Projects

2. Validate the Risk Assessment (the Consolidated Gaps, Solutions and
Dependencies Report can be used here)
3. Prioritise the Projects. Examples that could affect priorities are:
o Costs
o Risks
4. Ensure stakeholders agree on prioritisation
Confirm Architecture Roadmap
1. Confirm Transition Architecture Time-Spans

2. Take into account Business Value, Capability, Risk
3. Then consolidate deliverables to create a revised Architecture Roadmap
131
State Evolution Table
 This technique looks at the evolution of the Solution Building Blocks, mapped to
the TRM
 Use in conjunction with Architecture Definition Increments Table
Outputs
 Implementation and Migration Plan (detailed) including
o Implementation and Migration Strategy
o Project and Portfolio Breakdown
o Project Charters (optional)
 Finalised Architecture Definition Document and Transition Architectures if any (see
Deliverables for detailed headings of document)
 Finalised Architecture Requirements Specification
 Finalised Architecture RoadmapReusable Architecture Building Blocks
 Requests for Architecture Work for the architecture aspects of implementation
projects (if any)
 Implementation Governance Model
 Change Requests for Architecture Capability arising from lessons learnt
There are no artifacts included in these outputs.
132
Implementation and Migration Plan

Typical contents are...
 Implementation and Migration Strategy
 Project and Portfolio breakdown:
o Capabilities delivered by projects
o Included work packages
o Business value
o Risk, issues, assumptions, dependencies
Project charters:
o Related work packages
o Business value
o Risk, issues, assumptions, dependencies
o Resource requirements and costs
o Benefits of migration
o Estimated costs of migration options
Security
 Migration is itself a business process that needs to be secured. The migration strategy should include a risk
assessment and a Risk Mitigation Plan
 In Phase F, the Risk Mitigation Plan is limited to the transition. These concepts have already been
mentioned in earlier phases of the ADM. Migration of live environments should always include regression
planning so that there is a way to reverse out a failed migration. This is an essential part of risk
management
 In addition, migration planning should include a security impact analysis to understand any security impacts
of the target state of the change
5.8.1 Security Audit
Security audit includes security reviews of implemented processes, technical designs, developed code, and
configurations against policies and requirements. It also includes security testing, comprising functional security
testing, performance testing, and penetration testing.
5.8.2 Security Training and Awareness
Security training and awareness means that sufficient training is provided to ensure correct deployment,
configuration, and operations of security-relevant subsystems and components, including awareness training of all
users and non-privileged operators of the system and/or its components. It is critical for a proper, continuous, and
secure performance.
In many control frameworks, security training must be followed and results documented to demonstrate due
diligence. Substantiated corrective actions or sanctions are needed in cases where exploits or errors compromise
security objectives.
133
Summary
The Migration Planning Phase addresses migration planning; that is, how to move from the Baseline to the Target
Architectures. It includes creating the finalised Architecture Definition Document and the detailed Implementation
and Migration Plan. After completion of this phase the preparation for implementation has been completed.
134
Phase G – Implementation Governance

Session Objectives
This module focuses on the Implementation Governance Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Implementation Governance Phase contributes to the
Phase Objectives
 Ensure conformance with the Target Architecture by implementation projects
 Perform appropriate Architecture Governance functions for the solution and any implementation-driven
architecture Change Requests
Approach
This is where the plans have to be put into action – an Implementation Programme is likely to involve transitions,
each delivering their own benefits. The overall approach includes:
 Delivery of Transition Architectures
 Business priorities
 Organisational standards
 Existing Programme or Project Management approach
 Operational considerations
A vital link between implementing organisation and architecture is established through an overall Architecture
Contract. Project details are recorded:
 Name, description, and objectives
 Scope, deliverables, and constraints
 Measures of effectiveness
 Acceptance criteria
 Risks and issues
Ensuring compliance with defined architecture(s) by both implementation projects and other ongoing projects.
135
Inputs

Non-architectural
Architectural
 Architecture Definition Document
 Architecture Requirement Specification
 Architecture Contract
 Implementation and Migration Plan
Steps
1. Confirm scope and priorities for deployment with development management
2. Identify deployment resources and skills
3. Guide development of solutions deployment
4. Perform Enterprise Architecture compliance reviews
5. Implement business and IT operations
6. Perform post-implementation review and close the implementation and Migration
Plan
136
Step Summary
1. Confirm scope and priorities for deployment with development management
Review migration planning outputs and produce deployment recommendations, identify Enterprise Architecture
priorities, recommend on deployment issues, identify BBs for replacement/update, etc., identify gaps in Enterprise
Solution Framework (current enterprise SBBs) and specific BBs that fill those gaps, produce Gap Analysis report.
2. Identify deployment resources and skills
Consider system development methods (i.e. developers, languages used), ensure development feedback can be
given to the architects.
3. Guide development of solutions deployment
Formulate project recommendations, document Architecture Contract, update repository, guide development of
business and IT Operating models, derive service requirements, guide definitions of business and IT operational
requirements, do Gap Analysis between Solution Architecture and operations, produce implementation plan.
4. Perform Enterprise Architecture compliance reviews
See Governance chapter.
5. Implement business and IT operations
Carry out deployment projects such as IT or Business Service Delivery implementation; communications document
publication.
6. Perform post-implementation review and close the implementation
Closure takes place when solutions are fully deployed once.
Tailoring a Compliance Review

 Focus on:
o High risk areas
o Expected (and emergent) differentiators
 For each question in the checklist, understand:
o The question itself
o The principle behind it
o What to look for in the responses
 Ask subject experts for their views
 Fix the checklist questions for your use
 Bear in mind the need for feedback to the Architecture Board
Conducting a Compliance Review

 Understand the objectives
 Deal with side issues later
 Make precise objectives
 Ask “open” questions
 To avoid “hidden agendas”, depersonalise approach to discussions
 Be respectful – if the reviewees have messed up, they may also have done their best
 Make the review a learning exercise
 Reviews should include detailed assessment activities against the architectures and should ensure that the
results are stored in the Enterprise Continuum
137
Outputs
 Architecture Contract (signed)

 Compliance Assessments
 Change Requests
 Architecture-compliant solutions deployed, including:
o The architecture-compliant implemented system
o Populated Architecture Repository
o Architecture compliance recommendations and dispensations
o Recommendations on service delivery requirements
o Recommendations on performance metrics
o Service Level Agreements (SLAs)
o Architecture Vision, updated post-implementation
o Architecture Definition Document, updated post-implementation
o Business and IT operating models for the implemented solution
Architecture Contract Contents

 Statement of Architecture Work
 Contract between Architecture Design and  Contract between Architecting Function and
Development Partners Business Users
o Introduction and background o Introduction and background
o The nature of the agreement o The nature of the agreement
o Scope of the architecture o Scope
o Architecture and strategic principles and o Strategic requirements
requirements o Architecture deliverables that meet the
o Conformance requirements business requirements
o Architecture development and management o Conformance requirements
process and roles o Architecture adopters
o Target architecture measures o Time window
o Defined phases of deliverables o Architecture business metrics
o Prioritised joint work plan o Service architecture (includes Service
o Time window(s) Level Agreement (SLA))
o Architecture delivery and business metrics
Relationship of AC to Architecture Governance

To ensure effectiveness of these contracts, the following governance aspects may need to be introduced:
 Simple processes
 People-centred authority
 Strong communication
 Timely responses and an effective escalation process
 Supporting organisational structures
 Status tracking of architecture implementation
138
Security
 Establish architecture artifact, design, and code reviews and define acceptance criteria for the successful
implementation of the findings
 Implement methods and procedures to review evidence produced by the system that reflects operational
stability and adherence to security policies
 Implement necessary training to ensure correct deployment, configuration, and operations of security-
relevant subsystems and components; ensure awareness training of all users and non-privileged operators
of the system and/or its components
 Determine “what has gone wrong?”
5.8.1 Security Audit
Security audit includes security reviews of implemented processes, technical designs, developed code, and
configurations against policies and requirements. It also includes security testing, comprising functional security
testing, performance testing, and penetration testing.
5.8.2 Security Training and Awareness
Security training and awareness means that sufficient training is provided to ensure correct deployment,
configuration, and operations of security-relevant subsystems and components, including awareness training of all
users and non-privileged operators of the system and/or its components. It is critical for a proper, continuous, and
secure performance.
In many control frameworks, security training must be followed and results documented to demonstrate due
diligence. Substantiated corrective actions or sanctions are needed in cases where exploits or errors compromise
security objectives.
Risk Monitoring
 The residual risk has to be accepted and approved
 Mitigation measures need to be monitored
 Sometimes risks can be identified in this phase that require another partial or full circuit of the ADM
Sample Risk Identification and Mitigation Worksheet
Summary
The Implementation Governance Phase defines architecture constraints on the implementation projects and
obtains signatures on an Architecture Contract. The contract, along with all the documentation, is then delivered to
the implementation team. This phase includes governing the architecture through implementation by conducting
compliance reviews, and by risk monitoring as well as post-implementation reviews.
139
Phase H – Change Management

Session Objectives
This module focuses on the Change Management Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The purpose of this module is to help understand how the Change Management Phase contributes to the success
of Enterprise Architecture.
Phase Objectives
 Ensure that the architecture lifecycle is maintained
 Ensure that the Architecture Governance Framework is executed
 Ensure that the Enterprise Architecture Capability meets current requirements
Change Management Approach (1)

Consider drivers for change that can be:
 Strategic (top-down) architecture to enhance or create new capability
 Bottom-up to correct or enhance current infrastructure
 Changes to previously delivered projects (now operational) that are related to ongoing projects
 Requests for Change (RFCs) handled by Architecture Board. RFCs could be:
o Technology-based: new technology, asset management cost reductions, technology withdrawal,
change in standards
o Business-based: “BaU” developments, exceptions, innovations, business technology innovations,
strategic change

Consider Enterprise Architecture Change Management Process, often handled by existing frameworks such as
ITIL, PRINCE2. Change can be about:
 Simplification change: A simplification change can normally be handled via change management
techniques
 Incremental change: An incremental change may be capable of being handled via change management
techniques, or it may require partial re-architecting, depending on the nature of the change
 Re-architecting change: A re-architecting change requires putting the whole architecture through the
architecture development cycle again
140

Consider Guidelines for Maintenance versus Re-design. A good rule-of-thumb is:
 If the change impacts two stakeholders or more, then it is likely to require an architecture redesign and re-
entry to the ADM
 If the change impacts only one stakeholder, then it is more likely to be a candidate for change management
 If the change can be allowed under a dispensation, then it is more likely to be a candidate for change
management
For example:
 Re-architecting – If the impact is significant for the business strategy, then there may be a need to redo the
whole enterprise
 Incremental Change – If new technology or standards emerge, then there may be a need to refresh the
Technology Architecture, but not the whole Enterprise Architecture
 Change management techniques – If the change is at an infrastructure level – for example, ten systems
reduced or changed to one system – this may not change the architecture above the physical layer, but it
will change the Baseline Description of the Technology Architecture. This would be a simplification change
handled via change management techniques
Inputs
Non-architectural
Architectural
 Organisation Model
 Statement of Architecture Work
 Architecture Definition Document
 Architecture Requirements Specification
 Change Requests (technology change, business change, lessons learnt)
 Architecture Contract
 Compliance Assessments
 Implementation and Migration Plan
141
Change Requests
 Changes can arise because:
o During implementation circumstances may give rise to deviation from plan, or a change in the
scope
o At any time, changes (i.e. business, technology) may require revision of architecture
 A Change Request would typically contain:
o Description of the proposed change
o Rationale for the proposed change
o Impact assessment of the proposed change, including:
 Reference to specific requirements
 Stakeholder priority of the requirements to date
 Phases to be revisited
 Phase to lead on requirements prioritisation
 Results of phase investigations and revised priorities
 Recommendations on management of requirements
o Repository reference number
Steps
1. Establish Value Realisation process
2. Deploy Monitoring Tools
3. Manage Risks
4. Provide Analysis for Architecture Change Management
5. Develop Change Requirements to meet Performance Targets
6. Manage Governance Process
7. Activate the process to implement change
142
Step Summary
1. Establish Value Realisation process
Exploit Enterprise Architecture in order to realise value (benefit/outcome) to the business.
2. Deploy Monitoring Tools
Monitor business, technology, on-going business value, architecture capability maturity, asset management
programs, QoS, business continuity.
3. Manage Risks
Use risk assessment to provide recommendations for IT strategy.
4. Provide Analysis for Architecture Change Management
Analyse and review performance – especially with Service Management, assess change requests to ensure value
is realised and service level expectation met, identify gaps in performance of Enterprise Architecture, ensure
change management requests adhere to architecture governance.
5. Develop Change Requirements to meet Performance Targets
From the above, make recommendations on change requirements.
6. Manage Governance Process
Arrange and then hold Governance Board meetings to discuss changes and dispensations, and make decisions.
7. Activate the process to implement change
Produce a new Request for Architecture Work; capture implemented changes and document in architecture
repository.
Typical Board Meeting Agenda

 Minutes of Previous Meeting
 Requests for Change
 Dispensations
 Compliance Assessments
 Dispute Resolution
 Architecture Strategy and Direction Documentation
 Actions Assigned
 Contract Documentation Management
 Any Other Business (AOB)
 Schedule of meetings
Outputs
 Architecture updates
 Changes to architecture framework and principles
 New Request for Architecture Work, to initiate another cycle of the ADM in
response to change
 Statement of Architecture Work, updated if necessary
 Architecture Contract, updated if necessary
 Compliance Assessments, updated if necessary
143
Security
Phase H does not produce tangible security outputs but defines two processes essential for continued alignment
between the business requirements and the architecture: risk management and architecture governance. Even
though they are not formal artifacts, they are added here to emphasise their importance.
 ERM is the process in which the existing architecture is continuously evaluated regarding changes to
business opportunity and security threat. Based on the results of this process, the current architecture
might deem it unsuitable to mitigate changed or new risks, or it might constrain the business too much in
exploiting new opportunities. In that case, a decision on architecture change must be made
 Architecture governance is the process in which decisions are made on changes to the existing
architecture, either by minor changes in the current iteration or by means of a completely new iteration.
This is explained in the TOGAF® Architecture Governance Framework (TOGAF 9.1 §50.2). Changes
related to risk and security should be an explicit part of that framework. Large changes to the architecture
should include a security impact analysis.
Summary
The Change Management Phase ensures that changes to the architecture are managed in a cohesive and
controlled manner in line with the Architecture Governance processes.
It also establishes and supports the Enterprise Architecture to provide flexibility to evolve the architecture rapidly in
response to changes in the technology or business environment.
144
Architecture Requirements Management

Session Objectives
This module focuses on the Requirements Management Phase’s
 Objectives
 Approach
 Inputs
 Steps
 Outputs
The order of the five objectives is significant (and this will be repeated in all the subsequent phases). From an
exam perspective, “Objectives” and “Approach” relate to the Foundation (Level 1) exam and are therefore dealt
with together as a unit. An awareness of the remaining three items is assumed for the Certified (Level 2) exam. In
the version 9.1 document this order of items was used. But for version 9.2, it was felt by the Architecture Forum
that order of items should be changed so the “Approach” is now the final item.
Phase Objectives
 Ensure that the Requirements Management process is sustained and operates for all relevant ADM
phases. Crucial to this process is the recording of all requirements, impact analysis of changed
requirements, and adjustment of any gaps
 Manage architecture requirements identified during any execution of the ADM cycle or a phase
 Ensure that relevant architecture requirements are available for use by each phase as the phase is
executed
Approach
 Generally, the ADM must be able to respond to the dynamic environment
 At all phases of architecture requirements must be considered, as well as constraints, principles, policies
and standards
 Useful resources
o Business Scenarios
o Requirements tools (see volere.co.uk/tools.htm)
145
Inputs
Reference Materials External to the Enterprise.
Non-architectural.
Architectural:
 Architecture Requirements
 Requirements Impact Statement
Steps – Phase/Requirements Management Related
1. Identify/Document requirements.
2. Baseline requirements – determine priorities, confirm stakeholder buy-in, record
priorities.
3. Monitor baseline requirements.
4. Identify changed requirements – remove, add, modify, and re-assess
priorities.
5. Identify changed requirements and record priorities – identify and resolve
conflicts, generate requirements impact statements.
6. Assess impact of changed requirements on current and previous ADM
phases, decide whether to do something now or later, issue requirements
impact statement.
7. Implement requirements arising from Phase H (catches changes from
Phase H and ensures proper consideration).
8. Update the requirements repository.
9. Implement change in the current phase.
10. Assess and revise Gap Analysis for past phases, using Gap Analysis
technique.
N.B. Phase-related steps shown in bold.
146
Outputs
 Requirements Impact Specification
 Requirements Impact Assessment, which identifies the phases of the ADM that
need to be revisited to address any changes. The final version must include the
full implications of the requirements (e.g. costs, timescales, and business
metrics)
When new requirements arise, or existing ones are changed, a Requirements Impact Statement is generated,
which identifies the phases of the ADM that need to be revisited to address the changes. The statement goes
through various iterations until the final version, which includes the full implications of the requirements (e.g. costs,
timescales, and business metrics) on the architecture development. Once requirements for the current ADM cycle
have been finalised then the Architecture Requirements Specification should be updated.
Security
 Requirements Management is central to architecture work. Its purpose is to identify, store, maintain, and
communicate business requirements through the different phases of architecture development by means of
a controlled and repeatable process. Also, operational performance is monitored against target
requirements. This is not explicitly addressed in the ADM but lies within Phase H: Architecture Change
Management, and the continual validation of Requirements Management.
 The ADM method validates and updates business requirements in every stage of an architecture
development project. However, the TOGAF® standard does not provide a required technique for describing
or documenting requirements. Such a technique is present in SABSA, which presents its unique Business
Attribute Profiling technique as a means to describe requirements effectively.
5.10.1 Business Attribute Profile
Business Attribute Profiling is a SABSA requirements engineering technique that translates business goals and
drivers into requirements using a risk-based approach. Some important advantages of this technique are:
 Executive communication in non-IT terms
 Traceability mapping between business drivers and requirements
 Performance measurement against business-defined targets
 Grouping and structuring of requirements, which facilitates understanding and oversight by architects
The SABSA Business Attribute Profile is at the heart of the SABSA methodology. It is this requirements
engineering technique that makes SABSA truly unique and provides the linkage between business requirements
and technology/process design. See the SABSA® Blue Book [2]. © The SABSA Institute
Figure 6: Example of a SABSA Business Attribute Taxonomy
Each SABSA Business Attribute in the example taxonomy of © The SABSA Institute
Figure 6 has a detailed generic definition and some suggested guidelines for applying metrics to that attribute, not
included in this overview. A Business Attribute Profile is built by the architects, using the taxonomy as a guideline.
The objective is to document the relevant attributes for the business case in hand, redefining each selected
attribute in terms of the business case, developing a measurement approach, specific metrics, and performance
targets, again related to the business case. The model is flexible and adaptive. When needed, new attributes and
new definitions should be added to fulfil the business requirements. Thus, although the method is well defined, the
Business Attribute taxonomy can be extended as much as is appropriate and each Business Attribute Profile is
highly customised according to the business case being considered by the architecture team.
An integral part of the SABSA Business Attribute Profile is the selection of metrics to set targets, so that
performance can be measured in the operational phase (“did you hit the target?”). The business analyst can
choose to either use the suggested metrics in the detailed examples, or create new metrics if that seems more
147
appropriate. Eventually, the creation of a real-time operational risk dashboard is possible that monitors
performance of operational capabilities against the predetermined performance targets, and provides early
warnings of upcoming risk events that may require management intervention.
In O-ISM3, performance targets are called “security targets”. As well as expressing security objectives in terms of
what matters to the business, O-ISM3 defines the tolerable deviations. All O-ISM3 objectives (business and
security) must include their security target. This is the maximum deviation from the desired outcome that
management tolerates before taking corrective action. O-ISM3 can support any specified variance. This enables
the O-ISM3 program to support and manage both aspirational objectives (whose allowable deviations may be very
high) and critical objectives (where there is usually a very narrow compliance range).
Security targets are normally defined in terms of frequency of occurrence and threshold cost. The allowable
business impact of missing objectives reflects the trade-off against other priorities and objectives. Security targets
show what the organisation expects from its information security investment. In a way, management’s act of
defining security targets also specifies its risk appetite.
5.10.2 Control Objectives/Security Objectives
A control objective (sometimes called a security objective) is a desired state of security for a given process, person,
activity, system, or dataset. It differs from a security requirement since an objective is a goal that the ISM process
aims to fulfil. This control objective might not exactly match the security requirement. Control objectives are linked
to business attributes.
O-ISM3 documents the contribution of information security towards meeting business objectives through using a
dependency analysis. The output of the dependency analysis is a list of security objectives that form the basis for
design, implementation, and monitoring of the ISMS. They also form the business objectives for the security
component when planning Enterprise Architecture. Security objectives, derived from business objectives, state
explicitly how information security contributes to business objectives.
Some examples of security objectives derived from the business objective “Invoicing all products and services
provided” are:
 Invoices are accessible only to the accountancy and collection teams
 Paid invoices are kept for three years and destroyed after no more than four years
5.10.3 Security Standards
Location in the Architecture Framework: TOGAF 9.1 §41.4 (Standards Information Base) provides a repository area
to hold a set of specifications to which architectures must conform. The standards can apply at every architecture
domain in the TOGAF standard. Security standards can be added to this existing catalogue as well.
The Security Architecture provides guidance on which security standards to use in which situation. Whether a
security standard applies is decided by the business owner or business analyst. If so, the standard is applied to the
architecture work through the Requirements Management process. The standard can dictate security controls for
the Business, Data, Application, or Technology Architecture.
Standards are needed to ensure that many different components can be integrated to form a larger system.
Different types of standards exist, such as regulatory standards, technical standards, etc. An example is the PCI-
DSS standard that applies for businesses in the payment card industry, the ETSI standards that apply in the
telecomms industry, etc. It is also worth noting that security standards may be externally imposed, or they may be
internally developed.
Summary
Requirements Management is an ongoing activity of the ADM. The requirements repository contains the current
requirements for the Target Architecture.
148
Architecture Partitioning
Objectives
 Describe the purpose of Partitioning
 Consider Architecture and Solutions in the context of partitioning
 Employing Architecture Partitioning
Overview
In a complex enterprise there can be many architectures, at different stages and describing different levels of detail
(architectures and solutions). Partitioning is a way of dealing with this complexity because...
 Architecture is complex
 Different architectures conflict with one another
 Different teams need to work on different elements of architecture at the same time
 Effective architecture reuse requires modular architecture segments
Characteristics of Solutions
149
Characteristics of Architectures
Applying Partitioning in Preliminary Phase

 Determine the organisation structure for architecture within the enterprise – establish standing teams for
each main partition:
o Governance bodies applicable to the team
o Team Membership
o Team reporting lines
 Determine the responsibilities for each standing architecture team – further partitioning may be needed for
each team defining:
o Subject Matter
o Level of Detail
o Time periods the architecture should cover
o Stakeholders
 Determine the relationships between architectures – consider:
o Architecture overlap/dovetail/drill-down
o Compliance requirements between architectures
150
Summary
In a complex enterprise there can be many architectures, at different stages and describing different levels of detail
(architectures and solutions). Partitioning is a way of dealing with this complexity.
151
Adapting the ADM

Objectives
We will be looking at...
 Iterations
o The concept of iteration and how it applies to TOGAF
o Factors influencing the use of iteration
o Suggested iteration cycles, and their application to the ADM
 Levels
o Identifying and applying different ADM levels within an enterprise
o Architecture engagement
o Combining levels and iterations
 Security (which has mainly been covered in previous chapters)
Iterations
The ADM is not a sequential process – it can take many iterations, and cycles through the phases.
Iteration can be used:
 Each cycle through the ADM is bound to a Request for Architecture Work, intended to either extend or
change the Architecture Landscape
 Separate projects may give rise to concurrent operation of ADM cycles
 One project may trigger another, causing the instantiation of a further ADM cycle. This is particularly so
where strategy architectures give rise to segment architecture, which eventually give rise to capability
architectures
Examples of Iterations between phases

Architecture Capability-related:
 Projects may need to iterate between Preliminary and Phase A to (re-)establish aspects of Architecture
Capability
 Projects may need to revisit the Preliminary Phase as a result of new Capability requirements
Architecture Development-related
 Project teams may operate their own ADM cycles concurrently
 Project teams may cycle between ADM phases in planned phases
 Project teams may return to previous phases
Other Iteration Cycles

 Transition Planning iterations
 Architecture Governance iterations
152
Iteration Cycles applied to the ADM
Approaches to Architecture Development

Two approaches can be adopted within the ADM for the development of architectures:
 Baseline First: In this style, an assessment of the baseline landscape is used to identify problem
areas and improvement opportunities. This process is most suitable when the baseline is complex, not
clearly understood or agreed upon. This approach is common where organisational units have had a
high degree of autonomy
 Target First: In this style, the target solution is elaborated in detail and then mapped back to the
baseline, in order to identify change activity. This process is suitable when a target state is agreed at a
high level and where the enterprise wishes to effectively transition to the target model
Typically, if the baseline is broadly understood a higher value will be obtained, focusing on the target first, then
baseline to the extent necessary to identify changes.
In practical terms, an architecture team will always give informal consideration to the baseline when analysing the
target (and vice versa).
In situations where baseline and target are expected to be considered in parallel by stakeholders, it is
recommended that the architecture team focuses priority on one state in order to maintain focus and consistency of
execution.
153
Mapping TOGAF Phases to Iteration Cycles

Baseline First
Target First
154
Classes of Architecture Engagement
ADM Levels and Iteration Cycles
155
Levels of Architecture
Levels of the Architecture Landscape
156
Security Architecture
 Aligns Business and supporting Information Systems to realise goals
 A structure of organisational, conceptual, logical and physical components that coherently act to provide
security
 Close integration is needed between Security and Enterprise Architecture
 A common language needs to be used
 ISM – Information Security Management
 ERM – Enterprise Risk Management
 The way in which these concepts have been integrated with the framework is shown diagrammatically later
Security is Cross-cutting
157
Integration of ISM/ERM and the TOGAF® Framework
Concepts with an underscore are additions to the TOGAF® Framework and brought in by ISM or ERM.
Summary
 Iterations and Levels of Architecture are both ways of organising how/what the ADM processes are dealt
with
 Security is a distinct but integrated part of architecture
158
Architecture Maturity Models

Objectives
In this chapter we will cover the following:
 The role of Maturity Models
 The CMMI Approach
 The ACMM
 Maturity Assessments
The Role of Maturity Models

 Capability Maturity Models help to improve processes. Developed by CMU/SEI in late 80s/early 90s
 They are templates describing “best process”, in a variety of areas, along with a maturity scale (i.e. 0 to 5, 1
to 5)
 An organisation can assess its current maturity against this scale, and then aim to improve their “score” by
improving/introducing processes
 They are used to:
o Implement and audit processes
o Measure quality
o Measure people’s competency
o Judge maturity of outsourced partners
 Many models exist, for activities such as:
o People (P-CMM, improving management and development of HR)
o Systems Engineering (SE-CMM)
o Software Acquisition (SA-CMM)
The CMMI Approach

 Capability Maturity Model Integration (CMMI) was introduced to integrate different models, and to help...
o Link management and engineering activities to business objectives, and ensure outputs
(products/services) meet customer expectations
o Implement robust high-maturity practices, based on lessons learnt
o Address additional organisational functions critical to its outputs
o Assist compliance/conformance with ISO standards
 CMMI used to rate overall Maturity (“staged representation”) AND/OR process-by-process Capability
(“continuous representation”)
159
Architecture Maturity Model

 The Architecture Capability Maturity Model (ACMM) developed by US Dept. of Commerce
 Defines six maturity levels and nine elements (processes)
Levels: Elements:
0. – None  Architecture Process
1. – Initial  Architecture Development
2. – Under Development  Business Linkage
3. – Defined  Management Team Participation
4. – Managed  Operating Unit Participation
5. – Measured  Architecture communication
 IT Security
 IT Investment and Acquisition Strategy
Full details of the ACMM available on:

http://ocio.os.doc.gov/ITPolicyandPrograms/Enterprise_Architecture/PROD01_004935
Business Transformation Readiness Assessment – Maturity Model

Please note the following example Maturity Model scorecard relates to Business Transformation Readiness
Assessment, which itself is also a kind of Maturity Model. This example does not appear in the Framework
document and has been obtained from online resources, but is included below just to provide a real example of
Maturity Model templates.
160
Maturity Assessments
 If desired an organisation can go through a formal assessment called SCAMPI (Standard CMMI Appraisal
Method for Process Improvement)
 Used to measure Capability and Maturity
 Three types of assessment
o Class A: Formal and Official
o Class B: Interim assessment (semi-informal)
o Class C: Self-assessments (totally informal)
Summary
In this chapter we looked at:
 The role of Maturity Models to describe best practice and define how to assess your maturity level
 The CMMI Approach integrates a variety of models
 The ACMM is a model that focuses on Enterprise Architecture
 Maturity Assessments are performed using the SCAMPI system
161
Architecture Skills Framework

Objectives
In this chapter we will look at:
 The purpose of the Architecture Skills Framework
 Why it is needed
 Benefits of using the framework
 Structure of the Skills Framework
Purpose and Need

 The purpose of Skills Frameworks is typically to define:
o Roles
o Competencies or skills
o Proficiency or depth of knowledge
 An Architecture Skills Framework refines these characteristics to fit the context
 Successful EA is characterised by establishing:
o A uniform definition of the architecture roles, which is understood both internally and externally
o A proper practice that recognises the skills required AND encourages certification where possible
Benefits of using the Skills Framework
Reduced time, cost, and risk in training, hiring, and managing architecture pros, both internal and external
 Simplified communications with recruiting agencies

 No wasting of time interviewing unsuitable candidates
 Avoids overlooking staff that may already be available
Reduced time and cost to set up an internal architecture practice
 A ready-made set of job roles is available

 People with the right skills can fill these roles
 Using an industry-standard approach ensures consistency
Solution Development time, cost and risk is also reduced
 Because the right people are doing the jobs

 There is less chance of having to re-hire or re-assign people
 The eventual solutions work better
162
Structure of the Skills Framework

Roles Skills Proficiency Levels
 Architecture Board Members  Generic – leadership, team player, 1. Background – not a
etc. required skill
 Architecture Sponsor
 Business – business cases, 2. Awareness – understands
 Architecture Manager
processes, strategic planning background, issues and
 Architects implications
 EA – modelling, Building Blocks,
o Enterprise applications, system integration 3. Knowledge – detailed
o Business knowledge, can provide
 Programme/Project management professional advice and
o Data – change mgmt., PM methods guidance
o Application  IT General Knowledge – broking 4. Expert – substantial and
o Technology apps, asset mgmt., SLAs, extensive knowledge and
migration planning practical experience on the
 Programme/Project Managers
 Technical IT – software subject
 IT Designers engineering, security, data
 And many others... interchange
 Legal Environment – DP law,
contract law, procurement law,
fraud
Summary
In this chapter we looked at:
 The purpose and need for an Architecture Skills Framework – to provide a consistent and uniform structure
 Benefits of using the framework – reduced cost, time and risk because the right people are being used in
the right way
 Structure of the Skills Framework – consists of Roles, Skills and Proficiencies
163
Adapting the ADM Business Benefits, 5

Classes and Architecture Engagement, 155 Definition, 5
ISM/ERM and TOGAF, 158 Purpose, 5
Iterations, 152 Evolution of Framework, 4
Applied to ADM, 153 Exam Paths, 10
Between Phases, 152 Structure of TOGAF, 8
Other Cycles, 152 Suitability of TOGAF, 7
Levels and Iteration Cycles, 155 The Open Group, 4
Levels of Architecture TOGAF Capabilities, 9
Architecture Landscape, 156 TOGAF Library, 9
Objectives, 152 Types of Architecture, 6
Phases Mapped to Cycles What is an Architecture Framework?, 7
Target First, 154 Building Blocks
Security, 157
Architecture Building Blocks, 73
Security Concerns, 157
Link with ADM, 74
Architecture Content Framework Patterns, 75
Artifact, 35 Qualities, 73
Building Block, 35 Solution Building Blocks, 74
Content Metamodel Business Scenarios
Main Graphic, 37
Overview, 65
Deliverable, 35
Process, 66
Example Deliverable, 36
Key Relationships, 36 Content Metamodel
Overview, 35 Artifacts, 42
Work Products, 35 Core and Extension Parts, 40
Core Concepts, 38
Architecture Development Method
Core Diagram, 39
Key Points, 22
Core Entity Diagram, 39
Request for Architecture Work, 53
Full Diagram with Extensions, 41
Architecture Maturity Models
Core Concepts
ACMM, 160 Architecture Capabilities, 17
CMMI Approach, 159
Architecture Content Framework
Maturity Assessments, 161
Introduction, 14
Objectives, 159
Architecture Development Method
Role, 159
Main Graphic, 13
Architecture Partitioning Architecture Repository, 16
Applying, 150 Enterprise Continuum
Architecture Characteristics, 150 Main Graphic, 15
Objectives, 149 Integrated Information Infrastructure RM, 19
Overview, 149 Technical Reference Model, 19
Solution Characteristics, 149 Using TOGAF with other Frameworks, 18
Architecture Repository Enterprise Continuum
Architecture Landscape, 33 Architecture Continuum, 29
Classes of Information, 32 Definition of Continuum, 27
Link with Enterprise Continuum, 32 Main Constituents, 28
Overview, 31 Main Graphic, 28
Repositories, 31 Relationship with ADM, 30
Standards Information Base, 33 Reuse, 27
Solutions Continuum, 29
Architecture Skills Framework What is it?, 27
Benefits of Use, 162
Objectives, 162 Governance
Purpose and Need, 162 Architecture Board
Structure, 163 Board Meetings, 61
Responsibilities, 61
Basic Concepts Setting up, 61
Certification Program, 10 Architecture Compliance Definitions, 62
Definitions of System Architecture, 6 Architecture Contracts, 62
Enterprise Architecture
164
Capabilities, 64 Approach, 96
Compliance Review Inputs, Outputs and Steps, 97
Processes, 63 Objectives, 96
Purpose, 63 Repository Items, 96
Governance Framework Structure, 58 Security, 97
Key Success Factors, 60
Phase C – Applications
Need for Architecture Board, 60
Approach, 104
Need for Architecture Compliance, 62
Architecture Definition Doc, 109
Organisation Structure, 59
Architecture Requirements Spec, 109
Overview, 57
Inputs, 105
Specifics, 60
Objectives, 104
Integrated Information Infrastructure RM Outputs, 108
Boundaryless Information Flow, 117 Principles, 105
Components, 118 Selecting Ref.Models/Viewpoints/Tools, 107
Detailed Structure, 119 Step Summary, 106
High-level Structure, 118 Steps, 105
Introduction to the ADM Phase C – Data
Adapting the ADM, 24 Achitecture Requirements Spec, 103
Architecture Integration, 25 Approach, 99
Architecture Scope, 25 Architecture Definition Doc, 103
Governance and Information, 24 Governance, 100
Guidelines and Techniques Inputs, 100
Introduction, 23 Management, 99
Phases A-D, 22 Migration, 100
Relationships, 23 Objectives, 99
Outputs, 102
Phase A
Principles, 100
Approach, 76
Reference Models, 102
Architecture Repository, 77
Step Summary, 101
Business Transformation Readiness, 80
Steps, 101
Capabilities Example, 84
Capability-based Planning, 84, 85 Phase D – Security, 114
Creating an Architecture Vision, 76
Phase D – Technology
Inputs, 77
Approach, 110
Interoperability
Architecture Definition Doc, 114
Business, 85
Architecture Requirements Spec, 114
Phase level, 85
Inputs, 111
Objectives, 76
Outputs, 113
Outputs, 83
Phase Objectives, 110
Risk Impact Classification Scheme, 82
Principles, 111
Risk Management, 81
Step Summary, 112
Security, 86
Steps, 112
Stakeholders Concerns and Requirements, 79
Step Summary, 78 Phase E – Opportunities and Solutions
Steps, 78 Approach, 120
Suggested Readiness Factors, 80 Confirm Change, 123
Identify Work Packages, 124
Phase B
Illustrate, 121
Approach, 87
Implementation and Migration Strategy, 124
Building Blocks, 93
Objectives, 120
Business Modelling, 90
Outputs, 125
Gap Analysis, 92
Review Gaps, 123
Gap Analysis Matrix, 92
Security, 126
Inputs, 88
Step Summary, 122
Objectives, 87
Steps, 121
Outputs, 93
Transition Architectures, 125
Principles, Goals, Drivers, 88
Security, 94 Phase F – Migration Planning
Step Summary, 89 Approach, 127
Steps, 89 Business Value, 130
Business Value Assessment Technique, 130
Phase C
Confirm Architecture Roadmap, 131
165
Framework Interaction, 129 Example One, 51

Implementation and Migration Plan, 133 Example Two, 51
Inputs, 128 Identifying, 48
Outputs, 132 Qualities, 52
Phase Objectives, 127 Template, 50
Prioritise Migration Projects, 131 TOGAF List, 49
Security, 133 Relationship Between Frameworks, 45
State Evolution Table, 132 Security, 54
Step Summary, 129 Steps, 46
Steps, 128 Tailoring the Framework, 53
Phase G – Implementation Governance Requirements Management
Approach, 135 Approach, 145
Architecture Contract Contents, 138 Inputs, 146
Objectives, 135 Objectives, 145
Outputs, 138 Outputs, 147
Risk Monitoring, 139 Security, 147
Security, 139 Steps, 146
Step Summary, 137
Steps, 136
Critical Aspects, 70
Tailoring a Compliance Review, 137
Identifying Stakeholders, 70
Phase H – Change Management Overview, 70
Approach, 140 Stakeholder Categories, 71
Change Requests, 142 Stakeholder Map, 72
Inputs, 141 Stakeholder Power Grid, 71
Objectives, 140
Technical Reference Model
Outputs, 143
Application Platform Service Categories, 116
Security, 144
Main Categories, 115
Step Summary, 143
Overview, 115
Steps, 142
Platform Service Categories, 116
Preliminary Phase Tailoring, 116
Approach, 44 Views, 115
Establish EA Team and Organisation, 47
Views and Viewpoints
Further Considerations, 46
Creating Views, 69, 72
Inputs, 45
Definitions, 67
Outputs, 53
Example, 68
Phase Objectives, 44
ISO42010, 67
Principles
Overview, 67
Defining, 48
166
To continue your learning journey, visit
QA.COM
Professionally social.
#SkillsfortheDigitalAge
Our skills and education solutions. Trusted, awarded, accredited.
Learning Consulting Apprenticeships Higher Education

Professional training and A leading provider of Career-changing tech, Industry-focused, full and
learning solutions for consulting services to the digital and business part-time degrees, delivered
individuals and organisations. Government, Financial and apprenticeships. with leading university
Commercial sectors. partners.
V1.9

TOGAF9FC

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TOGAF9FC

Uploaded by

Copyright:

Available Formats

TOGAF® 9

Foundation and Certified.

TOGAF® 9 Foundation and Certified

The Open Group

The TOGAF® Framework Evolution

Enterprise Architecture – What is its Purpose?

What are the Business Benefits?

 Faster, simpler, and cheaper procurement:

What is a [System] Architecture?

The Different Types of Architecture

What is an Architecture Framework?

So why is the TOGAF® Framework so suitable?

The TOGAF® Framework Parts

TOGAF® Framework Capabilities

Core Concepts and Reference Models

The Architecture Development Method

The Architecture Content Framework

The Enterprise Continuum

The Architecture Repository

Using TOGAF® with other Frameworks

MSP: Managing Successful Programmes

Technical Reference Model

Integrated Information Infrastructure RM

Introduction to the ADM

The ADM and Key Points

Definition process – Phases A to D

Guidelines and Techniques

– Strategic, Segment or Capability – the Architecture Landscape.

Adapting the ADM

ADM Governance and Information

The Enterprise Continuum

What is the Enterprise Continuum?

When you “idealise” about architecture you should:

When you “realise” an architecture you should:

Relationship with the ADM

The Architecture Repositories

Classes of Repository Information

Enterprise Continuum and the Repository

Standards Information Base

Architecture Content Framework

Content Framework Items

The Content Metamodel

Core Entity Diagram

Core and Extension Parts

Full Diagram with Extensions

Relationship Between Frameworks

Further Input Considerations

Establish EA Team and Organisation

 Determine existing enterprise and business capability

Business Primacy of Principles

Data Data is an Asset

Application Technology Independence

Technology Requirements-based Change

Name Should both represent the essence of the rule as well

Statement Should succinctly and unambiguously communicate

Rationale Should highlight the business benefits of adhering to

Implications Should highlight the requirements, both for the

Example Principle (#1)

Name Primacy of Principles

Statement Principles of information management apply to all organisations within the

Implications • Without this principle, exclusions, favouritism and inconsistency would

Example Principle (#2)

Name Service Orientation

Statement The architecture is based on a design of services which mirror real-world