1. TOGAF 9
Framework for Enterprise
Architecture
Andrew Tomsky
E.A. Consultant

2. Introduction to TOGAF

3. TOGAF is…
• TOGAF is an architecture framework.
– The Open Group architecture framework.
• Provides the methods and tools for
assisting in the acceptance, production, use
and maintenance of an enterprise
architecture
• TOGAF is based on:
– An iterative process model
– A re-usable set of existing architecture assets
– Supported by architectural best practices
3 – www.anywhere.cz Introduction to TOGAF

4. What is enterprise architecture?
4 – www.anywhere.cz Introduction to TOGAF

5. Enterprise architecture is…
Enterprise Architecture
Solution Solution
System A System D
Architecture Architecture
System B System C
Solution Solution
Architecture Architecture
5 – www.anywhere.cz Introduction to TOGAF

6. Enterprise architecture is…
6 – www.anywhere.cz Introduction to TOGAF

7. Typical problems in Enterprise Architecture
• Multiple sources for the same data entity
• Proliferation of interfaces
• Incompatible technologies
7 – www.anywhere.cz Introduction to TOGAF

8. Enterprise architecture is…
Enterprise Architecture
• How the business
Business
meets it‘s strategy
Architecture
and goals
IT Architecture
Information System • Support of business
Architecture strategy and goals
• How the technology
Technology Architecture
fits together
8 – www.anywhere.cz Introduction to TOGAF

9. Other issues in Enterprise Architecture
FINANCE SALES CUSTOMER SERVICE
:Application_5
:Application_1 :Application_6
:Application_3
:Application_4
:Application_2
.. ... .
:Database_5
:Database_3
:Database_6
:Database_1
:Database_4 :Database_7
:Database_2
• Reuse
• Procurement and supplier control
• Support of business strategy
9 – www.anywhere.cz Introduction to TOGAF

10. What should an Architectural Framework
contain?
• A foundational structure, or set of
structures, which can be used for
developing a broad range of different
architectures
• It should contain a method for designing
an information system in terms of a set
of building blocks, and for showing how
the building blocks fit together
• It should contain a set of tools and
provide a common vocabulary
• It should also include a list of
recommended standards and compliant
products that can be used to implement
the building blocks
10 – www.anywhere.cz Introduction to TOGAF

11. TOGAF – history and development
The Open Group
• A vendor- and technology-neutral consortium
• Committed to the vision of boundary-less information flow
• Architecture Forum members – more than 300 organizations, from
industry, government as well as academia
• „Making Standards Work“
• IT Specialist Certification – ITSC
11 – www.anywhere.cz Introduction to TOGAF

12. TOGAF – history and development
The Open Group Architecture Framework
• First version of TOGAF launched in 1995 – originally based on the US
department of defense TAFIM framework
• First version of TOGAF focused primarily on technology.
• 2002 – Enterprise Edition – TOGAF v 8
• 2009 – TOGAF 9
– Better linkage to business layer (business strategy, business models, processes)
– More user friendly framework (templates, guidelines)
– Parts of the methodology have been simplified
• TOGAF has been continuously improved for over 15 years!
12 – www.anywhere.cz Introduction to TOGAF

13. Some members of the Architecture Forum
• American Express • Massachusetts Institute of
• ACORD Corporation Technology, Lincoln Laboratory
• BP International • NASA SEWP
• British Telecom Plc • Nissan Motor Co., Ltd.
• Capgemini SA • Nomura Research Institute, Ltd.
• Cisco Systems, Inc. • PricewaterhouseCoopers LLP
• Deloitte Consulting LLP • Procter & Gamble Company
• Deccan Global Solutions LLC • Rolls-Royce plc
• Hewlett-Packard • SAP
• France Telecom • Sun Microsystems
• HSBC Bank plc • Sybase® PowerDesigner®
• IBM • Tata Consultancy Services
• IDS Scheer AG • The Boeing Company
• Infosys Technologies Ltd • Unisys
• Intel Corporation • Wipro Technologies
• Lockheed Martin Corporation •
13 – www.anywhere.cz Introduction to TOGAF

