The Open Group OGEA-103 TOGAF Enterprise Architecture Combined Part 1 and Part 2 Exam Exam Practice Test

According to the TOGAF Standard, 10th Edition, a stakeholder is “an individual with an interest in a system” 1. A stakeholder can be anyone who is affected by the system, or who can influence or be influenced by the system. Stakeholders can have different roles, perspectives, and concerns regarding the system, and they can be internal or external to the organization. Stakeholder management is a technique that helps to identify, analyze, and engage the stakeholders of an architecture project, and to address their needs and expectations 2. The other options are not correct, as they are not the term used by the TOGAF Standard to describe an individual with an interest in a system. A consumer is “an individual or group that uses a product or service” 1. A lead architect is “an individual who is responsible for leading the development of an architecture” 1. A sponsor is “an individual who provides funding and support for an architecture project” 1. References: 1: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 2: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 24: Stakeholder Management.

The class of information known as the Reference Library within the Architecture Repository contains guidelines and templates used to create new architectures. The Reference Library provides a set of resources that can be leveraged or customized for specific architecture development purposes. It includes generic building blocks, patterns, models, standards, frameworks, methods, techniques, best practices, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4 Architecture Repository.

According to the TOGAF Standard, Version 9.2, an architecture view is a representation of a system from the perspective of a related set of concerns1. It consists of one or more architecture models that demonstrate how the system addresses the stakeholder concerns1.

An architecture viewpoint is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns1. It defines the perspective, scope, notation, and techniques for creating an architecture view of a system1.

Architects can present architecture views and viewpoints to stakeholders to extract hidden agendas, principles, and requirements that could impact the final Target Architecture, because23:

Architecture views and viewpoints help to communicate and visualize the architecture in a way that is meaningful and relevant to different stakeholders, addressing their specific interests and needs.

Architecture views and viewpoints help to elicit and validate the stakeholder concerns and requirements, ensuring that they are aligned with the business goals and objectives, and that they are consistent and feasible within the architecture context.

Architecture views and viewpoints help to identify and resolve any conflicts, gaps, or trade-offs among the stakeholder concerns and requirements, ensuring that they are balanced and prioritized in the architecture design and decision-making.

Architecture views and viewpoints help to demonstrate and verify the value and benefits of the architecture to the stakeholders, ensuring that they are satisfied and committed to the architecture outcome and governance.

References:

1: The TOGAF Standard, Version 9.2, Chapter 22: Architecture Views, Viewpoints, and Stakeholders

2: The TOGAF Standard, Version 9.2, Chapter 4: Introduction to Part II, Section 4.2: What is an Architecture Framework?

3: The TOGAF Standard, Version 9.2, Chapter 31: Architectural Artifacts, Section 31.1: Basic Concepts

The Enterprise Continuum consists of two complementary concepts: the Architecture Continuum and the Solutions Continuum1. The Architecture Continuum provides a consistent way to describe and understand the generic and reusable architecture building blocks, such as models, patterns, and standards, that can be applied and tailored to specific situations2. The Solutions Continuum provides a consistent way to describe and understand the specific and implemented solution building blocks, such as products, services, and components, that realize the architecture building blocks3. The Enterprise Continuum enables the reuse and integration of architecture and solution assets across different levels of abstraction, scope, and detail, ranging from foundation architectures to organization-specific architectures1.

The Enterprise Continuum is used when developing an enterprise architecture to support the following activities1:

•Selecting relevant architecture and solution assets from the Architecture Repository or other sources, based on the business drivers, goals, and requirements

•Adapting and customizing the architecture and solution assets to suit the specific needs and context of the enterprise

•Defining and developing the target architecture and the architecture roadmap, based on the gaps and opportunities identified between the baseline and the target states

•Defining and developing the implementation and migration plan, based on the architecture roadmap and the solution building blocks

•Governing and managing the architecture and solution assets throughout the architecture lifecycle, ensuring their quality, consistency, and compliance

