TOGAF Foundation: What OGEA-101 Expects Enterprise Architects to Understand

Enterprise architecture becomes useful when organizations need to connect strategy, business capabilities, information, applications and technology without letting every project solve those concerns in isolation. The OGEA-101 examination tests the foundation of that discipline through The Open Group's TOGAF Enterprise Architecture framework. It is the English-language TOGAF Enterprise Architecture Part 1 examination and the route to the Foundation qualification. Unlike design assessments that reward a convincing project diagram, OGEA-101 asks candidates to recognize the purpose, terminology and relationships of the architecture method itself.

The Open Group lists the Part 1 examination as 40 multiple-choice questions, 60 minutes, closed book, with a 60% pass score. Its published syllabus groups items into Concepts, Introduction to the Architecture Development Method (ADM), ADM Techniques, Applying the ADM, Architecture Governance and Architecture Content. These are distinct areas but should be studied as one working approach: why an organization undertakes architecture, how an architecture cycle proceeds, how evidence is organized and how decisions remain accountable. The broader range of The Open Group certifications includes different exams and qualification routes, so the Foundation result should not be confused with passing the Practitioner portion.

Architecture exists to guide change, not to document the past

An architecture team adds value when decision-makers can see the consequences of choosing one direction over another. A business may be consolidating customer records after an acquisition, modernizing aging applications or creating a digital service used by multiple business units. Each change raises questions about capabilities, ownership, interoperability, data governance and long-term cost. Enterprise architecture provides structured ways to assess those concerns across projects rather than leaving each delivery team to invent an uncoordinated answer.

The starting point is to distinguish a business architecture concern from an application or technology concern. A customer onboarding capability describes what the organization needs to do; a particular application is one implementation of that capability. A data entity such as customer or contract has meaning independent of any one database. Infrastructure is necessary but is not the business outcome. These distinctions help architects identify duplicate applications, inconsistent definitions and dependencies that become invisible when conversations begin with product names alone.

TOGAF also distinguishes architecture from the governance and organizational arrangements required to use it. A technically elegant design may fail if nobody agrees on ownership, exceptions, funding or how compliance will be assessed. The framework is not a command to produce every possible document. It is a method for selecting enough evidence and decision structure to guide material change. When reviewing a practice question, ask which organizational problem the proposed activity solves before memorizing the name of the artifact.

Follow the ADM as a connected cycle

The ADM is central to the Foundation syllabus. Its Preliminary Phase addresses the context in which enterprise architecture will be practiced: scope, principles, stakeholders, governance and architecture capability. Phase A establishes an Architecture Vision that connects concerns and desired benefits to a credible initiative. Phases B, C and D develop Business, Information Systems and Technology Architectures, respectively. Phase C covers both Data and Application Architecture, and that pairing matters when a change affects the meaning of information as much as software functionality.

The cycle then turns toward delivery. Phase E explores opportunities and solutions, identifies possible work packages and starts shaping implementation options. Phase F develops Migration Planning, including an achievable sequence of change. Phase G provides Implementation Governance so delivery decisions remain aligned with approved architectural intent. Phase H covers Architecture Change Management, because organizations do not stop evolving when a target architecture is published. Requirements Management is depicted at the center of the ADM to indicate continuous evaluation of needs and changes across all phases.

Memorizing phase names is insufficient. Consider an organization that has approved a target integration architecture but discovers that a critical legacy component cannot be retired this year. The architect may need to revisit implementation sequencing and requirements without restarting every previous activity. The ADM is iterative: feedback from planning, delivery and newly discovered requirements can trigger reconsideration of earlier decisions. Foundation questions frequently become easier when you can explain why an activity belongs in a given phase rather than simply where a phase sits on a diagram.

Understand deliverables, artifacts and reusable building blocks

Architecture work produces several kinds of information, and TOGAF gives them different names. A deliverable is a formally specified work product that is reviewed or agreed with stakeholders. An artifact is a more granular representation of part of an architecture, often a catalog, matrix or diagram. A building block is a reusable element of business, application or technology capability. An Architecture Building Block expresses a required capability and architecture characteristics; a Solution Building Block represents a more concrete element used to realize a solution.

Why is the distinction useful? Suppose a team creates a data-flow diagram. The diagram is an artifact that may support a broader Architecture Definition Document deliverable. The logical event-integration capability shown in the diagram can be an architecture building block; an implementation based on a specific integration platform can be described at the solution level. Treating all four things as equivalent makes it harder to distinguish an approved requirement from a vendor choice or an illustration.

TOGAF's Architecture Content Framework offers structure for organizing such work products. The Enterprise Continuum and Architecture Repository provide ways to classify and reuse architectural assets. Reference models, standards, governance records and architecture landscapes should be used when appropriate to the organization. Studying the relationships among artifacts matters more than remembering a large list of labels in isolation. A correct answer is often the one that preserves traceability from goals and requirements to designs and implementation decisions.

