EA Frameworks - Tailor TOGAF + ArchiMate to Use

About this article

As the sixth installment (final) of the “Enterprise Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains EA frameworks.

Frameworks are not used as is - the iron rule is tailoring to your company, with companies “fully applying TOGAF” being a minority. This article covers comparisons of TOGAF/Zachman/FEAF/DoDAF, TOGAF ADM Phase A-H, the realistic answer of narrowing to Phase A-B-D, and operations not ending as picture exhibitions.

What is an EA framework in the first place

Think of a recipe book for cooking. An experienced chef’s procedures and measurements, refined over decades, are systematically compiled. Rather than reinventing everything from scratch through trial and error, borrowing predecessors’ wisdom is overwhelmingly more efficient.

EA frameworks (TOGAF, Zachman, etc.) are sets of procedures, glossaries, and output templates for designing enterprise-wide IT strategy. They’re packed with decades of practical knowledge, and you customize (Tailor) them to fit your company.

If you proceed with EA without a framework, you end up starting from term definitions, and discussions spin in circles without a common language among stakeholders.

Why EA frameworks are needed

Building methodology from scratch breaks down

EA’s scope is too wide to proceed empirically. Borrowing predecessors’ wisdom is more efficient, with existing frameworks packed with decades of practical knowledge.

Standardizing terminology and outputs

Even saying “architecture document” among stakeholders, meanings vary. Having common terminology and output names efficiently scales discussions.

Linkage with certifications

Certifications like TOGAF Certified objectively evaluate architects’ capabilities. Usable for hiring / placement decisions too.

Main framework list

Multiple EA frameworks exist, with different uses and emphases. No need to narrow to one - selecting from multiple is the modern usage.

Framework	Characteristics	Position
TOGAF	Methodology-centric, most adopted	Industry standard
Zachman Framework	Taxonomic, classic	For thought organization
FEAF	For US federal government	Used in government systems
DoDAF	For US Department of Defense	Military, aerospace
ArchiMate	Modeling language	Standard for diagrams
BIAN	Banking-industry-specialized	Financial industry

TOGAF

Acronym for The Open Group Architecture Framework, the de facto industry standard. First published in 1995, with TOGAF 10 (released 2022) the latest. ADM (Architecture Development Method), the phased approach, is the core.

TOGAF major elements	Content
ADM (methodology)	Proceed EA in 8 phases
Architecture Content Framework	Output definitions
Enterprise Continuum	Reference-model collection
Reference Models	Industry-specific templates
Capability Framework	Org capability definitions

There are TOGAF certifications (Foundation / Certified) - the standard certification for EA roles, recognized worldwide.

ADM (Architecture Development Method)

The core of TOGAF, the 8 phases proceeding EA in stages. The design philosophy is iterating Phase A → H, continuously maturing EA.

flowchart TB
    PRE[Preliminary<br/>preparation, principles]
    A[A. Architecture Vision<br/>target image]
    B[B. Business<br/>BA design]
    C[C. Information Systems<br/>DA/AA design]
    D[D. Technology<br/>TA design]
    E[E. Opportunities<br/>implementation opportunities]
    F[F. Migration<br/>migration plan]
    G[G. Implementation<br/>implementation governance]
    H[H. Change Management<br/>change management]
    REQ((Requirements management<br/>central))
    PRE --> A --> B --> C --> D --> E --> F --> G --> H
    H -.iterate.-> A
    REQ -.- A
    REQ -.- B
    REQ -.- C
    REQ -.- D
    REQ -.- E
    REQ -.- F
    REQ -.- G
    REQ -.- H
    classDef pre fill:#fef3c7,stroke:#d97706;
    classDef phase fill:#dbeafe,stroke:#2563eb;
    classDef req fill:#fae8ff,stroke:#a21caf,stroke-width:2px;
    class PRE pre;
    class A,B,C,D,E,F,G,H phase;
    class REQ req;

What to grasp here is that ADM is not waterfall passing through once top to bottom. With phase names lined up in order, easily misunderstood as “process going through A to H in order,” but the reality is an iterative approach moving back and forth between phases. Returning to fix vision (Phase A) when flaws are found in Phase B (BA), redrawing Phase C (DA/AA) from constraints visible in Phase D (TA) - such round-trips are built into the premise. In practice, no need to do all Phase A-H from the start - the practical pattern of starting from a specific phase is also general. For existing-system cloud migration, start from Phase D (TA); for business reform, enter from Phase B (BA) - choosing the entry per challenge is the key to actually running TOGAF.

Phase	Content
Preliminary	Preparation, principles
A. Architecture Vision	Target image, scope setting
B. Business Architecture	BA design
C. Information Systems	DA / AA design
D. Technology Architecture	TA design
E. Opportunities & Solutions	Identify implementation opportunities
F. Migration Planning	Migration plan
G. Implementation Governance	Implementation control
H. Architecture Change Management	Change management

“Starting from Phase B” is also possible, with flexibility to adapt per situation.

Zachman Framework

A taxonomic-approach framework. Proposed by John Zachman in 1987, drawing a 6x6 matrix crossing “6 questions (What/How/Where/Who/When/Why)” with “6 perspectives (executive / manager / designer / developer / implementer / user).”

Axis	Content
What	Data
How	Function
Where	Location
Who	People, organization
When	Time, process
Why	Purpose, strategy

Not a methodology but a taxonomy, used as a thinking tool for organizing EA’s whole picture. Co-usable with TOGAF.

ArchiMate

The modeling language for drawing EA as diagrams, formulated by The Open Group. Fully aligned with TOGAF, widely used as the standard EA notation.

Layer	Content
Strategy	Strategy, goals
Business	Business processes, services
Application	Apps, components
Technology	Physical foundation
Physical	Equipment, facilities
Implementation & Migration	Migration plans

Tools: Archi (OSS), BiZZdesign Horizzon (commercial), Sparx EA. Drawing tools are abundant, getting diagram consistency.

FEAF / DoDAF

Frameworks for US government. Less used in Japan, but useful when handling government systems / military-related, for reference.

Framework	Use
FEAF	US federal government agencies
DoDAF	US Department of Defense
MODAF	UK Ministry of Defence
TEAF	US Department of the Treasury

Built-in security and interoperability requirements are the feature, with applicable know-how for large-scale-org EA.

BIAN (industry-specialized)

The framework specialized for banking. Acronym for Banking Industry Architecture Network, providing reference models standardizing banking business capabilities.

Provided	Content
Service Landscape	Map of banking-business services
Business Capabilities	300+ standard capabilities
Reference Scenarios	Business scenarios
API Standards	Banking API standards

Beyond financial industry, industry-specialized frameworks (insurance, telecom, medical, etc.) exist, leveraging accumulated industry knowledge.

Framework selection

Which framework to use is decided by purpose, industry, org maturity. Realistic to combine multiple, not single selection.

Purpose	Recommended
First EA	TOGAF Lite
Organize whole picture	Zachman thinking tool
Diagram / visualize	ArchiMate
Industry-standard utilization	Industry-specialized like BIAN
Government	FEAF / DoDAF

“Base on TOGAF, draw with ArchiMate” is a frequent pattern.

Reality of framework utilization

Frameworks aren’t omnipotent - pitfalls are also many. “Perfectly running all TOGAF phases” leading to no progress in 3 years is a typical failure.

Pitfall	Countermeasure
Framework fundamentalism	Select / Tailor
Output creation as goal	Use for decisions
Field divergence	Practice per project
Learning cost	Common minimum via TOGAF certification
Outdated	Combine with agile EA

Creating outputs themselves isn’t value - value emerges only when used in decisions.

Agile EA

Traditional EA is plan-focused with large-scale design but can’t keep up with modern change speed. The thinking of proceeding EA agile-style is spreading.

Traditional EA	Agile EA
3-year plan	Quarterly review
Perfect model	Sufficient model
Top-down	Collaborate with each team
Output-focused	Decision-focused
Centralized	Distributed, community

Operations combining with SAFe (Scaled Agile Framework) or Team Topologies are increasing.

Decision criterion 1: org maturity

Approach varies with org maturity introducing EA. Inexperienced - simple; mature - full-fledged.

Maturity	Recommended
EA inexperienced	Learn TOGAF Foundation
Initial introduction	TOGAF Lite + ArchiMate
Years of operation	Full TOGAF + industry-specialized
Global large enterprise	Custom + multiple frameworks

Decision criterion 2: regulatory requirements

For strictly-regulated industries like government / finance / medical, certifications may be demanded.

Industry	Possibly demanded
Government projects	TOGAF Certified
Finance	BIAN, industry standards
US military-related	DoDAF
Medical	HL7 (medical-info exchange standard), HIMSS (medical-info-management maturity assessment)

How to choose by case

EA first introduction / small enterprise

TOGAF Foundation learning + Archi (OSS) for ArchiMate diagrams. Use Zachman just for thought organization, don’t run all ADM phases - narrow to Phase A-B-D. 1-2 architects part-time, quarterly review enough.

Mid-size enterprise / has EA org

TOGAF ADM-based + ArchiMate + Confluence / Sparx EA + agile EA. Dedicated 3-5 EA, tailored template ops, link with Technology Radar, combine with SAFe / Team Topologies. Recommend TOGAF Certified acquisition.

Finance / banking industry

TOGAF + BIAN + ArchiMate + FISC-compliant. Build company’s own capabilities based on BIAN Service Landscape, regime auto-generating regulator-explanation materials. API standards also BIAN-compliant.

Government / defense

DoDAF / FEAF + security-requirement integration. Military-related requires DoDAF views (OV / SV / TV), incorporating interoperability and confidentiality classifications into models. TOGAF Certified + domestic certifications (IPA etc.) often demanded.

Phased EA-framework-utilization roadmap

The iron rule for frameworks is phased introduction. Suddenly applying everything breaks down.

Phase	Period	Utilization scope	Investment people
1. Learning	3-6 months	Acquire TOGAF Foundation, understand Zachman	1-2
2. Lite introduction	6-12 months	Only TOGAF Phase A-D, ArchiMate drawing	EA 1-2
3. Periodic operation	1-2 years	All TOGAF ADM phases + quarterly review	EA team 3-5
4. Industry-specialized	2 years+	Co-use industry FW like BIAN / DoDAF	Dedicated EA org
5. EA as Code	Continuous	ArchiMate + Git + API publication, AI integration	Under CTO

The realistic Tailoring is narrowing to “only Phase A-B-D.” The case of a year and half stuck in Phase B is typical failure - “TOGAF full application” doesn’t reach the field even after 3 years.

Use frameworks as entry, not procedure manual. Without Tailoring, you definitely exhaust.

EA-framework-operation pitfalls and forbidden moves

Typical accidents in EA-framework operation. All are patterns of drawing and done, not used in decisions.

Forbidden move	Why it’s bad
Fully apply TOGAF ADM Phase A through H	A year and half stuck in Phase B, 300-page capability map leaves field behind
Use frameworks as procedure manuals	Fundamentalist rigidity, miss transformation opportunities
Just draw ArchiMate without using in decisions	Diagrams are means, zero value if not used in decisions
Operate in PowerPoint EA	AI-unparseable, leaving in machine-readable form is modern
Not utilize industry-specialized FW (BIAN etc.) and start from scratch	Ignoring industry-knowledge accumulation, reinventing the wheel
Try to solve everything with TOGAF only	Per-purpose combination of TOGAF + ArchiMate + industry-specialized is modern
Lock plans in 3-year fix unchangeable	Can’t follow business changes, era of agile EA
Output creation as KPI	300-page docs read by no one
Central EA diverged from field projects	EA becomes ivory tower, ignored by field
Believe in “applying TOGAF perfectly”	Full application is unrealistic; Tailoring for your company is the correct usage
Think “drawing ArchiMate is EA”	Diagrams are means; value emerges only when used in decisions — just drawing is meaningless
Dismiss “EA is an old method”	Classical EA is outdated but reborn as agile EA; necessity is rising
Insist “one framework is enough”	Per-purpose multiple combinations is modern; TOGAF + ArchiMate + industry-specialized is standard

Spotify’s agile EA (Tribe / Squad / Chapter / Guild model, later spread worldwide as “Spotify Model”) is a success case maintaining alignment of hundreds of teams not via centralized perfect models but with “sufficient models”. A contrasting lesson with the Japan major-SIer’s TOGAF-full-application 1.5-year Phase-B-stagnation case.

Frameworks are maps, but you walk. Start walking with sufficient maps, not perfect maps.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Major framework (TOGAF / Zachman etc.)
• Modeling notation (ArchiMate etc.)
• Application scope (Tailoring contents)
• Industry-specialized framework (BIAN etc. utilization)
• Tool selection (Archi / Sparx EA etc.)
• Certification / education (TOGAF Foundation etc.)
• Operational cycle (quarterly / annual)

Author’s note - cases of orgs exhausted by “framework fundamentalism”

Orgs failing by treating EA frameworks as procedure manuals recur in the industry.

In a Japanese major SIer, after setting the policy of fully applying TOGAF ADM from Phase A to H for a large customer project, they spent a year and half just on Phase B (BA), creating nearly a 300-page capability map, with the field distancing themselves saying “EA is the diagram-drawing dept,” and ultimately the project was frozen. After re-tailoring to “enter from Phase D (TA), scope only cloud migration,” concrete migration plans came out in half a year, recovering org trust - the story is continuously told as a lesson in EA circles.

In contrast, Spotify’s agile EA is often cited as a success case. Spotify operated EA with agile thinking from the start, creating the distributed-architecture-org model “Tribe / Squad / Chapter / Guild” (later spread worldwide as “Spotify Model”). Not a centralized perfect model but operations of “sufficient models” where each Squad autonomously decides architecture, with Chapter loosely coordinating company-wide standards - balancing high-speed development while maintaining alignment of hundreds of teams.

Both show that “using frameworks as entry, not procedure manuals” is the biggest key to not killing EA. Not drawing perfect maps but starting to walk with sufficient maps is the correct answer.

How to choose

The core of EA frameworks is the thinking of not using as is, Tailoring to your company. Perfectly applying all TOGAF phases yet making no progress in 3 years is a typical failure. Predecessors’ decades of practical knowledge for efficiency, with selection like narrowing to Phase A-B-D, is the realistic answer. The combination of TOGAF + ArchiMate + industry-specialized (BIAN etc.) is the modern standard, with single-framework fundamentalism outdated. Creating outputs themselves isn’t value — value emerges when used in decisions — this is the iron rule of framework utilization.

AI-era decision axes

When AI-driven dev (vibe coding) and AI usage are the premise, EA frameworks are re-evaluated as structured architecture descriptions AI can understand. Formalized models like ArchiMate are easy to analyze / generate / convert with LLMs (Large Language Models).

Favored in the AI era	Disfavored in the AI era
Formalized models like ArchiMate	PowerPoint hand-drawn diagrams
Code-ized EA	Paper documents
Git-managed models	Personal Excel
API-referenceable	Shared via files

In the era of “AI reading EA, analyzing / proposing,” framework-compliant formalized models become AI-era competitiveness. The movement of EA as Code (code-izing EA) is starting.

Another decisive axis is the demand for making it machine-readable via EA as Code. In the era when AI reads EA and does impact analysis / proposals, PowerPoint hand-drawn diagrams and personal Excel get eliminated. Only companies Git-managing formalized models like ArchiMate and keeping in API-referenceable state can leverage AI-era EA. The transition from traditional EA’s plan-focused to agile EA (quarterly review, per-team collaboration) also progresses in parallel.

AI-era EA leaves in machine-readable form. PowerPoint EA gets eliminated.

Selection priorities

1. TOGAF + ArchiMate as axes - industry standard, certifications, abundant drawing tools
2. Tailor and select - don’t fully apply, narrow to Phase A-B-D, fundamentalism forbidden
3. Co-use industry-specialized FW - BIAN (finance), DoDAF (government), leverage industry knowledge
4. Machine-readable, Git-managed, agile-ized - EA as Code, quarterly review, AI-readable form

“TOGAF + ArchiMate Tailored, Git-managed and machine-readable.” PowerPoint EA gets eliminated.

Summary

This article covered EA frameworks, including TOGAF, Zachman, ArchiMate, BIAN, FEAF/DoDAF, ADM Tailoring, agile EA, and EA as Code.

Anchor on TOGAF + ArchiMate, Tailor and select, co-use industry-specialized FW, Git-manage in machine-readable form. That is the practical answer for EA-framework utilization in 2026.

And this was the final installment of the “Enterprise Architecture” category. Next time we’ll start a new category (Solution Architecture).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.