References: 1: The TOGAF Standard, Version 9.2 - Enterprise Continuum 2: The TOGAF Standard, Version 9.2 - Architecture Continuum 3: The TOGAF Standard, Version 9.2 - Solutions Continuum

The TOGAF standard covers the development of four architecture domains: Business, Data, Technology and Application. These domains represent different aspects of an enterprise’s architecture and provide a consistent way of describing, analyzing, and designing them. Reference: The TOGAF® Standard | The Open Group Website, Section 2.2 Architecture Development Method (ADM).

Enterprises are examples of the scope of an architecture according to the TOGAF Standard. An enterprise is defined as any collection of organizations that has a common set of goals and/or a single bottom line. Enterprises can be whole corporations or divisions of a corporation, government agencies or single government departments, partnerships and alliances of businesses working together, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.1 Core Concepts.

Risk Management is the process of identifying, assessing, and responding to risks that may affect the achievement of the enterprise’s objectives. Risk Management involves balancing positive and negative outcomes resulting from the realization of either opportunities or threats. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.3 Risk Management.

Architecture governance is the practice of ensuring compliance with the enterprise architecture and its principles, standards, and goals. Architecture governance provides the means to establish, monitor, and control the architecture development and implementation processes, and to resolve any issues or conflicts that may arise. Architecture governance also ensures that all stakeholders are represented and involved in the decision-making process, and that their interests and concerns are balanced and aligned. Statements 1 and 2 highlight the value and necessity for architecture governance to be adopted within organizations, as they emphasize the importance of responsibility, accountability, fairness, and transparency in the architectural activities. Statements 3 and 4 are more related to the benefits and outcomes of having a good enterprise architecture, rather than the governance aspect.References: : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 29: Architecture Governance

The scope of an architecture is the extent and level of detail of the architecture work. The scope of an architecture can be defined along four dimensions: project, breadth, depth, and architecture domains. The project dimension considers the boundaries and objectives of the architecture project, such as the time frame, budget, resources, and deliverables. The breadth dimension considers the coverage and completeness of the architecture across the enterprise, such as the organizational units, business functions, processes, and locations. The depth dimension considers the level of detail and specificity of the architecture, such as the granularity, abstraction, and precision of the architectural elements and relationships. The architecture domains dimension considers the aspects or segments of the architecture, such as the business, data, application, and technology domains.

Therefore, the depth dimension is the one that considers to what level of detail the architecting effort should go.

References: : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25: Architecture Scope : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25.2: Scope Dimensions : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25.2.1: Project, Breadth, Depth, and Architecture Domains

An Enterprise Architecture Capability is the ability of the organization to perform effective and efficient architecture work, including the definition, governance, and management of its architectures2. The Preliminary Phase involves the following activities1:

•Reviewing the organizational context, scope, and drivers for conducting Enterprise Architecture

•Establishing the Architecture Capability desired by the organization, including the maturity level, roles, responsibilities, processes, and tools

•Defining and establishing the Organizational Model for Enterprise Architecture, which describes how the architecture function is organized and integrated within the enterprise

•Defining and establishing the Architecture Governance framework, which provides the mechanisms for ensuring the quality, consistency, and compliance of the architecture work

•Selecting and implementing the tools that support the Architecture Capability, such as repositories, modeling tools, and communication tools

•Defining the Architecture Principles that will guide and constrain the architecture work, based on the business principles, goals, and drivers of the organization

•Defining the Organization-Specific Architecture Framework, which is an adaptation of the generic TOGAF ADM to suit the specific requirements, standards, and practices of the organization

The Preliminary Phase is essential for preparing the organization for the successful development and implementation of its architectures, as well as for ensuring the alignment of the architecture work with the business strategy and objectives1.

References: 1: Preliminary Phase 2: Enterprise Architecture Capability

The purpose of Enterprise Architecture is to guide effective change by providing a coherent and consistent view of the enterprise’s current and future state, as well as the roadmap and principles for achieving it. Enterprise Architecture helps to align business and IT strategies, optimize resources and investments, reduce complexity and risks, enhance agility and innovation, and deliver value to stakeholders. Reference: The TOGAF® Standard | The Open Group Website, Section 1.3 Executive Overview.

