Free OGBA-101 Practice Test

A business capability defines what a business does to achieve a specific purpose or outcome. It represents a particular ability or capacity that the business possesses. This concept is a cornerstone of business architecture, abstracting away from the organizational structure, processes, or technology used to execute it. For example, "Customer Relationship Management" is a capability, representing the ability to manage customer interactions, regardless of which department or software system is involved. This focus on "ability" and "outcome" is the core of its definition.

A. This describes a business process or value stream, which details how activities are performed, not the underlying ability the business possesses.
B. This is the definition of a business goal or objective, which are high-level statements of intent, not the abilities needed to achieve them.
C. This describes a solution architecture or a specific design approach, which is a plan for implementation, not a fundamental business ability.

1. The Open Group Standard, TOGAF® Standard, Version 9.2 (April 2018). Part I, Chapter 3, Definitions, Section 3.21 defines a Capability as: "An ability that an organization, person, or system possesses."

2. The Open Group Guide, G189, "Business Capabilities" (October 2018). Section 2.1, "What is a Business Capability?", states: "A business capability is a particular ability that a business may possess or exchange to achieve a specific purpose or outcome."

3. The Open Group, "Open Business Architecture (O-BA) Standard," also known as the OGBA Standard (November 2022). Part I, Section 3.1.10 defines Business Capability as: "The ability of a business to do something to achieve a particular outcome."

A TOGAF Business Scenario is a technique used to articulate a business problem, the environment in which it exists, and the desired business outcomes. By creating a detailed and shared understanding of the business requirements and the context of the problem, it serves as a crucial communication vehicle. This clarity is invaluable for external parties, such as vendors, as it enables them to fully grasp the business needs. Consequently, vendors are better positioned to propose and deliver solutions that are appropriate and aligned with the organization's objectives, minimizing misunderstandings and rework.

A. This statement is too general. While business scenarios contribute to planning, their specific, defined benefit is in articulating and understanding business requirements for architecture work.
C. The organizing framework for change activity in a TOGAF project is the Architecture Development Method (ADM) itself, not the business scenario technique which primarily defines the problem.
D. This describes Architecture Principles, which are defined in the TOGAF standard as general, enduring rules and guidelines that support enterprise-level planning and decision-making.

1. The TOGAF® Standard, 10th Edition, Part III: ADM Techniques, Chapter 23, "Business Scenarios". Section 23.4, "Benefits of Business Scenarios", states: "The business scenario is a complete description of the business problem, both in business and in architectural terms, which enables individual requirements to be viewed in relation to one another in the context of the overall problem." This complete description is what aids vendors in understanding the full scope and delivering appropriate solutions.

2. The TOGAF® Standard, 10th Edition, Part III: ADM Techniques, Chapter 23, "Business Scenarios". Section 23.1, "Introduction", highlights that the technique is used to "identify and understand business needs and thereby to derive the business requirements that the architecture development has to address." This direct link to requirements is fundamental for vendor engagement.

3. The TOGAF® Standard, 10th Edition, Part III: ADM Techniques, Chapter 19, "Architecture Principles". Section 19.1, "Introduction", defines principles as "general rules and guidelines...that inform and support the way in which an organization sets about fulfilling its mission," which directly corresponds to the incorrect option D.

The diagram illustrates a value stream, which is defined as an end-to-end sequence of activities that collectively deliver value to a stakeholder. The value stream, "Acquire Retail Product," is broken down into its constituent parts. Each box ("Market Product," "Process Order," etc.) represents a distinct value stream stage. These stages are sequential, value-adding activities that progressively contribute to the final outcome. Therefore, the diagram shows a decomposition of the overall value stream into a sequence of value-creating stages, which is the fundamental structure of a value stream map in business architecture.

