Free OGEA-101 practice test: 30 questions with answers

The Architecture Development Method is the repeatable process TOGAF provides for developing architectures, so it meets the need for one shared method. Solution Building Blocks are implementation components, the Architecture Continuum classifies reusable assets, and a stakeholder map is an engagement technique rather than a process for building architecture.

TOGAF defines an enterprise as any collection of organizations sharing a common set of goals, which can be a company, a government, or a partnership. The other options narrow the term to a legal entity, a government department or a software platform, none of which matches the TOGAF definition.

TOGAF is an open, vendor-neutral framework and method for enterprise architecture, and enterprise architecture is used to align business goals with the supporting IT. The other two statements are wrong because TOGAF does not mandate a vendor product and enterprise architecture informs strategy rather than replacing it.

TOGAF treats enterprise architecture as spanning business, data, application and technology architectures, which are developed together because they depend on each other. The other options wrongly delay business review, restrict scope to IT, or drop data entirely.

TOGAF is designed to be adapted to an organization's own governance and needs, so the agency tailors roles and processes while keeping the core method. Adopting it unchanged, rejecting it, or using only the glossary all ignore that design.

In TOGAF, a deliverable is a formal, contractually agreed output of an architecture project that is reviewed and signed off. The first option describes an artifact, the second a building block, and the third a stakeholder, so none of them is the deliverable.

The Architecture Content Framework describes architecture work products as artifacts, and artifacts are grouped as catalogs, matrices and diagrams. Principles and roadmaps, baseline and target states, and views with concerns are other kinds of content rather than these three categories.

A baseline architecture is the as-is description of the architecture at a given point in time, and it is compared with the target architecture during gap analysis. The desired future state is the target architecture, the intermediate state is a transition architecture, and a template is a pattern or template rather than a baseline.

A concern is a key interest of stakeholders, and a building block is a potentially reusable component of business, IT or architectural capability. The other two options swap the definitions of view and viewpoint, a common source of confusion.

The Standards Information Base holds the standards, policies and rules that the enterprise must apply to its architecture work. The Reference Library holds reference models and patterns, the Governance Log records decisions, and the Architecture Landscape shows the assets in use or planned.

The Preliminary Phase prepares the organization by establishing the architecture capability, including frameworks, principles and governance arrangements. Phase A starts a specific architecture project, Phase G governs implementation, and Phase H handles change, so none of those prepares the capability.

Phase A validates the business context, defines the scope and produces the Architecture Vision, which the sponsor approves before detailed work starts. Phase B develops the business architecture, while Phases E and F come later and deal with delivery options and migration sequencing.

Phase F is where the implementation and migration plan is finalized, with projects prioritized using cost-benefit and risk assessment. Phase E identifies implementation options before this, Phase G governs the implementation once it starts, and Phase H manages later architecture changes.

The ADM is meant to be tailored to the scope, timeframe and needs of each engagement, and steps can be adjusted or omitted when there is a justification. Requiring every step in full ignores that flexibility, and scope can be revisited in later iterations rather than being fixed for good.

Gap analysis is a TOGAF technique that compares the baseline architecture with the target architecture to identify gaps. The other techniques support requirements capture, reusable solutions and stakeholder engagement rather than comparing architecture states.

Architecture patterns describe reusable solutions to recurring problems, which fits a team that solves the same integration problem repeatedly. The other techniques deal with migration sequencing, investment planning and risk, and none of them provides a reusable solution description.

Business scenarios are a TOGAF technique that describe the actors, roles, goals and processes involved, which helps validate and derive requirements. Interoperability requirements, readiness assessments and principles address other needs and do not describe how actors achieve their goals.

TOGAF records each principle with a name, statement, rationale and implications, and principles should be understandable and stable with a rationale tied to business benefit. Naming a vendor product is wrong because principles set general rules, and principles can be revised through governance rather than being frozen.

Iteration means revisiting earlier parts of the ADM when new requirements or conditions arise, so looping back to Phase B is an iteration. Partitioning divides the architecture work, Phase H covers changes after deployment, and a compliance review is a governance activity, so none of the other options describes revisiting an earlier phase.

Architecture partitioning divides the architecture into smaller segments with clear boundaries so that teams can work in parallel. Iteration repeats parts of the cycle rather than splitting the work, consolidation runs against partitioning, and stopping after Phase A is not a way of dividing work.

The ADM can be applied to digital enterprise work by tailoring its scope and cadence while still considering business, data, application and technology architectures. The other options wrongly say the ADM is only for back-office systems, that digital work needs only infrastructure, or that governance can be dropped.

Running the ADM in short iterations, with just enough architecture for each sprint, fits agile delivery and keeps architecture aligned with the team's pace. Completing all phases up front, dropping architecture entirely, or deferring governance to Phase H would either delay delivery or leave the work ungoverned.

The Architecture Board is the TOGAF governance body that oversees architecture, checks compliance and resolves issues across projects. The program office tracks budgets, the architecture team produces deliverables, and the repository stores assets, so none of them is the governance body.

An Architecture Contract is a joint agreement between sponsors and development partners on deliverables, quality and fitness for purpose. The Architecture Vision, the principles and the gap analysis are important architecture outputs or techniques, but none of them records the agreement between the parties.

A compliance review checks whether a solution conforms to the target architecture and the principles, and TOGAF governance relies on such reviews. Gap analysis compares states during planning rather than checking a delivered solution, while a business scenario workshop and a stakeholder map address requirements and engagement.

Architecture governance sets up a framework of roles, processes and controls, and decisions are recorded in a governance log for later reference. Treating governance as a single end-of-program review, or replacing the Architecture Board with a steering group, both contradict the ongoing governance role TOGAF describes.

The Architecture Vision is produced in Phase A and gives a high-level summary of the target architecture and its business value, which the sponsor approves. The roadmap, the definition document and the contract are all developed in later stages of the ADM.

The Architecture Definition Document holds the baseline and target architectures across the business, information systems and technology domains, and it is developed in Phases B to D. The vision is a Phase A summary, the change request arises in Phase H, and the contract is an implementation agreement.

Architecture Building Blocks specify required functionality and interfaces without naming implementations, while Solution Building Blocks realize them with specific products or vendors. The other options reverse the roles of the two blocks or claim they are identical, which is incorrect.

The Statement of Architecture Work defines the scope, approach and deliverables of an architecture project, and it is agreed with the sponsor. The other options describe detailed design, vendor selection and stakeholder exclusion, none of which is what this document defines.