This chapter will familiarize you with the fundamentals that you need to know to pass the TOGAF 9 Part 1 Examination. The objectives of this chapter are as follows:
• To provide an introduction to the basic concepts of enterprise architecture and the TOGAF framework, including providing a high-level view of the TOGAF standard, enterprise architecture, architecture frameworks, and the contents of TOGAF 9
Key Points Explained
This chapter will help you to answer the following questions:
• What is the TOGAF standard?
• What is an enterprise?
• What is enterprise architecture?
• Why do I need enterprise architecture? What are the business benefits?
• What is “architecture” in the context of the TOGAF standard?
• What is an architecture framework?
• Why do I need a framework for enterprise architecture?
• Why is the TOGAF standard suitable as a framework for enterprise architecture?
• What does the TOGAF standard contain?
• What are the different types of architecture that the TOGAF standard deals with?
(Syllabus Reference: Unit 1, Learning Outcome 7: You should be able to briefly explain what the TOGAF standard is.)
The TOGAF standard is an architecture framework. The TOGAF standard is a tool for assisting in the acceptance, production, use, and maintenance of enterprise architectures. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets.
The TOGAF standard is developed and maintained by The Open Group Architecture Forum. The first version of the TOGAF standard, developed in 1995, was based on the US Department of Defense Technical Architecture Framework for Information Management (TAFIM). Starting from this sound foundation, The Open Group Architecture Forum has developed successive versions of the TOGAF standard at regular intervals and published each one on The Open Group public web site.
This document covers TOGAF Version 9.1, referred to as “TOGAF 9” within the text of this document. TOGAF 9.1 is a maintenance update and was published in December 2011. It supersedes the original TOGAF 9 that was published in January 2009.
TOGAF 9 can be used for developing a broad range of different enterprise architectures. The TOGAF standard complements, and can be used in conjunction with, other frameworks that are more focused on specific deliverables for particular vertical sectors such as Government, Telecommunications, Manufacturing, Defense, and Finance. The key to the TOGAF standard is the method – the TOGAF Architecture Development Method (ADM) – for developing an enterprise architecture that addresses business needs.
(Syllabus Reference: Unit 1, Learning Outcome 6: You should be able to describe the structure of the TOGAF standard, and briefly explain the contents of each of the parts.)
Table 3 summarizes the parts of the TOGAF document.
(Syllabus Reference: Unit 1, Learning Outcome 1: You should be able describe what an enterprise is.)
The TOGAF standard defines an “enterprise” as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.
The term “enterprise” in the context of “enterprise architecture” can be used to denote both an entire enterprise, encompassing all of its information systems, and a specific domain within the enterprise. In both cases, the architecture crosses multiple systems and multiple functional groups within the enterprise.
(Syllabus Reference: Unit 1, Learning Outcome 8: You should be able to explain what architecture is in the context of the TOGAF standard.)
ISO/IEC 42010:20078 defines “architecture” as:
“The fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
The TOGAF standard embraces but does not strictly adhere to ISO/IEC 42010:2007 terminology. In the TOGAF standard, “architecture” has two meanings depending upon the context:
1. A formal description of a system, or a detailed plan of the system at a component level to guide its implementation
2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time
(Syllabus Reference: Unit 1, Learning Outcome 2: You should be able to explain the purpose of an enterprise architecture.)
The purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy. Effective management and exploitation of information through IT is a key factor to business success, and an indispensable means to achieving competitive advantage. An enterprise architecture addresses this need, by providing a strategic context for the evolution of the IT system in response to the constantly changing needs of the business environment.
(Syllabus Reference: Unit 1, Learning Outcome 3: You should be able to list the business benefits of having an enterprise architecture.)
The advantages that result from a good enterprise architecture can bring important business benefits, including:
• A more efficient business operation:
— Lower business operation costs
— More agile organization
— Business capabilities shared across the organization
— Lower change management costs
— More flexible workforce
— Improved business productivity
• A more efficient IT operation:
— Lower software development, support, and maintenance costs
— Increased portability of applications
— Improved interoperability and easier system and network management
— Improved ability to address critical enterprise-wide issues, such as security
— Easier upgrade and exchange of system components
• Better return on existing investment, reduced risk for future investment:
— Reduced complexity in the business and IT
— Maximum return on investment in existing business and IT infrastructure
— The flexibility to make, buy, or out-source business and IT solutions
— Reduced risk overall in new investments and their costs of ownership
• Faster, simpler, and cheaper procurement:
— Simpler buying decisions, because the information governing procurement is readily available in a coherent plan
— Faster procurement process, maximizing procurement speed and flexibility without sacrificing architectural coherence
— The ability to procure heterogeneous, multi-vendor open systems
— The ability to secure more economic capabilities
(Syllabus Reference: Unit 1, Learning Outcome 4: You should be able to define what an architecture framework is.)
An architecture framework is a foundational structure, or set of structures, that can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.
Using an architecture framework will speed up and simplify architecture development, ensure more complete coverage of the designed solution, and make certain that the architecture selected allows for future growth in response to the needs of the business.
(Syllabus Reference: Unit 1, Learning Outcome 5: You should be able explain why the TOGAF standard is suitable as a framework for enterprise architecture.)
The TOGAF standard has been developed through the collaborative efforts of more than 300 Architecture Forum member companies from some of the world’s leading companies and organizations. Using the TOGAF standard results in enterprise architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration both to current requirements and to the perceived future needs of the business.
Developing and sustaining an enterprise architecture is a technically complex process which involves many stakeholders and decision processes in the organization. The TOGAF standard plays an important role in standardizing and risk reduction of the architecture development process. The TOGAF standard provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which address their business issues and needs.
(Syllabus Reference: Unit 1, Learning Outcome 9: You should be able to list the different types of architecture that the TOGAF standard deals with.)
TOGAF 9 covers the development of four architecture domains. These are commonly accepted as subsets of an overall enterprise architecture, all of which the TOGAF standard is designed to support. They are as follows:
(Syllabus Reference: Unit 1, Learning Outcome 6: You should be able to describe the structure of the TOGAF standard, and briefly explain the contents of each part.)
The TOGAF standard reflects the structure and content of an architecture capability within an enterprise, as shown in Figure 3.
Central to the TOGAF standard is the Architecture Development Method (documented in TOGAF 9 Part II: ADM). The architecture capability (documented in TOGAF 9 Part VII: Architecture Capability Framework) operates the method. The method is supported by a number of guidelines and techniques (documented in TOGAF 9 Part III: ADM Guidelines and Techniques). This produces content to be stored in the repository (documented in TOGAF 9 Part IV: Architecture Content Framework), which is classified according to the Enterprise Continuum (documented in TOGAF 9 Part V: Enterprise Continuum and Tools). The repository is initially populated with the TOGAF Reference Models (documented in TOGAF 9 Part VI: TOGAF Reference Models). These are described in the following sections.
The ADM describes a process for deriving an organization-specific enterprise architecture that addresses business requirements. The ADM is the major component of the TOGAF standard and provides guidance for architects on a number of levels:
• It provides a number of architecture development phases (Business Architecture, Information Systems Architectures, Technology Architecture) in a cycle, as an overall process template for architecture development activity.
• It provides a narrative of each architecture phase, describing the phase in terms of objectives, approach, inputs, steps, and outputs. The inputs and outputs sections provide a definition of the architecture content structure and deliverables (a detailed description of the phase inputs and phase outputs is given in the Architecture Content Framework).
• It provides cross-phase summaries that cover requirements management.
See also Chapter 5 and Chapter 7.
ADM Guidelines and Techniques provides a number of guidelines and techniques to support the application of the ADM. The guidelines address adapting the ADM to deal with a number of usage scenarios, including different process styles (e.g., the use of iteration) and also specific specialty architectures (such as security). The techniques support specific tasks within the ADM (such as defining principles, business scenarios, gap analysis, migration planning, risk management, etc.).
See also Chapter 8.
The Architecture Content Framework provides a detailed model of architectural work products, including deliverables, artifacts within deliverables, and the Architecture Building Blocks (ABBs) that deliverables represent.
The details of the Architecture Content Framework are out of scope for TOGAF 9 Foundation, and are covered instead in the Level 2 syllabus.
The Enterprise Continuum provides a model for structuring a virtual repository and provides methods for classifying architecture and solution artifacts, showing how the different types of artifacts evolve, and how they can be leveraged and re-used. This is based on architectures and solutions (models, patterns, architecture descriptions, etc.) that exist within the enterprise and in the industry at large, and which the enterprise has collected for use in the development of its architectures.
See also Section 3.4 and Chapter 6.
The TOGAF standard provides two reference models for possible inclusion in an enterprise’s own Enterprise Continuum.
See also Chapter 13.
The Architecture Capability Framework is a set of resources, guidelines, templates, background information, etc. provided to help the architect establish an architecture practice within an organization.
See also Section 3.6, Section 3.7, and Chapter 9.
This chapter has introduced the basic concepts of enterprise architecture and the TOGAF standard. This has included answering questions, such as:
• “What is an enterprise?”
— A collection of organizations that share a common set of goals, such as a government agency, part of a corporation, or a corporation in its entirety.
— Large corporations may comprise multiple enterprises.
— An “extended enterprise” can include partners, suppliers, and customers.
• “What is an architecture?”
— An architecture is defined as “the fundamental organization of something, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”
The TOGAF standard is an architecture framework. It enables you to design, evaluate, and build the right architecture for your organization. An architecture framework is a toolkit that can be used for developing a broad range of different architectures.
• It should describe a method to design an information system in terms of a set of building blocks, and show 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.
The value of a framework is that it provides a practical starting point for an architecture project.
The components of TOGAF 9 are as follows:
• Architecture Development Method (ADM)
• ADM Guidelines and Techniques
• The Architecture Content Framework
• The Enterprise Continuum and Tools
• TOGAF Reference Models
• The Architecture Capability Framework
Q1: Which one of the following statements best describes the TOGAF standard?
A. The TOGAF standard is a tool for developing Technology Architectures only.
B. The TOGAF standard is a framework and method for architecture development.
C. The TOGAF standard is a business model.
D. The TOGAF standard is a specific architecture pattern.
E. The TOGAF standard is a method for IT Governance.
Q2: Which one of the following best describes why you need a framework for enterprise architecture?
A. Architecture design is complex.
B. Using a framework can speed up the process.
C. Using a framework ensures more complete coverage.
D. A framework provides a set of tools and a common vocabulary.
E. All of these.
Q3: Which of the following is not considered one of the main constituent parts of the TOGAF document?
A. The Architecture Development Method
B. The Enterprise Continuum & Tools
C. The Technical Reference Model
D. The TOGAF Architecture Capability Framework
Q4: Which one of the types of architecture below is not commonly accepted as part of the enterprise architecture addressed by the TOGAF standard?
A. Business Architecture
B. Data Architecture
C. Application Architecture
D. Technology Architecture
E. Pattern Architecture
Q5: Which part of the TOGAF document provides a number of architecture development phases, together with narratives for each phase?
A. Part I: Introduction
B. Part II: Architecture Development Method (ADM)
C. Part III: ADM Guidelines and Techniques
D. Part IV: Architecture Content Framework
E. Part V: Enterprise Continuum and Tools
The following are recommended sources of further information for this chapter:
• TOGAF 9 Part I: Introduction, Chapter 1 (Introduction) and Chapter 2 (Core Concepts).
• Why Does Enterprise Architecture Matter?, White Paper by Simon Townson, SAP, November 2008 (W076), published by The Open Group (www.opengroup.org/bookstore/catalog/w076.htm)
_______________________
8 ISO/IEC 42010:2007, Systems and Software Engineering – Recommended Practice for Architectural Description of Software-Intensive Systems, Edition 1 (technically identical to ANSI/IEEE Std 1471-2000).