The statement illustrates iteration and the ADM. Iteration is the technique of repeating a process or a phase with the aim of improving or refining the outcome. Iteration allows for feedback loops and adaptations at any point in the architecture development and transition process. Separate projects may operate their own ADM cycles concurrently, with relationships between the different projects, to address different aspects or levels of the architecture in an iterative manner. Reference: The TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.

Gap Analysis is a technique that compares the Baseline Architecture and the Target Architecture to identify the differences and gaps between them. The purpose of this technique is to determine the changes and additions that are required to achieve the desired future state of the architecture. One of the main aspects of Gap Analysis is to identify the functions that are missing or overlapping in the current and future architectures, and to plan how to address them. This helps to ensure that the architecture is complete, consistent, and aligned with the business objectives and requirements3

According to the TOGAF Standard, 10th Edition, an architecture contract is “a formal agreement between a service provider and a service consumer that defines the mutual commitments and expectations for the delivery of an architecture” 1. An architecture contract is a governed approach of a particular deliverable that will ensure adherence to the principles, standards, and requirements of the existing or developing architectures, as it specifies the roles, responsibilities, deliverables, quality criteria, and acceptance criteria for the architecture work 1. The other options are not correct, as they are not governed approaches of a particular deliverable, but rather different types of deliverables within the architecture development process. An architecture vision is “a high-level, aspirational view of the target architecture” 1. A statement of architecture work is “a document that defines the scope and approach that will be used to complete an architecture project” 1. An architecture definition document is “a document that describes the baseline and target architectures for one or more domains” 1. References: 1: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions.

A set of architecture principles that cover every situation perceived meets the recommended criteria of completeness. Completeness is one of the six criteria that should be applied when developing or assessing architecture principles. Completeness means that there are no gaps or overlaps in the coverage of principles across all relevant aspects of the enterprise’s architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.7 Architecture Principles.

According to the TOGAF standard, the deliverables that match the descriptions are as follows:

1 Architecture Principles: These are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission1. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions1.

2 Architecture Contracts: These are the joint agreements between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture2. They are used to ensure that the architecture is implemented and governed according to the agreed-upon specifications and standards2.

3 Request for Architecture Work: This is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle3. It defines the scope, schedule, budget, deliverables, and stakeholders of the architecture project3.

4 Architecture Requirements Specification: This is a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture4. It defines the requirements for each architecture domain, as well as the relationships and dependencies among them4.

References: 1: Architecture Principles 2: Architecture Contracts 3: Request for Architecture Work 4: Architecture Requirements Specification

A content metamodel is a formal structure that defines the types of entities and relationships that are used to capture, store, filter, query, and represent architectural information in a way that supports consistency, completeness, and traceability12.

A stakeholder map is a tool that identifies and analyzes the key stakeholders and their interests, influence, and expectations in relation to the architecture3. It is not used to structure architectural information, but rather to understand the stakeholder needs and concerns.

An architecture framework is a set of principles, guidelines, standards, and tools that provide a common structure and methodology for developing architectures4. It is not used to structure architectural information, but rather to guide the architecture development process and ensure alignment with the business strategy and objectives.

An EA library is a repository that stores and manages the architecture artifacts, deliverables, and other relevant information produced and consumed during the architecture development and governance. It is not used to structure architectural information, but rather to provide access, security, and version control for the architecture content.

References: 1: The TOGAF Standard, Version 9.2 - Content Metamodel 2: TOGAF 9.2 Content Metamodel Framework - A Quick Guide - KnowledgeHut 3: The TOGAF Standard, Version 9.2 - Stakeholder Management 4: The TOGAF Standard, Version 9.2 - Architecture Framework : The TOGAF Standard, Version 9.2 - Architecture Repository

Based on the illustration, the phase of the ADM labeled as item 2 is the Implementation Governance phase. This phase provides architectural oversight for the implementation. It ensures that the implementation project conforms to the architecture. It also provides a framework for monitoring and managing the implementation.