A. The service "Acquire Retail Product" consists of five events "Acquire Retail Product" is a value stream, not a service. The boxes represent stages (activities), not events, which are typically triggers or state changes.
B. The value stream consists of five business capabilities. This confuses value stream stages with business capabilities. Capabilities are what an organization can do, which enable the stages, but they are not the stages themselves.
C. A series of five subprocesses that makeup the value stream While stages can be detailed as processes, "value stream stage" is the precise business architecture term. "Subprocess" is a more granular, generic term and less accurate here.

1. The Open Group, TOGAF® Series Guide: Value Streams (G178), January 2017.

Section 2.1, "What is a Value Stream?": Defines a value stream as "a representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user."

Section 2.2, "Value Stream Stages": States, "A value stream is decomposed into value stream stages... Each value stream stage represents a distinct activity in the value stream." This directly supports the correct answer (D). The guide also provides a similar "Acquire Automobile" example.

2. The Open Group, The Open Group Guide: Business Architecture Body of Knowledge (O-BA BOK™), Version 1.0 (B190), April 2019.

Section 3.2, "Value Streams": "A value stream is depicted as a series of value stream stages... Each value stream stage creates and adds incremental value from one stage to the next." This confirms the diagram shows a decomposition into value-creating stages.

Section 3.3, "Capabilities": Distinguishes capabilities from value streams, clarifying that capabilities are the abilities needed to execute value stream stages, which refutes option B.

Business Capability Mapping is the formal process of identifying, defining, and structuring what a business does, independent of how it does it. The output of this process is a capability map, which is a hierarchical structure. This hierarchical nature, often organized into levels (e.g., Level 1, 2, 3), is precisely what allows the model to communicate different amounts of detail. Executives might review Level 1 capabilities for strategic planning, while solution architects might drill down to Level 3 for project scoping. Therefore, mapping is the process that creates this versatile structure for various stakeholder groups.

A. Layering: This is a technique used within the mapping process to create the hierarchical structure, but it is not the name of the entire process itself.
B. Stratification: This term, while meaning to arrange in layers, is not the standard terminology used for this process within The Open Group's business architecture framework.
C. Categorization: This is the act of grouping related capabilities. While part of the overall process, it does not inherently create the hierarchical levels required for showing different amounts of detail.

1. The Open Group. (2019). The Open Group Guide: Business Capabilities (Document No. G189). Section 3.1, "The Business Capability Mapping Process", explicitly names and describes the end-to-end process. Section 2.3, "What is a Business Capability Map?", clarifies that the map is "typically represented as a hierarchy" to provide different views for different stakeholders.

2. The Open Group. (2022). TOGAF® Standard, 10th Edition. The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability. Chapter 10, "Using the TOGAF Framework with Business-Oriented Architecture Styles", discusses Business Capability Mapping as the key technique for creating a structured, hierarchical view of the business for strategic communication.

Architecture Governance is the practice of managing and controlling the Enterprise Architecture process. A primary function of governing the Architecture Development Method (ADM) is to ensure that the process is being executed consistently and correctly across the enterprise. This involves implementing a system of controls, compliance assessments, and quality reviews to verify that the ADM is followed, standards are adhered to, and the resulting architecture aligns with business objectives. This oversight ensures the integrity and quality of the architecture work.

A. To enable a fast response to market changes. While a well-governed architecture practice can improve agility, the primary purpose of governance is ensuring correctness and compliance, not speed.
C. To enable development of reference architectures. Developing reference architectures is an activity that is subject to governance, but it is not the fundamental reason for governing the entire ADM process.
D. To permit the architecture domains to be integrated. Integrating domains is a key part of the ADM, but governance's role is broader, overseeing the entire method to ensure all aspects are applied correctly, not just integration. ---

1. The TOGAF® Standard, 10th Edition, Part VI: Architecture Governance Framework, Section 46.2, "Architecture Governance": This section states, "Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures are managed and controlled at an enterprise-wide level." It emphasizes implementing a "system of controls over the creation and monitoring of all architectural components and activities". This directly supports the concept of verifying correct application.

