OGEA-102: TOGAF Enterprise Architecture Part 2

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 ADM2: 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 Analysis2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks3: 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

The Business Transformation Readiness Assessment is a technique that can be used to evaluate the readiness of the organization to undergo change and to identify the actions needed to increase the likelihood of a successful business transformation. This technique can help to address the concerns of the key stakeholders about the risks and value of the proposed reorganization. The technique involves assessing the following aspects of the organization: vision, commitment, capacity, capability, culture, and communication. Based on the assessment, the risks associated with the transformations can be identified, classified, and mitigated for. The technique also helps to identify the dependencies between the set of changes, including gaps and work packages, and the improvement actions to be worked into the Implementation and Migration Plan.The technique also supports the determination of the business value, effort, and risk associated for each transformation, which can be used to prioritize and sequence the work packages and the Transition Architectures1References:1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 27: Business Transformation Readiness Assessment

The Business Value Assessment Technique is a technique that can be used to estimate and compare the business value of the projects and project increments 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.The business value is the measure of the benefits or advantages that the project or project increment delivers to the business, such as increased revenue, reduced costs, improved quality, or enhanced customer satisfaction1

The steps for applying the Business Value Assessment Technique are:

Identify the criteria and factors that are relevant to the business value assessment, such as costs, benefits, risks, and opportunities. The criteria and factors should be aligned with the business goals and drivers that motivate the architecture work, and the stakeholder requirements and concerns that influence the architecture work.

Assign weights and scores to the criteria and factors, using various methods, such as expert judgment, historical data, or analytical models. The weights and scores should reflect the importance and performance of the criteria and factors, and the trade-offs and preferences of the stakeholders.

Calculate the business value for each project or project increment, using various techniques, such as net present value, return on investment, or balanced scorecard. The business value should indicate the expected or actual outcomes and impacts of the project or project increment on the business.

Prioritize the implementation projects and project increments, based on the business value and other considerations, such as dependencies, resources, or risks. The prioritization should determine the order or sequence of the projects and project increments, and the allocation and utilization of the resources.

Therefore, the best answer is C, because it describes the next steps for the migration planning, which are the activities that support the transition from the Baseline Architecture to the Target Architecture. The answer covers the Business Value Assessment Technique, which is relevant to the scenario.

References:1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 28: Business Value Assessment Technique : 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 21: Phase F: Migration Planning : The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks

Business continuity is the ability of an organization to maintain essential functions during and after a disaster or disruption. Business continuity requirements are the specifications and criteria that define the acceptable level of performance and availability of the business processes and services in the event of a disaster or disruption. A gap analysis is a technique that compares the current state of the architecture with the desired state, and identifies the gaps or differences that need to be addressed. A change request is a formal proposal for an amendment to some product or system, such as the architecture.A Request for Architecture Work is a document that describes the scope, approach, and expected outcomes of an architecture project123

The best answer is A, because it describes the steps that would improve the resilience of the current architecture, which is the ability to withstand and recover from a ransomware attack or any other disruption. The steps are:

Determine the business continuity requirements, which specify the minimum acceptable level of performance and availability of the business processes and services in case of a ransomware attack. This would involve identifying the critical business functions, the recovery time objectives, the recovery point objectives, and the dependencies and resources needed for recovery.

Undertake a gap analysis of the current Enterprise Architecture, which compares the current state of the architecture with the desired state based on the business continuity requirements. This would involve assessing the strengths and weaknesses of the current architecture, the risks and opportunities for improvement, and the gaps or differences that need to be addressed.

Make recommendations for change requirements to address the situation and create a change request. This would involve proposing solutions and alternatives to close the gaps, enhance the resilience, and mitigate the risks of the current architecture. The change request would document the rationale, scope, impact, and benefits of the proposed changes, and seek approval from the relevant stakeholders.

Manage a meeting of the Architecture Board to assess and approve the change request. The Architecture Board is a governance body that oversees the architecture work and ensures compliance with the architecture principles, standards, and goals. The meeting would involve presenting the change request, discussing the pros and cons, resolving any issues or conflicts, and obtaining the approval or rejection of the change request.

Once approved, produce a new Request for Architecture Work to activate an ADM cycle to carry out a project to define the change. The Request for Architecture Work would describe the scope, approach, and expected outcomes of the architecture project that would implement the approved change request. The Request for Architecture Work would initiate a new cycle of the Architecture Development Method (ADM), which is the core process of the TOGAF standard that guides the development and management of the enterprise architecture.

References:1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 33: Business Scenarios2: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30: Gap Analysis3: 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 7: Request for Architecture Work : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 34: Business Transformation Readiness Assessment : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30: Gap Analysis : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 31: Architecture Change Management : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 7: Request for Architecture Work