TOGAF OGEA-101: Understanding Architecture Before Applying It

OGEA-101 is the TOGAF Enterprise Architecture Part 1 examination, aligned with foundational understanding of the TOGAF Standard, 10th Edition. The Open Group describes it as a closed-book, multiple-choice assessment of core concepts, the Architecture Development Method, architecture techniques, governance and content. It is not the same examination as the scenario-based Part 2 component or OGEA-103, which combines Part 1 and Part 2. Its practical value comes from providing a disciplined vocabulary for conversations that often become confused: what architecture describes, who makes decisions, which concerns belong at enterprise level and how a repeatable method creates useful evidence. Candidates should understand the structure of the standard without treating it as a rigid one-size-fits-all project sequence.

Define enterprise architecture around change and alignment

Enterprise architecture helps an organization understand its business capabilities, information, applications and technology as a connected system. The aim is not to produce a thick collection of diagrams. Architecture is useful when decisions about investments, transformations and constraints become more consistent because stakeholders can see dependencies and trade-offs. A system that works locally may still be a poor enterprise choice if it duplicates capabilities, creates unmanaged interfaces or conflicts with policy.

Imagine a regional bank planning to introduce a new lending product. The project might need customer identity, risk decisions, document handling, servicing and reporting. Without an enterprise perspective, each team could select separate vendors and build incompatible integrations. Architecture work clarifies shared capabilities, existing assets, constraints and desired future state. It does not replace delivery teams; it provides a common structure for making their decisions coherent.

Distinguish enterprise architecture from solution design. A solution architect decides how a specific capability can be implemented; enterprise architecture examines how that choice fits wider strategy and the portfolio. The two inform each other. Candidates should be comfortable explaining why architecture governance and stakeholder involvement belong early in change initiatives, not only after a new platform has already been purchased.

Use the ADM as an adaptable development method

The Architecture Development Method, or ADM, provides an iterative approach to creating, using and maintaining architecture. It encompasses preliminary work, vision, business architecture, information systems architecture, technology architecture, opportunities and solutions, migration planning, implementation governance, and change management, with requirements management throughout. Memorizing phase names is a starting point; understanding the purpose and outputs of each phase is more important.

Suppose a logistics firm has already identified a need to consolidate regional customer platforms. The architecture vision should explain the business outcomes and key stakeholders, while later phases examine capabilities, application and data dependencies, technology choices and transition steps. If early technical analysis reveals a serious regulatory conflict, architecture work may need to revisit the vision or requirements. The ADM supports iteration rather than a false promise of linear certainty.

Learn which questions each phase is intended to answer and which stakeholders need to be involved. Implementation governance is not the same as implementation coding, and architecture change management is not simply project status reporting. Candidates should be able to recognize when an architecture activity should be revisited and explain what new evidence triggered that decision.

Recognize stakeholder concerns and viewpoints

Stakeholders care about different consequences of a transformation. A finance director may need cost and investment visibility; security officers may focus on data movement and regulatory obligations; application teams may need interface contracts and delivery constraints. Architecture viewpoints present information that addresses these specific concerns. The same underlying architecture can be represented in several useful views without implying that each audience needs an entirely separate architecture.

Consider replacing a manual claims process with an integrated digital service. Operations managers need to understand changes to workflow and staffing, while integration engineers need to understand system interactions and data exchange. A single detailed infrastructure diagram is insufficient for both. The architect should choose or create viewpoints that support decisions and trace them back to an agreed set of concerns.

Be wary of diagrams that look precise but omit the questions that led to them. A service map without ownership or capability implications may offer little management value. Equally, a high-level capability diagram cannot substitute for an interface design when technical delivery begins. Understanding the relationship among concerns, stakeholders, views and viewpoints is a foundation for meaningful architecture communication.

Distinguish building blocks, artifacts and deliverables

TOGAF's content concepts help organize the information created during architecture work. Artifacts are specific architectural descriptions, such as a diagram, matrix or catalog. Deliverables are formal work products that can be reviewed or agreed. Building blocks describe reusable components of capabilities or solutions at differing levels of abstraction. These terms are related but should not be treated as synonyms.

An architecture building block might represent a logical identity-management capability, while solution building blocks identify actual components chosen to implement it. This separation allows architects to compare alternatives without prematurely turning conceptual requirements into commitments to a specific vendor. It also helps explain how existing systems can be assessed for reuse.