The Implementation Governance phase involves the following activities:

Finalizing the Architecture Roadmap and the supporting Implementation and Migration Plan

Assigning an Architecture Board to oversee the implementation

Establishing Architecture Contracts with the implementation partners

Reviewing and approving the implementation project plans and deliverables

Performing Architecture Compliance reviews to ensure alignment with the architecture

Performing Architecture Audit reviews to ensure quality and performance of the architecture

Resolving any architecture issues or change requests that arise during the implementation

Maintaining the architecture lifecycle and ensuring its continuity

The Implementation Governance phase is essential for ensuring that the architecture is realized as intended and that it delivers the expected business value and outcomes.

References: : Implementation Governance

In TOGAF, creating a Business Scenario is a foundational step in defining and understanding the business problem, especially for complex transformations involving multiple stakeholders and systems, such as in this scenario. This method aligns with Phase A (Architecture Vision) of the TOGAF Architecture Development Method (ADM). Here’s why this approach is the most effective:

Understanding Business Requirements:A Business Scenario provides a structured way to capture and analyze the business requirements, stakeholder concerns, and the contextual elements related to the problem. In this scenario, the company faces challenges in integrating newly acquired companies with existing operations, which includes complex stakeholder concerns across different functional areas. Developing a Business Scenario allows the EA team to break down these complexities into identifiable and manageable parts.

Risk Evaluation and Management:By using the Business Scenario approach, the EA team can not only define the requirements but also assess associated risks systematically. TOGAF emphasizes the importance of risk management through identifying potential risks, evaluating their impact, and defining strategies for handling these risks. The process includes assessing how risks can be avoided, transferred, or reduced—a necessary step in large-scale transformations to ensure that risks are proactively managed.

Residual Risks and Governance:Any risks that cannot be fully resolved should be identified as residual risks and escalated to the Architecture Board, which is aligned with TOGAF’s governance approach. The Architecture Board’s role in TOGAF is to provide oversight and make critical decisions on risks that exceed the control of the EA team. This ensures that unresolved risks are managed at the appropriate level of the organization.

Alignment with TOGAF ADM Phases:The Business Scenario approach directly aligns with the Preliminary and Architecture Vision phases of the TOGAF ADM, which focuses on establishing a baseline understanding of the business context and the strategic transformation required. The detailed understanding of requirements, stakeholder concerns, and risks identified here will guide the subsequent phases of the ADM, including Business Architecture and Information Systems Architecture.

TOGAF Reference (Section 2.6, ADM Techniques):TOGAF provides guidelines on the creation of Business Scenarios as part of ADM Techniques, highlighting the importance of defining a business problem comprehensively to ensure successful transformation. This method includes identification of stakeholders, business requirements, and associated risks, which aligns well with the company's need for strategic and systematic integration of new business units.

By utilizing a Business Scenario, the EA team ensures that all aspects of the transformation are well understood, risks are identified early, and residual risks are managed effectively, aligning with the company's strategic objectives and the TOGAF framework’s guidance on risk management and stakeholder alignment.

In this scenario, the enterprise is undergoing significant transformation due to a merger and the adoption of new technology (hand-held devices). Several key principles from TOGAF's ADM Techniques—particularly those focused on promoting enterprise-wide standardization, adaptability, and data utilization—are pertinent here:

Maximize Benefit to the Enterprise:This principle emphasizes that all architectural decisions should deliver maximum business value. Given that the company is integrating systems to cut costs and improve offerings, maximizing the benefit is crucial. Ensuring that the EA efforts align with enterprise-wide benefits supports the goal of optimizing costs and enhancing offerings, which aligns with the CEO’s vision for the merger.

Common Use Applications:Standardizing applications across the merged entity will be essential to achieve cost savings and to simplify operations. The goal of reducing the number of applications fits with this principle, ensuring that reusable and widely adopted applications support business functions across the organization. Adopting this principle will also aid in harmonizing the systems from both organizations and avoiding unnecessary diversity.

