This appendix contains the answers to the Examination Papers in Appendix B.
For each question, award yourself one point for each correct answer.
The target score for each examination is 28 points or more out of 40 (70%). Note that at the time of writing the certification examination has a pass mark lower than this test yourself examination, so if you can make the target you should be ready to take the real examination.
Item 1 A
This is the best answer. The TOGAF standard is a framework - a detailed method and a set of supporting tools - for developing an enterprise architecture.
Item 2 B
PART II: Architecture Development Method describes the TOGAF Architecture Development Method (ADM) - a step-by-step approach to developing an enterprise architecture in a number of phases.
Item 3 E
An architecture framework is a foundational structure, or 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.
Phase C: Information Systems Architectures describes the development of Information Systems Architectures for an architecture project, including the development of Data and Application Architectures.
Item 5 D
A deliverable is a work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders. Deliverables represent the output of projects and those deliverables that are in documentation form will typically be archived at completion of a project, or transitioned into an Architecture Repository as a reference model, standard, or snapshot of the Architecture Landscape at a point in time.
Item 6 E
The Enterprise Continuum is a model providing methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures. The Enterprise Continuum comprises two complementary concepts: the Architecture Continuum and the Solutions Continuum.
Item 7 E
Phase E: Opportunities & Solutions conducts initial implementation planning and the identification of delivery vehicles for the architecture defined in the previous phases.
Item 8 B
The first execution of the ADM will often be the hardest, since the architecture assets available for re-use will be relatively scarce. Even at this stage of development, however, there will be architecture assets available from external sources such as the TOGAF standard, as well as the IT industry at large, that could be leveraged in support of the effort.
Item 9 D
Output is generated throughout the ADM process, and output in an early phase may be modified in a later phase. The TOGAF standard recommends that the versioning of output is managed through version numbers. In all cases, the ADM numbering scheme is provided as an example. It should be adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.
Item 10 E
Organization-Specific Architectures are viewed as being at the right end of the Architecture Continuum, and are the most relevant to the IT customer community, since they describe and guide the final deployment of solution components for a particular enterprise or extended network of connected enterprises.
Item 11 C
The Enterprise Continuum provides a view of the Architecture Repository that shows the evolution of these related architectures from generic to specific, from abstract to concrete, and from logical to physical.
Item 12 E
The Solutions Continuum defines what is available in the organizational environment as re-usable Solution Building Blocks (SBBs).
Item 13 E
The Solutions Continuum is a population of the architecture with reference building blocks - either purchased products or built components - that represent a solution to the enterprise’s business need expressed at that level.
Item 14 D
Strategic change is a business driver.
Item 15 C
When an existing application is replaced, there will be a critical need to migrate data (master, transactional, and reference) to the new application. The Data Architecture should identify data migration requirements and also provide indicators as to the level of transformation, weeding, and cleansing that will be required to present data in a format that meets the requirements and constraints of the target application.
Item 16 C
“Who” is to identify the sponsor stakeholder(s) and other major stakeholders impacted by the business directive to create an enterprise architecture and determine their requirements and priorities from the enterprise, their relationships with the enterprise, and required working behaviors with each other. Note in this answer it incorrectly suggests that the sponsor performs the work.
Item 17 A
In Phase E the gap analysis results from all architecture domains are taken into account.
Item 18 E
The TOGAF TRM should be considered in the development of the Technology Architecture in Phase D.
Item 19 C
Architecture Contracts are prepared and issued in Phase G.
Item 20 B
Phase F activities include assessing the dependencies, costs, and benefits of the various migration projects.
Item 21 C
Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization to the architecture organization.
Item 22 B
A knowledge of the Business Architecture is a prerequisite for architecture work in any other domain (Data, Application, Technology), and is therefore the first architecture activity that needs to be undertaken, if not catered for already in other organizational processes (enterprise planning, strategic business planning, business process re-engineering, etc.).
Item 23 D
Capability-Based Planning is a business planning technique that focuses on business outcomes. It focuses on the planning, engineering, and delivery of strategic business capabilities to the enterprise. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. Capability-Based Planning accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities.
Item 24 B
Business Transformation Readiness is first assessed in Phase A, so actions can be worked into Phases E and F in the Implementation and Migration Plan.
Item 25 C
The risk categorization after implementation of mitigating actions is known as “Residual Level of Risk”.
Item 26 C
Principles are intended to be enduring and seldom amended.
Item 27 D
Business scenarios are an important technique that may be used at various stages of the enterprise architecture, principally the Architecture Vision and the Business Architecture, but in other architecture domains as well, if required, to derive the characteristics of the architecture directly from the high-level requirements of the business. They are used to help identify and understand business needs, and thereby to derive the business requirements that the architecture development has to address.
Item 28 C
A key step in validating an architecture is to consider what may have been forgotten.
Item 29 E
A key element in a successful architecture governance strategy is a cross-organization Architecture Board to oversee the implementation of the strategy.
Item 30 A
The TOGAF standard describes “compliant” as a situation where some features in an architecture specification have not been implemented, but those that have are in accordance with the specification.
The Compliance process ensures regulatory requirements are being met.
Item 32 C
The Data Architecture would define the structure of the organization’s Enterprise Continuum and Architecture Repository.
Item 33 B
A view is what you see. A viewpoint is where you are looking from - the vantage point or perspective that determines what you see.
Item 34 D
“Concerns” are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system’s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability. The terms “concern” and “requirement” are not synonymous. Concerns are the root of the process of decomposition into requirements. Concerns are represented in the architecture by these requirements. Requirements should be SMART (e.g., specific metrics).
Item 35 A
The TOGAF standard considers re-usability an attribute of a good building block.
Item 36 B
An ABB has fundamental functionality and attributes: semantic, unambiguous, including security capability and manageability.
Item 37 B
The TOGAF standard provides a typical baseline of architecture deliverables in order to better define the activities required in the ADM and act as a starting point for tailoring within a specific organization.
Item 38 A
Throughout the ADM, new information is collected relating to an architecture. As this information is gathered, new facts may come to light that invalidate existing aspects of the architecture. A Requirements Impact Assessment assesses the current architecture requirements and specification to identify changes that should be made and the implications of those changes.
Item 39 E
The TOGAF Foundation Architecture is an architecture of generic services and functions that provides a foundation on which more specific architectures and architectural components can be built. This Foundation Architecture is embodied within the Technical Reference Model (TRM), which provides a model and taxonomy of generic platform services.
Item 40 A
The TOGAF Integrated Information Infrastructure Reference Model (III-RM) is a Common Systems Architecture that focuses on the requirements, building blocks, and standards relating to the vision of Boundaryless Information Flow.
Item 41 E
Part VII: Architecture Capability Framework discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture practice within an enterprise.
Item 42 A
An enterprise architecture capability (or architecture capability), in the context of the TOGAF standard, is the ability for an organization to effectively undertake the activities of an enterprise architecture practice.
Item 43 C
Phase F confirms the Transition Architectures defined in Phase E with the relevant stakeholders and finalizes them.
Item 44 A
TOGAF 9 Part III contains a collection of guidelines and techniques for use in applying the TOGAF standard and the ADM. The guidelines document how to adapt the ADM process and specialist architecture styles, whereas the techniques are used when applying the ADM process.
The recommended dimensions to define the scope of an architecture activity are breadth, depth, time period, and architecture domains.
Item 46 A
The Architecture Capability defines the parameters, structures, and processes that support governance of the Architecture Repository.
Item 47 B
Phase A: Architecture Vision includes the validation of business principles, goals, strategic drivers, and also Key Performance Indicators (KPIs).
Item 48 C
The Architecture Content Framework provides a detailed model of architectural work products, including deliverables and their purpose, artifacts within deliverables, and the Architecture Building Blocks (ABBs) that deliverables represent.
Item 49 D
The TRM has two main components:1. A taxonomy that defines terminology, and provides a coherent description of the components and conceptual structure of an information system. 2. A model, with an associated TRM graphic, that provides a visual representation of the taxonomy, as an aid to understanding.
Item 50 E
The Architecture Vision provides the sponsor with a key tool to sell the benefits of the proposed capability to stakeholders and decision-makers within the enterprise. It describes how the new capability will meet the business goals and strategic objectives and address the stakeholder concerns when implemented.
Item 51 B
The TOGAF standard includes the Reference Model for Integrated Information Infrastructure (III-RM) that could be considered for use in this phase. It focuses on the application-level components and services necessary to provide an integrated information infrastructure.
Architecture Contracts are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. They are produced in Phase G.
Item 53 E
The process of managing architecture requirements applies to all phases of the ADM cycle. As shown by its central placement in the ADM cycle diagram, this process is central to driving the ADM process.
Item 54 D
Risk is pervasive in any enterprise architecture activity and present in all phases within the ADM.
Item 55 A
Capability-Based Planning is a business planning technique that focuses on business outcomes. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities.
Item 56 A
Architecture Governance is the practice by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.
Item 57 D
TOGAF Part VII recommends applying the ADM with the specific Architecture Vision to establish an enterprise architecture capability within an organization.
Item 58 C
The Architecture Requirements Specification provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.
Effective communication of targeted information to the right stakeholders at the right time is a critical success factor for enterprise architecture. Development of a Communications Plan in Phase A for the architecture allows for this communication to be carried out within a planned and managed process.
Item 60 A
Boundaryless Information Flow is essentially the problem of 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.
Item 61 A
Architecture governance artifacts should be stored in the Architecture Repository.
Item 62 E
The Technology Architecture includes the software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.
Item 63 D
The main components of the Architecture Repository are the Architecture Metamodel, Architecture Capability, Architecture Landscape, SIB, Reference Library, and Governance Log.
Item 64 B
The numbering scheme provided in the TOGAF ADM for its outputs is intended as an example. It should be adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed by the organization.
Item 65 D
Pattern Architecture is not one of the four domain architectures, which are BDAT: Business, Data, Application, and Technology Architecture.
Phase A: Architecture Vision is the initial phase of a cycle. Note that the Preliminary Phase is a preparatory phase. Phase A: Architecture Vision describes the initial phase of an Architecture Development Cycle. It includes information about defining the scope, identifying the stakeholders, creating the Architecture Vision, and obtaining approvals.
Item 67 E
A Transition Architecture is defined as a formal description of one state of the architecture at an architecturally significant point in time. One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.
Item 68 D
Phase F: Migration Planning develops the detailed Implementation and Migration Plan that addresses how to move from the Baseline to the Target Architecture.
Item 69 A
The III-RM is a Common Systems Architecture. The TOGAF Integrated Information Infrastructure Reference Model (III-RM) is a reference model that supports describing Common Systems Architecture in the Application domain that focuses on the requirements, building blocks, and standards relating to the vision of Boundaryless Information Flow.
Item 70 A
The Preliminary Phase has as part of its objectives establishment of the Architecture Capability; it includes defining and establishing the Organizational Model for Enterprise Architecture.
Item 71 A
Business scenarios are an appropriate and useful technique to discover and document business requirements in Phase A, and to articulate an Architecture Vision that responds to those requirements.
Item 72 B
The Transition Architectures are confirmed in Phase F. An objective of Phase F is to ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders.
The S in SMART stands for Specific. SMART is defined as follows: Specific, by defining what needs to be done. Measurable, through clear metrics for success. Actionable, by clearly segmenting the problem and providing the basis for a 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 opportunity expires.
Item 74 E
The Business Transformation Readiness Assessment technique is used for determining the readiness of an organization to accept change. Enterprise architecture often involves considerable change. It provides a technique for understanding the readiness of an organization to accept change, identifying the issues, and dealing with them in the Implementation and Migration Plan. It is based on the Canadian Government Business Transformation Enablement Program (BTEP).
Item 75 C
Capability-Based Planning is a business planning technique that focuses on business outcomes. It is business-driven and business-led and combines the requisite efforts of all lines of business to achieve the desired capability. It accommodates most, if not all, of the corporate business models and is especially useful in organizations where a latent capability to respond (e.g., an emergency preparedness unit) is required and the same resources are involved in multiple capabilities. Often the need for these capabilities is discovered and refined using business scenarios.
Item 76 B
The agreement is between development partners and sponsors. Architecture Contracts are joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. Successful implementation of these agreements will be delivered through effective Architecture Governance. Taking a governed approach to contract management ensures a system that continuously monitors integrity, changes, decision-making, and audit, as well as adherence to the principles, standards, and requirements of the enterprise. The architecture team may also be included in product procurement, to help minimize the opportunity for misinterpretation of the enterprise architecture.
Where no features are in common then it is termed Irrelevant.
Item 78 E
Stakeholders are people who have key roles in, or concerns about, the system; for example, users, developers, etc. Stakeholders can be individuals, teams, organizations, etc. A system has one or more stakeholders. Each stakeholder typically has interests in, or concerns relative to, that system.
Item 79 D
SBBs appear in Phase E of the ADM where product-specific building blocks are considered for the first time. SBBs define what products and components will implement the functionality, thereby defining the implementation.
Item 80 B
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).