UNDERSTAND / OGEA-101
Your study notes
Free theory, no account needed · TOGAF Foundation
Why use enterprise architecture?
Connect organizational change, investment, and systems to the enterprise’s shared objectives.
Enterprise, purpose, and benefits of EA
Define the ‘enterprise’ that architecture work targets, understand what an Enterprise Architecture is for, recognize the five families of benefits TOGAF associates with it, and know which situations trigger such work.
Understanding EA Foundation certification
Place OGEA-101 within the TOGAF certification path and prepare for an examination of fundamental knowledge.
Certification and the OGEA-101 exam in practice
What the EA Foundation certification validates, how the exam is built, and how to prepare effectively.
The four architecture domains
Distinguish Business, Data, Application, and Technology Architecture while understanding their relationships.
Domains and abstraction levels: a grid
Combine the four architecture domains and the four abstraction levels to know what you are talking about (the domain) and at what level of detail (the level), linking each level to a fundamental question.
Glossary: domains and types of architecture
The definitions of the four domains (Business, Data, Application, Technology) look alike and are easily confused in the exam. This sheet rephrases each of them, adds the two senses of the word 'architecture', Solution Architecture, and Digital Architecture, then gives simple criteria for placing an element in the right domain.
Moving from context to realization
Use contextual, conceptual, logical, and physical levels to choose an appropriate amount of detail.
Framework, method, and modeling language
Understand the contributions of TOGAF, a classification such as Zachman, and a language such as ArchiMate.
Why TOGAF suits Enterprise Architecture
Identify the arguments that make TOGAF a suitable EA framework: what an architecture framework should offer, a standard approach that lowers risk, three concrete contributions, and a strong ability to be tailored and integrated with other practices.
System, architecture, and description
Distinguish the reality being studied, its architectural characteristics, and the information used to express them.
Stakeholders, concerns, and roles
Identify who is affected, what matters to them, and the responsibilities they perform.
Glossary: actors, stakeholders, and statements of intent
Who acts, who is concerned, and how do you express what is expected? This sheet rephrases the definitions of Actor, Role, Stakeholder, and Concern, then those of three often-confused statements: Requirement, Architecture Principle, and Objective. It adds simple criteria for classifying a statement.
Views, viewpoints, and models
Choose representations suited to a concern and distinguish representation rules from the result produced.
Classifying and reusing with the Enterprise Continuum
Position architectures and solutions between general references and organization-specific needs.
The Enterprise Continuum in depth
Go deeper into the Enterprise Continuum as a classification and communication tool: what it classifies, its two continua linked by guidance and support, its levels from generic to specific, and how it works with the Architecture Repository.
Business and architecture capabilities
Distinguish what the enterprise can do from what enables it to sustain an architecture practice.
Operating the architecture capability
Understand what an Enterprise Architecture capability is, how to establish it as a full operational unit, which services it provides to the enterprise, and why governance sits at the heart of how it works.
Architecture services, Service Portfolio, and Foundation Architecture
How the architecture capability delivers its services, and two often-overlooked definitions: Service Portfolio and Foundation Architecture.
TOGAF 10 documentation: standard, guides, and Library
Understand how the 10th Edition is organized — six Fundamental Content documents, Series Guides that make the concepts operational, and a reference TOGAF Library — and why this modular split makes gradual adoption easier.
The eight components of the Architecture Repository
Know where each type of architecture asset belongs: why a structured repository becomes essential, what its eight components are, how to tell neighboring components apart, and how it fits into the Enterprise Repository.
Glossary: architecture states and the vocabulary of change
Baseline, Target, Transition, Gap, Work Package, Roadmap: these terms all describe moving from one state to another, but each answers a different question. This sheet rephrases them from the chapter 4 definitions of the standard and shows how to chain them without mixing them up.
Glossary: Landscape, levels, and partitions
The exam often tests the difference between Strategic, Segment, and Capability Architecture, and between a level and a partition. This sheet starts from the exact definitions of the standard, rephrased, to separate what divides the Landscape by granularity from what divides it to share out its management.
Glossary: capabilities, value, and business services
Capability, Business Capability, Business Model, Value Stream, Business Function, Business Service, Product: these business terms appear in Business Architecture and in many exam scenarios. This sheet gives their rephrased definition and the question to ask to recognize each one.
Glossary: frameworks, methods, governance, and interoperability
Framework, Method, Architecture Framework, ADM, Governance: these words structure all TOGAF discussion, yet their precise definitions are rarely memorized. This sheet rephrases them and adds the terms related to services and information exchange: Interoperability, Service Orientation, SOA, and Boundaryless Information Flow.
Using the TOGAF Standard and the role of The Open Group
The conditions for using and downloading the standard, The Open Group’s mission, and what the Architecture Forum offers.
The ADM: developing and evolving architecture
Understand phase objectives and the iterative nature of a method guided by requirements.
The ADM cycle: ten elements and their purpose
An overview of the Architecture Development Method: what it covers, the purpose of each of its ten elements, and the right way to read its graphic, which is a reference model rather than a waterfall of steps.
Draft, approved, and iteration: governing evolution
An architecture never stops evolving. This card explains how the ADM qualifies deliverable status, at which levels it iterates, and why creating and maintaining the architecture must be governed.
Preliminary Phase: preparing the practice
Establish an architecture capability suited to the organization before undertaking a particular piece of work.
Preliminary Phase: determine, then establish the capability
The Preliminary Phase does not produce a target architecture: it builds the capability that will produce them. Objectives, key activities, main inputs, steps, and outputs to know.
From business context to a request for work
Understand why an architecture initiative starts and what a Request for Architecture Work provides.
Phase A: Architecture Vision and scope
Establish understandable direction and obtain authorization for clearly scoped architecture work.
Phase A: objectives, inputs, steps, and deliverables
All architecture development starts with Phase A. It scopes the work, rallies stakeholders around a vision, and ends with approval of a Statement of Architecture Work. Here is what it consumes, what it does, and what it produces.
Phases B, C, and D: developing the domains
Move from a vision to Baseline and Target Architectures using a common approach tailored to each domain.
Phase B: developing the Business Architecture
Phase B turns the vision into a description of how the enterprise must operate. Objectives, inputs, steps shared by the domain phases, and deliverables to know.
Phase C: Data and Application Architecture
Phase C, Information Systems Architectures, develops two complementary architectures that enable the Business Architecture: data and applications. Objectives, order of work, content, and deliverables.
Phase D: developing the Technology Architecture
Phase D describes the technology means that will deliver the business, data, and application building blocks defined upstream. Objectives, inputs, content, deliverables, and the hand-over to Phase E.
Phase E: solutions, roadmap, and transitions
Combine architectural changes into coherent work and define useful steps towards the target.
Phase E in depth: from gaps to work packages
Phase E, Opportunities & Solutions, is the hinge between defining the architecture and implementing it. It starts from the gaps found in the domain phases, groups them into assessed work packages, and produces the first complete Architecture Roadmap. This lesson covers its purpose, objectives, inputs, steps, and outputs.
Phase F: planning migration
Turn the roadmap into a realistic plan coordinated with portfolios, programs, and projects.
Phase F in depth: from initial plan to approved projects
Phase F, Migration Planning, turns the initial roadmap from Phase E into a detailed migration plan, coordinated with the enterprise’s change portfolio. It ends with approved projects that have resources and dates, and closes the architecture development cycle before moving on to implementation governance.
Phase G: contracts and compliance
Govern implementation so solutions meet architecture commitments while deviations are addressed.
Phase G in depth: governing implementation
Phase G, Implementation Governance, accompanies the delivery of the projects defined in Phase F. Architecture does not build the solution here: it frames, checks conformance, and rules on deviations. This lesson details the phase’s purpose, objectives, inputs, steps, and outputs.
Phase H and Requirements Management
Keep architecture relevant and manage requirements throughout every phase of the cycle.
Phase H in depth: managing architecture change
Phase H, Architecture Change Management, monitors the architecture once deployed, measures the value actually obtained, and decides how to respond to change: a simple adjustment or a new ADM cycle. This lesson details its purpose, objectives, steps, change classification, and outputs.
Requirements Management: the process at the heart of the ADM
Requirements Management is not one phase among others: it is a continuous process, placed at the center of the cycle, that identifies, stores, and tracks architecture requirements and makes them available to every phase. This lesson clarifies its purpose, objectives, what it does and does not do, its steps, and its outputs.
Scoping an architecture and comparing alternatives
Before modeling, the limits of the work must be set: why restrict them, along which dimensions, and how to keep several teams from treading on each other. Then, once the target is sketched, why compare several of them.
Information flow and deliverables across the ADM
The circular ADM graphic does not describe a sequence of activities but how information moves between phases. Following deliverables from one phase to the next, who creates them, who enriches them, who finalizes them, is the best way to understand this flow and answer exam questions about the phases.
Defining useful architecture principles
State enduring rules connecting architecture choices to enterprise values and objectives.
Architecture Principles: what are they for and where do they come from?
Before writing a principle, you need to know what it will be used for and at which level it sits. This lesson details the four purposes of Architecture Principles, the people who produce and approve them, and their place in the hierarchy that starts with Enterprise Principles.
Writing and reviewing a principle: template, pitfalls, and criteria
This lesson is a writer’s checklist. It revisits the four-part template from a ‘what to include, what to leave out’ angle, lists the wording pitfalls TOGAF warns about, then shows how to diagnose a set of principles with the five quality criteria.
Engaging stakeholders and communicating
Tailor exchanges to each group to build shared understanding and support decisions.
Stakeholder management: identify, classify, engage
Stakeholder management is a technique in the ADM Techniques that helps win the support the architecture needs. It is not a Foundation syllabus outcome, but it sheds light on many Phase A questions. This lesson presents its benefits, its four steps, the stakeholder categories, and the power/interest grid.
Business Scenarios and SMART objectives
Describe a complete business problem to discover requirements and clarify intended outcomes.
Running a business scenario step by step
A business scenario turns a business problem into usable architecture requirements. This lesson walks through the method step by step, clarifies what a scenario does and does not describe, details SMART objectives, and places the technique within the ADM.
Capability Assessment and readiness for change
Assess capabilities and the human or organizational conditions needed for transformation.
Business Transformation Readiness Assessment: how to use it
An architecture can be right on paper and still fail because people are not ready. The Business Transformation Readiness Assessment evaluates and quantifies the organization’s ability to change. This lesson explains when to run it, with whom, through which activities, and how its results feed risks and the migration plan.
Identifying, reducing, and monitoring risk
Connect uncertainty to objectives and distinguish initial risk, mitigation, and residual risk.
Risk management: from initial to residual
Understand risk as the effect of uncertainty on objectives, tell risk assessment from risk management, follow the process TOGAF describes, and place initial risk, residual risk, and acceptance by governance.
Gap Analysis and trade-offs
Identify meaningful differences between states and compare alternatives against actual stakeholder concerns.
Gap Analysis step by step: the matrix
Build and read the Gap Analysis matrix to validate an architecture: Baseline and Target axes, the ‘New’ row, the ‘Eliminated’ column, the ‘Included’ mark, and how each identified gap is handled.
Considering interoperability from the start
Enable organizations, systems, and services to share understandable and usable information.
Interoperability: two classifications and a phase map
Interoperability is the ability to share information and services. This lesson separates the two lenses TOGAF offers (business categories and EAI-inspired integration forms), traces how interoperability is refined from Phase A to Phase F, then presents the degrees of interoperability described in the ADM Techniques.
The ADM and its techniques: who does what?
The ADM describes the phases and their objectives; the techniques and guides explain how to actually carry out certain steps. Understanding this split tells you where to look for help and lets you recognize, in the exam, what belongs to a phase and what belongs to a technique.
Applying the ADM to different needs
Tailor architecture work for strategy, a portfolio, a project, or solution delivery.
Four purposes to size a project
Before launching an Architecture Project, you need to know what the resulting architecture will be used for. Series Guide G186 proposes four purposes: supporting strategy, a portfolio, a project, or the delivery of a solution. Each sets a different horizon, breadth, and depth, and also guides what is kept in the Enterprise Architecture Repository. This lesson compares these purposes so you can recognize them in a scenario.
The ADM, agility, and other approaches
TOGAF is not opposed to Agile or to other frameworks: it combines with them. This lesson explains where the ADM meets Agile development, what architecture brings to Agile teams, how the standard approaches enterprise agility, and how it integrates with other frameworks such as ITIL or PRINCE2.
Navigating the Standard, 10th Edition
Understand the modular structure of Fundamental Content, Series Guides, and the TOGAF Library.
Iterating in the ADM: patterns and cycles
The ADM circle is not walked like a task list. The standard describes several ways to iterate: chaining complete cycles to enrich the Architecture Landscape, running several phases in parallel within one cycle, and evolving the architecture capability itself. This lesson explains these patterns, the four iteration cycles that group the phases, and the situations that justify each of them.
Classifying the Landscape and dividing the work
A large enterprise describes dozens of architectures at once, some very general, others very detailed. To make sense of them, TOGAF classifies the Architecture Landscape by three characteristics and three levels, then divides the work into partitions assigned to teams. This lesson shows how these two tools complement each other without being confused.
Adapting TOGAF: guides, frameworks, and styles
TOGAF is a generic framework: it is never applied as is. The standard shows where to find application guidance, how to combine TOGAF with other frameworks and best practices, and how to put it at the service of a particular architecture style. This lesson brings these three adaptation angles together.
EA, digital enterprise, and agility
Digital enterprises deliver products and services in short cycles. Enterprise Architecture does not slow teams down there: it helps them go faster by managing technical debt, providing reusable components, and simplifying an ecosystem that has become complex. The standard also distinguishes enterprise agility from agile software development and shows which TOGAF concepts make it possible.
Understanding architecture governance
Organize decisions, authority, and responsibility to direct change coherently.
Nature, levels, and framework of Architecture Governance
Architecture Governance is neither just a committee nor a list of rules. It is a decision system that directs and controls architectures across the enterprise, sits within a wider hierarchy of governance, and relies on a framework that separates process, content, and context. This lesson gives the overview needed for outcome 6.1.
Characteristics and benefits of governance
Why govern architecture? TOGAF answers in two ways: six characteristics describing what good governance looks like, and a list of concrete benefits for the enterprise. This lesson helps you recognize each characteristic in a scenario and argue for the value of governance (outcome 6.2).
Architecture Board and decision rights
Coordinate stakeholders, address non-compliance, and evolve EA capability through governed decisions.
The Architecture Board in practice
The Architecture Board is the central element of a successful governance strategy, yet its role is often misunderstood. This lesson separates what the Board owns from what belongs to stakeholders, then groups its responsibilities into three sets (general, operational, governance), before covering how to set it up (outcome 6.3).
Architecture Contracts throughout the ADM
An Architecture Contract is not a single document signed in Phase G: there are several, at different points of the ADM, between different parties. This lesson follows these contracts, their typical content, and how governance uses them (outcome 6.4).
Architecture compliance: reviews, levels, and dispensations
Checking that projects respect the Enterprise Architecture is an essential aspect of governance. This lesson explains why and when compliance reviews are held, how to qualify the result precisely with TOGAF’s six conformance levels, and what to do when compliance is not achieved (outcome 6.5).
Organizing architecture content
Distinguish Content Framework, Content Metamodel, artifacts, and deliverables to produce consistent descriptions.
Content Framework and Enterprise Metamodel
Before producing any deliverable, an architecture practice has to decide how to file its outputs and which types of elements it describes. The Content Framework provides the classification grid for work products; the Enterprise Metamodel sets the entity types and their relationships. Together they make ADM outputs consistent, complete, and traceable.
Deliverable, artifact, building block: what contains what
The three categories of work products do not compete: they nest. A contractual deliverable groups artifacts, and each artifact presents a view of one or more building blocks. Placing a product in the right category, according to its context of use, is a skill the exam expects.
Architecture and Solution Building Blocks
Move from required capabilities to implementation components without choosing a supplier prematurely.
Building blocks across the ADM
A building block starts as an abstract idea in Phase A and ends up, in Phase E, linked to a work package. In between, Phases B, C, and D apply the same four-step pattern that moves from ABBs to SBBs. This lesson follows that path and recalls what makes a good building block.
The Architecture Repository
Organize architecture information, status, and traceability as assets people can actually use.
Landscape levels and partitioning
Connect Strategic, Segment, and Capability Architectures while preserving overall coherence.
Commitments, descriptions, and requirements
Distinguish the Statement of Architecture Work, Architecture Definition Document, and Architecture Requirements Specification.
Key deliverables: defining the architecture
During Phases B, C, and D, two twin deliverables grow together: the Architecture Definition Document, which expresses the architects' intent, and the Architecture Requirements Specification, which derives measurable criteria from it. Knowing what each phase adds to them lets you answer "which deliverable" and "which phase" questions.
Change requests and impact assessment
Evolve a decision in a controlled way when new information changes the context.
Glossary: work products, building blocks, and patterns
Artifact, Deliverable, Building Block, Pattern, Reference Model: these terms name what an architecture team produces or reuses. This sheet gives their rephrased definition, the criteria that separate them, and the link with the adjectives Logical and Physical, which explain the relationship between ABBs and SBBs.
Glossary: models, metamodels, and views
Model, Modeling, Model Kind, Metamodel, Metadata, View, Viewpoint: a family of very close terms that exam questions like to contrast. This sheet defines them one by one and shows how they fit together, from the modeling technique to the organized collection of views.
Catalogs, matrices, and diagrams in practice
Artifacts come in three complementary forms: the list, the relationship table, and the picture. Recognizing an artifact's form from its description, and knowing at which ADM step it typically appears, helps you read deliverables and answer classification questions.
Key deliverables: starting architecture work
The Preliminary Phase and Phase A produce the deliverables that frame everything else: the sponsor's request, the principles, the tailored framework, the agreement on the work, the vision, the communications plan, and the capability assessment. This lesson gives each one's purpose, typical content, and phase.
Key deliverables: planning, governing, evolving
From Phase E onwards, the focus shifts toward planning, implementation governance, and change management. Architecture descriptions continue to be refined, including Transition Architectures. Roadmap, migration plan, governance model, contracts, compliance, change requests, and impact assessment form this second half of the deliverable set.
From concerns to views in deliverables
An architecture deliverable is only useful if it answers the questions of those who read it. The model derived from ISO/IEC/IEEE 42010 links stakeholders, concerns, viewpoints, views, and models into a logical chain. This lesson shows how to follow it to build deliverable content, rather than reciting definitions.