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 the 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.

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

It links up with the certifications. Certifications like TOGAF Certified objectively evaluate architects’ capabilities. Usable for hiring / placement decisions too.

The main frameworks

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

TOGAF is the one to know first.

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

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

The Zachman Framework comes at the same problem from a different angle.

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).”

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

ArchiMate is the modelling notation rather than a method.

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

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

FEAF and DoDAF are the public-sector and defence lineage.

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

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

BIAN is the industry-specialised example.

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

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

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.

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.

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

The reality of using a framework, and agile EA

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

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

Agile EA is where that reality has landed.

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.

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

Choosing by scale and industry

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

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

The first axis is the maturity of the organisation.

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

The second is the regulatory requirements.

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

By case, the choice lands like this.

Introducing EA for the first time, at a 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.

A mid-size enterprise with an EA function. 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 and banking. 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 and defence. 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.

A phased roadmap for using an EA framework

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

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.

AI decision axes — Make it machine-readable with EA as Code

ArchiMate models for AI impact analysis

ArchiMate models can be exported in structured formats (XML/JSON), enabling queries like “analyze the blast radius if we decommission this system” via AI. PowerPoint diagrams don’t convey structure to AI, forcing manual impact tracing one dependency at a time.

EA as Code with Git management

The movement of managing EA models as PlantUML, Structurizr, or ArchiMate XML in Git with PR-based reviews — “EA as Code” — is spreading. This makes EA model change history trackable, and opens the door to AI analyzing model diffs and auto-generating impact reports. 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.

Pitfalls and forbidden moves

Here are the six most dangerous of the typical ways operating an EA framework goes wrong. Every one of them is the pattern where the diagrams get drawn and are never used in a decision.

Dismissing EA as “an old method” is a mistake too. Classical EA is out of date, but it has been reborn as agile EA, and in the AI era the need for it has gone up rather than down.

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.

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)

Related Articles

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.