Togaf

Common sense
applied: Enterprise
Architecture, Process
Improvement,
Emotional
Intelligence
Wednesday, November 7, 2012
WHAT IS TOGAF ("CRIB NOTES")?
TOGAF is an extense body of knowledge describing what an Enterprise Architecture capability will look
like, after it it fully deployed in an organization.
According to TOGAF, an Enterprise Architecture capability is made up of :
 The method for developing new architectures
 The content framework
 The enterprise continuum
 The architecture repository
 The reference models
 The capability framework
These several parts of TOGAF are briefly described next. The following sections present the « crub
notes » for each one of these six key parts of TOGAF.
The figure reproduced below depicts and relates these parts of TOGAF. Each part has its own specific «
crub notes » section.
TOGAF - OVERVIEW
(A) ADM (Architecture Development Method)
The ADM describes what needs to be done in order to create an architecture. The ADM describes the 10
activities that are required for developing and managing an Enterprise Architecture. It is expected that the
generic ADM be customized for a particular organization.
TOGAF considers ADM as its core. It is the only part of the TOGAF body of knowledge that is considered
mandatory, if an organization wants to be TOGAF compliant. The other components might be replaced by
equivalent ones ; for example, the Architecture Content Framework may be replaced by the Zachmann
Framework.
The figure reproduced below presents an overview of TOGAF ADM.

TOGAF ADM
(B) Architecture Content Framework
The content framework describes what the architecture should look like once it is done. The architects
executing the ADM will produce a number of outputs. The Architecture Content Framework provides the
structure for organizing these outputs.
ACM uses three categories for classifying the architects’ work products:
 Deliverables
 Artifacts (granular architecture works – lists, matrices and diagrams)
 Building blocks (a potentially reusable architecture component)
The Architecture Content Metamodel identifies all the types of building blocks that may exist within an
architecture.
The figure reproduced below depicts the Architecture Content Metamodel.

TOGAF ARCHITECTURE CONTENT FRAMEWORK
(C) Enterprise Continuum
No architecture is developed from the scratch. The architects build on previously existing knowledge.
During their engagements, the architects use diverse architecture and solution models – foundation
models, industry models, etc. – that are extended and customized to the organizations’ needs. They
represent invaluable knowledge, that has to be leveraged if the architecture team will produce assets that
create value to the organization.
The Enterprise Continuum organizes the models used by the architecture team, in a way that is
meaningful to the organization.
The figure reproduced below depicts the general organization of the Enterprise Continuum.
TOGAF ENTERPRISE CONTINUUM
(D) Architecture Repository
The architecture work creates a huge volume of architectural output. Effective management and leverage
of these contents require a formal taxonomy, processes and tools. TOGAF « provides a structural
framework for an Architecture Repository that allows an enter pr ise to distinguish between different types
of architectural assets that exist at different levels of abstraction in the organization ».
The Architecture Repository holds six classes of information.

 The Architecture Metamodel
 The Architecture Capability
 The Architecture Landscape
 The Standards Information Base
 The Reference Library
 The Governance Log
The figure reproduced below depicts the structure of the TOGAF Architecture Repository and some
relationships with other enterprise contents.
ARCHITECTURE REPOSITORY
(E) Reference Models
An Enterprise Architecture requires at least one « Reference Model », that defines the complete
landscape of IT asset categories.
The reference model has double function

 It sets the taxonomy of IT assets, so that all participants in the organization talks the
same language when discussing about the assets
 It provides a diagramatic representation of the IT asset landscape, facilitating the
communication between architects and the rest of participants in the IT processes
Other reference models may be used, for focusing on specific areas of the IT asset landscape.
The figure reproduced below depicts the TOGAF Technical Reference Model.
TOGAF TRM
(F) Capability Framework
The enterprise architecture function requires a set of appropiate organization structures, processes, roles,
responsibilities and skills. TOGAF Architecture Capability Framework provides a set of reference
materials for this matter. Despite they do not make up a comprehensive template, these reference
materials are of great value for the architecture team.
The figure reproduced below depicts the overall structure of the TOGAF Architecture Capability
Framework.
TOGAF ARCHITECTURE CAPABILITY FRAMEWORK
The following sections present the « crub notes » for each one of these six key parts of TOGAF.
TOGAF ARCHITECTURE CONTENT FRAMEWORK ("CRIB

NOTES")
TOGAF Architecture Content Framework
Architecture development is under way. Wev’e got the architecture capability up and running. The
architects are working on a number of engagements, applying the best of their skills and energy.
What will their work products look like ?
A few well known architecture frameworks deal with the enterprise architecture content domain. The
Zachmann Framework and UK Ministry of Defense are two good examples. These frameworks have
some material related to methodology and governance, but they concentrate primarily on the organization
of the outcomes of the work products generated by the architects.
TOGAF’s authors (The Open Group Architecture Forum) have dedicated a rich section of TOGAF to the
organization and « framing » of the work products generated by the architecture team. TOGAF’s
approach is based on real practice, kind of « bottom up ». Most enterprise architecture practitioners will
immediately feel familiar with the organization of the contents proposed by TOGAF, even if they have
been using a different framework or no framework at all, only his common sense.
TOGAF’s approach to Architecture Content is based on the following ideas :

 The set of objects (« building blocks ») the enterprise architect deals with is limited
and can be fully described in a model. This is the Content Metamodel.
 The Content Metamodel has to be flexible, in order to adjust to the different contexts
found in the organizations.
 The architects produce « deliverables » and describe the « building blocks » (for
sure !). However, they aren’t the only products that have to be managed. In order to reach
effectiveness and efficiency, the intermediate, more atomic « artifacts » generated by the
architecture work have to be managed as well. The artifacts have higher reusability than the final
deliverables and building blocks.
 The enterprise architecture content represents the whole organization, and that is too
much information. In order to get effective communication with the stakeholders and participants,
the architecture contents has to presented in « views » that address the particular concerns of
each interest group.
« A TOGAF architecture is based on defining a number of architectural building blocks within architecture
catalogs, specifying the relationships between those building blocks in architecture matrices and then
presenting communication diagrams that show in a precise and concise way what the architecture is. »
The figure reproduced below depicts in a diagram the key roles that take part in the TOGAF Architecture
Content Framework.
TOGAF CONTENT METAMODEL - OVERVIEW
TOGAF Architecture Content Metamodel
« The content metamodel provides a definition of all the types of building blocks that may exist within an
architecture ». (« Building blocks » are presented below. If you are thinking of LEGO blocks, you are right.
Business functions, data entities, application components and technology components are examples of
building block categories.)
We’ve already seen that, while executing an ADM engagement, the architecture team will :
 Define a « vision » for the engagement
 Manage the requirements identified by architecture
 Define the baseline architecture and the target architecture, for the four domains :
business, data, applications and technology
 Define the work packages, projects and programs to the executed
 Govern the execution of those projects and programs
The Architecture Content Metamodel presents the structured set of objects (or « building blocks ») that is
generated by the architects executing the ADM. « The ADM describes what needs to be done to create
an architecture and the content framework describes what the architecture should look like once it is
done. »
TOGAF’s authors have created a metamodel made up of 32 entities. Minor inconsistencies among parts
of the text reveal the intensity of the debate before reaching the current result. A few aspects of the
metamodel are not completely clear. The final result is definitely invaluable for the enterprise architect.
TOGAF Architecture Content Metamodel is a detailed data model, encompassing the 32 entities, their
respective attributes and the relationships among them. Any enterprise architecture should fit in TOGAF
content metamodel.
The figure reproduced below presents an overview of the TOGAF Architecture Content Metamodel.
TOGAF ARCHITECTURE CONTENT METAMODEL
The figure reproduced below presents the entity-relationship view of the full metamodel.
CONTENT METAMODEL - ENTITY-RELATIONSHIP VIEW
TOGAF Architecture Content Metamodel : Core Content and Extensions
There is no « onse size fits all » in enterprise architecture. Each organization, in each phase, has a
different context for the enterprise architecture engagements. Budget and time restrictions might impose
restrictions on the scope.
A few examples of variable conditions that might apply :

 The business drivers might be fully defined or they might be a rough draft
 Business processes might be fully modeled, or their modeling might be out of scope
 Services (meaning a Services Oriented Architecture) might be key to the modelling, or
they might be not considered at all
 Technology domain might be a key concern, or it might be out of scope
Other architecture content frameworks intended for specific organizations are very specific in their
modeling of objects. This is the case with MODAF (intended for use in the UK Ministry of Defense) and
DODAF (intented for use in the US Department of Defense). TOGAF is intended to be used by any kind
of organization ; how to cope with the range of different contexts ?
The solution proposed by TOGAF is to structure the metamodel object types in a few groups. There is a
« core » set of objects that are required in all contexts. To this core, a few optional groups can be added.
If all optional groups were added, we’d get the complete model we’ve seen above.
One gets the feeling that the resulting grouping is not completely « natural », meaning that if the exercise
of grouping the entities were repeated by a different work group, the result might have been different.
Anyway, it is an excellent model to follow.
The picture reproduced below represents the core content metamodel and the six extensions.
TOGAF CONTENT METAMODEL - CORE AND EXTENSIONS
TOGAF’s architecture core content metamodel is made up of 17 entities. The remaining 15 entities (the
full metamodel is made up of 32 entities) are distributed in the 6 optional extensions.
The 17 entities TOGAF authors consider mandatory in order to build an enterprise architecture are
identified in the picture reproduced below.
TOGAF CORE CONTENT METAMODEL
It stands to reason that the majority of the mandatory, « non negotiable » entities in the metamodel are
the ones that make up the foundation of the architecture function and the ones that reflect the business
domain. The 15 entities that are classified as « extensions » add detail to the description of the resulting
architecture in the four domains (business, data, applications and technology).
TOGAF Architecture Content : Artifacts and Views
The architects produce « deliverables » and « building blocks ». However, these products are the final
outcomes and too coarse-grained to allow optimum content management. Before assemblying them, the
architects produce a whole lot of more atomic work products, called « artifacts ».
An « artifact » is a piece of documentation that captures any aspect of the system analyzed by the
architect and that is relevant to his work. While working on an existing or on a new system, the architect
will deal with a whole lot of viewpoints, information and stakeholders ; he will have to:
 Document aspects and components of the current system that are relevant to him, without getting
lost in too much detail
 Understand and document relatioships between aspects and components of the current system
 Capture facts and scenarios, in order to present them to the stakeholders and participants
 Detail to some degree the future scenarios
 Describe aspects and components of the target solution (again, without getting lost in details
 Understand and document relatioships between aspects and components of the target system
 Convince all of the stakeholders of the quality of his ideas, talking to each one in his own
language and addressing the concerns of his viewpoint
 Relate his ideas to the company’s objectives
TOGAF Content Framework identifies a set of artifacts that typically is generated by the architects’ work.
The artifacts are also called « viewpoints ». The combination of viewpoints make up the views of the
architecture.
Three classes of artifacts are generated :

 Lists
 Matrices
 Diagrams
The picture reproduced below represents the artifacts (or « viewpoints ») identified in TOGAF.
TOGAF CONTENT METAMODEL - ARTIFACTS
Combinations of artifacts allow the architects to tackle the concerns of all of the atakeholders, each one of
them requiring a specific view of the solution. The following views are identified in TOGAF. Additional
views will be added, depending on the nature of the architecture being developed.
 Business architecture view
 Enterprise security view
 Software engineering view
 System engineering view
 Communications engineering view
 Data flow view
 Enterprise manageability view
 Acquirer view
TOGAF Architecture Content : Deliverables
TOGAF proposes a taxonomy of deliverables that are typically produced during the execution of the ADM
cycle. For each one, TOGAF describes the general organization and provides an elaborated template.
The deliverables enumerated by TOGAF are listed below. They are grouped by the ADM phases in which
they are produced.
During the customization of TOGAF for a specific organization, the templates have to be extended and
detailed ; a deliverable such as « Architecture Definition Document » can include just about any contents.
 ADM Preliminary Phase
o Business Principles, Business Goals, and Business Drivers
o Architecture Principles
o Tailored Architecture Framework
o Request for Architecture Work
o Organizational Model for Enterprise Architecture
o Architecture Repository
 Phase A: Architecture Vision
o Statement of Architecture Work
o Capability Assessment
o Architecture Vision
o Communications Plan
 Phase B: Business Architecture
 Phase C: Information Systems Architectures — Data Architecture
 Phase C: Information Systems Architectures — Application Architecture
 Phase D: Technology Architecture
o Architecture Definition Document
o Architecture Roadmap
o Architecture Requirements Specification
 Phase E: Opportunities & Solutions
o Statement of Architecture Work
 Phase F: Migration Planning
o Implementation Governance Model
o Architecture Contract
o Architecture Building Blocks
 Phase G: Implementation Governance
o Solution Building Blocks
o Compliance Assessment
 Phase H: Architecture Change Management
o Change Request
o Requirements Impact Assessment
 ADM Architecture Requirements Management
o Architecture Requirements Specification
TOGAF Architecture Content : Building Blocks
« An architecture is a set of building blocks depicted in an architectural model, and a specification of how
those building blocks are connected to meet the overall requirements of the business.
The building blocks in an architecture specify the scope and approach that will be used to address a
specific business problem. »
In other words, an « architecture description » is a model that :

 identifies all of the building blocks in all of the categories in the Architecture Content Metamodel
(17 categories, if only the core model is used ; 32 categories, if all of the extensions are used) :
o all of the actors and roles
o all of the functions and processes
o all of the business services
o all of the application components
o all of the technology components
o etc.
 identifies all relationships between those building blocks
 describes each building block and each relationship in enough detail
 represents the set of building blocks and relationships in ways that can be understood by the
stakeholders
 « Building blocks have generic characteristics as follows:
 A building block is a package of functionality defined to meet the business needs across an
organization.
 A building block has a type that corresponds to the TOGAF content metamodel (such as actor,
business service, application, or data entity)
 A building block has a defined boundary and is generally recognizable 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 re-usable and replaceable, and well specified. »
The definition of the set of building blocks that make up an architecture is developed in two phases:
 Architecture building blocks (ABBs) in phases A to F
 Solution building blocks (SBBs) in phase G
« ABBs:
 Capture architecture requirements; e.g. business, data, application and technology
requirements
 Direct and guide the development of SBBs »
“SBBs:
 Define what products and components will implement the functionality
 Define the implementation
 Fulfil business requirements
 Are product or vendor-aware”
Typically, several ABBs map to SBBs in a obvious way, that will be promptly identified by the architects
and stakeholders.
The target architecture typically reuses to the maximum extent the building blocks already present in the
baseline architecture.
The picture reproduced below describes how the building blocks are developed during the ADM.
TOGAF ADM AND THE "BUILDING BLOCKS"
TOGAF ENTERPRISE CONTINUUM ("CRIB NOTES")

TOGAF Enterprise Continuum
The amount and variety of matters that are analyzed by an architect is overwhelming. The pace at which
she or he works, challenging. The effectiveness and efficiency of her/his work frames the whole IT
function.
In order to cope with the required performance, the architecture team have to build on previously existing
knowledge - in the same way a physician does his daily work applying well established protocols and
drugs. No architecture is developed from the scratch. During their engagements, the architects use
diverse architecture and solution models – foundation models, industry models, etc. – that are extended
and customized to the organizations’ needs. They represent invaluable knowledge, that has to be
leveraged if the architecture team will produce assets that create value to the organization.
TOGAF gives formal status to this general practice and dedicates a framework to it : the Enterprise
Continuum. The body of knowledge the architecture team reuses when they are working on an
engagement requires a thoughtful and dedicated management. The share of their time the architecture
team dedicates to building and managing this body of knowledge is well worth the effort later on, during
the architecture engagements. Higher effectiveness is reached, time and effort are saved, risks and costs
are lowered. Any time the architects dedicate to their professional development is benefitial ; the benefit is
doubled if they identify new contents for the organization’s Enterprise Continuum.
The TOGAF Enterprise Continuum can be thought of as a bidimensional index, classifying the knowledge
contents used by the architecture team in two dimensions :
 Abstract – concrete (vertical dimension)

 Generic – organization specific (horizontal dimension)
The Enterprise Continuum points to contents in the Architecture Repository or elsewhere (in other
repositories in the organization or in external web sites).
The figure reproduced below depicts the general organization of the Enterprise Continuum.
ENTERPRISE CONTINUUM - OVERVIEW
The Enterprise Continuum is partitioned in three distinct continua :
 Enterprise Context Continuum

o Classifies contextual assets such as policies, standards, strategic initiatives,
organizational structures and enterprise-level capabilities
 Architecture Continuum
o Represents a structuring of Architecture Building Blocks, from generic to organization-
specific entities.
 Foundation frameworks (e.g. TOGAF TRM and the whole TOGAF)
 Common system architectures (e.g. TOGAF III-RM, OASIS WS-* standards)
 Industry architectures (e.g. a logic data model for a particular vertical industry)
 Organization-specific architectures
 Solutions Continuum
o Represents a structuring of the Solution Building Blocks, from generic to organization-
specific entities.
 Foundation solutions (e.g. ITIL, EDIFACT)
 Common system solutions (e.g. a portal and content management product suite,
an ESB product)
 Industry solutions (e.g. a physical database schema specific to an industry)
 Organization-specific solutions
WHAT IS TOGAF ADM ("CRIB NOTES")?

TOGAF ADM (Architecture Development Method)
TOGAF ADM is the core of TOGAF. It is the only part of the TOGAF body of knowledge that is considered
mandatory, if an architecture organization wants to be « TOGAF compliant ».
The ADM describes the 10 activities that are required for developing and managing an Enterprise
Architecture. The figure reproduced below presents an overview of TOGAF ADM.
TOGAF ADM
Phase C activity is typically split in two : Data Architecture and Application Architecture.
It is expected that the generic ADM be customized for a particular organization.
Open Group TOGAF working group’s materials describe ADM in full detail and in shortened forms. These
« crub notes » briefly describe the purpose and outcomes of each activity, in my own words.
TOGAF ADM Approach
One of the corner stones of TOGAF is the « ADM cycles ». In TOGAF, in a mature architecture practice,
most of architecture work is organized in a succession of engagements, each one with its specific
objectives and scope.
Two workstreams, though, are performed in a more continuous mode : the ADM activities tagged as
« Preliminary » and « Phase H : Architecture Change Management ». The former encompasses the
building and the management of the basic capabilities required for executing the architecture
engagements. The latter encompasses the monitorization of the organization needs and of the
stakeholders, in order for capturing new needs leading to new architecture engagements.
In short, for TOGAF’s authors:

 the changes and the added value come from the specific and unique architecture
engagements, framed by their objectives, scope, budget and callendar
 the continuous activities of the architecture team are essential, but they are enablers and
do not generate change and new value by themselves
ADM : Preliminary Phase
The Preliminary Phase can be understood in two ways :

 the initial setup of the architecture capability in the organization and the later evolution and
management of this capability
 the update of such architecture capability, in order to complement it with the specific aspects
required for a new architecture engagement
 In other parts of TOGAF (specifically in « Part VII - Architecture Capability Framework »,
«Establishing an Architecture Capability ») the initial setup of the architecture capability is
presented as a full execution of the ADM cycle. However, in the description of the Preliminary
Phase, both goals are combined. This minor overlapping is not a big issue and can be easily
handled during the customization of TOGAF.

The maintenance and evolution of the architecture capabilities are continuous activities. On the
other hand, before a particular engagement, it should be expected to spot certain capabilities
related to the new engagement that should be reinforced, before the new ADM cycle starts.
 In its « continuous process » version, the scope of the Preliminary Phase encompasses :
 to identify the « architecture footprint » for the organization (i.e., the people executing architecture
work and their responsibilities)
 to define and establish the architecture framework (i.e., to tailor the ADM, the Content Framework
and the Enterprise Continuum)
 to define and establish the architecture governance model
 to integrate the enterprise architecture processes with the rest of management frameworks in the
organization
 to select and implement supporting tools (such as the tool for implementing the Architecture
Repository)
 to define the architecture principles, the standards and the reference models
 to assess the enterprise architecture maturity level
 On the other hand, in its more sctrict « preliminary » version, previous to a specific new
engagement, the scope of the Preliminary Phase encompasses :
 to identify the key drivers and elements in the organizatonal context
 to identify the stakeholders and their concerns
 to define the requirements for architecture work
 to identify the areas of the current architecture capability that have to be updated or increased
Phase A: Architecture Vision
Purpose. Phase A has two groups of actors : the architecture team and the stakeholders. It is aimed at
getting a clear understanding among both groups of the context, the business drivers and the business
goals that are claiming for a new architecture engagement. The goals of Phase A are:
 to establish the vision and the scope for the architecture engagement
 to get buy-in and commitment of the stakeholders
According to the spirit of TOGAF, the develoment work of the enterprise architecture team (Phases B to
F) should not start until there is a clear understanding with the stakeholders, formalized by their signature
of the outcomes of Phase A.
Outcomes of Phase A :
 Capability Assessment
o Identifies the business goals and strategic drivers of the organization.
o Defines what business capabilities (i.e. business functions) the organization will need to develop in
order to fulfill its business goals and strategic drivers.
o Assesses the current capabilities and the implications of the new requirements for the organization.
 Architecture Vision
o Defines the purpose of the new architecture engagement (i.e., how the new engagement will allow the
organization to meet the new capability requirements).
o « The Architecture Vision provides a first-cut, high level description of the Baseline and Target
Architectures, covering the business, data, application and technology domains. » (that is, « pencil-
sketches » or « version 0.1 » of these architectures).
o « A common practice is to draw a simple solution concept diagram that illustrates concisely the major
components of the solution and how the solution will result in benefit for the enterprise ».
o Architecture vision aims at the communication with the stakeholders ; completeness and exactitud will
come later, in the following phases B, C and D.
 Statement of Architecture Work
o Defines the scope of the engagement
o Defines the target architecture value proposition and KPI’s (i.e., an agreement on how to assess the
success of the architecture engagement, after it is completed)
o Identifies the business transformation risks and mitigation activities
o Develops initial high level plans
 Communications plan:
o Identifies all stakeholders and their information needs
o Shows where, how and when the architects will communicate with them
All Phase A deliverables are aimed at the stakeholders, whose understanding, buy-in and commitment
must be granted, if the new architecture engagement is to be successful.
Phase B: Business Architecture
Purpose. Phase B defines the target business architecture and the roadmap components that are related
to the business domain.
The business architecture is the structured collection of the following building blocks :
 Business services (bound by a service contract) and business functions (not bound)
 Drivers/goals/objectives
 Organizations/actors/roles
 Locations
 Business processes (i.e. Process/Event/Control/Product)
 Contracts/Measures
In Phase B, the following views of the business architecture are developed :
 Baseline business architecture
 Target business architecture
 Gap analysis between the two
 Business roadmap for prioritizing activities
Outcomes of Phase B :
 Architecture Definition Document (chapters related to the business domain)
o Business footprint (high level description of people and locations involved)
o Business functions and their information needs
o Baseline business architecture v1.0
o Defines criteria for prioritizing these activities
 Architecture Requirements Specification (chapters related to the business domain)
o Functional requirements
o Non-functional requirements
o Assumptions, constraints, domain specific Business Architecture principles
o Policies, Standards and Guidelines
Phase C: Information Systems Architectures — Data Architecture
Purpose. Phase C (Data Architecture) defines the major types and sources of data necessary to support
the business. It is NOT concerned with database design – what comes on a later phase, during software
engineering.
All data management issues are of interest, including :
o Processes, services and application components that create and use the data
o Corporate standards
o Data transformations
o Data interfaces (with internal and external systems)
o Data migration
o Data governance
 The data architecture is concerned with the following building blocks :
o Data entity / data component
 In Phase C (Data Architecture), the following views of the data architecture are developed :
o Baseline data architecture
o Target data architecture
o Gap analysis between the two
o Criteria for prioritizing activities in the roadmap
 Outcomes of Phase C (Data Architecture) :
 Architecture Definition Document (chapters related to the data domain)
o Baseline data architecture v1.0
o Target data architecture v1.0
o Views for selected viewpoints
 Architecture Roadmap (chapters related to the data domain)
o Identifies the activities related to the data architecture domain
 Architecture Requirements Specification (chapters related to the data domain)
o Assumptions, constraints, domain specific Business Architecture principles
Phase C: Information Systems Architectures — Application Architecture
Purpose. Phase C (Application Architecture) defines the « application landscape » needed to support the
business. It is NOT concerned with application systems design. The goal is to identify the logical
application components, their relationships, and to describe each one with enough detail.
All issues related to the applications are of interest, including :
 Application and user location
 Application communication
 Manageability
 Process/system realization
 Application migration
 Software engineering
 The application architecture is concerned with the following building blocks :
 Application components
 Interface catalog
 In Phase C (Application Architecture), the following views of the application architecture are
developed :
 Baseline application architecture
 Target application architecture
 Criteria for prioritizing activities in the roadmap
 Outcomes of Phase C (Application Architecture) :
 Architecture Definition Document (chapters related to the application domain)
o Baseline application architecture v1.0
o Target application architecture v1.0
 Architecture Roadmap (chapters related to the application domain)
o Identifies the activities related to the application architecture domain
 Architecture Requirements Specification (chapters related to the application domain)
o Assumptions, constraints, domain specific Architecture principles
Phase D: Technology Architecture
Purpose. Phase D defines the « technology landscape » needed to support the business. As technology
architecture defines the physical realization of an architecture solution, it has strong links to
implementation and migration planning.
The technology architecture supports the cost assessment of different scenarios.
All issues related to the technology domain are of interest, including :
 Physical locations
 Sizing and capacity planning
 Installation, governance and migration
 Performance
 Maintainability
 Availability
The technology architecture is concerned with the following building blocks :
 Technology standards
 Technology portfolio
In Phase D, the following views of the technology architecture are developed :
 Baseline technology architecture
 Target technology architecture
 Criteria for prioritizing activities in the roadmap
Outcomes of Phase C (Application Architecture) :
 Architecture Definition Document (complete, including the technology domain)
o Baseline architecture v1.0
o Target architecture v1.0
 Architecture Roadmap (complete)
o Identifies the activities related to all domains
o Defines criteria for prioritizing the activities
 Architecture Requirements Specification (complete, including the technology domain)
o Assumptions, constraints, domain specific Architecture principles
Phase E: Opportunities & Solutions
Purpose. Phase E addresses the scope of the projects that will deliver the new architecture. Phase E is
not concerned with the delivery aspects, which are examined in Phase F.
In Phase E, the architecture team:
 reviews and consolidates the gap analysis done in Phases B, C and D
 identifies all work packages and organizes them into projects and portfolios
 develops a series of transition architectures, for moving incrementally from the baseline
architecture to the target architecture
 creates portfolio and project charters
Phase F: Migration Planning

Purpose. Phase F addresses the formulation of an implementation and migration plan, for executing the
transaction architectures and the target architecture identified in Phase E.
In Phase F, the architecture team :
 estimate resource requirements, project timings and delivery vehicles for each project
 prioritize the migration projects (assessing cost, benefits and risks)
 generates the architecture implementation roadmap (time lined)
Main outcomes of Phase F : will guide the implementation projects in Phase G
 Architecture Definition Document (reviewed version)
 Architecture Requirements Specification
 Architecture Contracts
 Implementation and Migration Plan
Phase G: Implementation Governance

Purpose. To guide and monitor the implementation of the projects defined in Phase F.
In Phase G, the architecture team:
 guides development of solutions deployment and formulate recommendations
 governs and manages the Architecture Contracts
 performs enterprise architecture compliance reviews
 implements business and IT operations
Phase H: Architecture Change Management

Purpose : Though it appears as Phase H of the ADM cycle, Architecture Change Management can be
better seen as a continuous activity, monitoring the new architecture resulting of the current architecture
engagement in its entirety (that is, the whole enterprise architecture, not only the building blocks that were
altered by the last engagement).
Phase H objectives are :
 to monitor whether the baseline architectures are fit for purpose
 to assess the performance and business value of the architecture and to make
recommendations for improvement
 to run the architecture change management process
 to operate the architecture governance framework
ADM Architecture Requirements Management

The requirements management process is executed on a continuous basis, meaning that it interacts with
all processes in the ADM cycle.
The initial set of requirements in a new engagement (Phase A) is aimed at the architecture team, who
needs to make sure they had good communication with the stakeholders.
The requirements generated in Phases B to F are aimed at the implementation teams in Phase G. They
are formalized in the « Architecture Requirements Specification », one of the key inputs delivered to the
implementation teams.
TOGAF does not mandate a specific process or tool. It is up to the organization to select their own
options.
TOGAF TRM ("CRIB NOTES")

What are Reference Models used for ?
There are two main purposes behind the Reference Models :
 to establish a taxonomy shared by all participants in the architecture and engineering
processes
 to establish the complete map of the architecture domain
Shared taxonomy. Establishing an « official » taxonomy for IT assets is not a trivial task. Endless hours
are spent in the most innefficient way because of misunderstandings among the participants in the
development processes. Even seemingly simple terms such as « CPU » can generate confusion. There
several kinds of CPU’s and in a virtualized environment what is a CPU may not be clear.
Moreover, a taxonomy should take into account the established names in the organization, for lowering
resistance and avoiding a costly « reeducation process ». Hence, it takes some effort. The pay-off is not
easy to measure, as it comes under the form of saved time in future meetings and the avoindance of
awkward situations generated by misunderstandings.
The complete map. The reference model provides the « big picture » of the domain. Typically, each
participant in the development processes is deeply concerned with the tasks and challenges that direct
depend on him, at the same time he is oblivious to the rest of areas. If the IT landscape is compared to a
city, each participant is concerned only about his neighborhood. The reference model facilitates the
architecture team to argue with the stakeholders going beyond their immediate concerns.
TOGAF Technical Reference Model (TRM)

The TOGAF Technical Reference Model (TRM) is an architecture of generic services and functions that
provides a foundation on which more specific architectures and architectural components can be built.
Any TRM has two components :

 A taxonomy (which provides a coherent description of the components and conceptual
structure of the information systems)
 The TRM graphic (which provides a visual representation of the model)
The TRM is expected to be customized for each organization.

The TRM can be used as a taxonomy to develop a Standards Information Base (SIB).
TOGAF TRM is organized in three major entities (Application Software, Application Platform and
Communications Infrastructure) connected by two interfaces (Application Platform Interface and
Communications Infrastructure Interface).
The figure reproduced below depicts the TOGAF Technical Reference Model.
TOGAF TRM
Application software
This entity encompasses Business Applications and Infrastructure Applications.
Business Applications
Implement business processes for a particular enterprise or vertical industry. This section of the model
identifies all of the application components used in the organization.
A few examples :
 Patiente record management (in the Medical industry)
 Inventory management (in Retail)
 Geological data modeling (in Petroleum)
 Vehicle tracking (in Logistics)
Infrastructure Applications
Provide general purpose business functionality, based on infrastructure services. They typically have the
following characteristics :
 Widespread availability as COTS software means that it is uneconomic to consider
custom implementation.
 User interaction is an important part of the application’s function.
 Implementations are based on infrastructure services.
 Implementations may include significant extensions beyond that needed to use the
underlying infrastructure services.
 Interoperability is a strong requirement.
A few examples :
 Groupware services
 Spreadsheets
 Document editing and presentation
 System and network management applications
 Software engineering tools
Application platform
The Application Platform identifies and provides structure to the set of technical services that are required
for supporting the business and infrastructure applications. It is the green area in the above diagram. The
technical service groups are :
 Graphics and image

 Data management
 Data interchange
 User interface
 International operations
 Location and directory
 Transaction processing
 Security
 Software engineering
 System and network management
 Operating systems services
 Network services
Additional groups or some regrouping might be adopted in an organization.

An additional purpose of the TRM is to avoid too much heterogeneity. Ideally, each service should be
provided by a single component, what makes asset management much more efficient.
Application platform interface

The Application Platform Interface (API) specifies a complete interface between the Application Software
and the underlying Application Platform.
The goal is to achieve full application portability.
Communications infrastructure
The Communications Infrastructure provides the services to interconnect systems. It deals with the
complex world of networks and the physical Communications Infrastructure, including switches, service
providers, and the physical transmission media. Currently, Internet typically plays a role in this domain.
Communications infrastructure interface

The Communications Infrastructure Interface is the interface between the Application Platform and the
Communications Infrastr ucture.
The goal is to achieve full interoperability.
Qualities
There is a set of attributes or qualities that are applicable across all TRM components. For example, for
the management service to be effective, manageability must be a pervasive quality of all platform
services, applications, and Communications Infrastructure services.
Taxonomy of Service Qualities

The service qualities presently identified in the TRM taxonomy are:
 Availability (the degree to which something is available for use), including:

o Manageability
o Serviceability
o Performance
o Reliability
o Recoverability
o Locatability
 Assurance, including:
o Security
o Integrity
o Credibility
 Usability, or ease-of-operation by users, including:
o International Operation
 Adaptability, including:
o Interoperability
o Scalability
o Portability
o Extensibility
ARCHITECTURE MATURITY MODEL ("CRIB NOTES")
Architecture Maturity Model
In the past years, the Capability Maturity Models have been extensively used by many organizations, for
assessing their status and guiding the improvement of their IT related processes, mainly in the software
and systems engineering areas.
« Such models provide the following benefits :

 They describe the practices that any organization must perform in order to improve its
processes
 They provide a yardstick against which to periodically measure improvement
 They constitute a proven framework within which to manage the improvement efforts
The various practices are typically organized into five levels, each level representing an increased ability
to control and manage the development environment. »
TOGAF 9 does not provide an « official » Maturity Model for Enterprise Architecture. It does provide,
however, a quite detailed example, taken from the US Department of Commerce.
US DoC Architecture Maturity Model
The DoC ACMM consists of six maturity levels and nine architecture elements.
The six levels are :

0 – none
1 – initial
2 – under development
3 – defined
4 – managed
5 – measured
The nine enterprise architecture elements are

 architecture process
 architecture development
 business linkage
 senior management involvement
 operating unit participation
 architecture communication
 IT security
 architecture governance
 IT investment and acquisition strategy
The table below describes in a brief way the maturity levels 1 to 5. Level 0 means « no enterprise
architecture program ; no enterprise architecture to talk about. »
Enterprise
Level 1: Level 2: UNDER Level 3: Level 4: Level 5:
Architecture
INITIAL DEVELOPMENT DEFINED MANAGED MEASURED
Aspect
EA process is
architecture Ad hoc; Clear roles and largely EA process is EA process is under
process dependence on responsibilities are followed part of the constant
individual culture. Quality
efforts defined metrics are improvement effort
("heroes"). captured.
EA
Gap analysis
documentation is
Vision; principles; and migration Standards and
regularly
architecture Ad hoc, baseline and target plan are waivers process
updated. All
development localized architecture; completed. encompasses all IT
architectures
TRM; standards Standards decisions
comply to
framework profile is fully
standards.
developed
CAPEX and
EA integrated investment
Business is involved
business Explicit linkage to with CAPEX control take EA
Minimal in the continuous EA
linkage business strategies and investment as key input.
process improvement
control Periodic re-
examination of
business drivers.
Senior Senior
Senior
senior management management Senior management
management is
management Minimal actively directly involved is involved in the
aware of EA
involvement supports EA in EA review continuous EA
effort
process and process. process improvement
standards
Most elements The entire unit

Clear roles and Feedback from unit
operating unit support and supports and
Minimal responsibilities are drives EA process
participation actively actively
defined improvement
participate in participates in
EA process EA process
EA own web
Documentation Related web pages EA Architecture
architecture pages; they are
is are kept up to date documentation is documentation is
communication kept up to date
on the web with EA regularly updated used by every
with EA
deliverables decision maker in IT
deliverables
IT security
Clear roles and Performance
Ad hoc, architecture Feedback from IT
IT security responsibilities are metrics are
localized standards secutiry drives EA
defined captured
profile fully process improvement
developed
architecture Explicit
No governance
governance Some adherence toExplicit governance of all
Standards and
governance of
existing standards waivers process
majority of IT IT investments
profile encompasses all IT
investments
decisions
IT acquisition
IT investment Minimal Some adherence to strategy All planned IT No unplanned IT
and acquisition participation of existing standards complies with acquisitions are investment or
strategy EA profile EA; cost benefit governed by EA acquisition activity
analysis of
projects
TOGAF Architecture Repository ("CRIB NOTES")

TOGAF Architecture Repository
TOGAF states that a mature architecture capability requires an Architecture Repository in order to
structure all of the information generated and managed by the architecture team. TOGAF provides a
structural framework for such Repository.
« At a high level, six classes of architectural information are expected to be held within an Architecture
Repository : »
 The Architecture Metamodel

 The Architecture Capability
 The Architecture Landscape
 The Standards Information Base
 The Reference Library
 The Governance Log
The picture reproduced below illustrates TOGAF’s Framework for the Repository.
TOGAF ARCHITECTURE REPOSITORY
The Architecture Metamodel

Describes the architecture framework tailored to the organization, including:
 The Architecture Content Metamodel (i.e. the set of 17 to 32 categories of building

blocks, as defined for the organization)
 The set of artifacts (or viewpoints) as defined for the organization
 The set of deliverables
 The method for architecture development
The Architecture Capability
Defines the processes and the organization that support the governance of the architecture macro
functions :
 The management and development of the enabling capabilities (including training and
certification of the architects, management and development of the Enterprise Continuum,
development of new processes, etc.)
 Demand management and monitorization of request for changes
 The development of new architectures
The Architecture Landscape
Architectural views of the building blocks in the organization (such as the application landscape, data
landscape and technology landscape).
The architecture landscape is divided in three levels the granularity:
 Strategic architectures : show a long-term summary of the entire enterprise. This view is
used at the executive level, for setting directions.
 Segment architectures : show operating models for areas within an enterprise (business
functions, business services, process models). This view is used at the portfolio management
level, fur supporting planning.
 Capability architectures : detailed models of building blocks, describing the units of
capability (application component models, data element models, technology component models).
This view is used for defining the work packages.
Standards Information Base
The SIB provides a repository area to hold the corporate standards to which architecture building blocks
must conform.
Standards fall into three classes :
 Legal and regulatory obligations

 Industry's standards
 Organizational standards
The SIB is aimed at the teams developing new architectures. The governance of these projects by the
architecture team will assess the compliance of their products to the standards in the SIB.
The Reference Library

The Reference Library is intended to store « best practice », template and reference materials that may
be used/reused for building the new architectures (that is, part or all of the materials structured by the
Enterprise Continuum). This material includes :
 Foundation architectures
 Common systems architectures
 Industry architectures
 Organization specific architectures (developed in previous engagements and re-worked
for later reuse)
The Governance Log
The Governance Log holds information produced during the architecture governance processes, that
must be available for later use and reference.
It should contain the following groups of information:
 Decision log
 Compliance assessments
 Capability assessments
 Calendar
 Project portfolio
 Performance measurement
A good business scenario is also "SMART":
 Specific, by defining what needs to be done in the business

 Measurable, through clear metrics for success
 Actionable, by:
o Clearly segmenting the problem
o Providing the basis for determining elements and plans for the solution
 Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost
constraints
 Time-bound, in that there is a clear statement of when the solution opportunity expires
Architecture Repository:
Architecture Metamodel, Solutions Landscape, Architecture Requirements Repository,
Architecture Landscape, Reference Library, Standards Library, Governance Repository,
Architecture Capability
Architecture Governance beneficial because it provides discipline, fairness, transparency,

accountability
Phase: Requirements Management: Similar to the preliminary phase the requirements
management phase is outside of the phased ADM cycle, but is just as important as any other
phase if not more. The requirements management phase interacts with every other phase
providing a way tracking and managing the inputs & outputs from every ADM phase. This
information is tracked in the architecture repository.
The typical contents of an Architecture Vision are as follows:
• Problem description:
◦ Stakeholders and their concerns
◦ List of issues/scenarios to be addressed
• Objective of the Statement of Architecture Work
• Summary views necessary for the Request for Architecture Work and the draft Business, Data,
Application, and Technology Architectures
• Mapped requirements
• Reference to the Draft Architecture Definition Documen

Architecture Principles are general rules and guidelines that relate to architecture work. They are an
output of the Preliminary Phase. See the TOGAF Standard – ADM Techniques document (Architecture
Principles) for guidelines and a detailed set of generic Architecture Principles
The Architecture Definition Document is the deliverable container for the core architectural artifacts
created during a project and for important related information.
It is first created in Phase A, where it is populated with artifacts created to support the Architecture
Vision
Typical contents of an Architecture Definition Document include: • Scope • Goals, objectives, and
constraints • Architecture Principles • Baseline Architecture
• Architecture models (for each state to be modeled): ◦ Business Architecture, Data Architecture,
Application Architecture, Technology Architecture • Rationale and justification for architectural approach
• Mapping to Architecture Repository: ◦ Mapping to Architecture Landscape ◦ Mapping to reference
models ◦ Mapping to standards ◦ Re-use assessment • Gap analysis • Impact assessment • Transition
Architecture
Business Scenarios: The method can be used in any ADM phase; most notably it can be used in the
Preliminary Phase to define requirements for establishing an Enterprise Architecture Capability, the
initial phase of an ADM cycle, Phase A (where it is used to define relevant business requirements and to
build consensus with stakeholders), as well as in the Business Architecture phase, to derive the
characteristics of the architecture directly from the high-level requirements of the business.
Architecture Principles:
They address the following purposes: • Enabling decision-making – it is important to set precedence
during trade-off discussions and authority of “tie-breaking” if it must occur • Aligning the enterprise –
principles take subjectivity and bias out of the equation and drive critical conversations that are
objective and aligned to the enterprise’s values 5.3. Architecture Principles Chapter 5. ADM Techniques
56 The Open Group (2023) Personal PDF Edition. Not for redistribution. • Ensuring Governance – how
will the enterprise ensure that the right decisions are surfaced at the right time and with the right
decision-makers, and, moreover, how to monitor the decisions and approach taken to arrive at the
decision? • Understanding values and culture – provide a better understanding about the enterprise’s
culture and values; provide an approach and insight into how well the enterprise reacts to change
Discipline – all involved parties will have a commitment to adhere to procedures, processes, and
authority structures established by the organization.
Transparency – all actions implemented and their decision support will be available for inspection by
authorized organization and provider parties.
Independence – all processes, decision-making, and mechanisms used will be established so as to

minimize or avoid potential conflicts of interest.
Accountability – identifiable groups within the organization – e.g., governance boards who take actions
or make decisions – are authorized and accountable for their actions.
Responsibility – each contracted party is required to act responsibly to the organization and its
stakeholders.
Fairness – all decisions taken, processes used, and their implementation will not be allowed to create
unfair advantage to any one particular party
Compliance Assessment
Once an architecture has been defined, it is necessary to govern that architecture through
implementation to ensure that the original Architecture Vision is appropriately realized and that any
implementation lessons are fed back into the architecture process. Periodic compliance reviews of
implementation projects in Phase G provide a mechanism to review project progress and ensure that the
design and implementation is proceeding in line with the strategic and architectural objectives. Typical
contents of a Compliance Assessment are:
• Overview of project progress and status
• Overview of project architecture/design
• Completed architecture checklists:
◦ Hardware and operating system checklists
◦ Software services and middleware checklists
◦ Applications checklists
◦ Information management checklists
◦ Security checklists
◦ System management checklists
◦ System engineering checklists
◦ Methods and tools checklist
Typical contents of an Implementation Governance Model are: • Governance processes • Governance

organization structure • Governance roles and responsibilities • Governance checkpoints and
success/failure criteria
import org.apache.spark.sql.{SparkSession, Row}
import org.apache.spark.sql.functions.{split, explode}
val spark = SparkSession.builder.appName("WordExtraction").getOrCreate()
// Sample DataFrame creation
val df = Seq("Hello Rahul age 25 lives in Pune speaks 2 languages").toDF("data")

// Define a regular expression pattern to extract words
val reWord = "\\b[a-zA-Z]+\\b"
// Use the regular expression to extract words from the "data" column
val extractedWordsDF = df.select(explode(split(df("data"), " ")).alias("word")).filter(s"word RLIKE

'$reWord'")
// Show the extracted words
extractedWordsDF.show(false)
https://uwaterloo.ca/ist-project-management-office/tools-and-templates/tools
https://miro.com/blog/context-diagram/
https://support.unicomsi.com/manuals/systemarchitect/114100/starthelp.html#page/
Architecting_and_designing%2FTOGAF1005475.html%23
Activity diagram: a method of representing a process model to represent how a business operates
Affinity chart: synthesizes large amounts of data by finding relationships/themes between ideas to
discover common themes, connections, or root causes
Context diagram: show the interactions between a system and other actors (external factors) with which
the system is designed to interface
Fishbone diagram: illustrates the cause of a specific event, typically used for quality control or root
causes
Prioritization techniques: MoSCoW, priority matrix, priority scale, voting
Process and data modelling tools: process flow diagram, cross-functional process flow diagram, data flow
diagram, state diagram, entity-relationship diagram (ERD), class diagram, data dictionary
Identifying roles and responsibilities: (DRACI/DRASCI)
Use case: tool for capturing functional requirements of the system
Additional information can be acquired through the Business Analysis Body of Knowledge (BABOK) and
from the Project Management Body of Knowledge (PMBOK).
Building deliverables for the TOGAF Preliminary Phase
In the Preliminary Phase of TOGAF, you prepare for and begin activities required to meet the business
requirements for a new enterprise architecture.
Preliminary work of the enterprise architecture effort includes agreeing on the architecture principles of
the organization, deciding upon the framework and method you will use, defining the “architecture
footprint” for the organization (the people responsible for performing architecture work, where they are
located, and their responsibilities), and specifying the scope of the effort.
You can use the TOGAF framework, another framework, or tailor the TOGAF framework or another
framework to create a framework particular to your organization. Method wise, you can use TOGAF
Architecture Development Method (ADM), tailoring it as necessary, or use another method.
For a full description on how to build the architecture at this phase, see the TOGAF documentation at:
https://pubs.opengroup.org/togaf-standard/adm/chap02.html
This graphic is described in the surrounding text.
Deliverables for the Preliminary Phase
Catalogs (Reports)
•Principles Catalog.
Matrices
•No matrices are specified to be created during Preliminary Phase.
Core diagrams
•No diagrams are specified to be created.
Building deliverables for Phase A: Architecture Vision
In Phase A of the TOGAF Architecture Development Method (ADM) you establish the scope of the
architecture effort, get buy in from senior management and line management, and develop the vision of
the architecture effort.
The phase starts with a Request for Architecture Work, delivered from the sponsoring organization to the
architecture organization, and results in a the production of a Statement of Architecture Work.
Deliverables for Phase A: Architecture Vision

Catalogs (Reports)
•Stakeholder Catalog.
Matrices
•No matrices are defined to be created during Preliminary Phase.
Core diagrams
•Solution Concept diagram – as an aide to articulating the architecture vision, you can create Solution
Concept diagrams to provide a high-level view of the solution for an initiative.
•Business Model diagram.
•Business Capability Map.
Key Definition Types
The following outputs are created as a result of building Phase A:
•Statement of Architecture Work.
•Project, including scope, constraints, and the plan for the architectural work.
•Refined statements of Principle, Business Goal (see Relating Business Goals to Business Objectives by
using a matrix), and Driver.
•Architecture Principle.
•Architecture Vision, as specified within Statement of Architecture Work definition.
Business Scenario, including:
•Business Baseline version 1.
•Technical Baseline version 1.
•Business Architecture version 1.
•Technical Architecture version 1.
System Architect features to use
•You can use the workspace functionality (see Creating a workspace) within System Architect to model
these baseline and target architectures: creating a workspace for the baseline, version 0.1, and creating a
workspace for the target, version 0.1.
Building deliverables for Phase B: Business Architecture
In Phase B of the TOGAF Architecture Development Method (ADM) you establish the Business
Architecture of the organization.
Deliverables for Phase B: Business Architecture
Catalogs (Reports)
•Business Capabilities Catalog.
•Business Service/Function Catalog.
•Contract/Measure Catalog.
•Driver/Goal/Objective Catalog.
•Location Catalog.
•Organization Unit/Actor Catalog.
•Process/Event/Control Product Catalog.
•Role Catalog.
•Value Stream Catalog.
Matrices
•Actor/Role matrix.
•Business Interaction matrix.
•Capability/Organization matrix.
•Strategy/Capability matrix.
•Value Stream/Capability matrix.
Core diagrams
•Business Architecture diagram.
•Business Capability Map.
•Business Footprint diagram.
•Business Service Information diagram.
•Event diagram.
•Functional Decomposition diagram.
•Goal/Objective/Service diagram.
•Information Model.
•Organization Decomposition diagram.
•Organization Map.
•Process Flow diagram.
•Roadmap Marker diagram to model Product Lifecycle.
•Use Case diagram.
•The objectives of building the business architecture are to understand, describe, and model the current
(or baseline, or 'as is') business architecture, and then develop target, or to be business architectures. In
System Architect, you can use workspaces (see Creating a workspace) to enable baseline and target
architectures.
Building deliverables for Phase C: Information System Architectures
In Phase C of the TOGAF Architecture Development Method (ADM), you model the Information System
Architectures of the organization. This includes:
•The Data Architecture.
•The Application Architecture.
Building data architectures for TOGAF Phase C
Building the data architecture includes creating the following views of data:
•Information Model – very high-level view of data in the organization.
•Conceptual Data Model.
•Logical Data Model.
•Physical Data Models.
There are other prescribed models to show how data is used in the Enterprise Architecture, such as:
•Security of data.
•Migration of data within the architecture.
•Migration of data to future state architectures.
Deliverables for Phase C: Information (Data) Architecture
Catalogs (Reports)
•Data Catalog.
Matrices
•Entity/Function matrix.
•Application/Entity matrix.
Core diagrams
•Conceptual Data Model.
•Data Dissemination diagram.
•Data Migration diagram.
•Information Model.
•Logical ER diagram.
Building application architectures for TOGAF Phase C
The Application Architecture of the organization involves:
•Capturing the Application Portfolio. This entails:
•Understanding what Physical Application Components you have, who owns them, how they are used,
how much they cost, what vendor supplies them, and so on. This endeavor is called Application Portfolio
Management (APM).
•Optionally capturing what Logical Applications you have. A Logical Application layer enables you to
categorize what Physical Applications are being used. An example of a Logical Application Component is
“Enterprise Architecture tool”, or “Graphics tool”. An example of a Physical Application Component is
“System Architect”, or “Paint”.
•Understanding what Versions of Applications are deployed, and what versions of Technologies they use.
Note that the Physical Application Version definition is an extension to the TOGAF standard by UNICOM
Systems Inc.
•Making decisions on the Application portfolio – which applications to invest in, which to maintain, and
which to sunset – and the roadmap for decisions made.
•Understanding where the Physical Application Versions are deployed – on what Server Instances,
Device Instances, Database Instances – and where those are Located. Note that Device Instance, Server
Instance, and Database Instance are extensions to the TOGAF standard by UNICOM Systems Inc. for real-
world architecture. The TOGAF specification details that Physical Application Components are at
Locations.
Diagram Views that help you architect and visualize the Application Architecture are:
•Application Communication diagram.
•Application and User Location diagram.
•Network Infrastructure diagram.
Deliverables for Phase C: Application Architecture
Catalogs (Reports)
•Application Portfolio Catalog.
•Interface Catalog.
Matrices
•Application/Organization matrix.
•Role/Application matrix.
•Application/Function matrix.
•Application Interaction matrix.
Core diagrams
•Application Communication diagram.
•Application and User Location diagram.
•Application Migration diagram.
•Software Distribution diagram.
Building deliverables for Phase D: Technology Architecture
In Phase D of the TOGAF Architecture Development Method (ADM), you model the technology
architecture of the organization.
In Phase D of the TOGAF Architecture Development Method (ADM), you model the technology
architecture of the organization.
Deliverables for Phase D: Technology Architecture
Catalogs (Reports)
•Technology Standards Catalog.
•Technology Portfolio Catalog.
Matrices
•Application/Technology matrix.
Core diagrams
•Platform Decomposition diagram.
•Technical Architecture diagram.
Building deliverables for Phase E: Opportunities and Solutions
In Phase E of the TOGAF Architecture Development Method (ADM) you establish the Opportunities and
Solutions of the organization.
Deliverables for Phase E: Opportunities and Solutions
Catalogs
No catalogs are defined to be created during Phase E.
Matrices
No matrices are defined to be created during Phase E.
Core diagrams
•Project Context diagram – created using the Explorer diagram. Shows the scope of a work package to be
implemented as a part of a broader transformation roadmap. You can show how a work package is tied
to the organizations, functions, services, processes, applications, data, and technology that will be
added, removed, or impacted by the project.
•Benefits diagram – created using the Explorer diagram. Shows opportunities identified in an
architecture definition, classified according to their relative size, benefit, and complexity.
Extension diagrams
No extension diagrams are defined to be created during Phase E.
Inputs
Some of the inputs to this phase are:
•Request for Architecture Work.
•Statement of Architecture Work.
•Business Architecture.
•Building data architectures for TOGAF Phase C.
•Deliverables for Phase C: Application Architecture.
•Technical Architecture.
•Architecture Building Block.
•Products and Services profiles.
Outputs
Some of the outputs of this phase are the following artifacts:
•Impact Analysis.
•Project concept diagram.
Building deliverables for Phase F: Migration Planning
In Phase F of the TOGAF Architecture Development Method (ADM), you establish the Migration Planning
of the organization.
Deliverables for Phase F: Migration Planning
Relevant Definition Types

•Impact Analysis.
Catalogs (Reports)
•Any report using the “Cross Workspace” feature – to show difference between different versions of the
architecture.
Core diagrams
•Data Migration diagram.
•Application Migration diagram.
•Explorer diagram with analytics – to visualize the architecture at points in time.
•In System Architect, you can use workspaces (see Creating a workspace) to enable baseline and target
architectures.
Building deliverables for Phase G: Implementation Governance
In Phase G of the TOGAF Architecture Development Method (ADM), you establish the Implementation
Governance of the organization.
Deliverables for Phase G: Implementation Governance
Catalogs (Reports)
•Technology Standards catalog.
Core diagrams
•Explorer diagram – to report visually on how the architecture meets governance standards and
requirements
•In System Architect, you can use workspaces (see Creating a workspace) to enable baseline and target
architectures.
Building deliverables for Phase H: Architecture Change Management

In Phase H of the TOGAF Architecture Development Method (ADM), you establish the Architecture
Change Management of the organization.
Key activities within Phase G include:
Monitoring Implementation: This involves tracking the progress of architecture implementation

activities, ensuring that they are on schedule and within budget. It also involves monitoring the
performance of implemented solutions to ensure they meet the intended business objectives.
Conducting Compliance Reviews: This activity involves conducting regular reviews to ensure that
implemented solutions adhere to the architecture standards, principles, and guidelines defined earlier in
the ADM process.
Managing Changes: Implementation Governance includes managing changes to the architecture that
may arise during implementation. This involves assessing the impact of proposed changes on the
architecture and making decisions about whether to approve or reject them.
Addressing Issues and Risks: Implementation Governance involves identifying and addressing any issues
or risks that may arise during implementation. This may involve troubleshooting problems, resolving
conflicts, and mitigating risks to ensure the successful delivery of the architecture.
Providing Stakeholder Communication: Communication with stakeholders is critical throughout the

implementation process. This involves keeping stakeholders informed about progress, issues, and
changes related to the architecture implementation.
Key activities in Phase H include:
Establishing Architecture Change Management Process: In this activity, the architecture team establishes
a formal process for managing changes to the architecture. This process defines how changes are
identified, assessed, prioritized, and implemented, as well as how their impacts are analyzed and
communicated.
Identifying Change Requests: Change requests may come from various sources, including business
stakeholders, IT teams, regulatory requirements, or external factors. In this activity, change requests are
identified and documented, along with their rationale and potential impacts on the architecture.
Evaluating Change Requests: Change requests are evaluated based on their alignment with business
goals, architectural principles, and impact on the architecture. This evaluation helps to prioritize changes
and determine whether they should be approved, rejected, or deferred for further analysis.
Implementing Approved Changes: Approved changes are implemented according to the established
process and procedures. This may involve updating architectural artifacts, modifying systems or
applications, or reconfiguring infrastructure components. Change implementation should be carefully
managed to minimize disruption and ensure that changes are properly tested and validated.
Managing Change Dependencies: Changes to the architecture may have dependencies on other
components, systems, or initiatives. It's essential to identify and manage these dependencies to ensure
that changes are coordinated and integrated effectively.
Assessing Change Impact: Changes to the architecture may have implications for other parts of the
organization, including business processes, data models, and technology infrastructure. Change impact
assessments help to understand the broader implications of changes and plan accordingly.
Communicating Change: Effective communication is critical for ensuring that stakeholders are informed
and engaged throughout the change management process. This includes communicating change
decisions, impacts, and implementation plans to relevant stakeholders in a timely and transparent
manner.
Monitoring and Reporting: Throughout the change management process, progress is monitored, and
status updates are reported to stakeholders. This helps to track the implementation of changes, identify
any issues or risks, and ensure that changes are delivering the expected benefits.
Reviewing and Auditing: Periodic reviews and audits are conducted to assess the effectiveness of the
architecture change management process and identify areas for improvement. Lessons learned from
change management activities are captured and used to refine the process over time.
Key activities in Phase G include:
Establishing Governance Framework: In this activity, the architecture team establishes a governance
framework for overseeing the implementation of the architecture. This framework defines roles,
responsibilities, decision-making processes, and metrics for monitoring and controlling implementation
activities.
Monitoring Implementation Progress: Implementation progress is monitored against the planned

activities, schedules, and milestones defined in the architecture roadmap. This involves tracking the
progress of implementation projects, identifying any deviations or delays, and taking corrective actions
as needed.
Managing Implementation Risks: Risks associated with implementation projects are identified, assessed,
and managed to minimize their impact on the architecture initiative. This may involve implementing risk
mitigation strategies, escalating issues to appropriate stakeholders, and ensuring that risks are
monitored and controlled throughout the implementation process.
Conducting Compliance Reviews: Compliance reviews are conducted to ensure that implemented
solutions adhere to the architecture standards, principles, and guidelines defined earlier in the ADM
process. This helps to maintain architectural integrity and alignment with business objectives.
Addressing Issues and Exceptions: Issues and exceptions that arise during implementation are identified,
analyzed, and resolved in a timely manner. This may involve troubleshooting technical problems,
resolving conflicts between stakeholders, or revisiting architectural decisions to ensure that they remain
valid and appropriate.
Managing Change Control: Changes to the architecture that arise during implementation are managed
through a formal change control process. This process ensures that changes are properly evaluated,
approved, and implemented, while minimizing disruption to ongoing activities.
Providing Stakeholder Communication: Effective communication with stakeholders is critical throughout

the implementation process. This involves keeping stakeholders informed about progress, issues, and
changes related to the architecture implementation, as well as soliciting feedback and addressing
concerns as they arise.
Measuring and Reporting Performance: Performance metrics are defined to measure the success of
implementation activities and assess their impact on business objectives. Regular performance reports
are prepared and shared with stakeholders to provide transparency and accountability for
implementation efforts.
Reviewing and Improving Governance Processes: Periodic reviews are conducted to evaluate the
effectiveness of governance processes and identify opportunities for improvement. Lessons learned from
implementation activities are captured and used to refine governance processes over time.
Phase F:
Finalizing Transition Architectures: In this activity, the architecture team finalizes the Transition
Architectures, which are intermediate architectures that describe the steps required to move from the
baseline architecture to the target architecture. These Transition Architectures should be aligned with
the organization's overall business goals and objectives.
Identifying Transition Requirements: Transition requirements describe the changes needed to move from
the baseline architecture to the target architecture. During this activity, the architecture team identifies
and documents these transition requirements, including any necessary changes to processes,
applications, data, or infrastructure.
Developing Transition Architectures: With Transition Architectures and transition requirements in hand,
the architecture team develops detailed plans for each transition. This includes specifying the sequence
of migration steps, identifying dependencies between transitions, and estimating resource requirements
for each transition.
Identifying and Prioritizing Transition Projects: Based on the Transition Architectures and transition
requirements, the architecture team identifies the specific projects or initiatives needed to implement
the transitions. These projects should be prioritized based on factors such as business value, strategic
importance, and resource constraints.
Developing a Transition Strategy: A transition strategy outlines the overall approach to transitioning from
the baseline architecture to the target architecture. This strategy should consider factors such as timing,
sequencing, resource allocation, risk management, and stakeholder communication.
Finalizing the Transition Plan: The transition plan consolidates all the information gathered and
developed during Phase F into a comprehensive document. This plan should include detailed schedules,
resource allocations, budgets, risk assessments, and communication plans for each transition project.
Gaining Approval: Before proceeding with implementation, the transition plan should be reviewed and
approved by relevant stakeholders, including business leaders, project sponsors, and governance bodies.
This ensures alignment with organizational goals and secures necessary resources and support for
implementation.
Key activities in Phase E include:
Identifying Business Transformation Opportunities: During this activity, the architecture team works
closely with business stakeholders to identify opportunities for improving business processes, increasing
efficiency, reducing costs, or exploiting new technologies. These opportunities should be aligned with
the organization's strategic goals and objectives.
Identifying Information Systems Solutions: In this activity, the architecture team identifies potential
solutions to address the identified business transformation opportunities. This may involve evaluating
existing systems, technologies, and applications, as well as considering new solutions that could be
developed or acquired.
Assessing Solutions: Once potential solutions have been identified, they are assessed against a set of
criteria, including alignment with business objectives, feasibility, cost-effectiveness, and risk. This
assessment helps to prioritize solutions and determine which ones are most viable and beneficial for the
organization.
Developing Solution Proposals: Based on the assessment of potential solutions, the architecture team
develops detailed proposals for implementing the selected solutions. These proposals should include a
description of the solution, its benefits, costs, risks, and implementation considerations.
Evaluating and Selecting Solutions: Solution proposals are evaluated and compared to determine which
ones offer the best value and alignment with business objectives. This evaluation may involve conducting
cost-benefit analyses, risk assessments, and feasibility studies to inform the selection process.
Creating Implementation and Migration Plans: Once solutions have been selected, the architecture team
develops detailed plans for implementing and migrating to these solutions. These plans should outline
the steps, resources, timelines, and dependencies involved in the implementation process.
Gaining Approval: Before proceeding with implementation, solution proposals and implementation plans
should be reviewed and approved by relevant stakeholders, including business leaders, project sponsors,
and governance bodies. This ensures alignment with organizational goals and secures necessary
resources and support for implementation.
Key activities in Phase D include:
Developing Baseline Technology Architecture: In this activity, the architecture team documents the
current state of the technology infrastructure, including hardware, software, networks, and other
technology components. This baseline technology architecture serves as a reference point for identifying
gaps and defining future technology requirements.
Developing Target Technology Architecture: Based on the business requirements and architectural vision
established in previous phases, the architecture team develops a target technology architecture that
describes the desired future state of the technology infrastructure. This includes identifying technology
standards, platforms, and solutions that support the organization's strategic objectives.
Conducting a Gap Analysis: A gap analysis is performed to identify the differences between the baseline
and target technology architectures. This helps to identify areas where the current technology
infrastructure falls short of meeting business requirements and where new technologies or solutions are
needed.
Defining Transition Architectures: Transition architectures are intermediate architectures that describe
the steps required to move from the baseline technology architecture to the target technology
architecture. These transition architectures help to guide the implementation of technology changes and
ensure that they are aligned with the overall enterprise architecture.
Identifying Opportunities for Reuse: During this activity, the architecture team identifies opportunities to
reuse existing technology assets, solutions, and components. This helps to minimize costs and accelerate
the implementation of the target technology architecture.
Developing Implementation and Migration Strategies: Implementation and migration strategies are
developed to guide the deployment of new technology solutions and the transition from the baseline to
the target technology architecture. These strategies outline the sequence of implementation steps,
resource requirements, and timelines for technology changes.
Finalizing the Technology Architecture: The technology architecture is finalized based on the results of
gap analysis, reuse opportunities, and implementation strategies. This includes documenting the
technology standards, guidelines, and principles that will govern the design and deployment of
technology solutions within the organization.
Gaining Approval: Before proceeding with implementation, the technology architecture should be
reviewed and approved by relevant stakeholders, including business leaders, IT managers, and
governance bodies. This ensures alignment with business objectives and secures necessary resources
and support for implementation.
Key activities in Phase C include:
Developing Baseline Information Systems Architecture: In this activity, the architecture team documents
the current state of the information systems landscape, including existing applications, databases,
interfaces, and data stores. This baseline information systems architecture provides a foundation for
identifying areas of improvement and defining future information systems requirements.
Developing Target Information Systems Architecture: Based on the business requirements and
architectural vision established in previous phases, the architecture team develops a target information
systems architecture that describes the desired future state of the information systems landscape. This
includes identifying key application components, data entities, interfaces, and integration patterns
required to support business processes and objectives.
and target information systems architectures. This helps to identify areas where the current information
systems landscape falls short of meeting business requirements and where new applications or systems
are needed.
the steps required to move from the baseline information systems architecture to the target information
systems architecture. These transition architectures help to guide the implementation of information
systems changes and ensure that they are aligned with the overall enterprise architecture.
Identifying Opportunities for Reuse: During this activity, the architecture team identifies opportunities to
reuse existing applications, components, and data models. This helps to minimize costs and accelerate
the implementation of the target information systems architecture.
developed to guide the deployment of new applications and the transition from the baseline to the
target information systems architecture. These strategies outline the sequence of implementation steps,
resource requirements, and timelines for information systems changes.
Finalizing the Information Systems Architecture: The information systems architecture is finalized based
on the results of gap analysis, reuse opportunities, and implementation strategies. This includes
documenting the application components, data models, interfaces, and integration patterns that will
govern the design and deployment of information systems within the organization.
Gaining Approval: Before proceeding with implementation, the information systems architecture should
be reviewed and approved by relevant stakeholders, including business leaders, IT managers, and
governance bodies. This ensures alignment with business objectives and secures necessary resources
and support for implementation.
Key activities in Phase B include:
Developing Baseline Business Architecture: In this activity, the architecture team documents the current
state of the business landscape, including business processes, organization structure, capabilities, and
functions. This baseline business architecture provides a foundation for identifying areas of
improvement and defining future business requirements.
Developing Target Business Architecture: Based on the business drivers and architectural vision
established in previous phases, the architecture team develops a target business architecture that
describes the desired future state of the business landscape. This includes defining business processes,
organization roles, capabilities, and functions required to support business objectives and strategies.
and target business architectures. This helps to identify areas where the current business landscape falls
short of meeting business requirements and where changes are needed.
the steps required to move from the baseline business architecture to the target business architecture.
These transition architectures help to guide the implementation of business changes and ensure that
they are aligned with the overall enterprise architecture.
Identifying Opportunities for Business Improvement: During this activity, the architecture team identifies
opportunities for improving business processes, increasing efficiency, reducing costs, or exploiting new
business models. This helps to drive business innovation and competitive advantage.
developed to guide the deployment of new business processes and organizational changes. These
strategies outline the sequence of implementation steps, resource requirements, and timelines for
business changes.
Finalizing the Business Architecture: The business architecture is finalized based on the results of gap
analysis, opportunities for improvement, and implementation strategies. This includes documenting the
business processes, organization roles, capabilities, and functions that will govern the design and
operation of the business landscape.
Gaining Approval: Before proceeding with implementation, the business architecture should be reviewed
and approved by relevant stakeholders, including business leaders, executives, and governance bodies.
This ensures alignment with business objectives and secures necessary resources and support for
implementation.
Key activities in Phase A include:
Establishing the Architecture Vision: The architecture team works closely with key stakeholders to define
the vision for the enterprise architecture initiative. This vision articulates the long-term goals, objectives,
and desired outcomes of the architecture effort, aligning with the organization's strategic objectives and
business drivers.
Identifying Stakeholders and Concerns: During this activity, the architecture team identifies and engages
with stakeholders who have an interest in or will be impacted by the architecture initiative. Stakeholders
may include business leaders, executives, IT managers, end-users, and external partners. The team also
captures their concerns, needs, and expectations regarding the architecture.
Defining Business Scenarios: Business scenarios are developed to illustrate how the architecture will
address specific business challenges or opportunities. These scenarios help to validate the architecture
vision, clarify requirements, and prioritize architectural decisions.
Assessing Business Capabilities: The architecture team assesses the organization's current business
capabilities to understand its strengths, weaknesses, and areas for improvement. This assessment
informs the development of the architecture vision and helps to identify opportunities for business
transformation.
Developing a Statement of Architecture Work: A Statement of Architecture Work (SoAW) is created to

define the scope, objectives, and deliverables of the architecture initiative. This document serves as a
contract between the architecture team and stakeholders, outlining the expectations and commitments
for the architecture development process.
Identifying Risks and Constraints: Risks and constraints that may impact the architecture initiative are
identified and documented. This includes technical constraints, organizational constraints, budgetary
constraints, regulatory requirements, and other factors that may influence the architecture vision and
implementation.
Developing a Communication Plan: A communication plan is developed to ensure that stakeholders are
informed and engaged throughout the architecture development process. This plan outlines the
communication channels, frequency, and content for keeping stakeholders updated on progress,
decisions, and key milestones.
Gaining Approval: Before proceeding with further architecture development activities, the architecture
vision and the Statement of Architecture Work should be reviewed and approved by relevant
stakeholders, including business leaders, executives, and governance bodies. This ensures alignment
with business objectives and secures necessary resources and support for the architecture initiative.
This preliminary phase typically involves activities such as:
Understanding Organizational Context: This involves gaining a thorough understanding of the

organization's business goals, strategies, and objectives. It also involves identifying key stakeholders and
understanding their concerns and priorities.
Assessing Current State: This activity involves assessing the current state of the organization's
architecture, including existing systems, processes, technologies, and capabilities. This assessment helps
to identify strengths, weaknesses, opportunities, and threats that may impact the architecture initiative.
Establishing Governance Framework: Governance is critical for ensuring that the architecture initiative is
well-managed and aligned with organizational objectives. This involves defining governance structures,
roles, responsibilities, and decision-making processes for the architecture development process.
Securing Sponsorship and Support: Securing executive sponsorship and support is essential for the
success of the architecture initiative. This involves gaining buy-in from key stakeholders, including
business leaders, IT executives, and other decision-makers.
Defining Scope and Objectives: Clearly defining the scope and objectives of the architecture initiative
helps to ensure that it remains focused and aligned with business goals. This involves identifying the
scope of the architecture effort, defining the desired outcomes, and establishing measurable objectives.
Setting Up Architecture Framework and Tools: Selecting and setting up the appropriate architecture
framework and tools is essential for supporting the architecture development process. This may involve
selecting a standardized framework such as TOGAF, establishing architecture repositories, and
configuring tools for architecture modeling and analysis.
Developing Initial Architecture Principles: Architecture principles provide a set of guidelines and
constraints for architecture development. Developing initial architecture principles helps to establish a
common understanding and direction for the architecture initiative.
Creating Communication Plan: Effective communication is critical for engaging stakeholders and keeping
them informed throughout the architecture development process. Developing a communication plan
helps to define communication channels, frequency, and content for keeping stakeholders updated on
progress and key decisions.
The approach of the TOGAF ADM Preliminary Phase is about defining "where, what, why, who, and how
we do architecture". Which one of the following statements is false?
Architecture Principles
The TOGAF standard provides fundamental content and key functionalities to support enterprise
architecture development and management. Here are some key functionalities and components of
TOGAF:
Architecture Development Method (ADM):
The ADM is a step-by-step process for developing and managing enterprise architectures.
It provides guidelines, templates, and techniques for each phase of the architecture development
lifecycle, from inception to implementation.
Architecture Content Framework:
Defines the types of architectural artifacts and deliverables that should be produced during the ADM.
It includes guidelines for creating and organizing architecture artifacts such as catalogs, matrices,
diagrams, and documents.
Enterprise Continuum:
The Enterprise Continuum provides a structured repository for organizing and classifying architecture
assets, including models, patterns, standards, and reference architectures.
It categorizes assets based on their level of abstraction and generality, ranging from generic foundation
architectures to organization-specific architectures.
TOGAF Reference Models:
TOGAF provides reference models such as the TOGAF Technical Reference Model (TRM) and the
Integrated Information Infrastructure Reference Model (III-RM).
These models offer standardized architectures and building blocks for designing and integrating IT
solutions within the enterprise.
TOGAF Content Metamodel:
The Content Metamodel defines a standard set of entities and relationships for describing architecture
content.
It provides a common language and structure for representing architecture artifacts and their
interdependencies.
Architecture Capability Framework:
Describes the organizational structures, roles, responsibilities, and processes needed to establish and
operate an effective architecture practice.
It includes guidance on governance, stakeholder management, competency development, and

architecture maturity assessment.
TOGAF Tools and Techniques:
TOGAF recommends various tools and techniques to support architecture development, analysis, and
communication.
These tools include modeling languages (e.g., ArchiMate), architecture repository systems, assessment
frameworks, and communication frameworks.
TOGAF Certification Program:
The TOGAF Certification Program offers certification exams and training courses for architects and
practitioners.
It validates individuals' knowledge and proficiency in applying TOGAF principles, methods, and
techniques.
Here's how the approach addresses the key questions you mentioned:
Where: This refers to the scope and context of the architecture effort. It involves identifying the scope of
the enterprise or specific domains within it that will be covered by the architecture. It also involves
understanding the organizational context, including the business drivers, strategies, and constraints that
will influence the architecture.
What: This relates to the objectives and outcomes of the architecture effort. It involves defining the
purpose of the architecture, the desired business outcomes, and the key architectural concerns that
need to be addressed. It also involves identifying the stakeholders who will be impacted by or involved in
the architecture.
Why: This involves understanding the rationale and justification for undertaking the architecture effort. It
involves identifying the business drivers, challenges, and opportunities that necessitate architectural
change. It also involves assessing the benefits and value that the architecture will deliver to the
organization.
Who: This involves identifying the key stakeholders and roles involved in the architecture effort. It
includes identifying the architecture sponsor or champion who will provide leadership and support for
the initiative. It also involves identifying the architecture team members, including architects, subject
matter experts, and other stakeholders who will contribute to the architecture development process.
How: This involves defining the approach, methods, and resources needed to execute the architecture
effort. It includes establishing the governance framework, processes, and tools that will be used to
develop, manage, and communicate the architecture. It also involves identifying any dependencies, risks,
or constraints that need to be addressed.
Here's a typical structure of the section highlighting the business benefits:
Rationale/Justification: This section explains the reasoning behind the principle and why it is necessary
for the organization. It may include a brief overview of the business context, challenges, or opportunities
that the principle addresses.
Business Benefits: This subsection outlines the specific benefits that adhering to the principle will bring
to the organization. It may include both tangible and intangible benefits, such as increased revenue,
improved customer satisfaction, reduced time to market, enhanced agility, or better compliance with
regulations.
Alignment with Business Objectives: This subsection demonstrates how the principle aligns with the
organization's overall business objectives and strategic priorities. It explains how adhering to the
principle supports the organization's mission, vision, and goals.
Return on Investment (ROI): If applicable, this subsection quantifies the potential return on investment
associated with implementing the principle. It may include estimates of cost savings, revenue
generation, or other financial metrics that demonstrate the value of adhering to the principle.
Risk Mitigation: This subsection discusses any risks or challenges that the principle helps mitigate or
address. It explains how adhering to the principle can reduce operational, financial, or compliance risks
for the organization.
In the TOGAF standard, the risk categorization after the implementation of mitigation actions is defined
as "Residual Risk." Residual risk refers to the level of risk that remains after mitigation measures have
been implemented. It represents the remaining exposure to potential harm or loss that the organization
still faces despite taking preventive or corrective actions.
Residual risk assessment is a crucial step in risk management processes as it helps organizations
understand the effectiveness of their mitigation efforts and determine whether additional measures are
needed to further reduce risk to an acceptable level.
Therefore, the correct term defined by the TOGAF Standard for the risk categorization after the
implementation of mitigation actions is "Residual Risk."
According to the TOGAF standard, a true statement about a good architecture principle is that it should
be stable. Stability refers to the principle's endurance and resilience over time, meaning that it remains
relevant and applicable despite changes in technology, business conditions, or organizational priorities.
Architecture principles should not be overly specific to particular technologies or solutions but should
instead focus on fundamental concepts and values that guide decision-making and promote consistency
across the enterprise. This stability ensures that architecture principles continue to provide meaningful
guidance to architects and stakeholders, even as circumstances evolve.
Therefore, a good architecture principle, according to the TOGAF Standard, is one that demonstrates
stability, enduring relevance, and adaptability to changing environments and requirements.
In the TOGAF Standard, a representation of a system from the perspective of a related set of concerns is
defined as an "View." Views in TOGAF are used to depict specific aspects of an architecture to different
stakeholders. They provide different viewpoints or perspectives on the architecture, each tailored to
address specific concerns or interests of stakeholders.
Therefore, the correct term defined by the TOGAF Standard for a representation of a system from the
perspective of a related set of concerns is "View."
In the TOGAF Standard, a work product that describes an aspect of the architecture is referred to as an
"Architecture Artifact." Architecture artifacts are documentation outputs produced during the
architecture development process. They provide detailed descriptions, representations, and
specifications of different architectural aspects, such as business architecture, data architecture,
application architecture, and technology architecture.
Architecture artifacts help capture and communicate the architecture's structure, behavior, and
characteristics to stakeholders. They serve as important communication tools for conveying architectural
decisions, rationale, and requirements throughout the architecture development lifecycle.
Therefore, the correct term defined by the TOGAF Standard for a work product that describes an aspect
of the architecture is "Architecture Artifact."
According to the TOGAF Standard, a deliverable...
a) is used to package an architecture output.
b) may be composed of other deliverables.
c) may have dependencies on other deliverables.
d) may only be produced during the Preliminary Phase.
The statement that does not correctly describe an architecture deliverable according to the TOGAF
Standard is:
d) may only be produced during the Preliminary Phase.
In reality, architecture deliverables can be produced throughout the architecture development process,
not solely during the Preliminary Phase. They are generated at various stages of the ADM (Architecture
Development Method) as part of the ongoing development and refinement of the architecture.
The TOGAF Standard deliverable that identifies changes that should be made to the architecture and
considers their implications is called the "Architecture Roadmap."
The Architecture Roadmap is a key deliverable within TOGAF that outlines the evolution of the
enterprise architecture over time. It identifies the sequence of changes or initiatives needed to transition
from the current state architecture to the desired future state architecture. This roadmap considers
various factors such as business drivers, constraints, dependencies, risks, and resource requirements
associated with each change.
The Architecture Roadmap helps stakeholders understand the planned evolution of the architecture and
enables effective decision-making regarding investment priorities, resource allocation, and risk
management. It provides a strategic view of how the architecture will evolve to support business
objectives and address emerging challenges and opportunities.
Therefore, the Architecture Roadmap is the TOGAF Standard deliverable that identifies changes that
should be made to the architecture and considers their implications.
The true statement about Architecture Views and Architecture Viewpoints according to the TOGAF
Standard is:
Views are representations of the architecture from the perspective of one or more concerns, and
Viewpoints are the conventions, principles, and practices used to construct and interpret those views.
This means that while views provide specific representations or snapshots of the architecture,
viewpoints define the conventions and principles for creating and interpreting those views. Together,
views and viewpoints facilitate effective communication between stakeholders by ensuring that
architectural information is presented in a meaningful and understandable way, tailored to the concerns
and interests of different stakeholders.
According to the TOGAF Standard, which one of the following best describes the reasons for the
establishment of an Architecture Board?
make notes on adm phases input and output
artifact vs deliverable
architectures that address the detailed needs and business requirements are specific architectures
continuum is described as view on artifacts held in repository
compliance
governance
capability
Which of the following is defined as formal description of the enterprise, providing executive-level, long-
term view for direction setting?
why strategic why not business architecture
What class of architectural information within the Architecture Repository defines processes that
support the governance of the Architecture Repository?
architectural capability
business scenarios used to discover and document business needs
Which one of the following the TOGAF Standard describes as the purpose of the Standards Library as
part of the Architecture Repository?
According to the TOGAF Standard, which one of the following documents acts as a deliverable container
for the core architectural artifacts created during an architecture project? architecture definition
document
According to the TOGAF Standard, which one of the following documents is produced early in an
Architecture Development Method (ADM) cycle containing a summary of the changes to the enterprise?
Architecture vision
According to the TOGAF Standard, where should Architecture Governance activities be recorded within
the Architecture Repository? governance repository
architecture principles described with name, statement, rationale, implication
quality criteria for architecture principles complete consistent, robust, stable, understandable
quality criteria for requirements.. smart?
A good business scenario is also "SMART":
 Specific, by defining what needs to be done in the business

 Measurable, through clear metrics for success
 Actionable, by:
o Clearly segmenting the problem
o Providing the basis for determining elements and plans for the solution
 Realistic, in that the problem can be solved within the bounds of physical reality, time, and cost
constraints
 Time-bound, in that there is a clear statement of when the solution opportunity expires
Which part of the Architecture Repository includes parameters, structures, and processes that support
its governance?
What is the purpose of an Architecture Compliance Assessment?
when is architecture capability created

Architecture Governance Characteristics
Architecture Governance is the practice and orientation by which Enterprise Architectures and other
architectures are managed and controlled at an enterprise-wide level. It includes the following:
 Implementing a system of controls over the creation and monitoring of all architectural
components and activities, to ensure the effective introduction, implementation, and evolution of
architectures within the organization
 Implementing a system to ensure compliance with internal and external standards and regulatory
obligations
 Establishing processes that support effective management of the above processes within agreed
parameters
 Developing practices that ensure accountability to a clearly identified stakeholder community,

both inside and outside the organization
1. Standards Information Base (SIB): This component captures the standards and
guidelines that new architectures must comply with. These standards may include
industry standards, supplier products and services, or shared services that are already
deployed within the organization. The SIB helps to ensure that new architectures are
aligned with the organization’s strategic goals, objectives, and policies.
Reference Library: This component provides a range of 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 reference library
can include architectural principles, best practices, and guidance on specific domains
or technologies. The reference library helps to promote consistency and reuse across
the organization,
Together, the Architecture Method and the Content Metamodel form a comprehensive
framework for developing and managing enterprise architecture within an organization.
Architecture Capability In the TOGAF framework, the Architecture Capability is
defined as the set of organizational resources and processes that support the development
and management of the enterprise architecture.
One of the key components of the Architecture Capability is the Architecture Repository,
which is a structured collection of all architecture artifacts and building blocks within an
organization.
The Architecture Capability defines the parameters, structures, and processes that support
the governance of the Architecture Repository.
In the TOGAF framework, the Architecture Metamodel is composed of two parts: the
Architecture Method and the Content Metamodel.
 The Architecture Method describes the process for developing and managing the
architecture within an organization. It includes various phases and steps for
developing and implementing an enterprise architecture. The Architecture Method is
designed to be flexible and adaptable to different organizations and their unique needs.
 The Content Metamodel provides a framework for organizing and structuring the
architecture content, including the building blocks, artifacts, and deliverables that are
produced during the architecture development process. It defines the structure,
relationships, and attributes of the architecture content, and provides a common
language and vocabulary for describing and communicating the architecture.
At a high level, the following classes of architectural information are expected to be held within an
Architecture Repository:
 The Architecture Metamodel describes the organizationally 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 organization
 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 authorized 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
A cost-optimization project wants to reduce the amount of servers at an infrastructure level from ten to
one servers. What kind of architectural change is necessary for this?
Enterprise Architecture Change Management Process
The approach is based on classifying required architectural changes into one of three categories:
 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.
Another way of looking at these three choices is to say that a simplification change to an architecture is
often driven by a requirement to reduce investment; an incremental change is driven by a requirement to
derive additional value from existing investment; and a re-architecting change is driven by a requirement
to increase investment in order to create new value for exploitation.
To determine whether a change is simplification, incremental, or re-architecting, the following activities

are undertaken:
1. Registration of all events that may impact the architecture

2. Resource allocation and management for architecture tasks
3. The process or role responsible for architecture resources has to make assessment of what
should be done
4. Evaluation of impacts
Guidelines for Maintenance versus Architecture Redesign

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:
 If the impact is significant for the business strategy, then there may be a need to redo the whole
enterprise architecture - thus a re-architecting approach.
 If a new technology or standards emerge, then there may be a need to refresh the Technology
Architecture, but not the whole enterprise architecture - thus an incremental change.
 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.
In particular, a refreshment cycle (partial or complete re-architecting) may be required if:
 The Foundation Architecture needs to be re-aligned with the business strategy.

 Substantial change is required to components and guidelines for use in deployment of the
architecture.
 Significant standards used in the product architecture are changed which have significant end-
user impact; e.g., regulatory changes.
If there is a need for a refreshment cycle, then a new Request for Architecture Work must be issued (to
move to another cycle).
In the TOGAF 9.2 framework, the "Preliminary Phase" focuses on defining the enterprise's architecture
vision and strategy, which includes determining the desired architecture capability. This phase
establishes how an organization's architecture capability will meet the strategic objectives of the
enterprise. Phase A is more about defining the high-level strategic intent of the entire architecture
development. Phase B describes the current and future state of the business environment. Phase D
defines the technology infrastructure needed to support the other architecture domains. Among the
provided choices, only the Preliminary Phase captures the objective of determining the desired
architecture capability of the organization.
Architecture principles are intended to be enduring, but they should not be immutable. Regular reviews
ensure they remain aligned with the organization's mission, strategy, and evolving context. While the
exact frequency of review might vary based on the organization's size, culture, and industry, a common
best practice is to review architecture principles at least annually. This ensures that they remain relevant
in a changing business environment. "Every time a new project starts" is too frequent, making it difficult
to maintain a consistent architectural vision. "Only when there is a significant change in the
organization's strategy" is too infrequent, as waiting for a significant strategic change might mean
missing out on other relevant changes or nuances. "Once it has been set, it should not be changed"
contradicts the evolving nature of business and technology environments.
Architecture governance in the TOGAF 9.2 context refers to the overarching practice of overseeing,
directing, and ensuring that architectural initiatives and activities are in alignment with the
organization's business objectives and strategies. It encompasses principles, practices, roles,
responsibilities, and processes that ensure the effective and efficient use of architecture resources in
achieving desired outcomes.
In the TOGAF 9.2 framework, "Phase B" is dedicated to Business Architecture. The main objective of this
phase is to develop the Target Business Architecture that describes how the enterprise will operate in
the future, given the desired architecture outcome. This phase looks into the organizational structure,
governance, business processes, and operations of the enterprise. On the other hand, "Phase A"
(Architecture Vision) sets the overall vision for the architectural endeavor, "Phase C" delves into
Information Systems Architectures, and the "Preliminary Phase" prepares the organization for
undertaking an architecture project. Of all these phases, only "Phase B" focuses specifically on the
development of the Target Business Architecture.
the "Statement of Architecture Work" is developed and approved during "Phase A: Architecture Vision".
This statement details the scope, approach, and content of an architecture development activity. It
serves as a reference throughout the enterprise architecture process. While the Preliminary Phase deals
with the preparation and initiation of the ADM cycle, including tailoring the framework and defining
principles, it is in Phase A where the Statement of Architecture Work is defined and agreed upon by
stakeholders, especially the sponsors.
In TOGAF 9.2, an "Architecture Contract" is the joint agreement between architecture practitioners and
stakeholders. It is contractually specified and details the deliverables, artifacts, and responsibilities of the
parties involved. Once established, the Architecture Contract is formally reviewed, agreed upon, and
signed off by the stakeholders. The "Architecture Principle", provides the general rules and guidelines for
architecture work but isn't a contractually binding document. The "Architecture Vision", sets the high-
level direction and initial descriptions of an architecture initiative but does not serve as a contractual
agreement.
In the TOGAF 9.2 framework, the "Draft Architecture Definition Document" is created during "Phase A:
Architecture Vision". This document provides a description of the new architecture as a series of views
addressing stakeholder concerns, thus capturing both the baseline (current) and target (desired)
architectural states. Phase A focuses on creating the high-level vision of the capabilities and business
value to be delivered as a result of the proposed enterprise architecture. The other phases further refine
or implement parts of the architecture, but it is Phase A where the initial draft of the Architecture
Definition Document is established.
In the TOGAF 9.2 framework, the "Request for Architecture Work" is an optional artifact that can be
produced during the "Preliminary Phase". This request provides a justification for starting a new
architecture project cycle and defines the sponsor's requirements and constraints. It might originate
from the business strategy, enterprise planning, portfolio management, or another source. While other
phases in the ADM process focus on defining and detailing architecture vision, business architecture, and
other domains, it is the Preliminary Phase where foundational steps such as creating the “Request for
Architecture Work” take place to kickstart the architecture activity.
This phase aims to map out and define the technology infrastructure, platforms, and software necessary
to support the enterprise's architecture. It entails designing the hardware, software, and network
solutions to meet the application and data requirements of the organization.
an "Artifact" is an architectural work product that describes an aspect of the architecture. Artifacts
represent specific pieces of information that are produced, consumed, or utilized during the
architectural process.
the "Preliminary Phase" is the phase where the TOGAF Architecture Framework is customized and
tailored to align with the enterprise's specific needs, capabilities, constraints, and the existing
environment. It sets the foundation by establishing the architecture team, tools, principles, and
governance structures that will guide subsequent phases.
Only "Phase H" emphasizes the continual monitoring and management of the architecture after it has
been established.
Which phase of the ADM ensures that the architecture responds appropriately to both the needs of the
business and the evolving project requirements?
Requirement mgmt phase
In the TOGAF 9.2 framework, the "Requirements Management Phase" acts as a central hub that governs
the flow of requirements to and from the various phases of the ADM. It ensures that the architecture
remains consistently aligned with business needs throughout its lifecycle. The phase manages and
addresses requirements as they are identified, throughout the architecture development cycle. While
other phases such as "Phase A", "Phase H", and "Phase F" have important roles in the ADM process, it is
the Requirements Management Phase that is specifically dedicated to overseeing and managing
requirements in a holistic manner.
"Architecture Vision" in TOGAF, is the correct answer. This phase is the initial phase of the TOGAF ADM
and is specifically dedicated to creating an initial architectural vision that outlines the high-level scope,
objectives, and stakeholders' concerns for the architecture project. It plays a crucial role in obtaining
stakeholder buy-in and ensuring that all stakeholders have a common understanding of the architecture
project's goals and objectives.
The Preliminary Phase in the TOGAF ADM primarily deals with preparing and setting up the architecture
capability in an organization. It defines the scope, establishes the necessary architecture principles and
practices, and prepares the organization to undergo a structured and systematic architecture
development process.
The TOGAF standard considers an "enterprise" to be any collection of organizations that have common
goals.
For example, an enterprise could be:
 A whole corporation or a division of a corporation

 A government agency or a single government department
 A chain of geographically distant organizations linked together 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
https://www.itexams.com/exam/OG0-092
79 Togaf part 2 questions
First of all, a TOGAF architecture principle is divided into 4 parts. A TOGAF principle
always has a:
1. Name - Clear, precise, and easy to remember.
2. Statement - Generally one sentence in length. Clearly tells you what the
principle is.
3. Rationale - Explanation of why the principle is important and how it will
benefit the business.
4. Implications - List of what is required to successfully carry out this principle
and how it could potentially impact the business.
Which phase of the TOGAF Architecture Development Method (ADM) ensures that the
(Enterprise) Architecture Capability meets current requirements?
 Phase H: Architecture Change Management
Which phase of the TOGAF Architecture Development Method (ADM) primarily creates plans
to guide the implementation of the Target Architecture?
 Phase F:
Migration
Planning
Which phase of the TOGAF Architecture Development Method (ADM) determines the
(Enterprise) Architecture Capability desired by the organization?
 Preliminary Phase
As Enterprise Architect you adopted the Architecture Principle that "Data is an asset". How often
should you review this principle to see if it's still valid and possibly change it?
 Only if there is significant change in the enterprise's strategy
Which one of the following is the perfect example for an architecture asset that might be part of
the specific category of the Architecture Continuum as part of the Enterprise Continuum in the
TOGAF Standard?
 Standardized infrastructure components
What is the main objective of the Preliminary Phase of the TOGAF Architecture Development
Method (ADM)?
 Scope the elements of the enterprise affected by the EA Capability
According to the TOGAF Standard, 10th edition, which of the following best describes
Architecture Governance?
 System by which (Enterprise) Architectures are directed and controlled
Which phase of the Architecture Development Method (ADM) primarily concentrates on
formulating the implementation and migration strategy?
 Phase E: Opportunities and Solutions
In which phase of the TOGAF Architecture Development Method (ADM) is the 'Request for
Architecture Work' created?
Complete the sentence: All of the following element belong to the Enterprise Continuum...
 …Architecture Continuum.
 …Architecture Context and Requirements.
 …Solutions Continuum.
The Solutions Continuum in TOGAF primarily focuses on:

 Specific organizational solutions and configurations.
How does TOGAF recommend handling the transition from Architecture Building Blocks
(ABBs) to Solution Building Blocks (SBBs)?
 Through a process of detailed requirement analysis and mapping each ABB to one
or more SBBs that fulfill those requirements.
Which of the following best describes the Architecture Continuum?
 A structured approach to organizing generic architecture artifacts.
The Architecture Continuum offers a consistent way to organize generic architecture artifacts that
represent different levels of abstraction in the enterprise.
What is the primary role of Architecture Governance in TOGAF?

 To provide a framework for managing and controlling architecture work.
Architecture Governance in TOGAF provides a structure for overseeing, guiding, and controlling
architecture activities and projects.
Configured Solutions are part of the Solutions Continuum. The Architecture Continuum consists of
Foundation Architectures, Common Systems Architectures, Industry Architectures, and Organization-
Specific Architectures.
The Architecture Capability focuses on establishing, maintaining, and using an architecture capability
within an organization.
Architectural deliverables in TOGAF represent the outputs of architectural work at various stages of the
ADM.
Which of the following best describes the relationship between deliverables, artifacts, and
building blocks in TOGAF?
 Deliverables contain artifacts, which are composed of building blocks.
Deliverables are contractually specified and contain artifacts. Artifacts represent specific classes
of architectural output, and building blocks represent architectural components at various levels
of abstraction.
What is the primary purpose of Phase A in establishing an architecture practice according to
TOGAF?
 To define or review the vision, stakeholders, and principles of the architecture
practice
Explanation
In Phase A: Architecture Vision, the focus is on defining or reviewing the vision, stakeholders,
and principles of the architecture practice. This phase emphasizes understanding the broader
context and setting the foundational aspects of the architecture practice.
Which of the following best describes the relationship between the Preliminary Phase and the
Architecture Repository?
 The Preliminary Phase reviews and leverages existing content in the Architecture
Repository
Explanation
The Preliminary Phase doesn't create the Architecture Repository from scratch but rather
leverages existing content, ensuring that previous architectural work is considered in new
initiatives.
Which of the following best describes the iterative nature of the ADM?
 Iterations can occur within a phase, between phases, or spanning multiple phases in
any order.
Explanation
The ADM is inherently iterative, and iterations can happen in various ways, not just between
adjacent phases or in a strict sequence.
In TOGAF's stakeholder management, what is a key consideration when determining

communication and engagement strategies for stakeholders?
 The stakeholder's level of influence and interest in the architecture initiative.
Explanation
While various factors can influence communication strategies, in TOGAF's stakeholder
management, the stakeholder's level of influence and their interest or concern regarding the
architecture initiative are primary determinants. This ensures that engagement is tailored to those
who have a significant impact or vested interest in the outcome.
Which of the following is NOT a typical benefit of assessing architectural maturity in TOGAF?
 Ensuring compliance with external regulations.
Explanation
While compliance with regulations is important, the primary focus of Architectural Maturity
Models in TOGAF is on assessing and improving the maturity of architectural processes and
capabilities, rather than regulatory compliance.
How many phases does the ADM cycle consist of?
 8
Explanation
The ADM cycle consists of eight phases, starting from the Phase A and going through Phase H.
Preliminary phase and Requirements Management are phases not included in an ADM cycle.
Which statement about "Artifacts" in TOGAF is accurate?
 Artifacts are the tangible outputs of the architecture work
Explanation
Artifacts in TOGAF are a means of describing the architecture in a form that provides a guide for
stakeholders and which enables a clear understanding, governance, and evolution of the
architecture. They can be in the form of diagrams, specifications, tables or compilations and can
be at varying levels of detail.
Refer to the information below:

Output & Outcome: Work package description, Implementation and Migration strategy
Input: Analysis of differences between the Baseline and Target Architectures
Phase: ?
Which ADM phase(s) does this describe?
 Phase E
Explanation
Phase E: Opportunities and Solutions is where the initial implementation plans are formulated,
and the migration strategy is developed. This phase takes the results of the gap analysis and
begins to shape them into Work Packages, while also defining the Implementation and Migration
strategy. The focus is on identifying major implementation projects and grouping them into work
packages.
In TOGAF, what is the primary purpose of a building block?
 To represent a specific architectural component at various levels of abstraction.
Explanation
Building blocks in TOGAF represent specific architectural components at various levels of
abstraction.
Building blocks in TOGAF typically go through a lifecycle of Proposal, Evaluation, Adoption,
and eventually Obsolescence.
The mission of The Open Group is to drive the creation of Boundaryless Information
Flow™ achieved by:
 Working with customers to capture, understand and address current and emerging
requirements, establish policies, and share best practices
 Working with suppliers, consortia and standards bodies to develop consensus and
facilitate interoperability, to evolve and integrate specifications and open source
technologies
 Offering a comprehensive set of services to enhance the operational efficiency of
consortia
 Developing and operating the industry's premier certification service and encouraging
procurement of certified products
Explanation
The Architecture Capability Framework in TOGAF provides the tools, practices, roles, and
responsibilities for establishing an architecture practice. The Architectural Maturity Model, on
the other hand, is used to assess the effectiveness and maturity of these practices and processes.
The TOGAF standard includes which of the following reference models?
 GRM and MSA

Explanation
Explanation: GRM (Governance Reference Model) and MSA (Microservices Architecture) are
foundational reference models included in the TOGAF standard. They provide a foundation for
guiding and developing an organization-specific architecture.
In the Preliminary Phase, which of the following is crucial for ensuring that the architecture function
operates effectively within the enterprise?
 Establishing architecture governance
Explanation
Explanation: Establishing architecture governance in the Preliminary Phase ensures that there's a
structured approach to overseeing and guiding the architecture development. It's crucial for the
effective operation of the architecture function.
Which of the following is NOT a primary component of the Architecture Capability Framework?
 Architecture Technology List
Explanation
While the Architecture Capability Framework covers various aspects of establishing and maintaining an
architecture practice, it doesn't focus on a specific Architecture Technology List.""
What is a viewpoint library?

 A collection of the specifications of architecture perspectives contained in the
Reference Library
Explanation
A viewpoint is a specification of stakeholder's perspective, so a viewpoint library is a collection
of them.
Which of the following architectural artifacts provides a detailed listing of individual architectural
components?
 Catalog
Explanation
Catalogs are used to provide detailed listings of individual architectural components.
Question: Refer to the information below:
Phase : ?
Output & Outcome : A deliverable container for the core architectural artifacts created during a
project and for important related information
Input : Data principles.
 Phase C
Explanation
Explanation: Phase C, Information System Architecture – Data Architecture, is the phase where
the data principles are analyzed to build the Architecture Definition Document.
Which of the following is typically considered a characteristic of a building block in TOGAF?
 Package of functionality
 Boundary
 Type
Explanation
While interfaces are crucial in understanding how building blocks interact, within the generic
characteristics of building blocks in TOGAF, an interface is not typically listed.
In the context of TOGAF's Business Transformation Readiness Assessment, which of the following
is typically a factor considered when evaluating readiness?
 Stakeholder commitment and alignment with the transformation goals.

 The organization's past history with change initiatives.
 Potential risks and mitigations associated with the transformation.
Explanation
While technology can play a role in business transformation, the Business Transformation
Readiness Assessment focuses more on organizational, cultural, and strategic factors rather than
specific technology choices.
Architecture principles should be technology-agnostic and not tied to specific products. They should
provide clear, enduring guidance that can adapt to changes and support decision-making.
In TOGAF, which artifact would typically provide a high-level (often graphical) representation of
the overall architecture?
 Diagram
Explanation
Diagrams are used to provide a visual representation of various aspects of the architecture, often
capturing the high-level structure and relationships.
In the Architecture Capability Framework, what is the primary purpose of the Architecture
Maturity Models?
 To assess and measure the maturity of the architecture discipline within the
organization.
Explanation
Architecture Maturity Models in TOGAF are used to evaluate the maturity level of architecture
capabilities, helping organizations understand their current state and areas for improvement.
In TOGAF, which deliverable would typically provide a high-level (often contractual)

representation of the overall architecture?
 Architecture Definition Document
Explanation
The Architecture Definition Document provides a high-level representation of the architecture,
often serving as a contractual means between stakeholders.
Which of the following best describes the relationship between the Architecture and Solutions
Continuums?
 The Architecture Continuum provides the foundational structure, which the

Solutions Continuum realizes with specific solutions.
Explanation
The Architecture Continuum offers a logical structure, while the Solutions Continuum provides
the corresponding concrete solutions and implementations.
A viewpoint in TOGAF defines the perspective from which a view is taken. It establishes the conventions
for constructing and using a view.
In TOGAF's Enterprise Continuum, what is the primary role of Foundation Architectures?
 To provide a set of architecture building blocks and corresponding standards.
Explanation
Foundation Architectures provide a set of generic building blocks and their interrelationships,
complete with generic standards.
What does the Architecture Repository store in TOGAF?
 Both the current and future states of the architecture

Explanation
The Architecture Repository in TOGAF is a structured way to capture and manage outputs
throughout the ADM. It stores both the current (baseline) and future (target) states of the
architecture.
What is the purpose of creating an Implementation Factor Catalog in the TOGAF framework,
and how does it impact the architecture Implementation and Migration Plan?
 To document factors impacting the architecture Implementation and Migration
Plan, including risks, dependencies, and other critical elements.
Explanation
The Implementation Factor Catalog in TOGAF serves to document a comprehensive list of
factors that could impact the architecture implementation and migration plan, thereby aiding in
the formulation of a more effective and realistic plan that accounts for various contingencies and
dependencies.
Which of the following is a primary component of the Architecture Repository that houses generic
architectural assets?
 Reference Library
Explanation
The Reference Library is a component of the Architecture Repository that contains generic
architectural assets that can be leveraged across projects.
In the context of TOGAF, where would you typically store organization-specific architectures and
solutions?
 Architecture Landscape
Explanation
The Architecture Landscape is a component of the Architecture Repository that contains
architectures tailored to the specific needs and context of the organization.
Benchmarking against industry standards allows an organization to understand its position relative to
others in the industry, providing insights into areas of strength and potential improvement.
Which component of the Architecture Capability Framework aids organizations in understanding
their current architecture capabilities and areas for improvement?
 Architecture Maturity Models
Explanation
Architecture Maturity Models are designed to assess and measure the maturity of the architecture
discipline within an organization, highlighting current capabilities and areas for enhancement.
In the context of TOGAF, a matrix would typically be used to:
 Detail the relationships between architectural components.

Explanation
Matrices are used to show relationships between different architectural components, often in a
two-dimensional format.
Which of the following best describes the relationship between a view and a viewpoint in TOGAF?
 A viewpoint defines the perspective, and a view is the representation of the system
from that perspective.
Explanation
In TOGAF, a viewpoint establishes the conventions for a particular kind of view. A view is what
you see from the perspective established by the viewpoint.
In TOGAF, how are building blocks typically related to architectural patterns?
 Building blocks can be assembled to fit specific architectural patterns.
Explanation
Building blocks represent specific architectural components, and they can be assembled or
organized in a manner that fits specific architectural patterns.
Which statement about the relationship between architecture principles and business principles in
TOGAF is most accurate?
 Architecture principles often derive from business principles, ensuring alignment

between IT and business strategies.
Explanation
In TOGAF, architecture principles often have their roots in business principles. This ensures that
the IT architecture aligns with and supports the overarching business strategy and goals.
What are the main categories of skills identified in the TOGAF Architecture Skills Framework,
and how do they contribute to the role of an Enterprise Architect?
 Generic Skills, Business Skills & Methods, Enterprise Architecture Skills, Program
or Project Management Skills, Legal Environment, IT General Knowledge Skills.
Explanation
"Generic Skills, Business Skills & Methods, Enterprise Architecture Skills, Program or Project
Management Skills, Legal Environment, IT General Knowledge Skills."
This choice is correct and aligns closely with the categories defined in the TOGAF Architecture
Skills Framework, covering a comprehensive range of skills necessary for an Enterprise
Architect.
Using predefined architecture viewpoints allows architects to create views more efficiently, as the
viewpoints are already defined. Additionally, stakeholders are more likely to understand and be familiar
with these predefined viewpoints.
Which stakeholder is most likely to be involved in the Preliminary Phase to ensure that the
architecture function will meet the needs and constraints of the business environment?
 Corporate management
Explanation
Corporate management plays a crucial role in the Preliminary Phase. They provide insights into
the business environment, needs, and constraints, ensuring that the architecture function aligns
with business objectives.
In the Architecture Capability Framework, which component provides a structured method for
storing and leveraging architecture-related assets?
 Architecture Repository
Explanation
The Architecture Repository offers a consistent and structured way to store, manage, and utilize
architecture-related assets.
Which of the following is a characteristic of the TOGAF standard?
 Vendor-neutral
 Provides a detailed method and set of supporting tools
 Based on open standards
Explanation
TOGAF is vendor-neutral and based on open standards. It provides a detailed method and set of
supporting tools for developing an enterprise architecture. It's not technology-specific, meaning
it doesn't favor one technology over another.
Which of the following can be an external source of architectural input in the TOGAF
framework?
 Non-architectural documents
Explanation
Non-architectural documents can provide valuable external input to the architectural process.
These might include market studies, regulatory standards, or other documents not inherently
architectural but still influential.
Which of the following best describes the granularity of building blocks in TOGAF?
 The granularity of building blocks can vary, representing both high-level and
detailed components.
Explanation
Building blocks in TOGAF can represent components at various levels of abstraction, from high-
level system components to detailed ones.
In the context of TOGAF, the Architecture Contract primarily serves to:
 Define the responsibilities and expectations between stakeholders and architects.

Explanation
The Architecture Contract outlines the agreements, responsibilities, and expectations between
various stakeholders and the architecture practitioners.
Which of the following best describes the primary focus of the Preliminary Phase" in the
TOGAF Series Guide: MSA?"
 Maturity and readiness assessment and governance and support strategy.
In the context of TOGAF, which of the following best describes the relationship between
architecture patterns and building blocks?
 Architecture patterns provide a high-level contextual solution, while building blocks
represent individual components or functionalities.
Why is the establishment of an Architecture Capability Framework crucial for organizations?
 To ensure that the architecture function operates effectively and meets business
needs.
Explanation
The Architecture Capability Framework is essential for establishing, maintaining, and using an
architecture capability that aligns with business goals and operates effectively.
Why is it crucial in TOGAF's framework to assess stakeholder commitment during a Business
Transformation Readiness Assessment?
 To gauge the likelihood of successful transformation, as stakeholder buy-in is

critical for driving and sustaining change.
Explanation
Stakeholder commitment is a pivotal factor in the success of any transformation initiative. Their
buy-in and support can drive the change, while their resistance can pose significant challenges.
Assessing this commitment helps in strategizing for a more effective transformation.
The Solutions Continuum focuses on the realization of architectures in specific solutions tailored
for the organization.
Enterprise Continuum is not actively used while running ADM, as it is mostly used when starting a new project
or re-entering a project into ADM. - More details on slide 91.
The five criteria to distinguish a well-written principle are: Complete - being complete means that all
principles are important and comprehensive. Consistent − Being consistent means that a strict adherence to one
principle cannot generate a vague interpretation of another principle. Stable - be stable, that is, the principles
must be lasting, but capable of accommodating changes. Understandable - be easily understandable by another
principle and by the entire organization. Robust - being robust, that is, allowing good quality decisions about
architectures.
Project Management is necessary to reduce or eliminate potential sources of gaps and not the opposite. –
The use of open data standards does NOT represent the information exchange model, as not all data can have
its content open as it is confidential data. Furthermore, the content of information exchanges in phase "C"
(Data Architecture) aims to detail the “structure” for data exchange using the corporate model, this does not
mean that this structure must have its content with unrestricted access (open standards). - More details on slide
136.
Phase G (Implementation Governance) has as one of its main objectives ensuring compliance with the Target
Architecture by governance implementation projects. However, establishing an IT capability is not a function
of Implementation Governance (phase G) as the Architecture Capability (which is the same as IT capability) is
discovered (or defined) in the Preliminary Phase of ADM. - More details on slides 103, 179.
The 5 key concepts within the Architecture Governance Framework are: Process, Context, Content, Repository
and Process Flow Control
The Architecture Board is not responsible for improving and optimizing business architecture or people
integration; but to meet business needs through the discipline of architecture. - More details on the slide 34.
success alert
Good job!
The 6 levels of Architecture Compliance are: Irrelevant, Consistent, Compliant, Conformant,
Fully Conformant and Non-conformant - More details on the slide 112.
A viewpoint addresses a related set of concerns, and a concern is addressed by one or more viewpoints. A
Viewpoint is NOT a specification of conventions for architecture, as Architecture standards are defined in
foundation architectures that contain Architecture principles and conventions.
A Viewpoint can be described using a set of related elements. These related elements are: Stakeholders,
Concerns, Model and View
The main objectives of Phase A (Architecture Vision) of ADM are: • Obtain approval for an Architecture
Statement of Work that defines a program of work to develop and implement the architecture described in the
Architecture Vision; • Develop a high-level model of candidate building blocks, i.e. documentation of the
existing architecture (framework description, architecture descriptions, existing baseline descriptions, etc.); -
More details on slides 147, 148, 149.
In ADM Phase C (Data and Application Architecture), the Architecture Definition Document is NOT updated
through the “database content” or applications, but rather through the “data architecture” and “application
architecture”. Do not confuse Data Architecture with data “content”.
The three main parts of the TRM (Technical Reference Model) are: Applications, Application
Platform and Communications Infrastructure;
The TOGAF Integrated Information Infrastructure Reference Model (III-RM) contains 5 main components:
Information Consumer Applications; Information Provider Applications; Intermediation Applications;
Development Tools; Management Utilities;
Preface (history of TOGAF): • Executive Overview; • Fundamental Concepts for Enterprise Architecture; •
Definitions and Release Notes; Therefore, Part I describes the TOGAF approach to Enterprise Architecture. -
More details on the slide 60.
Although Enterprise Architecture is at the highest level of strategic organization, according to TOGAF, the best
definition for Enterprise Architecture is “An architecture that crosses multiple systems and multiple functional
groups within the enterprise”.
Phase E is the Opportunities and Solutions Phase and one of the outputs of this Phase is the “high-level plan
and implementation” which is an Architecture Roadmap, that is, a script with the migration and
implementation strategy. The detailed migration and implementation plan (architecture roadmap) (version 1.0)
will be produced in Phase F – Migration Planning. NOTE: Every high-level initial (preliminary) version is
classified in TOGAF as version 0.1, and detailed versions as version 1.0 of the architecture documents.
Phase H is the Architecture Change Management phase, whose objective is to ensure that the
expected benefits of the target corporate architecture are achieved to add value to the business
(because the quality of delivery will always add value to the business).
Industry architectures guide the integration of common systems components with organization-
specific components and guide the creation of industry solutions for specific customer problems
within a specific organization, an example of this would be: “An association of companies has
defined a data model for sharing inventory and pricing information.”
If there is no architecture created for the project, or if there are few architecture assets defined, the best
approach to developing the Baseline Business ArchitecturE is to map the current scenario (“bottom up”). ”),
that is, to survey what currently exists in order to define the target architecture (TO-BE), which is at the top
level, taking as a starting point the already existing scenario (AS-IS) which is at the bottom level in relation to
the business objective.
TOGAF does not have as a guideline that the corporation be treated as a single project, especially because
TOGAF conceptualizes “company” not as a physical establishment. Contrary to this, TOGAF describes a
company as any project developed by any area or department. This concept becomes clearer and more
assertive when Enterprise Architecture is used in large corporations, as each area or department can have
different architectures from one application to another. Regarding the Togaf ADM, recommends using the
same approach used in other resources, that is, using the same pattern.
Any Technical Reference Model (TRM) has two main components: A taxonomy - which defines terminology
and provides a coherent description of the components and conceptual structure of an information system. An
associated TRM chart - which provides a visual representation of the taxonomy, as an aid to understanding.
In Part V of the TOGAF standard document, which is the Enterprise Continuum and Tools, we have: •
Corporate Continuum; • Architecture partitioning; • Architecture repository; • Tools for Architecture
Development; Therefore, the view of the Architecture Repository, in addition to Architecture Partitioning and
Tools for Architecture Development is the simplest way to think about the Corporate Continuum. NOTE: For
more information, see our training material in module III - Structure of the TOGAF standard document
(SLIDE 64). Not library.
In Part VII of the TOGAF standard document, which is the Architecture Capability Framework, we have: •
Architecture Board; • Architecture compliance; • Architecture contracts; • Architecture Governance; •
Architecture Maturity Models; • Architecture Skills Framework; So the class of architecture information within
the architecture repository that defines the processes that support the governance of the architecture repository
is Architecture Capability Framework. NOTE: For more information, see our training material in module III -
Structure of the TOGAF standard document (SLIDE 66)
Business scenarios are first seen in the preliminary phase of ADM, and are detailed in Phase B – Business
Architecture, therefore they are not covered in Phase H of Change Management. Phase H has the following
inputs: • Architecture change requests due to technology changes; • Architecture change requests due to
business changes; The change requests that serve as input for Phase H were generated in previous phases in
their respective architecture domain (technology and business).
Risks are identified from Phase A, and as the ADM life cycle progresses to the next phase, new specific risks
may be identified that were not identified in previous phases. It is very difficult in a large project to identify all
project risks in the initial ADM phase, therefore for TOGAF, the risk is “generalized” and can be identified and
managed in all ADM phases.
For the architect to be able to create any initial architecture vision (in Phase A), the first thing they will need to
have in hand are the macro business requirements (high-level vision), which will make up the “business
scenario”. Without this business scenario information, it would be very difficult for the architect to draw up a
diagram with a view of the target architecture.
Remember this: Part II of the TOGAF standard document refers to the Architecture Development Method,
which is the ADM. While part VII refers to the Architecture Capability Framework. However, in this Question
pay attention to the word “implement”. For the architect to be able to “implement” any architecture resource,
he or she will have to use ADM, which, as the name suggests: “architecture development method”.
Architecture Governance is not responsible for creating the architecture definition document (because this was
already done in the preliminary Phase), nor is it responsible for controlling the deployments (this was already
done in Phase F – migration planning), either is not responsible for creating the communications plan (this is
the responsibility of the corporation's Project Management) and is also not responsible for conducting business
scenarios (because this has already been resolved in Phase B – Business Architecture).
The TOGAF Technical Reference Model, described in the TRM Guide (Technical Reference Model) focuses
on the Application Platform space. TOGAF does not impose the use of this model, but “recommends” its use,
especially because the TOGAF Technical Reference Model (TRM) is flexible and can be adapted to the
organization's needs. NOTE: For more information, see our training material Module II – Definitions (SLIDES
45, 46 and 47)
The TOGAF III-RM Integrated Information Infrastructure Reference Model allows architects to design
architectures addressing limitless information flow because III-RM focuses on the application platform. This
set of components enables architects to build architecture diagrams for any type of applications and their
information flows, so there are no limits for architects to design architectures using this model.
The TOGAF Architecture Principles (TOGAF Foundation ArchitecturE) is an architecture of generic services
and functions that provides a foundation upon which more specific architectures and architecture components
can be built. This foundation architecture has two main elements: • TRM; • SIB; For example: In Phase D of
ADM, which is Technology Architecture, the Technical Reference Model (TRM) is used as the base
architecture (fundamental or foundation).
The 7 parts of the TOGAF 9 Specification are: • Part I – Introduction; • Part II – Architecture Development
Method; • Part III - ROM Guidelines and Techniques; • Part IV - Architecture Content Framework; • Part V –
Corporate Continuum and Tools; • Part VI - TOGAF Reference Models; • Part VII - Architecture Capability
Framework; The only correct description is from Part VII - Architecture Capability Framework, which is
intended to describe processes and skills to establish an enterprise function.
To ensure implementation compliance, Implementation Governance is necessary, which belongs to Phase G of
the ADM life cycle. NOTE: For more information, consult our training material Module V - ADM
(Architecture Development Method. (SLIDES 177 to 182)
The word “compliance” is directly linked to “Governance”, as Implementation Governance (in Phase G of
ADM) is the stage where it is validated whether what is being delivered is in compliance with what was
defined by the architecture. - Note: More information on slides 112, 178 of our training material
Phase D of the ADM (Technology Architecture) consists of identifying, describing and developing the
Technology Architecture, that is, defining technology components in a set of technology platforms. - Note:
More information on slides 161, 162, 163, 164 of our training material
The Enterprise Continuum is a way to classify items in the architecture repository. - Note: More information
on slides 90, 91 of our training material
The identification of the main interested parties occurs in Phase A (architecture vision) and not in the
Preliminary Phase whose main objectives are: • establish architecture principles; • define the relationships
between management structures; • define the architecture undertaking (effort); • assess the maturity of the
corporate architecture; - Note: More information on slides 146,147, 148, 197 of our training material
The Architecture Board's main objective is to carry out a review to apply Architecture Compliance. This
review is based on a project checklist to validate whether what is being delivered by the development teams
complies with the architecture that was defined for the project. - Note: More information on slides 112, 113 of
our training material
Business transformation risks are first identified in Phase A (architecture vision) and maintained as governance
artifacts in Phase G (Implementation Governance). However, the objective of the Architecture Board is not to
identify project risks, but rather to carry out a review to ensure architecture compliance. - Note: More
information on slides 28, 31, 32, 33, 34 of our training material
In phases B, C and D of ADM, the impacts on the architecture scenario are resolved, however, in order to reach
the target architectures, it is necessary to first access the architecture repository that contains the reference
models, tools necessary to the project and viewpoints with the architecture vision that were previously created
in Phase A. Therefore, before developing the artifacts of Phases B, C and D, it is necessary to previously
develop the foundation architectures and target architectures with the aim of selecting the necessary reference
models, viewpoints and tools.
Part I of the TOGAF standard document describes the TOGAF approach to Enterprise Architecture. And the
Document Categorization model is intended to assist in managing the release of the TOGAF specification. -
Note: More information on slides 60, 67 of our training material
Enterprise Continuum is used in the organization to help with communication and understanding between
architects, as Enterprise Continuity will provide the Architecture Continuum and this in turn will be integrated
with the corporate architecture repository (which will provide the necessary documentation to architects), thus
facilitating shapes architects’ communication and understanding of the architecture available for the project. -
Note: More information on slides 90, 94, 95, 96, 97 of our training material
Capabilities-Based Planning is a business planning technique that focuses on achieving business goals. - -
Note: More information on slides 102, 103, 104, 105 of our training material
Part IV of the TOGAF standard document which is the Content Architecture Framework contains the
following items: • Architecture Content Metamodel; • Architecture Artifacts; • Architecture Deliverables; •
Building Blocks; - Note: More information on slides 63, 82, 84 of our training material
A foundation architecture contains baseline building blocks (data, application, business, and technology) with
their corresponding principles and patterns. Tip: the word “standard” or “principle” always refers to a
foundation architecture, as foundation architectures have “generic” standards defined by the corporation for the
development and evolution of all its systems. - Note: More information on slides 37, 40, 45, 48, 49, 179 of our
training material
The ADM Preliminary Phase is used to develop the enterprise architecture team. It focuses on the key
problems or issues that the enterprise architecture team must address. One of the first objectives of the
Preliminary Phase is to select and implement the architecture tools to be used in the project. Tools can be
considered as architecture “frameworks”, whose standards must be used in the project. - Note: More
information on slides 103, 140, 141, 142, 143 of our training material
The catalog is a type of artifact that contains lists of things (or item lists) of the architecture. - Note: More
information on slide 84 of our training material
success alert
Good job!
To understand the business requirements in Phase A (Architecture Vision) it is necessary to
describe the business scenario in which these requirements will be used. A business flow is
usually created (which is nothing more than the business scenario) to help understand the
requirements. Initially, the high-level view of business scenarios is seen in Phase A and the
detailing of business requirements is done later in Phase B (Business Architecture) of ADM. -
Note: More information on slides 145, 146, 147, 148, 149, 152 of our training material
The Standards Information Base (SIB) is a repository area containing specifications that architectures must
conform to. The Standards Information Base is a database of facts and guidance about information systems
standards. - Note: More information on slides 45, 48, 49, 50 of our training material
The Architecture Definition Document is the delivery container for the key architecture artifacts created during
a project. The Architecture Definition Document covers all architecture domains (business, data, applications,
and technology) and also examines all relevant states of the architecture (baseline, intermediate state, and
target). - Note: More information on slide 43 of our training material
An architecture work or vision called “high level” means that it is work with a more generic approach and
without much detail. TOGAF conventions define baseline architecture documentation as “version 0.1” because
it is high level (not detailed) and target architecture documentation which contains a higher level of detail and
final understanding as “version 1.0”.
Artifact is a referred architecture work product that comes in one of three types: Catalog, Matrix, or Diagram. -
Catalog is a list of architecture items; - Diagram is a visual representation of architecture; - Matrix shows the
relationships between things through rows and columns; - - Note: More information on slides 41, 83, 84, 154
of our training material
The focus of ADM Phase F (Migration Planning) is the creation of an Implementation and Migration Plan in
cooperation with the portfolio and project managers. - Note: to make it easier to consolidate your learning,
whenever you find the word “migration” or the word “implementation plan” in any test question, you can
associate this with Phase F, which is “Migration Planning”.
Architecture governance is the practice and guidance by which enterprise and other architectures are managed
and controlled at the enterprise level. So the most plausible answer to this question is: Audit information,
process status and reference data. Tip: you should note some “key” words in the question such as “governance”
and “managed”. The only plausible answer that would answer this question is an answer that contains other
words that have a direct relationship with governance and management, these words are: “audit” and “process
status”.
A matrix shows relationships between things through rows and columns, and generally shows relationships
between business requirements and technical requirements (matrix example: Excel spreadsheets). - Note: More
information on slides 41, 83, 84, 154 of our training material
An architecture resource contained within the architecture repository has parameters, structures, and processes
to support the governance of the repository. TIP: to facilitate your learning, whenever you find the word
“architecture repository” in a test question, look for answers with keywords that have a direct relationship with
the repository, such as: “processes” or “parameters” or “governance logs”.
ADM Phase H is Architecture Change Management, and one of the objectives of this Phase is to determine
whether to start a new architecture cycle or make changes to the structure and principles. TIP: to facilitate your
learning, whenever you find the words “management” and “change” in any test question, you should always
associate them with Phase H, which is Change Management in the ADM life cycle .
For a system to have integrity, a set of architecture principles must be applied. This set of principles to be
applied (such as stability, robustness, understandability and consistency) serves to meet the recommended
system “integrity” criteria.
The architect chooses and develops a set of visions that will allow the architecture to be communicated and
understood by all interested parties and allow them to verify that the system will meet their concerns. A
stakeholder has one or more concerns about a system, and a concern may be shared by one or more
stakeholders.
A simplification change is carried out at PHASE H, even if this change is due to some internal or external
problem (example: if a store terminal breaks down or malfunctions and credit card purchases made on that
equipment cannot be deleted in real time). So a server consolidation project that does not change the
operational characteristics of the applications would require a simplification change identified in Phase H
(architecture change management). –
Any architecture project that uses TOGAF will begin in the Preliminary Phase. And there is no project that
starts without there being an imperative from the business area, that is, a business need. In the Preliminary
Phase, the scope and premises of the project are defined, the main stakeholders are identified and the
architecture principles are also defined. So in the Preliminary Phase “business imperatives” drive the
requirements and performance metrics when defining the scope of enterprise architecture work.
Ensuring compliance of individual projects with enterprise architecture is an essential aspect of architecture
governance. Phase G (implementation governance) of ADM is where all the information for successful
management of the various implementation projects is gathered. And one of the objectives of Phase G to
ensure architecture compliance is to review a project against established architecture criteria and business
objectives. - Tip: You may associate the word “compliance” with “governance”.
Part V of the TOGAF standard document is Enterprise Continuum and Tools, which is comprised of: •
Corporate Continuum (Enterprise Continuum); • Architecture partitioning; • Architecture Repository
(Architecture Repository); • Tools for Architecture Development; The Enterprise Continuum is a way of
classifying items in the architecture repository, so the simplest way to think about the Enterprise Continuum is
by referring to a view of the architecture repository.It doesn’t store(library), it classifies or views the store of
artifacts.
Phase C of ADM (Data Architecture and Application Architecture). This question refers to Data Architecture,
and this architecture's main objective is to “define the types and sources of data necessary to support the
business, so that they can be understood by interested parties”. However, it is not the responsibility of Data
Architecture to “implement” (build) data normalization or “implement” data models (Data Architecture will
not act as DBAs in implementing and maintaining databases, but rather in “definition” of how the data will be
used in the project).
Risks are first identified in ADM Phase A and maintained (or updated) in the remaining ADM phases. Even
though Phase G (Implementation Governance) places a greater focus on risk management, this does not mean
that risks should not be managed in the other phases of ADM. - Note: More information on slide 177 of our
training material
Architecture Governance typically does not operate in isolation, but within a hierarchy of governance
structures, which, particularly in a larger enterprise, may include all of the following as distinct domains with
their own disciplines and processes: • Corporate governance; • Technology Governance; • Architecture
Governance; • Service Governance; - This means that all architectures are managed and controlled at a
corporate level through the practice of Architecture Governance.
Togaf provides a set of reference materials for establishing an architecture role within an organization known
as the "Architecture Capability Framework". The Architecture Capability Framework provides a set of
reference materials on how to establish such an architecture function, although it is not intended to be a
comprehensive model for operating Enterprise Architecture Capability. - Note: More information on slides 66,
88, 100, 102, 103, 104
The Architecture Repository has six classes of architecture information: • The Architecture Metamodel; •
Architecture capability; • The landscape or vision of architecture; • The Standards Information Base (SIB); •
The Reference Library; • The Governance Register; - The “Governance Record” feature has processes to
support the governance of the Architecture Repository.
Phase H (Architecture Change Management) of ADM has a simplified process for re-entry into ADM. This
simplified architecture change process is driven by a business need to reduce change investment and promote
greater agility in the development of project changes. - Note: More information on slide 204 of our training
material
ADM can be viewed as the process of populating the enterprise's own "Architecture Repository" with relevant
reusable building blocks taken from the more generic side of the Enterprise Continuum. All architecture
drawings and documents produced by the architect must be “stored” in the corporation’s centralized location
for this purpose: “the architecture repository”.
Recommended Togaf is the category that describes a technique using the Togaf standard (core) and mandatory
as a “reference model”, but not with the obligation to strictly follow the entire architecture development cycle,
as it can be adapted to organization needs.
Togaf Support is not referenced in the reference libraries because Togaf support does not describe
the Togaf standard.
In order for the architect to be able to “visualize” the building blocks currently in use in the organization, he or
she must search the architecture repository for Architecture Landscape.
The “initial level of risk” always occurs “before” the architect determines and implements risk mitigation
actions.
An "incremental" change determines an "additional value" of the existing investment in the project.
The architecture repository is used to store different architecture output classes created by ADM, i.e. the
repository stores architecture artifacts.
Risk identification is not the scope of the architecture committee in the architecture compliance review
activity. Do not confuse risk management with risk identification.
In Phases B, C and D, the final step in each phase will output the detailed architecture definition document
(version 1.0)
If oversight of implementation then phase G
If implementation and migration then phase F
Which phase of the TOGAF Architecture Development Method (ADM) primarily creates plans
to guide the implementation of the Target Architecture?
 Phase F: Migration Planning
Should be E
Which phase of the Architecture Development Method (ADM) primarily concentrates on
formulating the implementation and migration strategy?
Phase F of TOGAF's Architecture Development Method (ADM) primarily focuses on the final
preparation and deployment of the architecture. While it does involve aspects of implementation
and migration, it is more concerned with the actual deployment of the solutions rather than
formulating the implementation strategy.
Phase F: Migration Planning is where the detailed plans for the migration of the existing
systems and data to the target architecture are developed. It involves finalizing the
detailed implementation and migration plans, as well as ensuring that all necessary
resources, such as people, tools, and infrastructure, are in place for the migration to
occur smoothly.
However, Phase E: Opportunities and Solutions precedes Phase F and is specifically

dedicated to formulating the implementation and migration strategy. In Phase E, the
focus is on identifying the projects and initiatives needed to realize the target
architecture, as well as developing the Implementation and Migration Plan. This phase
lays the groundwork for the actual deployment activities that take place in Phase F.
In summary, while both Phase E and Phase F are related to implementation and
migration, Phase E primarily concentrates on formulating the strategy, while Phase F is
more about executing the plans developed in Phase E and ensuring successful
deployment of the architecture.
Which one of the following the TOGAF Standard describes as an architectural work product that
is contractually specified and formally reviewed, agreed, and signed off by the stakeholders.
 Deliverable
Which one of the following the TOGAF Standard describes as an Architecture Contract?
 An agreement between the development partners and sponsors on the deliverables,
quality, and fitness-for-purpose of an architecture
Complete the sentence: According to the TOGAF Standard, the architectures that address the
detailed needs and business requirements are known as…
 ...Specific Architectures.
According to the TOGAF Standard, which one of the following is decribed as a view on artifacts
held in the Enterprise Repositories?
 Enterprise Continuum
Which one of the following describes a purpose of an (Architecture) Compliance Assessment
within the TOGAF Standard?
 Ensuring that the design and implementation is in line with the strategic and
architectural objectives and the Architecture Vision
Which statement about the Foundation-level Core Enterprise Metamodel is correct? The
model…
 ...supports the architecture work.
 …provides context for the artifacts suggested in the Architecture Development
Method (ADM).
 …structures the architectural information meeting stakeholders needs.
Which one of the following is a purpose of an Enterprise Architecture Capability according to
the TOGAF Standard?
 Architecture to support strategy
 Architecture to support portfolio
 Architecture to support projects
 Architecture to support solutions delivery
Complete the sentence: All of the following are part of the approach to the Preliminary Phase,
except…
 …defining Architecture Contracts.
All of the following are part of the approach to the Preliminary Phase,
 …defining the enterprise.

 …identifying key drivers and elements in the organizational context.
 …defining the framework to be used.
 …defining the requirements for architecture work.
What class of architectural information within the Architecture Repository defines processes that
support the governance of the Architecture Repository?
 Architecture Capability
(Governance – Cpability go together)
Which one of the following is considered a relevant resource for the TOGAF Architecture
Development Method (ADM) Phase B: Business Architecture available from the Architecture
Repository?
 Industry reference models
 Applicable standards
 Enterprise-specific business architecture views
 Enterprise-specific building blocks
 All of the above
(Correct)
According to the TOGAF Standard, which one of the following statements describing
relationships between stakeholders, concerns, views, and viewpoints is true?
 A stakeholder has one or more concerns.
According to the TOGAF Standard, which one of the following applies to an Architecture
Building Block (ABB)?
 It meets business goals and objectives.
According to the TOGAF Standard, which one of the following documents is produced early in
an Architecture Development Method (ADM) cycle containing a summary of the changes to the
enterprise?
 Architecture Vision then comes statement of architecture work
According to the TOGAF Standard, where should Architecture Governance activities be
recorded within the Architecture Repository?
 Governance Repository
The Gap Analysis is used in the Phases B, C, D and E of the Architecture Development Method
(ADM). Which of the following statements best describes this ADM Technique?
 Gap Analysis defines what must be changed within the enterprise
Several affiliated companies have a common data model to share global tax information. Which
of the following is the best way to classify the model within the Enterprise Continuum?
 Specific Architecture
In this case, the common data model for global tax information is specific to a particular
industry or domain, which is tax compliance and management. Therefore, it fits within the
category of "Industry-Specific Architecture." it is recognized as a specialized solution tailored to
the needs and requirements of a specific industry, The focus is on the industry-specific aspects
of the solution rather than its uniqueness to a particular organization.
The TOGAF Series Guides provide guidance to address specific concerns and use cases with
further explanations and more details. Which guide is part of the TOGAF Standard?
 Technology Architecture
 Business Architecture
 Security Architecture
 Adapting the ADM
Which phase of the TOGAF Architecture Development Method (ADM) determines existing
business constraints for the upcoming implementation?
Complete the sentence with the applicable pair of words: Mitigation actions identified with a
Business Transformation Readiness Assessment are worked into Phase … and Phase ….
 Phase E: Opportunities and Solutions / Phase F: Migration Planning
According to the TOGAF Standard, which one of the following statements about the Business
Transformation Readiness Assessment is false?
 The ADM Technique identifies risks and improvement actions.
Business Transformation Readiness Assessment is
 The ADM Technique consists of five recommended activities in an assessment of an
organization’s readiness.
 The ADM Technique assesses the organization’s readiness to address business
transformation.
 The ADM Technique uses maturity models to present the readiness factors.
Which one of the following statements about Building Blocks (BB) is false?
 They are equivalent to software components or micro services.
Which one of the following statements the TOGAF Standard describes as the purpose of the
Architecture Requirements Specification?
 A quantitative view of the solution stating measurable criteria that must be met
According to the TOGAF Standard, which one of the following documents or concepts contains
the business goals , strategic plans, and changes in environment?
 Request for Architecture Work why not vision
Complete the sentence: The Enterprise Continuum provides a model for categorizing internal and
external artifacts held in…
 …Enterprise Repositories.
In which phase of the TOGAF Architecture Development Method (ADM) business
transformation risks are mainly identified?
 Phase A: Architecture Vision
Which of the TOGAF Standard deliverables should contain mitigation actions addressing
business transformation readiness risks?
 Implementation and Migration Plan
According to the TOGAF Standard, which one of the following statements describing the
(Architecture) Content Framework is right?
 The Content Framework can be used as starting point for Enterprise Architecture
by structuring architectural information.
 The Content Framework mirrors phases of the Architecture Development Method
(ADM) on its top-level structure.
 The Content Framework is influenced by the applied Enterprise Architecture
Framework and software tooling.
Complete the sentence by selecting the applicable pair of words: When considering Architecture
Governance, the Enterprise Architecture team and the implementer are ... and ... by the
stakeholder.
 directed / controlled
According to the TOGAF Standard, 10th edition, which of the following best describes
Architecture Governance?
 System by which (Enterprise) Architectures are directed and controlled
What is the main objective of the Preliminary Phase of the TOGAF Architecture Development
Method (ADM)?
 Scope the elements of the enterprise affected by the EA Capability
Which one of the following is the perfect example for an architecture asset that might be part of
the specific category of the Architecture Continuum as part of the Enterprise Continuum in the
TOGAF Standard?
 Standardized infrastructure components
TOGAF recommends a detailed analysis process where each ABB, which represents a high-level
functional requirement, is mapped to one or more SBBs. These SBBs are more detailed and
implementation-oriented, ensuring that they fulfill the requirements outlined in the ABBs.
Deliverables are contractually specified and contain artifacts. Artifacts represent specific classes
of architectural output, and building blocks represent architectural components at various levels
of abstraction.
What is the primary purpose of Phase A in establishing an architecture practice according to
TOGAF?
 To define or review the vision, stakeholders, and principles of the architecture
practice
Explanation
In Phase A: Architecture Vision, the focus is on defining or reviewing the vision, stakeholders,
and principles of the architecture practice. This phase emphasizes understanding the broader
context and setting the foundational aspects of the architecture practice.
In TOGAF's stakeholder management, what is a key consideration when determining

communication and engagement strategies for stakeholders?
 The stakeholder's level of influence and interest in the architecture initiative.
Explanation
While various factors can influence communication strategies, in TOGAF's stakeholder
management, the stakeholder's level of influence and their interest or concern regarding the
architecture initiative are primary determinants. This ensures that engagement is tailored to those
who have a significant impact or vested interest in the outcome.
Which of the following is a typical benefit of assessing architectural maturity in TOGAF?
 Identifying areas of improvement in architectural processes.

 Benchmarking against industry standards.
 Guiding the evolution of the architecture capability.
Explanation
While compliance with regulations is important, the primary focus of Architectural Maturity
Models in TOGAF is on assessing and improving the maturity of architectural processes and
capabilities, rather than regulatory compliance.
Which statement about "Artifacts" in TOGAF is accurate?
 Artifacts are the tangible outputs of the architecture work
Explanation
Artifacts in TOGAF are a means of describing the architecture in a form that provides a guide for
stakeholders and which enables a clear understanding, governance, and evolution of the
architecture. They can be in the form of diagrams, specifications, tables or compilations and can
be at varying levels of detail.
Refer to the information below:
Output & Outcome: Work package description, Implementation and Migration strategy
Input: Analysis of differences between the Baseline and Target Architectures
Phase: ?
 Phase E
Explanation
Phase E: Opportunities and Solutions is where the initial implementation plans are formulated,
and the migration strategy is developed. This phase takes the results of the gap analysis and
begins to shape them into Work Packages, while also defining the Implementation and Migration
strategy. The focus is on identifying major implementation projects and grouping them into work
packages.

Togaf

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

Togaf

Uploaded by

Copyright:

Available Formats

Common sense

(A) ADM (Architecture Development Method)

The figure reproduced below presents an overview of TOGAF ADM.

(B) Architecture Content Framework

The figure reproduced below depicts the Architecture Content Metamodel.

(C) Enterprise Continuum

(D) Architecture Repository

The Architecture Repository holds six classes of information.

(E) Reference Models

The reference model has double function

(F) Capability Framework

TOGAF ARCHITECTURE CONTENT FRAMEWORK ("CRIB

TOGAF’s approach to Architecture Content is based on the following ideas :

TOGAF CONTENT METAMODEL - OVERVIEW

TOGAF Architecture Content Metamodel

TOGAF Architecture Content Metamodel : Core Content and Extensions

A few examples of variable conditions that might apply :

TOGAF CONTENT METAMODEL - CORE AND EXTENSIONS

TOGAF Architecture Content : Artifacts and Views

Three classes of artifacts are generated :

TOGAF CONTENT METAMODEL - ARTIFACTS

TOGAF Architecture Content : Deliverables

TOGAF Architecture Content : Building Blocks

In other words, an « architecture description » is a model that :

TOGAF ADM AND THE "BUILDING BLOCKS"

TOGAF ENTERPRISE CONTINUUM ("CRIB NOTES")

 Abstract – concrete (vertical dimension)

The Enterprise Continuum is partitioned in three distinct continua :

 Enterprise Context Continuum

WHAT IS TOGAF ADM ("CRIB NOTES")?

TOGAF ADM Approach

In short, for TOGAF’s authors:

ADM : Preliminary Phase

The Preliminary Phase can be understood in two ways :

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures — Data Architecture

Phase C: Information Systems Architectures — Application Architecture

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

ADM Architecture Requirements Management

TOGAF TRM ("CRIB NOTES")

TOGAF Technical Reference Model (TRM)

Any TRM has two components :

The TRM is expected to be customized for each organization.

 Graphics and image

Additional groups or some regrouping might be adopted in an organization.

Application platform interface

Communications infrastructure interface

Taxonomy of Service Qualities

 Availability (the degree to which something is available for use), including:

« Such models provide the following benefits :

US DoC Architecture Maturity Model

The six levels are :

The nine enterprise architecture elements are

Most elements The entire unit

TOGAF Architecture Repository ("CRIB NOTES")

 The Architecture Metamodel

The Architecture Metamodel

 The Architecture Content Metamodel (i.e. the set of 17 to 32 categories of building

 Legal and regulatory obligations

The Reference Library

A good business scenario is also "SMART":