Data is an Asset:Data plays a central role in the company's operations, especially with the use of AI-driven inventory management and the integration of systems. Treating data as an asset is essential for reliable and accurate decision-making. This principle ensures that data is viewed as a critical enterprise resource and is managed with care, maintaining integrity, accuracy, and value.

Responsive Change Management:The organization’s ability to adapt quickly and effectively to changes, such as integrating new handheld devices and merging systems, is essential. This principle will facilitate the smooth transition required for integrating the new handheld devices and the merger-related system updates while minimizing disruption to store operations.

Technology Independence:Since the enterprise will likely encounter varied technologies from the merger, it is crucial to maintain flexibility. This principle advocates for using technology solutions that are adaptable and not bound to a single vendor or specific technology. This ensures that the enterprise can integrate various technological components from both organizations and evolve with minimal constraints.

These principles align well with TOGAF's broader recommendations for guiding architectural changes, as found in Section 2.6 of the TOGAF ADM Techniques. They ensure that the EA practice is aligned with business objectives while maintaining flexibility, data integrity, and a focus on enterprise-wide benefits. These guiding principles are critical for the successful execution of the integration and adoption of new technologies while achieving cost efficiencies and improving service delivery.

For reference, TOGAF's ADM Techniques highlight the importance of architectural principles in guiding transformational initiatives, ensuring that decisions are made consistently across the enterprise. Each principle supports organizational agility, system integration, and the efficient use of technology resources, all of which are vital for the enterprise's stated objectives.

In the TOGAF framework, understanding and addressing stakeholder concerns is crucial, particularly for complex projects with high stakes like the AI-first initiative described in the scenario. This approach aligns well with TOGAF’s ADM (Architecture Development Method) and its emphasis on effective stakeholder management and risk assessment. Here’s why this is the best course of action:

Stakeholder Analysis and Documentation:Conducting a stakeholder analysis is foundational in the early stages of any TOGAF project, particularly during the Preliminary and Architecture Vision phases. This process involves identifying the different stakeholders, understanding their positions, documenting their concerns, and considering any cultural factors that might influence their perspective on the AI-first initiative. Given the diverse concerns raised (such as job security, skill requirements, and cybersecurity), it’s essential to have a clear understanding of each stakeholder group’s priorities and fears.

Recording Concerns in the Architecture Vision Document:The Architecture Vision phase in TOGAF focuses on defining the high-level scope and objectives of the architecture project. By documenting stakeholder concerns and the corresponding views in the Architecture Vision document, the EA team ensures that these concerns are transparently acknowledged and addressed as part of the strategic direction. This step not only aligns with TOGAF best practices but also helps in building stakeholder buy-in and trust.

Architecture Requirements Specification and Risk Management:Risk management is a key aspect of TOGAF’s ADM, particularly in the Requirements Management and Implementation Governance phases. Documenting the requirements for addressing specific risks in the Architecture Requirements Specification provides a structured way to ensure that identified risks are acknowledged and managed throughout the transformation. Regular assessments and feedback loops ensure ongoing alignment and adaptability to emerging risks, which is particularly important given the dynamic nature of AI and its associated challenges.

Alignment with TOGAF ADM Phases:This approach follows the prescribed flow of TOGAF’s ADM, starting with stakeholder engagement in the Preliminary and Architecture Vision phases and progressing to risk assessment in the Requirements Management phase. By maintaining a focus on stakeholder needs and formalizing these into architecture requirements, the EA team can ensure that the architecture not only meets business objectives but also mitigates stakeholder concerns.

TOGAF Reference on Stakeholder Management Techniques:TOGAF places significant emphasis on managing stakeholder concerns through its stakeholder management techniques, which highlight the need to systematically identify, analyze, and address the concerns of all involved parties. This practice helps ensure that the architecture is viable and accepted across the organization.

By conducting a thorough stakeholder analysis and integrating the findings into both the Architecture Vision and the Architecture Requirements Specification, the EA team can proactively address stakeholder concerns, manage risks, and align the AI-first initiative with the agency’s strategic objectives. This approach is consistent with TOGAF’s guidance and provides a structured framework for addressing both business and technical challenges in the context of an AI-first transformation.