A data-flow diagram may be an artifact used within an architectural deliverable. Its usefulness depends on whether it expresses a necessary decision or constraint, not on whether the format is fashionable. Study why architecture repositories, catalogs and standards exist: they support consistency, traceability and reuse across multiple projects. The test-relevant understanding is of these relationships and purposes, rather than attempting to memorize every possible diagram an architect could draw.

Understand governance as decision rights and evidence

Architecture governance establishes how architectural decisions are evaluated, recorded and monitored. The goal is to align changes with strategy, standards, compliance and legitimate exceptions. Governance does not mean that every exception is forbidden or that an architecture board should approve routine technical details. It means that decision rights, criteria and consequences are explicit.

A business unit may need a short-term external service to meet a market deadline, despite an enterprise preference for an existing platform. An architecture review should assess the business benefit, security implications, integration consequences and eventual transition plan. A justified exception can be more responsible than rigidly enforcing a standard that would undermine the stated business objective. The exception should have an owner and defined conditions.

Candidates should recognize the role of contracts, compliance assessments and architecture oversight during implementation. The architecture's intended outcomes matter only if someone can detect when real delivery has diverged. Governance is most effective when it provides timely guidance and an audit trail, rather than creating a committee that examines projects only after expensive choices have been made.

Apply architecture techniques to gaps and trade-offs

Gap analysis compares baseline and target architectures to identify what must be added, removed, changed or retained. It supports migration planning by showing the consequences of moving toward the desired state. However, an architecture gap is not automatically a project task; teams still need to assess business priority, technical dependency and feasible transition steps.

Suppose the target architecture calls for a common customer identity platform, while three regions operate independent directories. Gap analysis identifies missing integration and governance capabilities, but does not decide that all users should be migrated in one weekend. Migration sequencing depends on risk, application compatibility, data quality and change windows. The ADM provides a disciplined setting for evaluating these constraints.

Other architecture techniques help stakeholders prioritize requirements, manage alternative solutions and revisit decisions when new information arrives. In OGEA-101, know the concepts well enough to identify their purpose in a situation, but avoid claiming the Part 1 exam requires the same scenario ranking as OGEA-103's practitioner component. The foundation is understanding how to reason systematically about enterprise change before detailed judgment is assessed.

Use architecture repositories without confusing them with strategy

Architecture repositories preserve standards, reference models, descriptions, governance records and lessons from earlier work. A repository can reduce repeated discovery and help teams compare new proposals with existing enterprise capabilities. But storing diagrams is not the same as maintaining a usable architecture practice. Material must be current, appropriately accessible and tied to decisions that stakeholders actually make.

For a company with many cloud projects, a reference architecture can provide starting assumptions about identity, networking and monitoring. Individual workloads may require exceptions, and the repository should reveal which assumptions were accepted, changed or rejected. Without this feedback, 'standard' diagrams can persist long after the operating environment has changed. Maintenance of the architecture knowledge base belongs in the governance model.

Ask who owns each important artifact, when it is reviewed and which decisions it supports. A catalog of applications might help assess technology sprawl; a capability map might reveal redundant investment. Present architecture information at the level needed for the decision. The examination tests a coherent mental model of these elements rather than a belief that more documentation is always evidence of better architecture.

Prepare for Part 1 with conceptual explanations and examples

The Open Group's OGEA-101 syllabus places substantial emphasis on introduction to the ADM alongside core architecture concepts, techniques, governance and content. The published Part 1 format is forty questions in sixty minutes, with a passing threshold specified by the issuer. Study the current official syllabus and exam policies before scheduling because exam administration can evolve independently of the technical material.

A productive revision method is to explain each major term using a single business scenario. If a retailer wants to rationalize applications, identify its stakeholders, architecture vision, baseline and target descriptions, gaps, governance decisions and potential migration dependencies. Explain why an artifact is useful, which ADM activity it supports and what would cause the team to revisit it. This is a stronger test of comprehension than reciting the phase list in isolation.

When ready to apply the same knowledge to graded scenarios, consider the OGEA-103 combined examination or the separate Part 2 pathway, depending on eligibility and learning goals. The Part 1 credential provides vocabulary and structure; practitioner-level competence adds choices under competing constraints. The lasting value of the foundation is the ability to make architecture conversations clearer, more disciplined and more focused on business outcomes.