Apply stakeholder thinking and architecture principles

Stakeholders do not all need the same view. A finance leader may care about investment exposure and measurable benefit; a privacy lead about permitted processing and retention; an operations manager about reliability and support boundaries. A successful architecture engagement identifies their concerns and selects viewpoints that make proposed decisions understandable. The same architecture can legitimately have different views without becoming internally inconsistent, provided those views represent the same underlying system and constraints.

Architecture principles are durable decision rules, not slogans. For example, a principle that organizational information should be managed as a shared asset has implications for ownership, data definitions, access control and migration. A candidate should be able to recognize how a principle is formulated and why a proposed exception requires attention. Principles matter most when options conflict: speed versus maintainability, central control versus local autonomy, interoperability versus specialized performance. Architecture governance makes the trade-offs visible and assigns a process for deciding them.

An Architecture Board or comparable governance body may help establish standards, review proposed designs and address departures from agreed architecture. Contractual or governance mechanisms can be used to hold implementation accountable. These terms do not imply that architects have unchecked authority to override business needs. They indicate that architectural decisions need a transparent decision route, defined responsibilities and evidence that benefits and risks were considered.

Relate ADM techniques to real decisions

ADM techniques support the phases rather than replacing the overall method. Business scenarios help expose drivers, stakeholders and measurable requirements. Gap analysis identifies differences between baseline and target arrangements. Migration planning makes dependencies visible and supports a coherent sequence of changes. Stakeholder management links technical work to the concerns of people who must approve, use, fund or operate the outcome.

Imagine a retailer combining its online and physical inventory systems. A baseline assessment may show duplicated stock definitions and incompatible interfaces. A target architecture may describe shared data ownership and a consistent fulfillment capability. A gap analysis identifies the data contracts, systems and operational skills that are missing. A migration roadmap then stages the change so the business can keep fulfilling orders. This progression illustrates why Phase E and Phase F cannot be reduced to writing a calendar: delivery sequencing must follow dependencies, business constraints and acceptable transition states.

When a question uses an unfamiliar scenario, decide what the organization is trying to achieve, which architecture information is missing and which technique would resolve the uncertainty. Do not confuse a technique with a phase. Gap analysis can inform different points in the ADM, while stakeholder concerns recur throughout the cycle.

Prepare for the closed-book Foundation examination

A disciplined OGEA-101 study sequence begins with the official TOGAF Foundation syllabus and standard terminology. Build a concise phase map that includes the purpose of each phase, representative outputs and the relationship to Requirements Management. Then test yourself with short scenarios: if a business has unclear stakeholders, what work should establish its Architecture Vision? If a target design is approved but delivery diverges, what governance concern arises? If requirements change after implementation begins, how can architecture respond without pretending the original baseline still applies?

Use the official learning outcomes to prioritize. The Open Group's published outline allocates substantial emphasis to the ADM introduction; this makes the relationships among phases more important than obscure detail from tangential reference material. Practice differentiating similar terms such as architecture versus solution building block, artifact versus deliverable, and baseline versus target architecture. Explain each distinction aloud in a way a delivery manager could understand. If you can only repeat a definition word-for-word, you may not yet understand when it applies.

Closed-book conditions reward fluency rather than a strategy of hunting in documentation. Use diagrams sparingly but deliberately: sketch the ADM from memory, annotate its iteration points and describe what an architecture repository contains. When you miss a question, record the conceptual confusion behind the error. A useful error log might say "I treated Phase G as migration planning" or "I confused requirements with implementation tasks." That is more actionable than recording which option letter was correct.

Foundation is also a stepping stone rather than the final word on architectural judgment. A candidate who needs a direct route to the Practitioner qualification can examine OGEA-103, which combines the Foundation knowledge test with scenario-based Practitioner assessment. The combined examination has a distinct format and preparation burden; do not assume that strong memorization alone covers both sections.

Use the framework responsibly after certification

An architect applying TOGAF in a real organization should tailor method, language and documentation to its size and decision risk. A small product change rarely needs the same governance overhead as a multinational technology consolidation. Nevertheless, both benefit from clear requirements, an honest baseline, stated principles, stakeholder alignment and explicit decisions about what will change. Certification knowledge is valuable when it improves those outcomes rather than becoming a reason to produce unneeded architecture diagrams.

Before scheduling, confirm the current OGEA-101 booking language, accommodations, approved training options and testing rules through The Open Group and its examination provider. The published details above are those verified for this editorial review, not a promise that prices or booking conditions never change. For preparation, keep returning to the central question: how does TOGAF turn a complex organizational change into an intelligible, governable series of architecture decisions?