Based on the TOGAF standard, this answer is the best approach for architecture development to realize the CEO’s change in direction for the company. The reason is as follows:

The scenario describes a major business transformation that requires a clear understanding of the current and future states of the enterprise, as well as the gaps and opportunities for change. Therefore, the priority is to understand and bring structure to the definition of the change, rather than focusing on the implementation details or the technology aspects.

The team should use the TOGAF ADM as the method and guiding framework for architecture development, and adapt it to suit the specific needs and context of the enterprise. The team should also leverage the existing Architecture Capability and the Architecture Repository to reuse and integrate relevant architecture assets and resources.

The team should focus iteration cycles on a baseline first approach to architecture development, which means starting with the definition of the Baseline Architecture in each domain (Business, Data, Application, and Technology), and then defining the Target Architecture in each domain. This will help to identify the current and desired states of the enterprise, and to perform a gap analysis to determine what needs to change in order to achieve the business goals and objectives.

The team should then focus on transition planning, which involves identifying and prioritizing the work packages, projects, and activities that will deliver the change. The team should also create an Architecture Roadmap and an Implementation and Migration Plan that will guide the execution and governance of the change.

The team should use the Architecture Vision phase and the Requirements Management phase to work out in detail what the shared vision is for the change, and to capture and validate the stakeholder requirements and expectations. The team should also use the Architecture Governance framework to ensure the quality, consistency, and compliance of the architecture work.

References: : The TOGAF Standard, Version 9.2 - Architecture Development Method : The TOGAF Standard, Version 9.2 - Architecture Vision : The TOGAF Standard, Version 9.2 - Requirements Management : [The TOGAF Standard, Version 9.2 - Architecture Governance]

The Target Architecture is a description of the future state of the architecture that addresses the business goals and drivers, and satisfies the stakeholder requirements and concerns. The Target Architecture is developed through the Architecture Development Method (ADM), which is the core process of the TOGAF standard that guides the development and management of the enterprise architecture. The Target Architecture is typically divided into four domains: Business, Data, Application, and Technology. The Target Architecture also includes a roadmap for change, which defines the Transition Architectures, the Capability Increments, and the work packages that enable the transition from the Baseline Architecture to the Target Architecture12

The best answer is B, because it describes the approach that should be taken to determine and organize the work to deliver the requested architectures, which are the Information Systems and Technology Architectures. The answer covers the following steps:

Refer to the end-to-end Target Architecture for guidance and direction. The end-to-end Target Architecture provides the overall vision, scope, and objectives of the architecture work, and the alignment with the business strategy and goals. The end-to-end Target Architecture also provides the high-level definitions and principles for the four architecture domains, and the roadmap for change that outlines the major milestones and deliverables.

Identify projects, dependencies and synergies, then prioritize before initiating the projects. Projects are the units of work that implement the architecture work packages, which are the sets of actions or tasks that are required to implement a specific part of the architecture. Dependencies are the relationships and constraints that affect the order or priority of the projects, such as logical, temporal, or resource dependencies. Synergies are the benefits or advantages that result from the combination or coordination of the projects, such as cost savings, efficiency gains, or innovation opportunities. Prioritization is the process of ranking the projects according to their importance, urgency, or value, and assigning resources and schedules accordingly.

Develop high-level architecture descriptions. High-level architecture descriptions are the outputs of the architecture development phases (B, C, and D) of the ADM cycle, which describe the Business, Data, Application, and Technology Architectures in terms of the Architecture Building Blocks (ABBs) and the Solution Building Blocks (SBBs), which are reusable components of business, IT, or architectural capability. High-level architecture descriptions also include the Architecture Views, which are representations of the system of interest from the perspective of one or more stakeholders and their concerns.

