TOGAF OGEA-101: Understanding Enterprise Architecture Foundations

OGEA-101 is the TOGAF Enterprise Architecture Part 1 examination associated with the TOGAF Enterprise Architecture Foundation qualification. The Open Group describes a 40-question, 60-minute exam with a passing threshold of 60 percent, covering concepts, the Architecture Development Method (ADM), techniques, application, governance, and architecture content. The credential is based on a body of knowledge drawn from the TOGAF Standard, 10th Edition, but The Open Group deliberately names its credentials by competency rather than calling this simply “TOGAF 10 Foundation.”

Foundation knowledge is most valuable when a learner understands why enterprise architecture exists. Large organizations make interdependent decisions about capabilities, processes, information, applications, technology, suppliers, and change. Without a consistent architectural method, teams may optimize individual projects while creating incompatible or expensive systems across the wider enterprise. TOGAF supplies concepts and practices for bringing these decisions into a coherent, governed view. It is not a promise that following every phase mechanically will make transformation succeed.

Understand what enterprise architecture contributes

An enterprise architecture connects business outcomes with the organization and technology needed to deliver them. It may describe the current environment, the desired future environment, and the transformations required to move between them. This work goes beyond drawing infrastructure diagrams: it incorporates stakeholders, capability needs, information flows, application relationships, standards, constraints, and governance decisions.

Architectural descriptions should answer questions that matter to decision-makers. If a bank is considering consolidating customer information across product lines, a useful model identifies relevant business capabilities, authoritative data sources, ownership, integration dependencies, privacy constraints, and how those decisions affect services. A drawing that simply shows every application in a box does not establish a defensible migration path.

The TOGAF approach also separates architecture from implementation detail. A target architecture defines important constraints and relationships; a project design decides how to realize a particular solution within those boundaries. Confusing the two can lead either to vague architecture that guides nobody or to an overly prescriptive central team that obstructs practical delivery.

Learn the ADM as an adaptable cycle

The Architecture Development Method organizes work through phases such as preparation, architecture vision, business architecture, information systems architecture, technology architecture, opportunities and solutions, migration planning, implementation governance, and architecture change management. Requirements Management operates across these phases. A candidate needs to understand the purpose of each phase and the relationships between them, rather than memorizing their names as a disconnected sequence.

The Preliminary Phase establishes readiness, scope, governance, capability, and architecture principles. Phase A frames vision and stakeholder agreement. Phases B, C, and D develop relevant business, information systems, and technology perspectives. Phases E and F connect architecture choices to work packages, transition architectures, and a migration roadmap. Phase G addresses implementation governance, while Phase H considers controlled changes in an evolving environment.

Actual architecture engagements do not always proceed through all phases exactly once. The ADM is iterative and should be adapted to scope, maturity, governance needs, and project context. A small change to one business capability may require a narrower cycle than a multi-year transformation. Foundation candidates should explain how tailoring preserves necessary decision quality while avoiding unnecessary documents or meetings.

Distinguish stakeholder concerns and architecture viewpoints

Different stakeholders care about different aspects of the enterprise. Finance may focus on cost and investment risk; operations may care about availability and supportability; regulators may require traceability and control evidence; business leaders may prioritize customer outcomes and speed of change. A single architecture view rarely communicates all of these concerns effectively.

Viewpoints define conventions for constructing views that answer a particular set of concerns. A capability map may help business leadership understand organizational investment. An application cooperation view may clarify system dependencies to a technology team. A transition roadmap may be most useful to program sponsors. The architecture description should make clear whose concern each view addresses and what decisions the representation supports.

Stakeholder analysis therefore is not an optional communications exercise. If the architect fails to identify affected teams or relevant approval bodies, later implementation may encounter unexpected objections. A good architecture engagement records stakeholder concerns early and revisits them when tradeoffs change.

Understand building blocks and architecture content

TOGAF uses concepts such as architecture building blocks and solution building blocks to distinguish required capabilities and architectural structure from specific implementation components. An architecture building block might express a need for identity federation or secure customer-data access; a solution building block may describe a particular service or configured product that fulfills it. This distinction helps avoid selecting a technology too early, before the requirement and constraints have been understood.

Architecture content may include catalogs, matrices, and diagrams. Each representation has a purpose. Catalogs help enumerate elements and attributes; matrices expose relationships or coverage; diagrams communicate structures, dependencies, and flows. The choice should reflect the question rather than a desire to fill every possible template. The value lies in creating reusable, traceable decisions that remain understandable during subsequent change.

The repository concept supports reuse across engagements. Architecture principles, building blocks, standards, reference models, and prior decisions can improve consistency when they are discoverable and maintained. Reuse should not mean blindly copying a solution into a different regulatory, business, or technical context.

Connect architecture governance with change delivery

Governance defines who may make decisions, which principles apply, how exceptions are handled, and how implementation is checked against agreed architectural constraints. An architecture board may play a part, but good governance does not require every minor design decision to wait for a large committee. The decision rights and escalation paths should match the scale and consequence of the change.

Implementation governance is important because an approved design can drift as projects encounter real constraints. An architecture contract or comparable agreement may establish expectations between the architecture function and delivery groups. Conformance reviews should seek evidence that important requirements are being satisfied, with a clear method for evaluating deviations. A change that departs from a standard for legitimate reasons needs a documented decision, not a hidden workaround.

Architectural change management keeps the target state useful after initial approval. New regulations, acquisitions, service demands, and technology changes can invalidate assumptions. The architecture practice needs a way to detect these triggers, determine whether a minor update or a larger ADM cycle is required, and keep the relevant repository information current.

Recognize how principles, requirements, and standards interact

Architecture principles express enduring rules or guidance for making enterprise-wide decisions. Requirements describe needs and constraints for a particular scope; standards may prescribe approved methods or technologies. These concepts can overlap in practice, but they should not be treated as interchangeable. A principle favoring reuse of shared services does not mean every project must use one fixed implementation regardless of security, performance, or regulatory constraints.

When requirements conflict, architecture governance should support a recorded decision. For example, a program may need rapid delivery while an existing standard imposes an integration approach that creates unacceptable latency. The architect should identify the stakeholder concerns, compare feasible alternatives, and seek an appropriate decision or exception rather than quietly bypassing the standard. This is a practical illustration of why the ADM includes requirements management and governance across its work.

Principles should also be testable enough to guide action. A phrase such as “technology should be modern” provides little basis for comparing architectures. A principle supporting interoperability, transparent ownership, or auditable data access can inform concrete criteria. Foundation study improves when learners connect each governance concept to a situation in which it would change a real decision.

A foundational learner should also know how an architecture engagement maintains its decision history. Architecture principles can guide decisions, but they do not remove competing constraints. Suppose an organization values common platforms and local operational independence. Adopting one shared service might reduce duplication but create a dependency for a business unit with strict availability requirements. The architect's work is to document the principle involved, the exception criteria, the stakeholder concerns, and the conditions under which the decision will be reconsidered.

Traceability connects those decisions across the architecture effort. A regulatory requirement may affect a business process, an information-handling rule, an application integration, and the hosting technology. Maintaining the relationship allows reviewers to see whether a late change has undermined an earlier agreement. Foundation-level understanding does not require solving every implementation problem, but it does require recognizing why business, data, application, and technology viewpoints cannot be evaluated as isolated diagrams.

The enterprise continuum and repository concepts are useful when organizations reuse standards, models, and reference architectures. Reuse should accelerate consistent decisions, not silently impose a pattern on a context where it does not fit. An architecture team should identify which elements are enterprise standards, which are adaptations, and which are project-specific. Treat reusable artifacts as governed knowledge that requires ownership and version control. This is a stronger demonstration of TOGAF vocabulary than memorizing a list of repository categories without explaining what they contain or how people use them.

Relate Foundation to Practitioner decisions

Foundation questions test understanding of the terms, purpose, and interactions within the body of knowledge. Practitioner work goes further: it asks which architecture approach best addresses a scenario involving stakeholders, constraints, gaps, and transitions. A candidate interested in that progression can compare the OGEA-103 combined exam, which includes both Foundation and Practitioner-level examination sections. The paths are related but their exam formats and expected reasoning differ.

For Foundation study, create a map linking business needs, stakeholder concerns, ADM phases, artifacts, governance mechanisms, and change outcomes. Use one realistic transformation example throughout the map. For instance, migrating an organization to a shared customer platform requires vision, business capability analysis, data architecture, application and technology choices, migration plans, and governance. This exercise tests whether the terms form a coherent method rather than just a vocabulary list.

The Open Group certifications assess different levels of architecture knowledge, so candidates should distinguish foundational terminology from scenario-based judgment when selecting an exam. Always check the official body of knowledge, language availability, and exam rules before booking. The durable value of OGEA-101 is learning to describe architecture work in terms of stakeholder concerns, traceable decisions, coherent views, and governed transformation.