2. The TOGAF® Standard, 10th Edition, Part VI: Architecture Governance Framework, Section 46.2.3, "Architecture Governance Processes": The "Compliance" process is described here, which involves formal assessments to ensure projects comply with the architecture. This process is a mechanism for "verifying that the method is being applied correctly".

3. The TOGAF® Standard, 10th Edition, Part VI: Architecture Governance Framework, Section 46.2.4, "Architecture Governance and the ADM": This section clarifies the relationship, stating, "The ADM is the process by which architectures are created and managed. The Architecture Governance Framework provides the context within which the ADM is executed." This establishes that governance oversees the ADM's correct execution.

Gap Analysis is a fundamental technique within the TOGAF Architecture Development Method (ADM). Its purpose is to compare the Baseline Architecture (the current state) with the Target Architecture (the future state) to identify differences. These differences, or "gaps," represent elements that need to be created, modified, or retired. A key output of this analysis is a list of building blocks that have been "eliminated" from the Baseline Architecture in the Target Architecture. Therefore, identifying items omitted from the Target Architecture is a direct and primary function of this technique, which is essential for planning the transition.

A. To allocate resources for architecture projects. Resource allocation is a project management activity that occurs after gaps are identified and work packages are defined, not the purpose of the analysis itself.
C. To govern the architecture throughout its implementation process. This describes the function of Architecture Governance (ADM Phase G), which ensures the implementation conforms to the defined architecture.
D. To develop a set of general rules and guidelines for the architecture. This describes the creation of Architecture Principles, a foundational activity that occurs in the Preliminary Phase and Phase A of the ADM.

1. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing.

Section 23.1, "Purpose": "In the context of the TOGAF ADM, gap analysis is the technique of identifying gaps between the Baseline and Target Architectures."

Section 23.2, "Steps": This section details the process, including step 4: "Where an ABB from the Baseline Architecture is missing in the Target Architecture, mark it as 'Eliminated'." This directly supports that the technique identifies items omitted from the Target Architecture.

The TOGAF standard explicitly defines four architecture domains that form the foundation of enterprise architecture development. These are Business, Data, Application, and Technology. The Application Architecture domain provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the organization's core business processes. It is a critical link between the Business Architecture (what the business does) and the Technology Architecture (how it is implemented). The question asks to complete this standard list of four domains.

A. Capability: Capability is a key concept and artifact within the Business Architecture domain, describing an ability that an organization possesses, but it is not one of the four primary domains.
C. Transition: A Transition Architecture is a temporary state of the architecture used to describe the roadmap from the Baseline to the Target Architecture, not a distinct domain.
D. Segment: An Architecture Segment is a detailed, self-contained portion of the overall enterprise architecture (e.g., for a specific department), not one of the four fundamental domains.

1. The Open Group. (2022). The TOGAF® Standard, 10th Edition. Van Haren Publishing.

Part II: Architecture Development Method (ADM), Section 5.2, "Architecture Domains": This section explicitly states, "The TOGAF standard covers the development of four architecture domains: Business, Data, Application, Technology."

Part I: Introduction, Section 3.10, "Application Architecture": This section defines Application Architecture as "A description of the structure and interaction of the applications as groups of capabilities that provide business functions and manage the data assets."

2. Lankhorst, M. (Ed.). (2013). Enterprise Architecture at Work: Modelling, Communication and Analysis (3rd ed.). Springer.

Chapter 2, Section 2.3.1, "The TOGAF Framework": This academic text discusses the TOGAF ADM and its phases, consistently identifying the four core domains as Business, Application, Data, and Technology. (Note: While sometimes grouped as Information Systems Architecture, Application and Data are distinct domains).

3. Pennsylvania State University. (n.d.). EA 871: Enterprise Architecture Foundations I. Course materials for the Master of Professional Studies in Enterprise Architecture and Business Transformation.

Module on TOGAF: Courseware in this program details the TOGAF framework, consistently referencing the BDAT (Business, Data, Application, Technology) model as the four primary architecture domains.

According to the TOGAF® Standard, the term "Enterprise" is used in a general sense to refer to any collection of organizations that has a common set of goals. This definition is intentionally broad to accommodate various contexts. The standard explicitly states that an enterprise can be a whole corporation, a division, a government agency, or even an "extended enterprise" comprising partnerships, alliances, consortia, or supply chains. The three statements provided in the question are direct examples of how the TOGAF framework defines the scope of an enterprise for which an architecture can be developed.

A. Organizations: While the examples are types of organizations, "Enterprise" is the specific, broader term used by the TOGAF standard to encompass single entities as well as collections of collaborating organizations.
B. Architectures Scopes: This term refers to the defined boundaries of the architecture work (e.g., breadth, time period, domains), not the entity being architected. The examples are types of entities for which a scope is defined.
C. Business Units: This term is too narrow. A business unit is typically a subdivision of a larger corporation and does not cover the full range of examples, such as a whole corporation or a consortium.

1. The Open Group Standard, TOGAF® Standard, 10th Edition. (2022). Core Concepts, Section 2.5, "What is an Enterprise?". This section explicitly lists the examples from the question: "A whole corporation or a division of a corporation", "A government agency or a single government department", and "Partnerships and alliances of businesses working together, such as a consortium or supply chain".

2. The Open Group Standard, TOGAF® Standard, 10th Edition. (2022). Definitions, Section 3.38, "Enterprise". The definition states: "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."

According to The Open Group Business Architecture Body of Knowledge (O-GBOK), a value stream stage is defined by several key elements. Among these is 'Exit Criteria', which explicitly specifies the set of conditions that must be met for the stage to be considered complete. This element serves as the formal definition of the stage's end state, ensuring that all required value items have been produced and quality standards are met before transitioning to the next stage or concluding the value stream. The exit criteria provide a clear, measurable, and verifiable checkpoint for completion.

A. Target state: This term typically refers to the desired future state of an entire architecture or capability, not the specific completion condition of a single process stage.
B. Completion stage: This is not a standard term within The Open Group's business architecture framework for describing the end conditions of a value stream stage.
C. End point: This is a generic term for a termination point but lacks the specific meaning of a set of defined conditions or criteria that must be satisfied.

1. The Open Group, The Open Group Business Architecture Body of Knowledge (O-GBOK), Version 1.0, The Open Group Standard (C196), April 2019. Section 5.3, "Value Stream Stages," states: "A value stream stage has the following attributes... Exit Criteria: The set of conditions that must be met for the value stream stage to be considered complete." (Page 28).

2. The Open Group, TOGAF® Business Architecture: Value Streams Guide, The Open Group Guide (G189), October 2018. Section 3.3, "Value Stream Stage," lists the components of a value stream stage, including "Exit Criteria: The conditions that must be met for the value stream stage to be considered complete." (Page 7).

According to the TOGAF® Standard, the term "enterprise" refers to any collection of organizations that shares a common set of goals. This definition is intentionally broad to be universally applicable. It can describe a whole corporation, a specific division, a government department, or even an "extended enterprise" that includes partners, suppliers, and customers working together, such as in a consortium or supply chain. The examples provided in the question are classic illustrations used within the TOGAF framework to define the scope of what constitutes an enterprise.

A. Architectures Scopes: This term defines the breadth and depth of an architecture effort, not the entity itself being described.
B. Organizations: This term is too narrow as the TOGAF concept of an "enterprise" can span multiple, independent organizations.
C. Business Units: This is a component part of a larger organization and does not encompass the full range of examples given.

1. The Open Group Standard, TOGAF® Standard, 10th Edition, Core Concepts. Section 2.5, "Enterprise", states: "An 'enterprise' is any collection of organizations that has a common set of goals. For example, an enterprise could be a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership... The enterprise may also be an 'extended enterprise' including partners, suppliers, and customers."

2. The Open Group Standard, TOGAF® Standard, 10th Edition, Definitions. Section 3.38, "Enterprise", defines it as: "The highest level of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations."