Free OGBA-101 practice test: 30 questions with answers

The TOGAF Standard is an open, vendor-neutral framework and method that organizations can tailor. Option A describes a tool rather than the standard, option C describes a legal obligation the standard does not impose, and option D invents a platform requirement that does not exist.

TOGAF treats a deliverable as a contractually specified work product that is formally reviewed and signed off, and an artifact as a working architecture product such as a catalog, matrix, or diagram. Option A swaps the two terms, option B treats them as the same thing, and option C ties each one to a single phase, which the standard does not do.

An architecture building block specifies the required functionality without naming a product, while a solution building block identifies the specific product or vendor that implements it. Option B reverses the two types, and options A and D each erase the difference between them.

The Enterprise Continuum classifies and organizes architecture and solution assets, moving from generic foundation assets to organization-specific ones. The fixed sequence of phases describes the ADM rather than the continuum, and the other two options describe financial and governance content that the continuum does not contain.

TOGAF defines a concern as an interest in the system held by a stakeholder, and both requests come from stakeholders, so they are concerns. Principles, building blocks, and capabilities are different architecture terms that describe rules, components, and abilities.

A view is a representation of a system from the perspective of a set of concerns, and a viewpoint is the specification of the conventions used to build that view. Option C reverses the two terms, while options A and D confuse views with catalogs and matrices, which are different kinds of artifact.

A catalog lists the elements of one type, and a matrix shows the relationships between two or more types. Option A confuses a matrix with a diagram, option C wrongly makes catalogs and matrices deliverables by definition, and option E describes a diagram rather than a catalog.

A stakeholder is an individual, team, or organization with interests in, or concerns relative to, the system. A viewpoint is a set of drawing conventions, a building block is a reusable component, and an architect is a practitioner role, so none of those describes the parties with interests.

Business Architecture (Phase B) describes business strategy, organization, functions, and processes, so it comes before the information systems and technology work. Phases C and D come after it, and Phase E turns the architectures into implementation options, so none of them is the right home for this work.

Requirements Management is at the centre of the ADM diagram because requirements are managed continuously across all phases. The Preliminary Phase is a starting point before Phase A, while governance and the repository are supporting resources, so none of them is the central element.

Phase F, Migration Planning, is where the implementation and migration plan is finalized, including cost-benefit and risk assessment. Phase E only identifies the options, Phase G governs delivery once it has started, and Phase H manages change after the architecture is in use.

TOGAF describes the ADM as iterative and to be tailored to each organization, so phases can be revisited. The other options describe a rigid one-pass process, a restriction the standard does not impose, or a limit to IT projects that does not exist.

A business model view shows how the enterprise creates, delivers, and captures value, which is the question the company is asking at this stage. The other three diagrams describe software interaction, data design, or physical infrastructure, which belong to later architecture work rather than to business modelling.

The business footprint diagram connects business goals, organization units, functions, and services, and shows the technology that delivers them. The other options describe a data inventory, a message sequence, and a portfolio ranking, none of which is the purpose of a business footprint diagram.

Business architecture links business model changes to the capabilities and processes they affect, then analyzes the gaps between baseline and target. The other approaches reverse that logic, derive the business from the systems, or drop business modelling altogether.

A business model describes how an enterprise creates, delivers, and captures value, while a business process is an ordered set of activities that produces a defined result. The other options swap the two concepts or treat them as systems, job roles, or the same artifact.

A business capability is an ability the business possesses, or can obtain from others, to achieve a purpose. The other options describe a process, an organizational unit, and an application, which are different concepts that architects model separately.

Capabilities describe what the organization can do, which tends to stay stable when processes, structures, or systems change, so they are best written as outcomes. The other options tie capabilities to structure, process, or software, which change far more often and would make the map unstable.

A capability heat map colours each capability by a chosen attribute, such as performance or investment priority, which makes weak but important areas visible at a glance. The RACI matrix, data catalog, and network diagram each answer a different question and do not show capability performance.

Capability models are usually hierarchical, and capabilities are more stable than the processes that deliver them. Linking capabilities to applications, equating them with value stream stages, and restricting maps to IT all work against the business-led purpose of capability modelling.

A value stream is the end-to-end set of activities that delivers a valuable result to a customer, stakeholder, or end user. The other options describe an application, a budget line, and an approval sequence, none of which is a flow of value-creating activity.

Value stream mapping shows the stages of an end-to-end flow and links each stage to the capabilities that support it. The budget comparison, data matrix, and governance log serve different purposes and do not show the patient journey across capabilities.

A value stream is judged end to end, from the point of view of the customer or stakeholder who receives the value. The other three options restrict the view to software, to one department, or to cost, which leaves out the value delivered to the customer.

In value stream mapping, each stage is a step of the end-to-end flow, and it is supported by the capabilities that enable it. The other readings treat the stage as an application, a budget item, or an approval, which are not what a value stream stage represents.

Organization decomposition produces an organization map showing the organization units, actors, and locations and how they relate to business functions. The other options describe a database schema, network routes, and a project plan, none of which show the enterprise's organizational structure.

Information mapping relates information entities to the business functions or processes that use them, which exposes ownership gaps. The other techniques show process timing, management structure, and physical infrastructure, so none of them shows which information each function uses.

Information maps and organization maps both relate architecture elements to business functions, which reveals who uses or owns what. The other options describe a physical network diagram, a vendor licence list, and a sequencing rule that TOGAF does not impose.

A business scenario is a technique for discovering and documenting a business problem, its goals, the actors involved, and the requirements, so the architecture addresses real needs. The other options describe vendor selection, asset accounting, and repository design, none of which is the purpose of business scenarios.

Business scenarios produce business requirements, and the architecture requirements derived from them, traced to the problem, drivers, and goals. The schema, contract, and hardware specification are later outputs of design, procurement, or technology work, not of the workshop itself.

Business footprint diagrams and gap analysis are core business architecture work in the ADM. Storage sizing, application source code, and protocol selection belong to technology, information systems, or implementation work.