For each project, estimate effort size, identify reference architectures, and candidate building blocks. Effort size is the measure of the amount of work, time, or resources required to complete a project. Effort size can be estimated using various techniques, such as analogy, expert judgment, parametric, or bottom-up. Reference architectures are standardized architectures that provide a common framework and vocabulary for a specific domain or industry. Reference architectures can be used as a source of best practices, patterns, and models for the architecture development. Candidate building blocks are the potential ABBs or SBBs that can be used to implement the architecture. Candidate building blocks can be identified from the Architecture Repository, which is a collection of architecture assets, such as models, patterns, principles, standards, and guidelines.

Identify the resource needs considering cost and value. Resource needs are the specifications and criteria that define the acceptable level and quality of the resources required to complete the project, such as human, financial, physical, or technological resources. Resource needs can be identified by analyzing the scope, complexity, and dependencies of the project, and the availability, capability, and suitability of the resources. Cost and value are the factors that influence the allocation and utilization of the resources, such as the budget, the return on investment, the benefits, or the risks.

Document options, risks, and controls to enable viability analysis and trade-off with the stakeholders. Options are the alternative ways of achieving the project objectives, such as different solutions, technologies, vendors, or approaches. Risks are the effects of uncertainty on the project objectives, such as threats or opportunities. Controls are the measures or actions that are taken to prevent, reduce, or mitigate the risks, such as policies, procedures, or standards. Viability analysis is the process of evaluating and comparing the options, risks, and controls, and determining the feasibility, suitability, and desirability of each option. Trade-off is the decision outcome that balances and reconciles the multiple, often conflicting, requirements and concerns of the stakeholders, and ensures alignment with the Architecture Vision and the Architecture Principles.

References: 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 5: Introduction to the ADM 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 19: Phase B: Business Architecture : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 20: Phase C: Information Systems Architectures : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30: Trade-Off Analysis : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 46: Tools for Architecture Development : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 47: Architecture Board : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 48: Architecture Compliance : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 49: Architecture Contract : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 51: Architecture Maturity Models : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 52: Architecture Skills Framework

A Consolidated Gaps, Solutions and Dependencies Matrix is a technique that can be used to create work packages for an incremental rollout of the architecture. A work package is a set of actions or tasks that are required to implement a specific part of the architecture. A work package can be associated with one or more Architecture Building Blocks (ABBs) or Solution Building Blocks (SBBs), which are reusable components of business, IT, or architectural capability. A work package can also be associated with one or more Capability Increments, which are defined, discrete portions of the overall capability that deliver business value. A Capability Increment can be realized by one or more Transition Architectures, which are intermediate states of the architecture that enable the transition from the Baseline Architecture to the Target Architecture123

The steps for creating work packages using this technique are:

For each gap between the Baseline Architecture and the Target Architecture, identify a proposed solution and classify it as new development, purchased solution, or based on an existing product. A gap is a difference or deficiency in the current state of the architecture that needs to be addressed by the future state of the architecture. A solution is a way of resolving a gap by implementing one or more ABBs or SBBs.

Group similar solutions together to define the work packages. Similar solutions are those that have common characteristics, such as functionality, technology, vendor, or location.

Identify dependencies between work packages, such as logical, temporal, or resource dependencies. Dependencies indicate the order or priority of the work packages, and the constraints or risks that may affect their implementation.

Regroup the work packages into a set of Capability Increments to transition to the Target Architecture. Capability Increments should be defined based on the business value, effort, and risk associated with each work package, and the schedule and objectives of the clinical trials. Capability Increments should also be aligned with the Architecture Vision and the Architecture Principles.

Document the work packages and the Capability Increments in an Architecture Definition Increments Table, which shows the mapping between the work packages, the ABBs, the SBBs, and the Capability Increments. The table also shows the dependencies, assumptions, and issues related to each work package and Capability Increment.

Therefore, the best answer is B, because it describes the approach to identify the work packages for an incremental rollout meeting the requirements, using the Consolidated Gaps, Solutions and Dependencies Matrix as a planning tool.

References: 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30: Gap Analysis 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 31: Architecture Change Management : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 23: Phase E: Opportunities and Solutions : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles