Togaf Flashcards
1
Q
Togaf 9.2 Document Structure
A
Part I. Introduction Part II. Architecture Development Method Part III. ADM Guidelines and Techniques Part IV. Architecture Content Framework Part V. Enterprise Continuum and Tools Part VI. Architecture Capability Framework Part VII. Appendices
2
Q
An Enterprise Architecture is …
A
An Architecture that crosses multiple systems, and multiple functional groups within the enterprise.
Can be applied to either an entire enterprise, encompassing all of its business activities and capabilities, information, and technology that make up the entire infrastructure and governance of the enterprise, or to one or more specific areas of interest within the enterprise.
1.3 page 6
3
Q
Difference between an artifact and a deliverable
A
Deliverables are specified as contractual outputs from a project, whereas artifacts are not.
29.1 page 271
4
Q
Main Components within the TOGAF Architecture Repository
A
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
37.1 page 391
5
Q
Why the ADM numbering scheme for versioning output is an example and not mandatory?
A
To permit adaptation as required
6
Q
Where should architecture governance artifacts be stored?
A
In the Architecture Repository
2.7 page 16
7
Q
Implications of TOGAF being a generic framework
A
It must be adapted to satisfy organisation specific requirements
2.10 page 20
8
Q
Which domain describes the logical software and hardware capabilities?
A
Technology Architecture
9
Q
Which section of the TOGAF document describes the processes, skills and roles to establish and operate and architecture function within the enterprise
A
Part VI. Architecture Capability Framework
10
Q
What is an architecture framework?
A
An architecture framework is a foundational structure, or a set of structures, which can be used for developing a broad range of different architectures. It should describe a method for designing a target state of the enterprise in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.
1.3 page 8
11
Q
Classifies architecture assets that are applicable across the entire scope of the enterprise architecture.
Classifies contextual assets used to develop architectures, such as policies, standards, strategic initiatives, organizational structures, and enterprise-level capabilities. Can also classify solutions (as opposed to descriptions or specifications of solutions).
A
Enterprise Continuum
39.3
12
Q
To promote effective architectural activity within the enterprise, TOGAF 9 recommends the establishment of …
A
Enterprise Architecture Capability
2.8 page 18
13
Q
An Enterprise Architecture practice should establish capabilities in the following areas
A
Financial Management Performance Management Service Management Risk Management Resource Management Communications and Stakeholder Management Quality Management Supplier Management Configuration Management Environment Management 2.9 page 19
14
Q
Benefits of Architecture Governance
A
The benefits of Architecture Governance include:
Increased transparency and accountability and informed delegation of authority
Controlled risk management
Protection of the existing asset base through maximizing reuse of existing architectural components
Proactive control, monitoring and management mechanisms
Process, concept, and component re-use across all organizational business units
Value creation through monitoring, measuring, evaluation, and feedback
Increased visibility
Greater shareholder value
Integrates with existing processes
2.9 page 19
15
Q
Phase of the ADM used to finalize a set of transition architectures that will support implementation
A
Phase F
16
Q
TOGAF 9.2 part III provides techniques, such as developing principles and gap analysis, to support tasks within the …
A
Architecture Development Method
17.2 page 175
17
Q
Recommended dimensions to define the scope of an architecture
A
Architecture Domains
Level of detail
Enterprise focus
Time Period
18
Q
Show a long-term summary view of the
entire enterprise.
Provide an organizing framework for
operational and change activity and allow for direction setting at an executive level.
A
Strategic Architecture
19
Q
What part of Architecture Repository holds specifications to which architectures must conform?
A
Standards Information Base
20
Q
An association of companies has defined a data model for sharing inventory and pricing information. Where this model would fit in the Architecture Continuum
A
Industry Architecture
21
Q
Key objectives of Phase A of the TOGAF ADM
A
Develop a high level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture
Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.
22
Q
What document is used to initiate ADM cycle
A
Request for Architecture Work
23
Q
Togaf defines 4 ADM iteration cycles (iterations)
A
Architecture Capability Iteration 0-A
Architecture Development Iteration B-D
Transition Planning Iteration E-F
Architecture Governance Iteration G-H
18.2 page 180
24
Q
Which of the following is the usual approach for developing the Baseline Business Architecture if no architecture of few architecture assets exists
A
Bottom up
7.3.2
25
First phase directly concerned with the planning of the implementation of the target architecture
Phase E
12.3.8 page 136
26
Phase which focuses on the governance and management of the Architecture Contracts that cover the overall implementation and deployment process
Phase G
27
A server consolidation project that does not change the operating characteristics of the application would require ...
a simplification change
15.5.2 page 162
28
Objective of the Preliminary Phase
To define the architecture principles
29
What drives the requirements and performance metrics when scoping the enterprise architecture work in the Preliminary Phase
Business imperatives
30
Requirements Management Phase is responsible for
Managing the flow of requirements
31
The Business Transformation Readiness Assessment is primarily focused on
determining if the organization is ready to accept change
Chapter 26 page 249
32
Architecture Principles
are a set of principles that relate to architecture work.
They reflect a level of consensus across the enterprise, and embody the spirit and thinking of existing enterprise principles.
Architecture principles govern the architecture process, affecting the development, maintenance, and use of the Enterprise Architecture.
Architecture principles may restate other enterprise guidance in terms and form that effectively guide architecture development.
Each Architecture principle should be clearly related back to the business objectives and key architecture drivers.
33
Architecture Principles template sections
Name
Statement or Principle
Rationale
Implications
20.3 page 198
34
Five Quality criteria for defining Architecture Principles
Stable, Understandable, Complete, Robust, Consistent
| 20.4.1 page 199
35
Gap analysis purpose
Identify potential missing or overlapping functions
36
In a Gap Analysis a building block which appears in the Target Architecture but does not appear in the Baseline Architecture indicates
A new function that must be built or procured
37
Parts of the conceptual structure of the TOGAF Architecture Governance Framework
```
Context
Process
Content
Repository
Process Flow Control
```
44.2.1 page 449
38
Architecture Board is responsible and accountable for ...
ensuring consistency between sub-architectures
enforcement of architecture compliance
identifying and approving components for reuse
providing the basis for all decision-making with regard to the architectures
flexibility of the enterprise architecture
improving the maturity level of architecture discipline within the organization
....
41.2 page 413
39
Architecture compliance review purpose
To review a project against established architectural criteria, spirit, and business objectives.
Normally forms the core of an Enterprise Architecture Compliance strategy.
Catch errors in the project architecture early, reduce cost and risk of changes required later
Ensure application of best practices
Provide an overview of the compliance
Identify where the standards themselves may require modification
Identify services which are application-specific but might be provided as part of the enterprise infrastructure
Document strategies for collaboration, resource sharing, and other synergies
Take advantage of advances in technology
Communicate to management the status of technical readiness
Identify key criteria for procurement activities
Identify and communicate significant architectural gaps
42.3 page 421
40
TOGAF guidelines to use the ADM to establish an architecture capability
Use the same approach as with any other capability
Regard the establishment as an ongoing practice
Apply the ADM with the specific vision to establish the practice
40.1 p.407
41
Architecture
1. The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
2. The structure of components, their inter-relationship, and the principles and guidelines governing their design and evolution over time
3.7 page 22
42
Viewpoints represent
concerns of the stakeholders
43
Building block (definition)
A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions.
3.23 page 24
44
Architecture Building Blocks vs Solution Building Blocks
Architecture building blocks define functionality where as Solution building blocks define the implementation of functionality
45
Purpose of Architecture Definition Document
The Architecture Definition Document is the deliverable container for the core architectural artifacts created during a project and for important related information. The Architecture Definition Document spans all architecture domains (business, data, application, and technology) and also examines all relevant states of the architecture (baseline, transition, and target).
A Transition Architecture shows the enterprise at an architecturally significant state between the Baseline and Target Architectures. Transition Architectures are used to describe transitional Target Architectures necessary for effective realization of the Target Architecture.
The Architecture Definition Document is a companion to the Architecture Requirements Specification, with a complementary objective:
- The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects
- The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture
A description to communicate the intent of the architect
32.2.3 page 352
46
Who initiates a Request for Architecture Work
The sponsoring organization
47
Togaf Technical Reference Model
The Technical Reference Model includes a set of graphical models and corresponding taxonomy.
The TOGAF TRM is an example of a Foundation Architecture. It is a fundamental architecture
upon which other, more specific architectures can be based.
A Foundation Architecture consists of generic components, inter-relationships, principles, and
guidelines that provide a foundation on which more specific architectures can be built. The
TOGAF ADM is a process that would support specialization of such Foundation Architectures
in order to create organization-specific models.
48
Integrated Infrastructure Reference Model (III-RM) is an example of an
Application Architecture reference model
49
Simplest way of thinking about Enterprise Continuum
View of the Architecture Repository
50
Class of architectural information within the Architecture Repository that defines processes that support governance of the Architectural Repository
Architecture Capability
Chapter 39 page 434
51
Most generic artifact in the Architecture Continuum
Foundation Architecture
52
As the architecture evolves, the assets in the Solutions Continuum progresses towards a
Organization Specific Solutions
53
In which phase are the business principles, business goals and strategic drivers first validated?
Phase A
54
Primary use of the Architecture Vision Document
A tool for selling the benefits of the proposed capability to stakeholders.
The Architecture Vision is created early on in the ADM cycle. It provides a summary of the
changes to the enterprise that will accrue from successful deployment of the Target Architecture.
The purpose of the Architecture Vision is to provide key stakeholders with a formally agreed
outcome. Early agreement on the outcome enables the architects to focus on the detail necessary
to validate feasibility. Providing an Architecture Vision also supports stakeholder
communication by providing a summary version of the full Architecture Definition.
32.2.8 page 356
55
Phase B objectives
Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve business goals, and respond to strategic drivers set out in the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Business Architectures
7.1 page 78
56
Phase C objectives
Develop the Target Information Systems Architecture, describing how the enterprise's Information Systems Architecture will enable the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns
Identify candidate Architecture roadmap components based upon gaps between the Baseline and Target Information Systems (Data and Application) Architectures
8.1 page 96
57
Model for use in Phase C Application Architecture
The Integrated Information Infrastructure Reference Model
| 35.4.1 page 379
58
What document establishes the connection between the architecture organization and the implementation organization in Phase G?
Architecture Contract
| 43.2.2 page 443
59
Phase H approach
Managing changes to the architecture in a cohesive and architected way.
Establish and support the implemented Enterprise Architecture as a dynamic architecture; one having the flexibility to evolve rapidly in response to changes in the technology and business environment.
Capacity Measurement
Change Management
Measuring Business Growth
page 160
60
Business imperatives to be considered when determining the requirements for enterprise architecture work in the Preliminary Phase.
Business requirements
Cultural aspirations
Forecast financial requirements
Strategic intent
5.5.3 page 59
61
ADM ongoing activity visited throughout TOGAF
Requirements Management
62
Risk management in ADM
Risk is pervasive in all enterprise architecture activity and should be managed in all phases of the ADM.
Classification, Identification, Initial Risk Assesment, Mitigation, Residual Risk Assessment
27.2 page 258
63
A business planning technique that focuses on business outcomes. It also copes well with the friction of co-ordinating projects across corporate functional domains that together enable the enterprise to achieve that capability.
Capability based planning
Chapter 28 page 263
64
Technique recommended by TOGAF to help identify and understand requirements
Business Scenarios
65
Foundation for making architecture and planning decisions, framing policies, procedures and standards and supporting resolution of contradictory situations
Architecture principles
20.4.1 page 199
66
Recommended to define requirements and articulate the Architecture Vision created in Phase A
Business Scenario
67
It highlights services that are yet to be developed
Gap Analysis
| chapter 23 page 235
68
Practice by which the enterprise architecture and other architectures are managed and controlled at an enterprise level
Architecture Governance
44.1.1 page 445
69
What does TOGAF Part VI recommend in order to implement an Enterprise Architecture Capability?
Architecture Development Method
| Chapter 40 page 407
70
Essential aspect of architecture governance
Ensuring the compliance of individual projects to the enterprise architecture
71
Architecture Compliance review purpose
To communicate the technical readiness of the project
42.3.1 page 421
72
A ... is used to describe ... of the stakeholder
View, Concern
73
Every architecture view has an associated ... that describes it, at least implicitly
Viewpoint
74
TOGAF building blocks
Packages of functionality intended to meet business needs across the organization
Should have stable, published interfaces that allow other building blocks to interoperate with them
May have multiple implementations but with different, interdependent Building Blocks
May be assembled from other Building Blocks
33.2.2 page 365
A building block's boundary and specification should be loosely coupled to its implementation; i.e. it should be possible to realize a building block in several different ways without impacting the boundary or specification of the building block
75
Legacy systems and processes that are going to be used again in the future are considered ...
Reusable Building Blocks
33.3.1.2 page 368
76
Purpose of the Architecture Requirements Specification
A quantitative view of the solution to measure the implementation
32.2.6 page 354
77
Purpose of Communications Plan
To ensure architecture information is communicated to the right stakeholders at the right time
78
TOGAF Technical Reference Model ...
is an example and should be tailored to the needs of an organization
79
Which TOGAF component was created to enable architects to design architectures addressing Boundaryless Information Flow
The Integrated Information Infrastructure Model
35.4.1. page 379
80
Getting information to the right people at the right time in a secure, reliable manner in order to support the operations that are core to the extended enterprise
Boundaryless Information Flow
81
TOGAF Technical Reference Model ...
is a fundamental architecture upon which more specific architectures can be based
35.4.1 page 379
82
Which phase of the ADM ensures that implementation projects conform to the defined architecture
Phase G
14.1 page 150
83
The requirements management phase ...
stores requirements and manages their flow into relevant ADM phases
84
Preliminary phase objective ...
To define the framework and methodologies to be used
85
When creating views for a particular architecture, what is the recommended first step?
Refer to existing libraries of viewpoints, to identify one for re-use
86
which of the following architectures in the Architecture Continuum contains the most re-usable architecture elements?
Foundation Architecture
87
Architecture Vision document
A high level description of the baseline and target architectures
88
Enterprise Continuum use in organizing and developing an architecture
Used to structure re-usable architecture and solution assets
89
Document sent from sponsoring organization to trigger start of an ADM cycle
Request for Architecture Work
90
Architecture Governance
The practice by which enterprise architectures are controlled at an enterprise-wide level
44.1.1 page 445
91
Component within Architecture Repository that holds best practice or template materials that can be used to construct architectures
Reference Library
| 37.3 page 393
92
Architecture Board responsibilities
Decision Making for changes in the architecture
Enforcing Architecture Compliance
Improving the maturity of the organization's architecture discipline
Production of governance materials.
41.2 page 413
93
Purpose of Compliance Assesment
To govern the architecture throughout its implementation process
94
Key objective of Technology Architecture Phase
Togaf 9.2 - 11.1
The objectives of Phase D are to:
Develop the Target Technology Architecture that enables the Architecture Vision, target business, data, and application building blocks to be delivered through technology components and technology services, in a way that addresses the Statement of Architecture Work and stakeholder concerns
Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures
To define technology components into a set of technology platforms
95
Why the ADM should be adapted
To suit the specific needs of the enterprise
96
In which phase of the ADM are Gap Analysis results from earlier phases consolidated
Phase E
12.1 page 132
97
Purpose of business scenario
To help identify and understand the business requirements that an architecture must address
98
Purpose of enterprise architecture
To optimise an enterprise into an environment that is responsive to business needs
99
How Architecture Principles are used within the ADM
They are used to guide decision making within the enterprise
20.1 page 197
100
TOGAF Building Blocks use in the ADM cycle
Building block become more implementation specific in Phase E
12.1 page 132
101
Phase A objective
To secure formal approval to proceed
102
TOGAF Part III provides
a set of resources that can be used to adapt and modify the Architecture Development Method
103
Objective of Phase B, Business Architecture
To demonstrate how stakeholder concerns are addressed in the Business Architecture
104
Which section of the TOGAF template for Architecture Principles should highlight the business benefits for adhering to the principle
Rationale - Should highlight the business benefits of adhering to the principle, using business terminology. Point to the similarity of information and technology principles to the principles governing business operations. Also describe the relationship to other principles, and the intentions regarding a balanced interpretation. Describe situations where one principle would be given precedence or carry more weight than another for making a decision.
20.3 page 198
105
Defined by TOGAF as a representation of a system from the perspective of a related set of concerns
Architecture View
31.1 page 319
106
TOGAF Architecture Governance Framework includes ...
a model for governance including process, content and context
44.2.1 page 449
107
Order of solutions ranging from generic to enterprise specific
Foundation, Common Systems, Industry, Organisation specific
35.4.1 page 378
108
Objectives of ADM phase E
Generate the initial complete version of Architecture Roadmap, based upon the gap analysis and candidate Architecture roadmap components from Phases B, C and D
Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
Define the overall solution building blocks to finalize the Target Architectures based on the Architecture Building Blocks (ABBs)
12.1 page 132
109
Part of Architecture Repository that shows the building blocks that are currently in use within the organisation
Architecture Landscape
37.2 page 392
110
Responsible for the acceptance and sign-off of an Architecture Compliance review
Architecture Board
42. 2 page 424
42. 4.3 page 426
41. 2 page 413
111
According to TOGAF, in which page of the ADM should an initial assessment of business transformation readiness occur
Phase A
6.2 page 67
112
A gap analysis will enable the architect to do:
identify building blocks that have been inadvertently ommited
identify building blocks that have been intentionally eliminated
identify building blocks to be carried over
identify new building blocks that are needed
23.1 page 235
113
Approach for adapting the ADM in the situation where the business case for doing architecture is not well recognized
If the business case for doing architecture at all is not well recognized, then creating an Architecture Vision is almost always essential; and a detailed Business Architecture often needs to come next, in order to underpin the Architecture Vision, detail the business case for remaining architecture work, and secure the active participation of key stakeholders in that work.
4.3 page 42
114
What technique does TOGAF recommend for evaluating the status of an organisation to undergo change?
Business Transformation Readiness Assessment
115
Initial Level of Risk in Risk Management
The categorization before determining and implementing mitigating actions
27.1 page 257
116
A View is used to describe how the ... of a stakeholder are being met
Concerns
117
The Architecture Development Method produces content to be stored in the Repository. Which is classified according to the ...
Enterprise Continuum
118
The state of the architecture artifacts as a project progresses through ADM phases A to D
The artifacts evolve from generic architectures to organisation-specific architectures
119
Phase H classification for an incremental change
A change driven by a requirement to derive additional value from the existing investment
155.2 page 162
120
Used as a template to create a View
Viewpoint
121
In which sequence should Application Architecture and Data Architecture be developed in Phase C
Application Architecture and Data Architecture may be developed in either sequence
122
Is used to store different classes of architectural output created by the ADM
Architecture Repository
37.1 page 391
123
A key step in validating a proposed target architecture is to consider what may have been forgotten. What technique does TOGAF recommend to address this issue?
Gap Analysis
124
In the Preliminary Phase, preparing the organization to undertake successful architecture
defining architecture principles 5.1, 5.3.4
defining relationship between management frameworks 5.5 page 57
defining the enterprise 5.3.1, 5.5
evaluating the enterprise architecture maturity 5.5
125
Which phase of the ADM establishes a set of Principles?
Preliminary Phase
126
In which phase of the ADM does the business scenario technique figure most prominently?
Architecture Vision
127
Describe Architecture Vision Document
A description of how the new capability will address stakeholder concern
somewhat 32.2.8 page 356
128
Describe TOGAF
A process model, best practices and assets to aid production, use and maintenance of enterprise architecture
129
Which ADM phase establishes the connection between the architecture organization and the implementation organization through the Architecture Contract?
Phase G - Architecture Governance
130
Requirements Management Phase
The ADM phase manages the flow of requirements, storing them, and feeding them in and out of the relevant ADM phases
131
Which section of the TOGAF template for defining principles should highlight the requirements for carrying out the principle?
Implications
| 20.3 page 198
132
Next step in an Architecture Compliance Review once the scope of the review has been determined?
Tailor the checklist to address business requirements
42.4.1 page 424
133
During the implementation of an architecture, if the original Architecture Definition and requirements are not suitable, a ... may be submitted to initiate further architecture work
Change Request
| 32.2.11 page 388
134
Architecture compliance review purpose
determining the technical readiness of a project
ensuring the application of best practices
identifying error in an architecture project
identifying where architecture standards require modification
42.3.1 page 421
135
Step in Phases B, C and D before development of the baseline and target architecture
Select reference models, viewpoints and tools
7.3 page 80
136
Which ADM phase is responsible for assessing the performance of the architecture and making recommendations for change
Phase H - architecture change management
15.3.5 page 159
137
Which Model within TOGAF is intended to assist with the release management of the TOGAF specification
Document Categorization Model
| Not in TOGAF 9.2
138
Which ADM phase provides architectural oversight of the implementation?
Phase G - Implementation Governance
Chapter 14 - page 149
139
Represents implementations of the architecture at the corresponding levels of the Architecture Continuum
Solutions Continuum
35.4.2 page 380
140
Used in organising and developing an architecture to aid communication and understanding between architects
Enterprise Continuum
35.1 p375
141
Purpose of Architecture Roadmap
To show progression of change from the Baseline Architecture to the Target Architecture
32.2.7 page 355 (indirect answer)
142
What technique does TOGAF recommend that focuses on achieving business outcomes rather than jut technical deliverables
Capability-Based Planning
Chapter 28 page 263
143
Which Model within TOGAF is closely related to the concept of Boundaryless Information Flow?
The Integrated Information Infrastructure Model
35.4.1 page 379
144
Which one of the following does TOGAF state is an objective for Phase A: Architecture Vision?
To validate business principles, goals, drivers and key performance indicators
6.3 page 67
145
In which ADM phase do building blocks become implementation specific
Phase E
12.1 page 132
146
Approach for adapting the ADM in the situation where business principles dictate that a packaged solution be used
Completion of the Business Architecture should follow the information Systems Architecture
147
Which Architecture domain is recommended to be the first architecture work undertaken in the ADM cycle
Business Architecture
148
According to TOGAF, all of the following are responsibilities of an Architecture Board
Ensuring consistency between sub-architectures
Ensuring flexibility of the enterprise architecture to meet business needs
Improving the maturity of the organization's architecture discipline
Monitoring of architecture contracts
41.2 page 413
149
Which section of the TOGAF document contains a structured metamodel for architectural artifacts
Part IV: Architecture Content Framework
Chapter 30 page 277
150
Building blocks specification should be loosely coupled to implementation
TRUE
33.2.2 page 365
151
Foundation Architecture characteristics
Generic building blocks, their inter-relationships with other building blocks, combined with the principles and guidelines that provide a foundation on which more specific architectures can be built.
The ADM is also useful to populate the Foundation Architecture of an enterprise. Business requirements of an enterprise may be used to identify the necessary definitions and selections in the Foundation Architecture. This could be a set of re-usable common models, policy and governance definitions, or even as specific as overriding technology selections (e.g., if mandated by law). Population of the Foundation Architecture follows similar principles as for an Enterprise Architecture, with the difference that requirements for a whole enterprise are restricted to the overall concerns and thus less complete than for a specific enterprise.
It is important to recognize that existing models from these various sources, when integrated, may not necessarily result in a coherent Enterprise Architecture. "Integratability" of Architecture Descriptions is considered in 4.6 Architecture Integration .
Foundation Architecture
A Foundation Architecture consists of generic components, inter-relationships, principles, and guidelines that provide a foundation on which more specific architectures can be built. The TOGAF ADM is a process that would support specialization of such Foundation Architectures in order to create organization-specific models.
The TOGAF TRM is an example of a Foundation Architecture. It is a fundamental architecture upon which other, more specific architectures can be based. See the TOGAF® Series Guide: The TOGAF® Technical Reference Model (TRM) for more details.
It includes a model of application components and application services software, including brokering applications
152
TOGAF covers the development of four architecture domains
Business
Data
Technology
Application
153
Objective of Phase G: Implementation Governance
Ensure conformance for the target architecture
14.1 page 150
154
Statement of Architecture Work
It defines the scope and approach to complete an architecture project
32.2.20 page 363
155
Phase H steps
The level of detail addressed in Phase H will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase H as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.
The steps in Phase H are as follows:
Establish value realization process
Deploy monitoring tools
Manage risks
Provide analysis for architecture change management
Develop change requirements to meet performance targets
Manage governance process
Activate the process to implement change
15.3 page 158
156
Value stream
A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user.
157
Objectives of the Preliminary Phase
Determine the Architecture Capability desired by the organization:
- Review the organizational context for conducting Enterprise Architecture
- Identify the scope of elements of the enterprise organizations affected by Architecture Capability
- Establish Capability Maturity target
Establish the Architecture Capability:
- Define and establish the Organizational Model for Enterprise Architecture
- Define and establish the detailed process and resources for Architecture Governance
- Select and implement tools that support the Architecture Capability
- Define Architecture Principles
158
In which part of the ADM cycle do building block gaps become associated with work packages that will address the gap?
Phase E
159
Responsibility of an Architecture Board
Enforcement of architecture compliance
160
Reason why Business Architecture is recommended to be first architecture developed
It provides prerequisite knowledge for undertaking work in the other architecture domains
161
Integrated Infrastructure Reference Model
Application Architecture Reference Model
162
Architecture Governance
Practice by which the enterprise architecture is managed and controlled at an enterprise level is known as
41.1.1 page 445
163
Phase H re-architecting change
A change driven by a requirement to increase investment in order to create new value for exploitation
15.5.2 page 162
164
The purpose of Business Transformation Readiness Assessment technique
To determine if organization is ready to undergo change
165
In which ADM phase is the implementation and Migration Plan coordinated with other frameworks
Phase F
13.1 page 142
166
Described by the TOGAF Architecture Content Framework as a type of artifact that shows list of things
Catalog
A.4 page 479
31.6 page 326
167
Includes open system standards and general building blocks
Foundation Architecture
168
TOGAF uses a version numbering scheme to illustrate the evolution of the Baseline and Target Architecture Definitions. Which version number in this convention indicates a formally reviewed, detailed architecture
1.0
169
TOGAF Architecture Development Method
A process for developing an organization-specific enterprise architecture
170
The need for the ADM process to be governed
To ensure that the method is being applied correctly
171
Objective of Phase A, Architecture Vision
Identifying stakeholders and their concerns
172
TOGAF recommends for use in developing of the Architecture Vision
Business Scenarios
173
Relevant architecture resource in Phase D
Generic technology models relevant to the organization's industry sector
174
In which section of the TOGAF template for Architecture Principles would a reader find the answer to the question 'How does this affect me'?
Implications
20.3 page 198
175
Key interests crucially important to stakeholders
Concerns
31.1 page 319
176
Which Architecture would describe Infrastructure requirements
Technology Architecture
11.3.1 page 125
177
Reference Library within Architecture Repository
```
The Reference Library provides a repository to hold reference materials that should be used to develop architectures. Reference materials held may be obtained from a variety of sources, including:
■Standards bodies
■Product and service vendors
■Industry communities or forums
■Standardtemplates
■Enterprise best practice
```
```
The Reference Library should contain:
■Reference Architectures
■Reference Models
■Viewpoint Library
■Templates
```
178
Five Criteria for a good set of principles
Understandable, Robust, Complete, Consistent, Stable
179
A ... is a representation of a system from the perspective of a related set of ...
view, stakeholders
| ?
180
Standards Information Base
The Standards Information Base provides a repository area to hold a set of specifications, to which architectures must conform. Establishment of a Standards Information Base provides an unambiguous basis for Architecture Governance because:
■The standards are easily accessible to projects and therefore the obligations of the project can be understood and planned for
■Standards are stated in a clear and unambiguous manner, so that compliance can be objectively assessed
181
Purpose of Gap Analysis technique
To identify missing functions
182
How enterprise continuum is used when developing an enterprise architecture
To structure re-usable architecture and solution assets
183
A ... is used in Phase A to help identify and understand business ... that the architecture has to address
business scenario, requirements
184
Architecture Pattern
A way to put building blocks together into context
Chapter 22 page 229
185
Residual level of risk
Risk Categorization after the implementation of mitigating actions.
186
Requirements Management process
It is used to manage architecture requirements throughout ADM cycle
16.1 page 166
187
Architecture
A formal description of a system, or a detailed plan of the system at component level to guide its implementation
188
Architecture Landscape is divided into three levels:
Strategic, Segment and Capability
37.2 page 392
189
In phases B, C, D which is the final step in each phase
Create the Architecture Definition Document
7. 2 page 79
9. 31 page 99
10. 3 page 111
11. 3 page 121
190
Which part of TOGAF describes taxonomies for categorizing the outputs of architecture activity in terms of reuse?
Part V. Enterprise Continuum and Tools
191
Purpose of Architecture Compliance Review
Identifying errors in the project architecture
| 42.3.1 page 421
192
TOGAF provides a set of reference materials for establishing an architecture function within an organization known as the
Architecture Capability Framework
39.1 page 405
193
Package of functionality defined to meet business needs across an organization
A building block
3.23 page 24
194
Which document should incorporate the actions arising from the Business Transformation Readiness Assessment technique
Implementation and Migration Plan
| 2.6.5 page 255
195
Architecture Vision purpose
It provides a high-level aspirational view of the end architecture project
6.1 page 66
196
TOGAF Part VI Architecture Capability Framework recommends use of ADM cycle for establishing an architecture practice. In this scenario which architecture would describe the organizational structure for the architecture practice.
Business Architecture
| 40.1 page 407
197
Business Scenario technique purpose
To help identify and understand requirements
198
The Requirements Management process is used to
Organize architecture requirements throughout the ADM cycle
199
TOGAF Technical Reference Model
A Foundation Architecture
200
Preliminary Phase Objective
Establish the Organizational Model for enterprise architecture
201
Class of information known as the Architecture Capabillity within the Architecture Repository
Processes to support governance of the Architecture Repository
202
An Objective of phase G, Implementation Governance is to
Ensure conformance with the defined architecture by the implementation projects
203
Part of the approach in the Preliminary Phase of the ADM
Defining a set of Architecture Principles
| 5.1 page 52
204
Describe TOGAF classification in Phase H for a simplification change
A change driven by a requirement to reduce investment
| 15.5.2 page 162
205
In Phases B, C and D which is the first step in each phase
Select reference models, viewpoints and tools
7. 3 page 80
9. 3 page 99
206
The ADM can be viewed as process of populating the enterprise's own ... with relevant re-usable building blocks taken from the more generic side of the Enterprise Continuum
Architecture Repository
207
Describes concept of Boundaryless Information Flow
Getting information to the right people at the right time in a secure, reliable and timely manner
208
describes people who have key roles in, or concerns about a system
Stakeholders
| 3.72 page 31
209
In which phase of the ADM cycle do building blocks become implementation specific
Phase E
| 12.1 page 132
210
Purpose of Architecture Definition Document
To act as a deliverable container for artifacts created during a project
32.2.3 page 352
211
Building Blocks that are viewed as being at the left-hand side of the Solutions Continuum are known as ...
Foundation Solutions
212
An approach to ensure the effectiveness of and organization's architectures
TOGAF Architecture Governance Framework
213
The Enterprise Continuum provides methods for classifying architecture artifacts as they evolve from
Generic Architectures to Organization-Specific Architectures
214
Objective of Phase F: Migration Planning Phase
The objectives of Phase F are to:
Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio
Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
Coordinate the Implementation and Migration Plan with other frameworks
215
Purpose of Gap Analysis technique
To hightlight shortfalls between the baseline and target architectures
Chapter 23 page 235
216
Define general rules and guidelines for the use of assets across the enterprise
Architecture principles
| 20.2 page 198
217
Which ADM Phase includes obtaining approval for the Statement of Architecture Work
Phase A: Architecture Vision
| 6.1 page 66
218
Which section of the TOGAF template for Architecture Principles highlights the requirements for carrying out the principle?
Implications
219
TOGAF uses version numbering convention to illustrate evolution of the Baseline and Target Architecture Definitions. Which version number in this convention indicates a high-level outline of the architecture?
Version 0.1
220
In which ADM phase is the goal to ensure that the architecture achieves its original target business value
Phase H - Enterprise Architecture Capability meets current requirements
15.5 page 159
(Phase G - conformance with target Architecture)
221
Which ADM phase starts with the receipt of a Request for Architecture Work from the sponsoring organization
Phase A
6. 2.2 page 66
32. 2.17 page 362
222
Described by TOGAF Architecture Content Framework as a type of artifact that shows relationships between things.
Matrix
| 31.6 page 327
223
TOGAF defines 5 criteria for a good set of principles
Complete, Consistent, Stable, Understandable, Robust
| 20.4.1 page 199
224
A review of an architecture project against established criteria and business objectives
Architecture Compliance Review
| 42.3 page 421
225
The Architecture Landscape is divided into three levels
Capability, Segment and Strategic
| 37.2 page 420
226
Reusable artifact used to create architecture models addressing stakeholder concerns
Viewpoint
page 321
31.1
227
TOGAF describes the role of an Architecture Contract as
An agreement between development partners and sponsors on the architecture deliverables
32.2.2 page 351
228
The structure of components, their inter-relationships and the principles guiding their design and evolution over time
Architecture
229
Describes a step-by-step approach to developing an enterprise architecture
Architecture Development Method
230
Provides a set of reference materials for establishing an architecture function within an organization
Architecture Capability Framework
231
First phase of an architecture development cycle, defines the scope for an engagement and identifies the stakeholders?
Architecture Vision
232
Portfolio of guidance material to support practical application of the TOGAF approach.
TOGAF Library
233
Library resources are organized into four sections
Foundation Documents
Generic Guidance and Techniques
Industry-Specific Guidance and Techniques
Organization-Specific Guidance and Techniques
234
A concepcual structure used to plan, develop, implement, govern, and sustain an architecture
Architecture Framework
235
Two key elements of an architecture Framework according to TOGAF 9.2
A definition of the deliverables that the architecting activity should produce
A description of the method by which this should be done
2.10 page 20
236
Building Blocks characteristics
a package of functionality defined to meet the business needs across an organization
has a type that corresponds to the enterprise's content metamodel (such as actor, business service, application or data entry)
A building block has a defined boundary and is generally recognizable as "a thing" by domain experts
may interoperate with other, inter-dependent building blocks
33.2.2 page 365
237
A Good Building block characteristics
considers implementation and usage, and evolves to exploit technology and standards
may be assembled from other building blocks
may be a subassembly of other building blocks
ideally is re-usable and replaceable, and well specified
33.2.2 page 366
238
Phase A: Architecture Vision steps
Establish Architecture Project
Identify Stakeholders, concerns, and business requirements
Confirm and elaborate business goals, business drivers, and constraints
Evaluate Capabilities
Assess readiness for business transformation
Define scope
Confirm and elaborate Architecture Principles, including business principles
Develop Architecture Vision
Define the Target Architecture value proposition and KPIs
Identify the business transformation risks and mitigation activities
Develop Statement of Architecture Work; secure approval
239
Phase B: Business Architecture Steps
Select reference models, viewpoints, and tools
Develop Baseline Business Architecture Description
Develop Target Business Architecture Description
Perform Gap Analysis
Define candidate roadmap components
Resolve impacts across the Architecture Landscape
Conduct formal stakeholder review
Finalize the Business Architecture
Create the Architecture Definition Document
240
Phase E: Opportunities & Solutions Steps
Determine/confirm key corporate change attributes
Determine business constraints for implementation
Review and consolidate gap analysis results from Phases B to D
Review consolidated requirements across related business functions
Consolidate and reconcile interoperability requirements
Refine and validate dependencies
Confirm readiness and risk for business transformation
Formulate Implementation and Migration Strategy
Identify and group major work packages
Identify Transformation Architectures
Create the Architecture Roadmap & Implementation and Migration Plan
241
provide more detailed operating models
for areas within an enterprise.
can be used at the program or portfolio level to organize and operationally align more detailed change activity.
Segment Architectures
242
show in a more detailed fashion how
the enterprise can support a particular unit of capability.
used to provide an overview of current capability, target capability, and capability
increments and allow for individual work packages and projects to be grouped within managed portfolios and programs.
Capability Architectures
243
provides a repository to hold reference materials that should be used to
develop architectures.
Reference Library
244
Reference Library should contain
Reference Architectures
Reference Models
Viewpoint Library
Templates
37.3.1
245
Standards typically fall into three classes:
Legal and Regulatory Obligations: these standards are mandated by law and therefore an
enterprise must comply or face serious consequences
Industry Standards: these standards are established by industry bodies, such as The Open
Group, and are then selected by the enterprise for adoption
Industry Standards offer potential for interoperation and sharing across enterprises, but
also fall outside of the control of the enterprise and therefore must be actively monitored.
Organizational Standards: these standards are set within the organization and are based
on business aspiration (e.g., selection of standard applications to support portfolio
consolidation)
Organizational Standards require processes to allow for exemptions and standards
evolution.
37.4.2
246
Standards Lifecycle
Proposed Standard, Provisional Standard, Standard (Active), Phasing-Out Standard, Retired Standard
37.4.3
247
Standards Classification within the Standards Information Base
Business Standards, Data Standards, Applications Standards, Technology Standards
37.4.4
248
Contents of the Governance Log
Decision Log, Compliance Assessments, Capability Assessments, Calendar, Project Portfolio, Performance Measurement
37.5.2
249
This includes the initial mobilization of the architecture activity for a given purpose or
architecture engagement type by establishing or adjusting the architecture approach,
principles, scope, vision, and governance.
Architecture Capability iterations support the creation and evolution of the required Architecture Capability
250
allow the creation of architecture content by cycling
through, or integrating, Business, Information Systems, and Technology Architecture
phases
Architecture Development iterations
These iterations ensure that the architecture is considered as a whole. In this type of
iteration stakeholder reviews are typically broader. As the iterations converge on a target,
extensions into the Opportunities & Solutions and Migration Planning phases ensure that
the architecture’s implementability is considered as the architecture is finalized
251
support the creation of formal change roadmaps for a
| defined architecture
Transition Planning iterations
252
support governance of change activity progressing
| towards a defined Target Architecture
Architecture Governance iterations
253
in this style, an assessment of the baseline landscape is used to identify
problem areas and improvement opportunities
This process is most suitable when the baseline is complex, not clearly understood, or
agreed upon. This approach is common where organizational units have had a high degree
of autonomy.
Baseline First
| 18.4
254
in this style, the target solution is elaborated in detail and then mapped back
to the baseline, in order to identify change activity
This process is suitable when a target state is agreed at a high level and where the
enterprise wishes to effectively transition to the target model.
Target First
| 18.4
255
characteristics typically used to organize the Architecture Landscape
Breadth, Depth, Time, Recency
Breadth: the breadth (subject matter) area is generally the primary organizing characteristic for describing an Architecture Landscape
Architectures are functionally decomposed into a hierarchy of specific subject areas or segments.
Depth: with broader subject areas, less detail is needed to ensure that the architecture has a manageable size and complexity
More specific subject matter areas will generally permit (and require) more detailed architectures.
Time: for a specific breadth and depth an enterprise can create a Baseline Architecture and a set of Target Architectures that stretch into the future
Broader and less detailed architectures will generally be valid for longer periods of time and can provide a vision for the enterprise that stretches further into the future.
Recency: finally, each architecture view will progress through a development cycle where it increases in accuracy until finally approved
After approval, an architecture will begin to decrease in accuracy if not actively maintained. In some cases recency may be used as an organizing factor for historic architectures.
256
The steps in Phase H
■ Establish value realization process
■ Deploy monitoring tools
■ Manage risks
■ Provide analysis for architecture change management
■ Develop change requirements to meet performance targets
■ Manage governance process
■ Activate the process to implement change
15.3
257
outputs of Phase H
may include, but are not restricted to:
■ Architecture updates (for maintenance changes)
■ Changes to architecture framework and principles (for maintenance changes)
■ New Request for Architecture Work, to move to another cycle (for major changes)
■ Statement of Architecture Work, updated if necessary
■ Architecture Contract, updated if necessary
■ Compliance Assessments, updated if necessary
258
The
| areas where the Technology Architecture may be impacted in Phase D
Performance
Maintainability
Location and Latency
Availability
In the earlier phases of the ADM, certain decisions made around service granularity and service boundaries will have implications on the technology component and the technology service. The areas where the Technology Architecture may be impacted will include the following:
Performance: the granularity of the service will impact on technology service requirements
Coarse-grained services contain several units of functionality with potentially varying non-functional requirements, so platform performance should be considered. In addition, coarse-grained services can sometimes contain more information than actually required by the requesting system.
Maintainability: if service granularity is too coarse, then introducing changes to that service becomes difficult and impacts the maintenance of the service and the platform on which it is delivered
Location and Latency: services might interact with each other over remote links and inter-service communication will have in-built latency
Drawing service boundaries and setting the service granularity should consider platform/location impact of these inter-service communications.
Availability: service invocation is subject to network and/or service failure
So high communication availability is an important consideration during service decomposition and defining service granularity
11.3.1.1
259
Architecture Compliance - levels of conformance
Irrelevant: The implementation has no features in common with the architecture specification (so the question of conformance
does not arise).
Consistent: The implementation has some features in common with the
architecture specification, and those common features are
implemented in accordance with the specification. However,
some features in the architecture specification are not
implemented, and the implementation has other features
that are not covered by the specification.
Compliant: Some features in the architecture specification are not
implemented, but all features implemented are covered
by the specification, and in accordance with it.
Conformant: All the features in the architecture specification are
implemented in accordance with the specification, but
some more features are implemented that are not
in accordance with it.
Fully Conformant: There is full correspondence between architecture
specification and implementation. All specified features
are implemented in accordance with the specification,
and there are no features implemented that are not
covered by the specification.
Non-conformant: Any of the above in which some features in the
architecture specification are implemented not in
accordance with the specification.
260
Architecture Compliance Review Process Steps
Architecture Review Request
Identify Responsible Organization, (Architecture Review Co-ordinator)
Identify Lead Architect, (Architecture Review Co-ordinator)
Determine Scope of Review (Discovery), (Architecture Review Co-ordinator)
Tailor Checklists, (Lead Architect)
Schedule Architecture Review Meeting, (Architecture Review Co-ordinator)
Interview Project Principals, (Lead Architect, Project Leader, Customers)
Analyze Completed Checklists, (Lead Architect)
Prepare Architecture Review Report (Lead Architect)
Present Review Findings (Lead Architect)
Accept, Review, and Sign off (Architecture Board, Customer)
Assessment Report/Summary
261
Types of standard
Legal and Regulatory Obligations: these standards are mandated by law and therefore an enterprise must comply or face serious consequences
Industry Standards: these standards are established by industry bodies, such as The OpenGroup, and are then selected by the enterprise for adoption
Industry Standards offer potential for interoperation and sharing across enterprises, but also fall outside of the control of the enterprise and therefore must be actively monitored.
Organizational Standards: these standards are set within the organization and are based on business aspiration (e.g., selection of standard applications to support portfolio consolidation)
Organizational Standards require processes to allow for exemptions and standards evolution.
262
Standards Lifecycle
Typically, standards pass through the following stages:
Proposed Standard: a potential standard has been identified for the organization, but has not yet been evaluated for adoption
Provisional Standard (also known as a Trial Standard): a Provisional Standard has been identified as a potential standard for the organization, but has not been tried and tested to a level where its value is fully understood Projects wishing to adopt Provisional Standards may do so, but under specific pilot conditions, so that the viability of the standard can be examined in more detail.
Standard (also known as an Active Standard): a Standard defines a mainstream solution that should generally be used as the approach of choice
```
Phasing-Out Standard (also known as Deprecated Standard): a Phasing-Out Standard is approaching the end of its useful lifecycle
Projects that are re-using existing components can generally continue to make use of Phasing-Out Standards. Deployment of new instances of the Phasing-Out Standard is generally discouraged.
Retired Standard (also known as an Obsolete Standard): a Retired Standard is no longer accepted as valid within the landscape
In most cases, remedial action should be taken to remove the Retired Standard from the landscape. Change activity on a Retired Standard should only be accepted as a part of an overall decommissioning plan.
```
263
Architecture Governance Framework
Architecture Governance is an approach, a series of processes, a cultural orientation, and set of owned responsibilities that ensure the integrity and effectiveness of the organization’s architectures
page 449
264
Some features in the architecture specification are not
implemented, but all features implemented are covered
by the specification, and in accordance with it.
Compliant
265
The implementation has some features in common with the architecture specification, and those common features are implemented in accordance with the specification. However, some features in the architecture specification are not implemented, and the implementation has other features that are not covered by the specification.
Consistent
266
The implementation has no features in common with the architecture specification (so the question of conformance does not arise).
Irrelevant
267
All the features in the architecture specification are implemented in accordance with the specification, but some more features are implemented that are not in accordance with it.
Conformant
268
There is full correspondence between architecture specification and implementation. All specified features are implemented in accordance with the specification, and there are no features implemented that are not covered by the specification.
Fully Conformant
269
Any of the above in which some features in the architecture specification are implemented not in accordance with the specification
non conformant
270
Risk Effect classification
Catastrophic - infers critical financial loss that could result in bankruptcy of the organization
Critical - infers serious financial loss in more than one line of business leading to a loss in productivity and no return on investment on the IT investment
Marginal - infers a minor financial loss in a line of business and a reduced return on investment on the IT investment
Negligible - infers a minimal impact on a line of business' ability to deliver services and/or products
271
Risk Frequency classification
Frequency can be classified as ‘Frequent, Likely, Occasional, Seldom and Unlikely’
272
The Impact of a risk, that is the combination of Effect and Frequency can be classified as
'Extremely High Risk', ‘High Risk, Moderate Risk and Low Risk’
273
Architecture Governance typically does not operate in isolation, but within a hierarchy of governance structures, which, particularly in the larger enterprise, can include all of the following as distinct domains with their own disciplines and processes:
Corporate Governance
Technology Governance
IT Governance
Architecture Governance
274
The Implementation and Migration Plan provides a schedule of the projects that will realize the
Target Architecture. The Implementation and Migration Plan includes executable projects
grouped into managed portfolios and programs. The Implementation and Migration Strategy
identifying the approach to change is a key element of the Implementation and Migration Plan
Typical contents of an Implementation and Migration Plan are:
■ Implementation and Migration Strategy:
— Strategic implementation direction
— Implementation sequencing approach
■ Project and portfolio breakdown of implementation:
— Allocation of work packages to project and portfolio
— Capabilities delivered by projects
— Milestones and timing
— Work breakdown structure
— May include impact on existing portfolio, program, and projects
Project charters:
— Included work packages
— Business value
— Risk, issues, assumptions, dependencies
— Resource requirements and costs
— Benefits of migration, determined (including mapping to business requirements)
— Estimated costs of migration options
275
The objectives of Phase H are to:
Ensure that the architecture lifecycle is maintained
Ensure that the Architecture Governance Framework is executed
Ensure that the Enterprise Architecture Capability meets current requirements
15.1
276
The objectives of Phase E are to:
Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D
Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value
Define the overall solution building blocks to finalize the Target Architecture based on the Architecture Building Blocks (ABBs)
12.1
277
The objectives of Phase G are to:
Ensure conformance with the Target Architecture by implementation projects
Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests
15.1
278
The objectives of Phase F are to:
Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan
Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio
Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders
13.1
279
The steps in Phase F:
The level of detail addressed in Phase F will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase F as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.
All activities that have been initiated in these steps must be closed during the "Complete the architecture development cycle and document lessons learned step" (see 13.3.7).
The steps in Phase F are as follows:
13. 3.1 Confirm Management Framework Interactions for the Implementation and Migration Plan
13. 3.2 Assign a Business Value to Each Work Package
13. 3.3 Estimate Resource Requirements, Project Timings, and Availability/Delivery Vehicle
13. 3.4 Prioritize the migration projects through the conduct of a cost/benefit assessment and risk validation
13. 3.5 Confirm Architecture Roadmap and Update Architecture Definition Document
13. 3.6 Complete the Implementation and Migration Plan
13. 3.7 Complete the Architecture Development Cycle and Document Lessons Learned
13.3
280
The steps in Phase G:
The level of detail addressed in Phase G will depend on the scope and goals of the overall architecture effort.
The order of the steps in Phase G as well as the time at which they are formally started and completed should be adapted to the situation at hand in accordance with the established Architecture Governance.
The steps in Phase G are as follows:
14. 3.1 Confirm Scope and Priorities for Deployment with Development Management
14. 3.2 Identify Deployment Resources and Skills
14. 3.3 Guide Development of Solutions Deployment
14. 3.4 Perform Enterprise Architecture Compliance Reviews
14. 3.5 Implement Business and IT Operations
14. 3.6 Perform Post-Implementation Review and Close the Implementation
