OGEA-101 Questions and Answers

According to the TOGAF Standard, an architecture view is a representation of a system from the perspective of a related set of concerns1. An architecture viewpoint is a specification of the conventions for a particular kind of architecture view1. Presenting different architecture views and architecture viewpoints to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final target architecture. This is because different stakeholders may have different concerns and interests in the system, and by showing them how the system addresses their concerns from different perspectives, the architects can elicit more feedback and validation from them2. For example, a business stakeholder may be interested in the business architecture view, which focuses on the business processes, functions, and capabilities of the system3. A security stakeholder may be interested in the enterprise security view, which addresses the security aspects of the system, such as confidentiality, integrity, and availability3. By presenting these views to the respective stakeholders, the architects can ensure that the system meets their expectations and needs, and also identify any potential issues or gaps that may affect the target architecture. References: 1: The TOGAF Standard, Version 9.2 - Architectural Artifacts - The Open Group1; 2: Understanding TOGAF Views and Viewpoints in Enterprise Architecture2; 3: Developing Architecture Views - The Open Group4

Business scenarios are a technique for capturing, clarifying, and communicating the functional and non-functional requirements of a system. Business scenarios describe the business environment, the actors involved, the desired outcomes, and the processes or rules that govern the behavior of the system. Business scenarios are useful for ensuring that the architecture addresses the real needs and concerns of the stakeholders, and for validating and testing the architecture against expected situations. Business scenarios are developed in Phase A: Architecture Vision of the ADM cycle, and refined and updated throughout the other phases3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 26: Business Scenarios : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision

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).

This statement best describes iteration and the ADM. The ADM is iterative over the whole process between phases and within phases because it allows for feedback loops and refinements at any point in the architecture development and transition process. Iteration enables architects to address changing requirements, assumptions, constraints, and environments; to validate and improve architectures; to manage risks and issues; and to ensure stakeholder satisfaction and value realization. Reference: The TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.

The illustration shows an architecture development cycle based on the TOGAF ADM (Architecture Development Method), which is a method for developing and managing an enterprise architecture1.

The ADM consists of nine phases, each with a specific purpose and output. The phases are1:

Preliminary Phase: To prepare and initiate the architecture development cycle, including defining the architecture framework, principles, and governance.

Phase A: Architecture Vision: To define the scope, vision, and stakeholders of the architecture initiative, and to obtain approval to proceed.

Phase B: Business Architecture: To describe the baseline and target business architecture, and to identify the gaps between them.

Phase C: Information Systems Architectures: To describe the baseline and target data and application architectures, and to identify the gaps between them.

Phase D: Technology Architecture: To describe the baseline and target technology architecture, and to identify the gaps between them.

Phase E: Opportunities and Solutions: To identify and evaluate the opportunities and solutions for implementing the target architecture, and to define the work packages and transition architectures.

Phase F: Migration Planning: To finalize the implementation and migration plan, and to ensure alignment with the enterprise portfolio and project management.

Phase G: Implementation Governance: To provide architecture oversight and guidance for the implementation projects, and to manage any architecture change requests.

Phase H: Architecture Change Management: To monitor the changes in the business and technology environment, and to assess the impact and performance of the architecture.

In addition to these phases, there is a central process called Requirements Management, which is labeled as item 1 in the illustration. This process operates throughout the ADM cycle, and its purpose is to manage the architecture requirements throughout the architecture development, ensuring that they are aligned with the business requirements and the stakeholder concerns2.

Therefore, the description that matches the phase of the ADM labeled as item 1 is C. Operates the process of managing architecture requirements.

1: The TOGAF Standard, Version 9.2, Chapter 5: Architecture Development Method (ADM)

2: The TOGAF Standard, Version 9.2, Chapter 17: Requirements Management

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.

1E: To identify delivery vehicles (projects programs portfolios) that will deliver the Target Architecture 2F: To confirm readiness and ability to undergo change 3E: To determine whether an incremental approach is required and if so identify Transition Architectures that will deliver continuous business value 4G: To perform appropriate governance functions while the solution is being implemented

(Authoritative Open Group guidance distinguishes conceptual, logical, and physical concerns; at the logical level, component types are identified independently of implementation.) For example, the Open Group’s metamodel guidance emphasizes technology-agnostic structure to ensure consistency within an architecture description, which is precisely what the logical level captures before physical realization.

“The Content Metamodel defines a formal structure… to ensure consistency within the architecture description and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.” Open Group Publications

The Architecture Requirements Repository stores all the requirements that are output of the architecture development cycle, as well as the requirements that are input to the architecture development cycle1. The Architecture Requirements Repository includes the following types of requirements1:

•Stakeholder Requirements: These are the high-level requirements and expectations of the stakeholders, derived from the business drivers, goals, and objectives. They are captured and refined in the Architecture Vision phase and the Requirements Management phase.

•Architecture Requirements: These are the detailed requirements that specify what the architecture must do or deliver to meet the stakeholder requirements. They are derived and refined in the Business, Information Systems, and Technology Architecture phases.

•Implementation and Migration Requirements: These are the detailed requirements that specify what the implementation and migration projects must do or deliver to realize the architecture. They are derived and refined in the Opportunities and Solutions and Migration Planning phases.

The Architecture Requirements Repository is used to manage the architecture requirements throughout the architecture lifecycle, ensuring their traceability, consistency, and compliance1. The Architecture Board is the authority that reviews and approves the architecture requirements, as well as the architecture deliverables and artifacts, as part of the architecture governance process2.

“TOGAF defines **‘enterprise’ as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.” www.opengroup.org

A business scenario describes business and technology environment in which those problems occur. It provides a realistic context for identifying and addressing business problems and opportunities, as well as their impact on the enterprise’s architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.1 Business Scenarios.

business and technology environment in which those problems occur https://pubs.opengroup.org/togaf-standard/business-architecture/business-scenarios.html#_Toc68617078 "

A Business Scenario is a uniform description of: - Real business problems - The business and technology environment in which those problems occur - Value streams enabled by capabilities - The desired outcome(s) of proper execution - The human and computing components (the “actors”) who provide the capabilities"

 According to the TOGAF template for Architecture Principles, the Rationale section should describe the relationship to other principles, as well as the business benefits and the intentions of adhering to the principle. The Rationale section should use business terminology and point to the similarity of information and technology principles to the principles governing business operations. The Rationale section should also explain how the principle supports the achievement of the business objectives and key architecture drivers. References:

Architecture Principles Template

The TOGAF Standard, Version 9.2 - Architecture Principles

The Open Group Exam OGEA-103 Topic 1 Question 4 Discussion

The image shows a diagram that illustrates the basic concepts of architecture description as defined by the ISO/IEC/IEEE 42010:2011 standard1, which is also adopted by the TOGAF standard2.

According to the ISO/IEC/IEEE 42010:2011 standard, an architecture description is a work product used to express an architecture, and it consists of one or more architecture views1.

An architecture view is a representation of a system from the perspective of a related set of concerns, and it conforms to an architecture viewpoint1.

An architecture viewpoint is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns1.

Therefore, the correct answer is option A, which identifies the items labeled as “A” and “B” in the image as an architecture viewpoint and an architecture view, respectively. References:

1: ISO/IEC/IEEE 42010:2011 - Systems and software engineering — Architecture description1

2: TOGAF Standard, Version 9.2 - Part IV: Architecture Content Framework - 31. Architectural Artifacts2

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.

Phase E: Opportunities & Solutions – Steps/Outputs emphasize grouping work packages, dependencies, and planning the roadmap/plan that reflect value/effort:

“Identify and group major work packages… Refine and validate dependencies… Create the Architecture Roadmap & Implementation and Migration Plan.” www.opengroup.org

This aligns with the TOGAF Architecture Repository model where:

A (Architecture Requirements Repository) contains requirements that drive architecture work.

B (Solutions Repository) stores the building blocks or solutions that support the architecture.

C (Architecture Landscape) represents the architecture assets that depict the current, transition, and target architecture states across the enterprise

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.

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

Business scenarios are a technique recommended by the TOGAF ADM for use in developing an Architecture Vision document12. Business scenarios are a means of capturing the business requirements and drivers, the processes and actors involved, and the desired outcomes and measures of success34. Business scenarios help to create a common vision and understanding among the stakeholders, and to identify and validate the architecture requirements . Business scenarios also provide a basis for analyzing the impact and value of the proposed architecture. References:

•The TOGAF Standard, Version 9.2 - Phase A: Architecture Vision - The Open Group

•TOGAF® Standard — Introduction - Phase A: Architecture Vision

•The TOGAF Standard, Version 9.2 - Definitions - The Open Group

•Business Scenarios - The Open Group

•[The TOGAF Standard, Version 9.2 - Architecture Requirements Specification - The Open Group]

•[The TOGAF Standard, Version 9.2 - Architecture Vision - The Open Group]

•[The TOGAF Standard, Version 9.2 - Business Transformation Readiness Assessment - The Open Group]

Concerns are interests important to the stakeholders in a system. They are used to identify and classify the system’s stakeholders and to guide the selection of viewpoints for the architecture description. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.1 Architecture Viewpoints

Business Transformation Readiness Assessment is a joint effort between corporate staff lines of business and IT planners to evaluate the readiness of the organization to undergo change. It involves assessing factors such as vision, commitment, capacity, capability, culture, and motivation that may influence the success of a business transformation initiative. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.2 Business Transformation Readiness Assessment.

The TOGAF standard divides Enterprise Architecture into four primary architecture domains: business, data, application, and technology. These domains represent different aspects of an enterprise and how they relate to each other. The business domain defines the business strategy, governance, organization, and key business processes. The data domain describes the structure of the logical and physical data assets and data management resources. The application domain provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes. The technology domain describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. Other domains, such as motivation, security, or governance, may span across these four primary domains. References:

The TOGAF Standard, Version 9.2 - Core Concepts

Domains - The Open Group

TOGAF® Standard — Introduction - Definitions - The Open Group

The TOGAF Standard, Version 9.2 - Definitions - The Open Group

TOGAF and the history of enterprise architecture | Enable Architect

The chart shown is a Gantt chart, which is commonly used for project management to illustrate a project schedule. In the context of TOGAF (The Open Group Architecture Framework), which is a framework for enterprise architecture, this Gantt chart is demonstrating the sequenced approach to the Architecture Development Method (ADM). The ADM is the core process of TOGAF which provides a tested and repeatable process for developing architectures. The ADM is described as being iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken about each of the parameters (scope, granularity, time period, and architecture assets).

The ADM consists of a number of phases that have to be followed in sequence:

Preliminary Phase: Framework and principles

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures, including Data and Application Architectures

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

Each phase is dependent on the outputs of the previous phase and the Requirements Management phase runs throughout. The Gantt chart clearly shows the dependency and sequence in which these phases occur, implying that a structured approach is followed to produce the enterprise architecture.

The TOGAF Standard, Version 9.2, a standard of The Open Group

The TOGAF documentation available at https://publications.opengroup.org/standards/architecture and https://publications.opengroup.org/guides/architecture

According to the TOGAF Standard, 10th Edition, risk is present in all phases within the Architecture Development Method (ADM), and it should be identified, classified, and mitigated before starting a transformation effort 1. Risk is defined as “the effect of uncertainty on objectives” 2, and it can have positive or negative impacts on the architecture project. Risk management is a technique that helps to assess and address the potential risks that may affect the achievement of the architecture objectives, and to balance the trade-offs between opportunities and threats. Risk management is applied throughout the ADM cycle, from the Preliminary Phase to the Requirements Management Phase, and it is integrated with other techniques, such as stakeholder management, business transformation readiness assessment, gap analysis, and migration planning 1. The other options are not correct, as they are not present in all phases within the ADM, and they are not necessarily identified, classified, and mitigated before starting a transformation effort. Budgetary constraints are the limitations on the financial resources available for the architecture project, and they are usually considered in Phase E: Opportunities and Solutions, and Phase F: Migration Planning 3. Schedule constraints are the limitations on the time available for the architecture project, and they are also usually considered in Phase E and F 3. Information gaps are the missing or incomplete data or knowledge that may affect the architecture project, and they are usually identified in Phase B: Business Architecture, Phase C: Information Systems Architecture, and Phase D: Technology Architecture . References: 1: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 32: Risk Management. 2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 3: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 16: Phase E: Opportunities and Solutions, and Chapter 17: Phase F: Migration Planning. : TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 13: Phase B: Business Architecture, Chapter 14: Phase C: Information Systems Architecture, and Chapter 15: Phase D: Technology Architecture.

 In the ADM documents which are under development and have not undergone any formal review and approval process are called “draft”. This indicates that they are subject to change and refinement as the architecture development progresses. Reference: The TOGAF® Standard | The Open Group Website, Section 4.2.5 Architecture Deliverables.

The planning horizon, depth, and breadth of an Architecture Project, along with the contents of the EA Repository, are typically framed by Strategy, Portfolio, Segment, and End-to-end Target Architecture. The 'Segment' refers to a part of the organization, typically addressed in a Segment Architecture, while 'End-to-end Target Architecture' encompasses the complete view of the planned architecture across the entire organization.

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.