TOGAF, Enterprise Architecture, and the Data Foundation for AI

Enterprise architecture is back, for a narrower reason

For a decade, enterprise architecture had a reputation problem. Architecture teams produced large repositories of current-state diagrams, review boards slowed delivery, and agile teams learned to route around them. Many organizations quietly shrank the function.

AI is reversing that, but not because AI needs more diagrams. It needs answers to questions that only an architecture view can give: which business capabilities AI should change first, which data those capabilities depend on, who owns that data, which platforms and models are approved, and why a given decision was made. When those answers are missing, each AI team rebuilds pipelines, buys its own tools and makes the same residency and security decisions again. Our operating model article describes the organizational side of that problem. This article covers the architecture side.

The argument here is simple. For AI, the value of enterprise architecture lies in a small number of living artifacts, not in adopting a framework end to end. TOGAF is the most useful source of those artifacts, and in Saudi Arabia a recognized framework is a documented requirement. But the organizations that get value from it use TOGAF as a toolkit to draw from, not a process to complete.

What TOGAF is in 2026

The current version is the TOGAF Standard, 10th Edition, released by The Open Group on 25 April 2022. Its main change was structural. The standard is now split into two parts:

• Fundamental Content: the core concepts, the Architecture Development Method (ADM), ADM techniques, guidance on applying the ADM, the architecture content framework, and enterprise architecture capability and governance.
• Series Guides: separately published guides on specific topics, many of which were previously inside the standard itself.

The split matters for data and AI work. The Fundamental Content changes slowly; the Series Guides carry most of the practical, topic-specific material. The Open Group's catalog includes guides on business capabilities, value streams, information mapping, metadata management, business intelligence and analytics, customer master data management, agile sprints and digital technology adoption. As of 11 August 2026, the published Series Guides list does not include a dedicated guide on artificial intelligence, so AI practices have to be assembled from the existing material.

TOGAF is a method. The other framework most often cited alongside it, the Zachman Framework, first published by John Zachman in the IBM Systems Journal in 1987, is a classification scheme: a matrix of six questions (what, how, where, who, when, why) against six stakeholder perspectives. Zachman helps you check that nothing is missing. TOGAF helps you decide what to do next. Most practices that use either borrow from both.

Why AI raises the stakes for architecture

Three features of AI workloads make architecture decisions harder to postpone.

AI consumes data across boundaries. A customer-service assistant may need product data, policy documents, order history and call transcripts, each owned by a different team and held on a different platform. Without an enterprise view of where data lives and who owns it, each AI use case negotiates access from scratch.

AI decisions are hard to reverse. Choosing an embedding model, a vector store, a model provider or a cloud region for inference creates dependencies that accumulate quietly. Re-embedding a large document estate or moving inference to a different region is a project in its own right.

AI governance assumes an inventory. NIST's AI Risk Management Framework asks organizations to maintain mechanisms to inventory AI systems (GOVERN 1.6), and ISO/IEC 42001, published in December 2023, defines a management system for AI that presupposes you know which AI systems you run. An AI inventory is, in architecture terms, an application portfolio with extra attributes: models, training and retrieval data, owners, risk tier. Architecture teams that already maintain a portfolio are best placed to own it.

None of these require a full ADM cycle. They require a few artifacts that are current, owned and used in real decisions.

The minimum viable architecture for AI

INVISOM's view is that five artifacts carry most of the value. Each maps to TOGAF content, and each can be produced in weeks, not quarters.

1. A business capability map with data and AI overlays. A capability map lists what the business does (for example, "assess credit risk" or "resolve customer complaints"), independent of how it is organized or which systems support it. TOGAF's Series Guide on business capabilities covers how to build one. For AI, overlay three things on each capability: its strategic importance, the data domains it depends on, and the quality and ownership of that data. Use cases that sit on high-value capabilities with well-owned data are the ones to fund first, which is the same logic our use-case selection framework applies from the business side.

2. Architecture principles that can fail a design. Principles in TOGAF follow a four-part form: a name, a statement, a rationale and implications. The implications are what make a principle useful, because they say what a team must do differently. Most organizations have principles such as "data is an asset". Few have principles specific enough to reject a design. The next section shows the difference.

3. A data architecture view. A conceptual model of key business entities, the systems of record for each, the target platform pattern and where data products and metadata live. This is TOGAF Phase C territory. In Saudi Arabia it is also what the NDMO standards require, as covered below.

4. An AI and data platform portfolio. The approved models, platforms, vector stores and integration patterns, each with a lifecycle status (adopt, trial, contain, retire) and an owner. This doubles as the AI system inventory that governance frameworks expect.

5. Architecture decision records. Short documents that capture each significant decision, its context and its consequences. They are the single most effective addition most architecture teams can make, and they are covered in detail below.

Principles that change decisions

The test of a principle is whether a reasonable team could violate it, and whether a review would catch that. Generic principles fail both tests.

A strong set for data and AI is usually short, between six and ten principles, and each one carries a measurable implication. Examples INVISOM recommends as a starting point:

• One owner per dataset. Every dataset used by an AI system has a named business owner and a system of record. AI systems read from governed sources; they do not create shadow copies without registration.
• Definitions before models. Metrics and business terms used in AI outputs come from the governed glossary or semantic layer, not from prompts or application code.
• Retrieval before fine-tuning. Enterprise knowledge reaches models through governed retrieval by default; changing model weights requires a documented case. Our RAG versus fine-tuning comparison sets out when the exception is justified.
• Classification travels with data. Data classification and residency constraints are attached to data as metadata and enforced at the point an AI service reads it, including for inference processed outside the primary region.
• Portable by default. New analytical data is stored in open table formats; model access goes through an internal gateway so that model providers can be swapped without changing applications.

Each of these can be checked in a design review. That is the bar.

Decision records: the cheapest high-value practice

An architecture decision record (ADR) is a short document that records one significant decision. Michael Nygard proposed the format in 2011: a title, the context and forces at play, the decision itself, its status (proposed, accepted, deprecated or superseded) and its consequences, good and bad. Records are numbered, kept in version control alongside the work, and never deleted; a reversed decision is superseded by a new record.

The practice has moved well beyond software teams. In November 2025 the UK Government Digital Service published an Architectural Decision Record framework for use across the UK public sector, with a template and guidance on when a decision should be escalated beyond the team that made it. The aim, in GDS's framing, is better-documented decisions, less duplication and more joined-up delivery.

For AI, decision records solve a specific problem. Many AI choices look tactical when they are made and strategic two years later: the embedding model, the chunking strategy, the inference region, the decision to accept a vendor's cross-region processing. An ADR forces the team to write down the alternatives and the consequences while they are fresh, and it gives the next team a reason not to reopen the question, or a clear basis for reopening it.

Three practical rules keep ADRs useful. Write them for decisions that would be expensive to reverse, not for every choice. Keep each one to a page. And make the architecture review board's job to read ADRs rather than to approve designs; escalate only the decisions that cross a principle or affect more than one domain.

The Gulf view: NDMO makes the framework mandatory

In Saudi Arabia, enterprise architecture is not optional for entities subject to the National Data Management Office standards. Specification DAM.2.1 of the NDMO Data Management and Personal Data Protection Standards requires each entity to document and publish a Data Architecture and Modeling Policy. Among its minimum requirements: the target data architecture must address the entity's data management strategy, must be developed together with the entity's overall enterprise architecture, and must adopt a widely used enterprise architecture framework, with TOGAF and Zachman given as examples. It is a priority 1 specification.

The following control, DAM.3, requires entities to define current and target data architectures and the gap between them, starting from conceptual, logical and physical data models. The domain's reference list cites the TOGAF Standard, Version 9.2, the edition current when the standards were first issued in 2020.

Two practical points follow:

• Adopting TOGAF 10 satisfies the intent. The specification asks for a widely used framework, not a specific edition. Entities building a practice now should use the current standard and record that choice, with the rationale, in their data architecture policy.
• The artifacts above double as compliance evidence. A capability map with data overlays, a current and target data architecture, principles and a decision log are exactly what an NDMO assessment looks for in this domain. Building them once, for delivery, avoids a separate compliance exercise. Our NDMO implementation guide covers the wider standards and how to evidence them.

Making it lightweight

The failure mode of enterprise architecture is not too little documentation but too much that nobody uses. A few operating choices keep the practice light:

The aim is to make the architecture practice the fastest route to an approved design, not an extra gate. When the platform team builds the principles into templates (an approved retrieval pattern, a model gateway, default classification tags), teams comply by using the platform rather than by reading a standard.

What to do in the next 90 days

1. Pick one capability map, not a full repository. Map business capabilities at two levels and overlay data domains, data owners and AI opportunity for the areas where AI demand is highest.
2. Rewrite your principles to fail designs. Keep six to ten, each with a statement, rationale and at least one checkable implication for data and AI.
3. Start an ADR log this month. Backfill the five most consequential AI and data decisions already made, including model providers, inference regions and vector stores.
4. Merge the AI inventory into the application portfolio. Add model, data source, owner and risk-tier attributes rather than creating a separate register.
5. Change the review board's mandate from approving designs to reviewing escalated ADRs and principle exceptions.
6. In Saudi Arabia, map these artifacts to DAM.2 and DAM.3 and record TOGAF 10 as the adopted framework in the data architecture policy.

Frequently asked questions

Do we need TOGAF certification to use TOGAF for AI?

No. Certification helps build a common vocabulary in the architecture team, but value comes from using a few artifacts consistently: a capability map, enforceable principles, a data architecture view, a platform portfolio and decision records.

What is the current version of TOGAF?

The TOGAF Standard, 10th Edition, released by The Open Group in April 2022. It is split into Fundamental Content, which includes the Architecture Development Method, and separately published Series Guides on specific topics.

Does TOGAF have specific guidance on AI?

As of August 2026, The Open Group's published Series Guides do not include a dedicated AI guide. Guides on business capabilities, information architecture, metadata management, analytics and digital technology adoption provide most of the relevant material.

Is an enterprise architecture framework required in Saudi Arabia?

For entities subject to the NDMO standards, yes. Specification DAM.2.1 requires the target data architecture to adopt a widely used enterprise architecture framework, giving TOGAF and Zachman as examples, and to be developed with the entity's overall enterprise architecture.

Sources and further reading

• The Open Group Announces Launch of the TOGAF Standard, 10th Edition, The Open Group, 25 April 2022.
• The TOGAF Standard and TOGAF Series Guides, The Open Group.
• Data Management and Personal Data Protection Standards, v1.5, NDMO, SDAIA (DAM.2.1, DAM.3).
• Documenting Architecture Decisions, Michael Nygard, 15 November 2011.
• Architectural Decision Record framework, Government Digital Service, 4 November 2025.
• NIST AI RMF Playbook: Govern, NIST.
• ISO/IEC 42001 explained, ISO.
• Zachman Framework, background reference.