TOGAF® 10 Enterprise Architecture Foundation

A complete knowledge compendium for the TOGAF Enterprise Architecture Part 1 exam (OGEA-101) — organised exactly as the official Level 1 syllabus organises it, covering all 63 learning outcomes, with the weighting of each unit shown so you know where the marks actually are.

The reading order that works

⚑ 35% of the exam  Unit 3 (the ADM) alone is 14 of 40 questions. If you are short on time, over-invest there and in Unit 1 (8 questions). Together they are 55% of the paper.

01 · The exam, precisely

LO 8.1 Explain the TOGAF Certification Program and distinguish between the levels for certification.

Question weighting — where the marks are

The Open Group publishes the exact distribution. Memorise it; it tells you how to budget revision.

The TOGAF certification portfolio where OGEA-101 sits

The pattern to hold: Foundation = Level 1 = Part 1 exam = closed book, 40 simple MCQs. Practitioner = Level 2 = Part 2 exam = open book, 8 gradient-scored scenario questions.

The portfolio also contains certification credentials (shorter learning paths, from three hours of study): Integrating Risk and Security in a TOGAF Enterprise Architecture · TOGAF Framework: Digital Specialist · TOGAF Framework: Agile Specialist · TOGAF Enterprise Architecture Leader · TOGAF Business Architecture Level 1. Legacy certifications based on Version 9.2 — TOGAF 9 Foundation and TOGAF 9 Certified — also remain in the portfolio.

U1 · Concepts 8 questions · 20%

Twelve learning outcomes — the second-heaviest unit and the most definitional. Most questions are a single sentence you either know verbatim or you don't.

1.1 What is an enterprise? LO 1.1 S0 §1.1

"Enterprise" in the context of "Enterprise Architecture" can be applied either to an entire enterprise — all its business activities and capabilities, information, and the technology, infrastructure and governance that make it up — or to one or more specific areas of interest within it. An enterprise may include partners, suppliers and customers as well as internal business units. In all cases, the architecture crosses multiple systems and multiple functional groups.

Examples of an enterprise

• A whole corporation or a division of a corporation
• A government agency or a single government department
• A chain of geographically distant organizations linked by common ownership
• Groups of countries, governments, or governmental organizations (such as militaries) working together to create common or shareable deliverables or infrastructures
• Partnerships and alliances of businesses working together, such as a consortium or supply chain

What is Enterprise Architecture? background — two industry definitions the Study Guide quotes

The TOGAF Standard notes there are many definitions, most focusing on structure and organization:

• "The process of translating business vision and strategy into effective enterprise change by creating, communicating, and improving the key principles and models that describe the enterprise's future state and enable its evolution." — Gartner®
• "A set of abstractions and models that simplify and communicate complex structures, processes, rules, and constraints to improve understanding, implementation, forecasting, and resourcing." — DoDAF

1.2 The purpose of Enterprise Architecture LO 1.2 S0 §1.1 · G186 §3.1 · G20F §1.2

It provides a framework for change linked to both strategic direction and business value, and a sufficient view of the organization to manage complexity, support continuous change, and manage the risk of unanticipated consequences.

All enterprises seek to improve. Regardless of type there is a need for deliberate, effective change:

Guidance on effective change takes place during the activity to realize the approved Enterprise Architecture. During implementation, stakeholders use the Enterprise Architecture to govern change, in two parts:

• Direct the change activity — align the change with the optimal path to realizing the expected value.
• Control the change activity — ensure the change stays on that optimal path.

Enterprise Architecture enables achievement of the right balance between business transformation and continuous operational efficiency. A good Enterprise Architecture facilitates effective governance, management, risk management, and exploitation opportunities.

Additionally, much global privacy legislation demands that processes around personal data be fully documented in a way that can be easily understood by untrained readers — data subjects, judges, lawyers. Penalties for failing to have this can be very significant, so creating appropriate controls and documentation is essential.

1.3 Key benefits of Enterprise Architecture LO 1.3 S0 §1.1 · G184 §3.6

A "list" outcome — single-item recognition is enough, but learn all five.

Ultimately the benefits derive from the better planning, earlier visibility, and more informed designs that result when Enterprise Architecture is introduced.

1.4 Why the TOGAF Standard is suitable as a framework LO 1.4 S0 §1.1 · G20F §1.2

What the TOGAF Standard is: a framework for Enterprise Architecture — a standard approach for developing, approving, using, and maintaining Enterprise Architectures. It applies to all Enterprise Architecture practices. It is based on an iterative process model supported by best practices and a re-usable set of existing architectural assets. It is a foundational framework, meaning it is applicable to the development of any kind of architecture in any context.

Using it results in Enterprise Architecture that is consistent, reflects the needs of stakeholders, employs best practice, and gives due consideration to both current requirements and the perceived future needs of the business.

It is also suitable because it provides three things

1. A definition and description of a standard cycle of change used to plan, develop, implement, govern, change and sustain an architecture for an enterprise — the TOGAF ADM.
2. A definition and description of the building blocks in an enterprise used to deliver business services and information systems — the TOGAF Content Framework.
3. A set of guidelines, techniques and advice to create and maintain an effective Enterprise Architecture and deliver change through new Solution Architectures at all levels of scale, pace and detail.

Origin & stewardship background

Developed and maintained by The Open Group Architecture Forum. Version 1 (1995) was based on the US Department of Defense TAFIM (Technical Architecture Framework for Information Management). Successive versions have represented the current state of stable, scalable, best practice.

1.5 Structure of the TOGAF documentation S0 §2

The documentation set is structured to address the transition from common universal scaffolding to the unique configuration within an organization. It spans the formal TOGAF Standard plus a broader body of knowledge, the TOGAF Library.

The six Fundamental Content documents — the {S0}–{S5} references

Why the split? To let different areas of specialization be considered in detail and potentially addressed in isolation, and to let individual documents be amended without impacting the whole set. Although all documents work together as a whole, it is feasible to select individual documents for adoption while excluding others — e.g. adopt the ADM process but not the Architecture Capability material. As an open framework, such use is encouraged, particularly for organizations new to TOGAF adopting incrementally, and for organizations merging TOGAF with an existing framework.

1.6 The four architecture domains LO 1.5 S0 §3.3

The TOGAF Standard covers the development of four architecture domains, closely related and commonly accepted as subsets of an overall Enterprise Architecture.

Other domains exist but are formed by combining appropriate views of the four primary domains — for example Information Architecture, Risk and Security Architectures, Digital Architecture. The Definitions put it as: other domains (motivation, security, governance, etc.) may span those four primary domains.

1.7 Architecture abstraction LO 1.6 S0 §3.7

Architecture abstraction is a technique for dividing a problem area into smaller problem areas that are easier to model and therefore easier to solve. Abstraction levels are layered in nature, moving from high-level models to more detailed models.

The four levels answer four fundamental questions about an architecture, and each level cuts across Business, Data, Application and Technology:

1.8 The Enterprise Continuum LO 1.7 S0 §3.10 · S4 §6

The simplest way of thinking of it: a view of the repository of all the architecture assets. It can contain Architecture Descriptions, models, building blocks, patterns, architecture viewpoints and other artifacts — existing both within the enterprise and in the IT industry at large, which the enterprise considers available for developing its architectures.

• Internal examples: the deliverables of previous architecture work, available for re-use.
• External examples: industry reference models and architecture patterns — highly generic (the TOGAF TRM), IT-aspect-specific (web services, generic manageability), processing-specific (e-Commerce, supply chain management), or vertical-industry (TM Forum in Telecommunications, ARTS in Retail, Energistics® in Petrotechnical).

The two ideas it supports

1. Re-use where possible — especially the avoidance of re-invention.
2. An aid to communication. Assets structured generic → specific give a consistent language to effectively communicate the differences between architectures. Understanding where you are in the continuum helps everyone communicate effectively and eliminates ambiguity when discussing concepts across departments or across organizations.

Three continua, not two 10th Edition refinement

The 10th Edition partitions the Enterprise Continuum into three distinct continua. A distinction is made between architectures and their possible solutions, and the relationship between the Architecture Continuum and the Solutions Continuum is one of guidance and support.

The four classes along each continuum S4 §6.4

Requirements are addressed in increasing detail from left to right. The architect will typically look to find re-usable architectural elements toward the left. These four types indicate a range, not fixed stages in a process — many types may occur in between.

The evolutionary progression is not a formal process, but it does progress at several levels: logical to physical · horizontal (IT-focused) to vertical (business-focused) · generalization to specialization · taxonomy to complete and specific architecture specification.

1.9 The Architecture Repository LO 1.8 S0 §3.11 · G186 §5.1

Operating a mature Architecture Capability within a large enterprise creates a huge volume of architectural output. Effective management and leverage of these work products requires a formal taxonomy for different types of architectural asset alongside dedicated processes and tools for architectural content storage.

The Architecture Repository is one part of the wider Enterprise Repository, which provides the capability to link architectural assets to components of the Detailed Design, Deployment, and Service Management Repositories.

The eight major components

1.10 Content Framework and Enterprise Metamodel LO 1.9 S0 §3.12 · G184 §8.3

Together they define a formal structure and provide guidance for organizations that wish to implement their architecture within an architecture tool.

1.11 Architecture Capability LO 1.10 S0 §3.13–3.14 · G184 §3.3, 5.1

To carry out architectural activity effectively within an enterprise it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes. Memorise that five-item list — it is the standard's exact phrasing and the hook for the "which does this illustrate?" question.

Barring capabilities set up purely to support change delivery programs, a successful Enterprise Architecture practice must sit on a firm operational footing: it should be run like any other operational unit within a business — i.e. it should be treated like a business. Over and above the core ADM processes, it should establish capabilities in nine areas:

Enterprise Architecture Services background — S0 §3.5

ADM activities are often provided through a service delivery model, organized into service categories that address specific needs independent of an organization's operating model. The first four are customer-centric, the rest are internally centred on architects: Enterprise Support Services (for C-level management) · Design Support Services (program-level decision-makers) · Development Support Services (project-level decision-makers) · Requirements Elicitation and Understanding Services · Architecture Planning Services · Enterprise Architecture Practice Development Support Services.

1.12 Risk management LO 1.11 S2 §9.1 · G152 §3.1.1

The effect of uncertainty is any deviation from what is expected — positive and negative. Uncertainty concerns predicting future outcomes given the limited information available when making a decision; this information can never be perfect, although better quality information should mean better quality decisions.

Every decision is based on assessing the balance between potential opportunities and threats, the likelihood of beneficial versus damaging outcomes, the magnitude of those potential events, and the likelihood associated with each identified outcome. Identifying and assessing these factors is "risk assessment" or "risk analysis". "Risk management" is the art and science of applying these concepts in the decision-making process.

There will always be risk with any architecture / business transformation effort. It is important to identify, classify and mitigate these risks before starting so they can be tracked throughout the transformation effort. Mitigation is an ongoing effort, and risk triggers may lie outside the scope of the transformation planners (merger, acquisition) — so planners must monitor the transformation context constantly.

The two levels of risk

1.13 Gap analysis LO 1.12 S2 §5.1 · G186 §15.2.3

Gap analysis is a technique used in the ADM to validate an architecture that is being developed. It is usually the final step within a phase.

The method — matrix steps

1. Draw a matrix with all ABBs of the Baseline Architecture on the vertical axis, and all ABBs of the Target Architecture on the horizontal axis.
2. Add a final row labelled "New" to the Baseline axis, and a final column labelled "Eliminated" to the Target axis.
3. Where an ABB is in both → record "Included" at the intersecting cell.
4. Where a Baseline ABB is missing from the Target → review it. If correctly eliminated, mark it as such in the "Eliminated" cell. If not, you have uncovered an accidental omission in your Target Architecture that must be addressed by reinstating the ABB in the next iteration of the architecture design.
5. Where a Target ABB cannot be found in the Baseline → mark it at the intersection with the "New" row as a gap that needs to be filled, either by developing or procuring the building block.

When the exercise is complete, anything under "Eliminated" or "New" is a gap, which should either be explained as correctly eliminated or marked as to be addressed by reinstating or developing/procuring the function.

U2 · Definitions Examined indirectly

LO 2.1 The Candidate is able to define 21 concepts. S0 §4  Syllabus note: "No definition from this list is required to be taught separately, or be examinable, unless it is used in the learning objective of another unit."

The 21 syllabus terms

Beyond the list: definitions Units 1 and 3–7 depend on

Not in the Unit 2 list, but they appear in other units' learning outcomes — so they are fair game.

U3 · Introduction to the ADM 14 questions · 35%

Twenty-six learning outcomes — the largest unit by far. Master the phase tables and you have a third of the paper.

3.1 The ADM and its phases LO 3.1 S0 §3.4 · S1 §1.2.2

The ADM (Architecture Development Method) is the core of the TOGAF framework: a multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation. It provides a tested and repeatable process for developing architectures, is a method for deriving organization-specific Enterprise Architectures, and is specifically designed to address business requirements.

It includes establishing an architecture framework, developing architecture content, transitioning, and governing the realization of architectures — all carried out within an iterative cycle of continuous architecture definition and realization that allows organizations to transform their enterprises in a controlled manner in response to business goals and opportunities.

The phase purpose table highest-yield table in the exam

3.2 Preliminary Phase LO 3.7 LO 3.8 G184 §13.1 · S1 §2.1

The ADM is used to develop the Enterprise Architecture Capability. There is no difference between exercising the ADM to architect an EA Capability, a finance capability, a portfolio, or an organizational strategy — we are using the concepts of the ADM to support two different activities.

Key activities — nine

• Setting the Enterprise Architecture context specific for the EA Capability
• Setting business objectives for the EA Capability
• Establishing Architecture Governance
• Alignment with other frameworks
• Customization of Architecture Contents and Metamodel
• Establishing the organization model for the Enterprise Architecture Team
• Establishing the process model
• Creating the Enterprise Architecture Capability Roadmap
• Establishing and evolving the EA Capability

Objectives — two, each with four sub-points

3.3 Phase A: Architecture Vision LO 3.9 LO 3.10 G186 §5.2.1–5.2.2 · S1 §3.1

All architecture development needs to start with Phase A.

Objectives — exactly two

1. Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture.
2. Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision.

3.4 Phases B, C and D LO 3.11 LO 3.12 LO 3.13 LO 3.14 G186 §5.2.2 · S1 §4.1, 5.1, 6.1, 7.1, 8.1

Essential knowledge determined in B, C and D — four questions

• How does the current enterprise fail to meet the preferences of the stakeholders?
• What must change to enable the enterprise to meet the preferences of the stakeholders? (Gaps)
• What work is necessary to realize the changes, consistent with the additional value being created? (Work Package)
• How do stakeholder priority and preference adjust in response to value, effort, and risk of change? (Stakeholder Requirements)

Objectives — identical pattern in all four; only the domain noun changes

3.5 Phase E: Opportunities & Solutions LO 3.15 LO 3.16 G186 §5.2.2 · S1 §9.1

Essential knowledge determined in Phase E

• The dependency between the set of changes (Work Package & Gap Dependency)
• The value, effort, and risk associated with each change and work package
• How stakeholder priority and preference adjust in response to value, effort, and risk of change

Objectives — three

1. Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C and D.
2. Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value.
3. Define the overall Solution Building Blocks (SBBs) to finalize the Target Architecture based on the ABBs.

3.6 Phase F: Migration Planning LO 3.17 LO 3.18 G186 §5.2.2 · S1 §10.1

Essential knowledge determined in Phase F

• The resources available to undertake the change
• How stakeholder priority and preference adjust in response to value, effort, and risk of change (Stakeholder Requirements)

Objectives — three

1. Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan.
2. Ensure that the Implementation and Migration Plan is co-ordinated with the enterprise's approach to managing and implementing change in the enterprise's overall change portfolio.
3. Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders.

3.7 Phase G: Implementation Governance LO 3.19 LO 3.20 G186 §5.2.2 · S1 §11.1

Essential knowledge determined in Phase G

• The purpose and constraints on the implementation team (Gap, Architecture Requirements Specification, Control)
• How stakeholder priority and preference adjust in response to success, value, effort, and risk of change (Stakeholder Requirements)

Objectives — two

1. Ensure conformance with the Target Architecture by Implementation Projects.
2. Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests.

3.8 Phase H: Architecture Change Management LO 3.21 LO 3.22 G186 §5.2.2 · S1 §12.1

Essential knowledge determined in Phase H

• The gaps between approved target, or preference, and realization from prior work (Value Realization)
• Changes in preference or priority (Stakeholder Requirements)

Objectives — three, all beginning "Ensure that…"

1. Ensure that the architecture development cycle is maintained.
2. Ensure that the Architecture Governance framework is executed.
3. Ensure that the Enterprise Architecture Capability meets current requirements.

3.9 Requirements Management LO 3.23 LO 3.24 S1 §13.1 · G186 §6.1.1

The TOGAF framework places Requirements Management at the centre of architecture development. Effective requirements management is dependent upon clear traceability from the organization's vision, mission, business model, and strategies through to the most detailed statement of requirement.

Objectives — three

1. Ensure that the Requirements Management process is sustained and operates for all relevant ADM phases.
2. Manage Architecture Requirements identified during any execution of the ADM cycle or a phase.
3. Ensure that relevant Architecture Requirements are available for use by each phase as the phase is executed.

3.10 Draft vs. approved deliverables LO 3.2 S1 §1.2.2

The lifecycle of outputs must be managed through a version numbering policy, adapted by the architect to meet the requirements of the organization and to work with the architecture tools and repositories employed. This is used in particular within the ADM to illustrate the evolution of Baseline and Target Architecture Definitions.

3.11 The iterative approach of the ADM LO 3.3 S1 §1.2.1 · G186 §5.2, 5.2.3

The ADM is iterative over the whole process, between phases, and within phases.

For each iteration, a fresh decision must be taken as to four things

1. The breadth of coverage of the enterprise to be defined
2. The level of detail to be defined
3. The extent of the time period aimed at, including the number and extent of any intermediate time periods
4. The architectural assets to be leveraged — including assets created in previous iterations of the ADM cycle within the enterprise, as well as assets available elsewhere in the industry (other frameworks, systems models, vertical industry models)

Information flows also result in iteration. Every time the EA team undertakes any activity within the scope of the ADM it is executing a phase and developing the contents of the Enterprise Architecture Landscape. The inter-dependent nature of developing a Target Architecture requires considering the entire architecture, resulting gaps, and resulting work to clear the gap simultaneously.

Worked example from the Standard: a practitioner working on roadmap development is exercising the steps in Phase E; they must consume the mandatory inputs and produce the mandatory outputs. This applies to all ADM phases. No practitioner can consider a change without considering the impact on all other domains, the resulting set of gaps, and the resulting set of work to clear the gap.

Represented as a Gantt chart, the inter-dependent nature of Enterprise Architecture requires all ADM phases that develop a candidate architecture to be executed simultaneously until the candidate architecture is tested for acceptance against the stakeholders' requirements. They then close to allow specific elements of supporting domains to be completed. This provides a process-oriented view of ADM iteration.

3.12 Governing Enterprise Architecture LO 3.4 S1 §1.4 · G186 §15.1.1–15.2.1

The ADM — whether adapted by the organization or used as documented — is a key process to be managed in the same manner as other architecture artifacts classified through the Enterprise Continuum and held in the Architecture Repository.

The practitioner is directed to develop an architecture within a controlled scope. Within that scope, the practitioner is directed to the stakeholder's preferences. The governance test will assess whether the practitioner is addressing the stakeholder's concerns.

The Architecture Board should be satisfied that the method is being applied correctly across all phases of an architecture development iteration. Compliance with the ADM is fundamental to the governance of the architecture, to ensure that all considerations are made and all required deliverables are produced.

The four governance instruments — learn which governs what

The implementation team is directed to create changes with intentional value-based outcomes. Best practice governance enables the organization to control value realization.

An Enterprise Architecture is more than just the artifacts produced by applying the ADM. Making the organization act according to the principles laid down in the architecture requires a decision-making framework — the TOGAF Standard provides guidelines for establishing and operating one, in the form of an Architecture Board (see Unit 6).

3.13 Scoping an architecture LO 3.5 S1 §1.5

Three reasons to constrain (restrict) the scope

1. Limits in the organizational authority of the team producing the architecture
2. Limits in the objectives and stakeholder concerns to be addressed within the architecture
3. Limits in the availability of people, finance, and other resources

The scope chosen should ideally allow the work of all architects within the enterprise to be effectively governed and integrated. This requires a set of aligned architecture partitions that ensure architects are not working on duplicate or conflicting activities, plus the definition of re-use and compliance relationships between architecture partitions.

The four scope dimensions

Scope is first expressed in terms of breadth, depth, and time period. Once those scoping dimensions are understood, a suitable combination of architecture domains can be selected that are appropriate to the problem being addressed.

3.14 Architecture alternatives and trade-off LO 3.6 S1 §1.6–1.6.1 · S2 §9

Creating an architecture normally requires trade-offs among competing forces. There is often more than one possible Target Architecture that would conform to the Architecture Vision, Architecture Principles, and Requirements.

It is most common that a single alternative does not exist that will meet all stakeholders' concerns. Commonly, alternatives are defined per domain to simplify the analysis; per-domain alternatives can then be merged into an overall analysis for the whole architecture.

The Architecture Trade-Off method — three parts

1. Uses the vision, principles, requirements, and other information to select sets of criteria fitting for different alternatives.
2. Defines alternatives based on the criteria and builds an understanding of each.
3. Will either select one of the alternatives, or else combine features from more than one, to create the proposed alternative.

Perform these activities in just enough detail to support that decision. The method can be used for any phase at any level of an architecture.

3.15 Information flow between the ADM phases LO 3.25 G186 §5.2

The TOGAF ADM is a logical method that places key activity steps together for the purpose of understanding relationship of activity and clarifying information flow.

The iconic graphic is a stylized path that shows essential information flow between the phases and is not a representation of activity sequence. The graphic is often misinterpreted as a linear waterfall process model.

3.16 Architecture for Agile software development LO 3.26 G186 §12.1

How architecture serves Agile teams

• Architecture can identify what products the enterprise needs, the boundary of the products, and what constraints a product owner has.
• Architecture can define a set of constraints that limit the choices of the Agile team.
• In short, a good architecture defines the enterprise's backlog.
• Constraints are where an individual product must bend to enterprise issues, and the parochial preference of a product owner is not valid.

In Phase G the practitioner serves the stakeholders in Agile development projects by guarding enterprise value — in terms of the mission, vision, goals, and investment roadmap.

U4 · Introduction to ADM Techniques 6 questions · 15%

Nine learning outcomes, three of them on Architecture Principles alone — so principles are the highest-value target in this unit.

4.1 How the ADM and Supporting Guidelines & Techniques relate LO 4.1 S1 §1.1.3

Application of the TOGAF ADM is supported by an extended set of resources — guidelines, templates, checklists and other detailed materials — held in three places:

The individual guidelines and techniques are described separately so that they can be referenced from the relevant points in the ADM as necessary, rather than having the detailed text embedded in the description of the ADM itself.

The eight techniques in the ADM Techniques document

4.2 Architecture Principles — purpose LO 4.2 G184 §4.3.3 · S2 §2

Broader framing from the Standard: principles are "general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission." They may be just one element in a structured set of ideas that collectively define and guide the organization — from values through to actions and results. Two key domains inform architecture: Enterprise Principles (a basis for decision-making throughout an enterprise, informing how it fulfils its mission) and Architecture Principles.

The four purposes — all examinable

4.3 The recommended template for Architecture Principles LO 4.3 S2 §2.3

Four parts. In addition to a name and definition statement, each principle should have associated rationale and implications statements — both to promote understanding and acceptance of the principles themselves, and to support the use of the principles in explaining and justifying why specific decisions are made.

Worked example from the Standard — Business Principle 1

The Standard's example set of 21 principles S2 §2.6 · background

Not individually examinable, but two facts are worth holding: the ADM Techniques document contains an example set of nine business principles that is "a useful starting point" (referenced by the Business Principles, Goals and Drivers deliverable), and the full example set spans all four domains.

4.4 What makes a good Architecture Principle LO 4.4 S2 §2.4–2.4.1

A good set of principles will be founded in the beliefs and values of the organization and expressed in language that the business understands and uses. Principles should be:

• Few in number
• Future-oriented
• Endorsed and championed by senior management

They provide a firm foundation for making architecture and planning decisions, framing policies, procedures and standards, and supporting resolution of contradictory situations. A poor set will quickly become disused, and the resultant architectures, policies and standards will appear arbitrary or self-serving, and thus lack credibility.

The five criteria for quality principles

4.5 Business scenarios LO 4.5 G176 §1

A business scenario describes four things

1. A business problem
2. The business and technology environment
3. The people and computing components ("actors") who execute the scenario
4. The desired outcome of proper execution

Where it can be used

The method can be used in any ADM phase. Most notably:

The method — six steps

1. Identify, document, and rank the problem that is driving the scenario
2. Document, as high-level architecture models, the business and technical environments where the problem situation is occurring
3. Identify and document desired objectives — the results of handling the problems successfully. Ensure the objectives are SMART: Specific, Measurable, Actionable, Relevant, Timebound
4. Identify human actors (participants) and their place in the business model
5. Identify computer actors (computing elements) and their place in the technology model
6. Check for fitness-for-purpose, and refine if necessary

4.6 Gap analysis — purpose LO 4.6 S2 §5.1

The purpose is to document the difference between the Baseline and the Target Architectures. It identifies components (building blocks) of the architecture that are added, deleted, and/or changed. Full method in Unit 1 §1.13.

4.7 Interoperability LO 4.7 S0 §3.9 · S2 §6

Defining the degree to which information and services are to be shared is very important, especially in a complex organization and/or extended enterprise.

Three categories of interoperability

Determination of interoperability occurs throughout the ADM

4.8 Business Transformation Readiness Assessment LO 4.8 S2 §7–8

Enterprise Architecture often involves considerable change. There are many dimensions to change, but by far the most important is the human element.

It is a joint effort between corporate (especially human resources) staff, lines of business, and IT planners.

Recommended activities — five

1. Determine the readiness factors that will impact the organization
2. Present the readiness factors using maturity models
3. Assess the readiness factors, including determination of readiness factor ratings
4. Assess the risks for each readiness factor and identify improvement actions to mitigate the risk
5. Work these actions into the Implementation and Migration Plan developed in Phases E and F

4.9 Characteristics of architecture risk management LO 4.9 S2 §8–9 · G152

ISO 31000: risk management = "coordinated activities to direct and control an organization with regard to risk."

The Enterprise Architect may identify the risks and mitigate certain ones, but it is within the governance framework that risks have to be first accepted and then managed.

The six-step process from the ADM Techniques document

Where risk management sits in the ADM

U5 · Introduction to Applying the ADM 4 questions · 10%

Six learning outcomes. A small unit, but three of the six are pure list recall — the cheapest marks on the paper.

5.1 Where the guidance on applying the Standard lives LO 5.1 S0 §2.2

The Series Guides are designed to support practitioners who need further explanation or more detail than that provided in the TOGAF Fundamental Content.

Not all Series Guides will be relevant in every situation. However, Enterprise Architects planning the deployment of the TOGAF Standard should be aware of the guidance available. Over time the guidance will expand as the professional body of knowledge that forms the TOGAF Standard expands with additional best practice.

Areas covered by the Series Guides include: strategy decision-making and business value-oriented decisions · Business Architecture and operating model description · information and data management · information system guidance · reference models and data integration models · Technology Architecture (applying EA to adopt new technology trends) · Security Architecture and risk management · the Agile enterprise · the digital enterprise · and using the Standard alongside other standards (O-AA™, DPBoK™, IT4IT™, ArchiMate®, Microservices Architecture).

5.2 How iteration enables concurrent operation of multiple ADM phases LO 5.2 S3 §2.1–2.2

Why this matters: the ADM graphic and the sequential description of phases "can be read to imply a deterministic waterfall methodology". In practice, two key concepts manage the complexity of developing an Enterprise Architecture and managing its lifecycle: iteration and levels — and the two concepts are tightly linked.

The ADM supports iteration in three ways

1. Iteration to describe a comprehensive Architecture Landscape through multiple ADM cycles, based upon individual initiatives bound to the scope of the Request for Architecture Work.
2. Iteration to describe the integrated process of developing an architecture, where the activities described in different ADM phases interact to produce an integrated architecture.
3. Iteration to describe the process of managing change to the organization's Architecture Capability.

The three iteration patterns in detail

The four suggested iteration cycles high-value detail

The iteration cycles group related architectural activities to achieve a specific purpose:

Three classes of architecture engagement S3 §2.3 · background

An architecture function may be called on in different contexts, since architectures range from summary to detail, broad to narrow coverage, and current state to future state. There are typically three areas of engagement:

5.3 The three levels of the Architecture Landscape LO 5.3 S3 §3.2, 3.4

The TOGAF framework uses the concept of the Architecture Landscape to refer to the complete set of descriptions for the Enterprise Architecture. In a typical enterprise many architectures will be described at any point in time — some address very specific needs, others are more general; some address detail, some provide a big picture. To address this complexity TOGAF uses levels and the Enterprise Continuum as a conceptual framework for organizing the Architecture Landscape.

Characteristics that frame the Landscape

The three levels of granularity memorise verbatim

An aside worth remembering from the Study Guide: "in most cases, Architecture Projects are not neat cubes… A real representation would look more like a sea urchin — a consolidated centre but with spikes going in all directions."

5.4 Partitioning LO 5.4 S3 §4

Partitions are used to simplify the development and management of the Enterprise Architecture. They lie at the foundation of Architecture Governance. They are distinct from levels and from the organizing concepts of the Architecture Continuum.

Three reasons for partitioning an architecture

1. Organizational unit architectures conflict with one another.
2. Different teams need to work on different elements of architecture at the same time — partitions allow specific groups of architects to own and develop specific elements of the architecture.
3. Effective architecture re-use requires modular architecture segments that can be taken and incorporated into broader architectures and solutions.

Reason 2 is the one the exam asks for when it says "why does partitioning help simplify development?"

What partitioning produces

It is valuable to partition and organize the Enterprise Continuum into a set of related solutions and architectures with: manageable complexity for each individual architecture or solution · defined groupings · defined hierarchies and navigation structures · appropriate processes, roles and responsibilities attached to each grouping.

Classification criteria used to partition background

5.5 The four purposes of Enterprise Architecture LO 5.5 G186 §3.2.2

Four purposes are used to frame the planning horizon and the breadth and depth of an Architecture Project, and the contents of the Enterprise Architecture Repository.

5.6 The TOGAF Standard and the digital enterprise LO 5.6 G217 §2.1

The need for companies to evolve into digital enterprises can be linked to a variety of drivers — not least the rapid change in technologies driving new ways of working, socializing, and entertaining. Enterprise Architecture supports and enables the Agile environment in delivering and enhancing digital products and services quicker and easier by providing insight into various areas.

The insight an Enterprise Architecture provides

• Reactively managing technical debt as the result of sprints, in a cohesive and connected fashion.
• Proactively managing technical debt and anticipating Agile development needs by:
  • Identifying standards and re-usable standard components that support shortened Agile development cycles
  • Appropriate governance or guardrails to oversee the re-use of components
• Managing mature digital products and delivering operational excellence by:
  • Simplifying complexity in the digital ecosystem using the TOGAF ADM
  • Establishing an Enterprise Architecture Capability that drives operational excellence in the management of digital products and services

U6 · Introduction to Architecture Governance 3 questions · 7.5%

Five learning outcomes — the smallest unit. But the six benefit characteristics and the Board's responsibilities are near-certain question sources, so learn them precisely.

6.1 The concept of Architecture Governance LO 6.1 S5 §3.1 · G184 §6.1

On governance generally: it is a decision-making process with a defined structure of relationships to direct and control the enterprise to achieve stated goals. The process by which direction and control is provided should take into account equality of concern and transparency, protecting the rights and interests of the business. The key difference between governance and management rests on the cornerstone of fiduciary and sustainable responsibility.

Governance is about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about effective usage of resources to ensure sustainability of an organization's strategic objectives.

By governance we define the way in which decisions are made: Who is responsible? Who is involved? Who is accountable?

Architecture Governance includes four things

• Controls on the creation and monitoring of components and activities — ensuring the introduction, implementation, and evolution of architectures
• Ensuring compliance with internal and external standards and regulatory obligations
• Supporting management of the above
• Ensuring accountability to external and internal stakeholders

Governance is about a hierarchy of decision-making that everyone commits to, and it can be used to drive a set of behaviors. The act of observation by the governance team should not change the fact or how something is done. An observation results in some form of measurement; a set of measurements and metrics can be used to focus and achieve organizational objectives. Being transparent about why the measurement is being made and what mitigation options are available will drive positive behavior.

The governance hierarchy high-yield

Architecture Governance typically operates within a hierarchy of governance structures. It does not operate in isolation, nor merely "at the top level of the organization", nor merely "in Phase G". The four distinct domains, each with their own disciplines and processes:

Each of these domains of governance may exist at multiple geographic levels — global, regional, and local — within the overall enterprise.

The Architecture Governance Framework S5 §3.2 · background

Conceptually, Architecture Governance is an approach, a series of processes, a cultural orientation, and a set of owned responsibilities that ensure the integrity and effectiveness of the organization's architectures. The framework is generic and can be adapted to the existing governance environment of an enterprise.

The split of process, content, and context is key: it allows new governance material (legal, regulatory, standards-based, or legislative) to be introduced without unduly impacting the processes. This content-agnostic approach ensures the framework is flexible. The framework is integral to the Enterprise Continuum and manages all content relevant both to the architecture itself and to the governance processes.

The six key Architecture Governance processes

Key success factors for Architecture Governance S5 §3.3.1 · background

• Best practices for the submission, adoption, re-use, reporting, and retirement of architecture policies, procedures, roles, skills, organizational structures and support services
• Organizational responsibilities and structures to support the governance processes and reporting requirements
• Integration of tools and processes to facilitate take-up, both procedurally and culturally
• Criteria for the control of the governance processes, dispensations, compliance assessments, SLAs and OLAs
• Internal and external requirements for the effectiveness, efficiency, confidentiality, integrity, availability, compliance, and reliability of all governance-related information, services and processes

6.2 Why Architecture Governance is beneficial LO 6.2 S5 §3.1.2 · G184 §6.1.1

Six characteristics — adapted from the book Corporate Governance (Naidoo 2002) — highlight both the value and the necessity for governance as an approach to be adopted within organizations and their dealings with all involved parties. These lead to specific benefits, and each has a one-line definition the exam quotes almost verbatim.

6.3 The Architecture Board LO 6.3 S5 §4 · G184 §6.2

Role

A key element in a successful Architecture Governance strategy is a cross-organization Architecture Board. This body:

• Is the sponsor of the architecture activity
• Oversees implementation of the governance strategy
• Should be representative of all the key stakeholders in the architecture

The actual name "Architecture Board" is not important — another name could be used, e.g. "Enterprise Architecture governance board".

Architecture Boards may have global, regional, or business line scope. Particularly in larger enterprises they typically comprise representatives from a minimum of two levels:

• Local — domain experts, line responsibility
• Global — organization-wide responsibility

In such cases each Board is established with identifiable and articulated responsibilities and decision-making capabilities, as well as remit and authority limits.

Responsibilities — three groupings

Setting up and operating the Board S5 §4.3–4.4 · background

6.4 Architecture Contracts LO 6.4 S5 §5

Taking a governed approach to contract management ensures:

• A system that continuously monitors integrity, changes, decision-making, and audit, as well as adherence to the principles, standards, and requirements of the enterprise
• A set of processes and practices that ensure accountability, responsibility, and discipline with regard to the development and usage of all architectural artifacts

The architecture team may also be included in product procurement, to help minimize the opportunity for any misinterpretation of the Enterprise Architecture.

Typically an Architecture Contract has been an agreement between the sponsor and the architecture function or IS department. But increasingly more services are being provided by systems integrators, applications providers, and service providers, coordinated through the architecture function — hence the need for contracts establishing joint agreements between all parties involved in architecture development and delivery.

Where Architecture Contracts occur in the ADM

6.5 The need for Architecture Compliance LO 6.5 S5 §6

Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture Governance.

Two complementary processes

1. The Architecture function will be required to prepare a series of Project Architectures — project-specific views of the Enterprise Architecture that illustrate how the Enterprise Architecture impacts on the major projects within the organization (see ADM Phases A to F).
2. The Enterprise and IT Governance functions will define a formal Architecture Compliance review for reviewing the compliance of all projects to the Enterprise Architecture.

Why compliance reviews are needed — seven reasons

All of the above help to shorten the overall project time, and ensure that the business gets the benefit of the architecture development faster.

Definition: an Architecture Compliance review is "a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives." A formal process for such reviews normally forms the core of an Enterprise Architecture Compliance strategy.

What "in accordance with" means S5 §6.2 · background

The Standard distinguishes levels of conformance between an architecture and an implementation ("conformant", "compliant", and so on). The key phrase is "in accordance with", which means the implementation:

• Supports the stated strategy and future directions
• Adheres to the stated standards — including syntax and semantic rules specified
• Provides the stated functionality
• Adheres to the stated principles — for example, open wherever possible and appropriate, and re-use of component building blocks wherever possible and appropriate

U7 · Architecture Content 5 questions · 12.5%

Three learning outcomes, but LO 7.3 alone covers sixteen deliverables. Expect at least one multi-item matching question here.

7.1 Stakeholders, concerns, views, viewpoints LO 7.1 S4 §3.1 · ISO/IEC/IEEE 42010

These four concepts are adapted from more formal definitions in ISO/IEC/IEEE 42010 and described within the context of the TOGAF Standard.

Supporting definitions

In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools. An architecture view will comprise selected parts of one or more models, chosen so as to demonstrate to a particular stakeholder or group of stakeholders that their concerns are being adequately addressed. The Standard summarises the actionable concepts as: selecting a key stakeholder → understanding and documenting their concerns → understanding how to model and deal with those concerns.

7.2 Building blocks and their use in the ADM LO 7.2 S4 §5 · S0 §3.6

Systems are built from collections of building blocks. They can be defined at many levels of detail — at an early stage a building block can simply consist of a name or an outline description; later it may be decomposed into multiple supporting building blocks and accompanied by a full specification.

A good choice of building blocks can lead to improvements in legacy system integration, interoperability, and flexibility in the creation of new systems and applications.

The work-product taxonomy — how the three categories nest high-value

The Architecture Content Framework uses three categories to describe the type of architectural work product within the context of use:

Catalogs, matrices and diagrams S4 §3.6.1

The Enterprise Metamodel structures architectural information so it can be processed to meet stakeholder needs. But most stakeholders do not need to know what the metamodel is — they are concerned with specific questions such as "what functionality does this application support?" or "which processes will be impacted by this project?". To meet those needs, TOGAF uses building blocks, catalogs, matrices and diagrams:

How building block specification proceeds through the ADM

The specification of building blocks using the ADM is an evolutionary and iterative process. In Phase A we start with abstract entities. Definition takes place gradually as the ADM is followed, mainly in Phases A, B, C and D. It is iterative because as definition proceeds, detailed information about the functionality required, the constraints imposed on the architecture, and the availability of products may affect the choice and content of building blocks.

The major work consists of identifying the ABBs required to meet the Business Goals and objectives, then refining the selected set of ABBs in an iterative process to arrive at a set of SBBs which can either be bought off-the-shelf or custom developed.

In Phases B, C and D — the common pattern of four steps

1. Select reference models, viewpoints, and tools
2. Develop Baseline Architecture description — a high-level model of existing building blocks, re-using definitions from the Architecture Repository where they are available
3. Develop Target Architecture description — develop the view of required building blocks through the creation of catalogs, matrices, and diagrams:
   • Fully document each building block
   • Document rationale for building block decisions in the architecture document
   • Identify the impacted building blocks, checking against a library of building blocks within the Architecture Repository and re-using where appropriate
   • Where necessary, define new building blocks
   • Select standards for each building block, re-using as much as possible from reference models selected from the Architecture Continuum
   • Document the final mapping of the building blocks to the Architecture Landscape
   • From selected building blocks, identify those that might be re-used, and publish as standards or reference models via the Architecture Repository
4. Perform gap analysis — identify building blocks carried over, eliminated, and new; identify gaps and determine realization approach (to be developed or to be procured)

In Phase E, building blocks are associated with work packages that will address the gaps.

7.3 Deliverables created and consumed in the ADM phases LO 7.3 S4 §4.2

The TOGAF Standard defines a set of suggested deliverables consumed and produced across the ADM cycle. The set is intended to provide a typical baseline of architecture deliverables in order to better define the activities required in the ADM and to act as a starting point for tailoring within a specific organization. Other deliverables may be produced elsewhere and consumed by the ADM.

The master table — key deliverables by ADM phase highest-yield table in Unit 7

The sixteen deliverables — purpose and typical contents

What goes into the Architecture Definition Document, by domain

What populates the Architecture Requirements Specification, by domain

The determination of interoperability is present throughout the ADM cycle; a set of guidelines for defining and establishing interoperability requirements is provided in the ADM Techniques document.

M1 · Memory vault & mnemonics

Every item on this page is something the exam asks you to recall. Drill until each comes back in under five seconds.

The numbered lists, all in one place

The phase-anchor sheet — "which phase?" answered at a glance

Verb-pattern shortcuts

Definition one-liners you must be able to complete

M2 · Trap list & look-alikes

Every row is a place where two TOGAF concepts are deliberately confusable. This is where marks leak. Learn to say both sides of the discriminator.

M3 · Flashcards

— cards across all seven units plus exam mechanics. Tap the card (or press Space) to flip; ← / → to move.

F1 · All 63 learning outcomes, with the answer ★ complete coverage

The official Level 1 syllabus in full — every learning outcome from Appendix D of the Study Guide, with the answer you must be able to give. If you can work down this table without hesitating, you know everything the exam can ask.

Unit 1 · Concepts 8 questions → full unit

Unit 2 · Definitions Examined indirectly → full unit

Unit 3 · Introduction to the ADM 14 questions → full unit

Unit 4 · Introduction to ADM Techniques 6 questions → full unit

Unit 5 · Introduction to Applying the ADM 4 questions → full unit

Unit 6 · Introduction to Architecture Governance 3 questions → full unit

Unit 7 · Architecture Content 5 questions → full unit

Unit 8 · TOGAF Certification Program No dedicated allocation → full unit

F2 · One-page cheat sheet

Read this on the morning of the exam. Nothing else.

F3 · Rapid recall drill

Cover-the-answer practice. Hide the answers, work down the list saying each one out loud, then tap a row to check it — or show everything again when you are done. 115 prompts covering every examinable fact.

F4 · Every number in the syllabus

If a question turns on a count, it is in this table. Numbers are the easiest thing to make a distractor out of, so they are worth ten minutes on their own.

F5 · Study plan checklist

Tick items off — progress is saved in this browser. A realistic path is 12–16 hours of focused study.

Session 1 — Orientation & Concepts ~3 h

Session 2 — The ADM ~4 h · the big one

Session 3 — Techniques, Applying, Governance, Content ~4 h

Session 4 — Consolidation ~3 h

Session 5 — Final pass ~2 h, day before

F6 · Sources & caveats

Every substantive claim in this compendium traces to one of these. Section-level pointers appear inline as S1 §3.1-style tags.

Primary — the Body of Knowledge for OGEA-101

Series Guides referenced by the syllabus

Exam logistics

• The Open Group — TOGAF® Examinations datasheet (© 2023–2025) — the authority for exam number, item count, time limit, pass mark, open/closed book, prerequisites and delivery.
• The Open Group Help Centre — exam plan for OGEA-101.
• Topic weighting (8 / 14 / 6 / 4 / 3 / 5) is from B230 §1.4.