14. Development overview
14 – www.anywhere.cz Introduction to TOGAF

15. Overview of the TOGAF content
Architecture Capability
Framework
(Part VIII)
The TOGAF content is divided into 7 parts:
• Part I – Introduction
Architecture
Development Method • Part II - Architecture Development Method
(Part II)
• Part III - ADM Guidelines and Techniques
ADM Guidelines and
Techniques (Part III) • Part IV - Architecture Content Framework
• Part V - Enterprise Continuum & Tools
Architecture
Content • Part VI - TOGAF Reference Models
Framework
(Part IV) • Part VII - Architecture Capability Framework
Enterprise Continuum
and Tools
(Part V)
TOGAF Reference
Models (Part VI)
15 – www.anywhere.cz Introduction to TOGAF

16. Types of content in TOGAF
The content in the TOGAF specification is categorized as follows:
– TOGAF Core consists of the fundamental concepts that form the essence of
TOGAF
– TOGAF Mandated consists of the normative parts of the TOGAF
specification. These elements of TOGAF are central to its usage and without
them the framework would not be recognizably TOGAF.
– TOGAF Recommended consists of a pool of resources that are specifically
referenced in TOGAF as ways in which the TOGAF Core and Mandated
processes can be accomplished (e.g., the SEI Architecture Trade-Off Analysis
Method or business scenarios)
– TOGAF Supporting consists of additional resources that are not referenced
in the other three TOGAF categories itself but provide valuable assistance
16 – www.anywhere.cz Introduction to TOGAF

17. Using TOGAF with other frameworks
• TOGAF is a generic framework and it is
expected that the architect will adapt and build
on the TOGAF to create an organization-specific
framework
• The generic TOGAF deliverables may be
replaced or extended by deliverables defined in
any other relevant framework
– E.g.: ITIL, CMMI, COBIT, PRINCE2, PMBOK, MSP etc
• TOGAF also complements other frameworks
that are aimed at specific vertical business
domains, specific horizontal technology areas
(such as security or manageability), or specific
application areas (such as e-Commerce)
17 – www.anywhere.cz Introduction to TOGAF

18. Advantages of using TOGAF (IT)
• Prevents growth of IT into unmanageable complexity
• TOGAF represents best practice in architecture development.
– It has been developed through the collaborative efforts of 300
Architecture Forum member companies from some of the world’s
leading IT customers and vendors
• Using TOGAF enable companies to build quality architectures, which are:
– Consistent
– Support the needs of stakeholders
– Support current requirements and to the likely future needs of the
business
– Employ best practice
• Strong focus on removing the barriers between business and IT
• Supports optimal reuse of existing IT assets
• Enables business strategy
18 – www.anywhere.cz Introduction to TOGAF

19. Architecture governance

20. What is architecture governance
• Architecture governance is the practice and orientation by which enterprise
architectures are managed and controlled at an enterprise-wide level
• Architecture governance typically operates within a hierarchy of other
governance structures, e.g.:
– Corporate governance
– Technology governance
– IT governance
– Architecture governance
• Domains of governance may exist at multiple geographic levels
• Effective Governance creates a controlled environment for IT across the
enterprise
20 – www.anywhere.cz Architecture Governance

21. What is architecture governance
• Conceptually, architecture
governance is:
– A series of processes
– A set of owned responsibilities
– An approach
– A cultural orientation
• These things are defined by the
governance framework
21 – www.anywhere.cz Architecture Governance

22. Establishing an Architecture Capability
• It is increasingly recognized that a
successful enterprise architecture
practice must sit on a firm
operational footing
• Effective governance requires
that all architecturally significant
activity is controlled and aligned
within a single framework
• In effect, an enterprise
architecture practice should be
run like any other operational
unit (e.g. a Project Management
Office)
22 – www.anywhere.cz Architecture Governance

23. Architecture Governance — Organization
Structure
23 – www.anywhere.cz Architecture Governance

24. Architecture Governance Framework —
Conceptual Structure
24 – www.anywhere.cz Architecture Governance

25. A mature Architecture Capability
25 – www.anywhere.cz Architecture Governance

26. Architecture Governance — Key Success
Factors
• For successful Architecture Governance, the following things should be
considered:
• Organizational responsibilities and structures which support the
architecture governance processes and reporting requirements
• Governance processes, procedures, roles, skills, and tools
• Best practices for architecture policies
– For their submission, adoption, reporting, and retirement
• Criteria for the control of the architecture governance processes,
dispensations, compliance assessments, SLAs, and OLAs
• Requirements for the effectiveness of all architecture governance-related
activities
26 – www.anywhere.cz Architecture Governance

27. The benefits of Architecture Governance
• Greater shareholder value → studies have demonstrated a correlation
between increased shareholder value and well-governed enterprises
• Upholds a standard of consistency, quality and interoperability in
architecture
– Prevents growth of architecture into unmanageable complexity
• Supports strategic, long-term evolution of architecture
• Increased transparency of accountability
• Proactive control, monitoring, and management mechanisms
• Integrates with existing processes and methodologies and complements
functionality by adding control capabilities
27 – www.anywhere.cz Architecture Governance

28. The Architecture Development
Method (ADM)

29. The architecture domains used by TOGAF
• Business Architecture
– Defines the business strategy, governance, organization, and key business
processes
• Data Architecture
– Describes the structure of an organization’s logical and physical data assets and
data management resources
• Application Architecture
– A blueprint for the individual application systems to be deployed, their
interactions, and their relationships to the core business processes of the
organization
• Technology Architecture
– Describes the logical software and hardware capabilities that are required to
support the deployment of business, data, and application services
– Includes IT infrastructure, middleware, networks, communications, processing,
standards, etc
29 – www.anywhere.cz The Architecture Development Method

30. Overview of the ADM
• The ADM consists of 9 phases:
– The Preliminary Phase
– Phase A: Architecture Vision
– Phase B: Business Architecture
– Phase C: Information Systems
Architectures
– Phase D: Technology Architecture
– Phase E: Opportunities & Solutions
– Phase F: Migration Planning
– Phase G: Implementation Governance
– Phase H: Architecture Change
Management
– And Requirements Management
• Each phase contains a series of steps
30 – www.anywhere.cz The Architecture Development Method

31. The Preliminary Phase
• Describes the preparation and initiation
activities to prepare to meet the business
directive for a new enterprise
architecture
– Includes the definition of an
Organization-Specific Architecture
framework
– Includes the definition of principles
31 – www.anywhere.cz The Architecture Development Method

32. Phase A: Architecture Vision
• Phase A is the initial phase of an
architecture development cycle
• It includes:
– Defining the scope
– Identifying the stakeholders
– Creating the Architecture Vision
– Obtaining approvals
32 – www.anywhere.cz The Architecture Development Method

33. Phase B: Business Architecture
• Phase B: Business Architecture
describes the development of a
Business Architecture to support an
agreed Architecture Vision
33 – www.anywhere.cz The Architecture Development Method

34. Phase C: Information Systems
• Phase C: Information Systems
Architectures describes the development
of Information Systems Architectures for
an architecture project, including the
development of Data and Application
Architectures
34 – www.anywhere.cz The Architecture Development Method

35. Phase D: Technology Architecture
• Phase D: Technology Architecture
describes the development of the
Technology Architecture for an
architecture project
35 – www.anywhere.cz The Architecture Development Method

36. Phase E: Opportunities & Solutions
• Phase E describes initial
implementation planning
– Includes the identification of delivery
vehicles for the architecture defined
in the previous phases
36 – www.anywhere.cz The Architecture Development Method

37. Phase F: Migration Planning
• Phase F addresses the formulation of a
set of detailed sequence of transition
architectures with a supporting
Implementation and Migration Plan
37 – www.anywhere.cz The Architecture Development Method

38. Phase G: Implementation Governance
• Phase G provides an architectural
oversight of the implementation
38 – www.anywhere.cz The Architecture Development Method

39. Phase H: Architecture Change
• Phase H: Architecture Change
Management establishes procedures for
managing change to the new architecture
39 – www.anywhere.cz The Architecture Development Method

40. Requirements Management
• Requirements Management examines
the process of managing architecture
requirements throughout the ADM
40 – www.anywhere.cz The Architecture Development Method

41. Overview of the ADM
• The ADM is a generic method: It can be used by enterprises in a wide
variety of different geographies, applied in different vertical
sectors/industry types and can be tailored to specific needs
• The ADM is iterative: Over the whole process, between phases, and
within phases
• For each iteration of the ADM, a fresh decision must be taken as to:
– The breadth of coverage of the enterprise to be defined
– The level of detail to be defined
– The extent of the time period aimed at
– The architectural assets to be leveraged, including:
Assets created in previous iterations of the ADM cycle within the enterprise
Assets available elsewhere in the industry (other frameworks, systems
models, vertical industry models, etc.)
41 – www.anywhere.cz The Architecture Development Method

42. Adapting the ADM
• To take account of the maturity of the
architecture discipline within the
organization
– e.g. by putting more emphasis on phases
that were formerly not well understood
by the organization
• The business and/or architecture
principles of an enterprise may require
that the ADM is adapted
• To integrate the ADM with another
enterprise framework or other firm
standards
– e.g. the Zachman Framework
– e.g. program management, business
planning or procurement
42 – www.anywhere.cz The Architecture Development Method

43. Advantages of the ADM as a method
• Strong focus on eliminating the barriers between Business and IT
• Ensures a high level of consistency and control
– Through reuse of architectures, use of principles etc
– Formal post-implementation feedback and control is part of the method
• Supports strategic, long-term architecture planning
– Planning techniques, architecture governance after implementation etc
• A realistic method
– Covers all the key domains, but does not force the architect to make views that
are not necessary for anyone
• Highly flexible and can be adapted:
– For companies of any size, for architecture projects to any level of detail
43 – www.anywhere.cz The Architecture Development Method

44. Supporting the architect

45. The Architecture Repository
• The Architecture Repository provides a framework and context to support
the leverage of relevant architecture assets in executing the ADM
– One part of the Architecture Repository is the Enterprise Continuum, which is a
tool for categorizing architectural source material
– At relevant places throughout the ADM, there are reminders as to which assets
from the repository can be used
– e.g. Foundation Architecture in Phase D: Technical Architecture
• In executing the ADM, the architect also populates the organization’s own
Architecture Repository
• The criteria for including source materials in an organization’s
Architecture Repository will typically form part of the enterprise
architecture governance process
45 – www.anywhere.cz Supporting the architect

46. Architecture repository
• An environment used to store
architectural output created
in the ADM
– Helps architects leverage
relevant resources and assets
for developing Architecture
46 – www.anywhere.cz Supporting the architect

47. Enterprise continuum
• A view of the
Architecture
Repository that
provides methods for
classifying
architectures and
solution artifacts in a
structured way
47 – www.anywhere.cz Supporting the architect

48. Enterprise continuum
48 – www.anywhere.cz Supporting the architect

49. TRM – Detailed level
• Entities:
– Application Software
– Application Platform
• Communications Infrastructure
– Interfaces:
– Application Platform Interface
– Communications Infrastructure
Interface
49 – www.anywhere.cz Supporting the architect

50. TOGAF Metamodel Entities
• Defines a set of entities
that allow architectural
concepts to be captured,
stored, filtered, queried,
and represented in a way
that supports consistency,
completeness, and
traceability
50 – www.anywhere.cz Supporting the architect

51. Metamodel Relationships
51 – www.anywhere.cz Supporting the architect

52. TOGAF supporting materials

53. Skills framework
• TOGAF provides a skills framework which details the skills needed by the roles
in the architecture team
53 – www.anywhere.cz TOGAF supporting materials

54. Skills framework
• Types of skill categories used in the TOGAF skills framework:
– Generic Skills: typically comprising leadership, team working, inter-personal
skills, etc
– Business Skills & Methods: typically comprising business cases, business
process, strategic planning, etc
– Enterprise Architecture Skills: typically comprising modeling, building block
design, applications and role design, systems integration, etc
– Program or Project Management Skills: typically comprising managing business
change, project management methods and tools, etc
– IT General Knowledge Skills: typically comprising brokering applications, asset
management, migration planning, SLAs, etc
– Technical IT Skills: typically comprising software engineering, security, data
interchange, data management, etc
– Legal Environment: typically comprising data protection laws, contract law,
procurement law, fraud, etc
54 – www.anywhere.cz TOGAF supporting materials

55. Developer-Led SOA
Developer-led SOA
Asks:”What is the best way to
design, build and operate services?
• Developer-led SOA considers an information system service to be a unit of
application code providing an open interface that is abstracted from its
implementation
55 – www.anywhere.cz TOGAF supporting materials

56. Business-Led SOA
Business-Led SOA
Ask:”What services are
needed and how should
they be governed and
fulfilled?
56 – www.anywhere.cz TOGAF supporting materials

57. How TOGAF Supports SOA
• TOGAF provides in an SOA context is a set of tools and techniques to link
top-down business-led SOA to bottom-up developer-led SOA in a robust
and maintainable way that addresses many of the nontechnical challenges
57 – www.anywhere.cz TOGAF supporting materials

58. TOGAF Guidelines and Techniques
They are detailed in part III of the TOGAF documentation:
• Applying Iteration to the ADM
– Discusses the concept of iteration and shows potential strategies for applying
iterative concepts to the ADM
• Applying the ADM at Different Enterprise Levels
– Discusses the different types of architecture engagement that may occur at
different levels of the enterprise. This section then also discusses how the ADM
process can be focused to support different types of engagement
• Security Architecture and the ADM
– Provides an overview of specific security considerations that should be
considered during different phases of the ADM
• Using TOGAF to Define & Govern SOAs
– Shows how SOA concepts can be supported by the TOGAF framework
58 – www.anywhere.cz TOGAF supporting materials

59. TOGAF Guidelines and Techniques
• Architecture Principles
– Principles for the use and deployment of IT resources across the enterprise —
describes how to develop the set of general rules and guidelines for the
architecture being developed
• Stakeholder Management
– Describes Stakeholder Management, an important discipline that successful
architecture practitioners can use to win support for their projects
• Architecture Patterns
• Business Scenarios
– A method for deriving business requirements for architecture and the implied
technical requirements
• Gap Analysis
– A technique used in the TOGAF ADM to validate an architecture that is being
developed
59 – www.anywhere.cz TOGAF supporting materials

60. TOGAF Guidelines and Techniques
• Migration Planning Techniques
– Describes a number of techniques to support migration planning in Phases E
and F
• Interoperability Requirements
– A technique for determining interoperability requirements
• Business Transformation Readiness Assessment
– A technique for identifying business transformation issues
• Risk Management describes
– A technique for managing risk during an architecture/business transformation
project
• Capability-Based Planning
• Tool selection
60 – www.anywhere.cz TOGAF supporting materials

61. TOGAF Certification

62. TOGAF Certification
• Ensures that individuals are
knowledgeable about TOGAF
• Is a common baseline of
knowledge
• Provides a visible trust mark
• Is a foundation for the emerging
profession
62 – www.anywhere.cz The TOGAF Certification for People Program

63. Certification
LEVEL TAG PURPOSE
1 TOGAF 9 To provide validation that the candidate has
Foundation gained knowledge of the terminology and basic
concepts of TOGAF 9 and understands the core
principles of Enterprise Architecture and
TOGAF
2 TOGAF 9 To provide validation that in addition to
Certified knowledge and comprehension, the candidate
is able to analyze and apply knowledge of
TOGAF
63 – www.anywhere.cz The TOGAF Certification for People Program

64. We are…. Anywhere
• Provide consultancy services and training linked to Enterprise Architecture
• The first Czech company to provide accredited training in TOGAF
• Members of the Open Group
Andrew.tomsky@anywhere.cz
www.anywhere.cz
64 – www.anywhere.cz