12 — Enterprise Architecture Frameworks — TOGAF, UML, IAF, BABOK

TOGAF, UML, IAF, BABOK — the framework cluster read as bureaucracy until I saw what they actually are. The model that made them make sense: they're shared languages for documenting and governing architecture at an organizational level, not technologies, and their value scales with how formally structured the enterprise is [1]. They're distinct from software development frameworks (Spring, React, .NET); they don't run code, they structure how architecture is described and decided. In a small startup they're overhead; in a large regulated enterprise they're the reason thousands of people can coordinate.

The roadmap frames this section as covering frameworks and methodologies used specifically for enterprise architecture modeling and business analysis, providing structured approaches for documenting and communicating architecture [1]. Familiarity matters most for architects in large, formally structured enterprises.

TOGAF: the enterprise-architecture process

TOGAF (The Open Group Architecture Framework) is one of the most widely used frameworks for developing and managing enterprise architecture [2]. Its centerpiece is the Architecture Development Method (ADM) — a structured, repeatable process for creating and maintaining architecture that aligns with business goals. Large organizations adopt TOGAF to bring consistency to how architecture decisions are made and documented across teams. The value isn't a specific output; it's a shared process so that two architects in different divisions produce comparable work. If you've ever been handed a "TOGAF-compliant" architecture document and recognized the structure, that's the point.

UML: the visual modeling language

The Unified Modeling Language (UML) is a standardized set of diagram types for visualizing a system's design — class diagrams, sequence diagrams, use-case diagrams, and so on [3]. It gives architects and developers a common visual language for describing structure and behavior before or during implementation. Not every team uses UML formally, but understanding its notation helps when reading architecture documentation [3]. The practical reality: full UML is rarely maintained end-to-end, but a class or sequence diagram in UML notation is still the lingua franca of architecture reviews. Knowing how to read one is more valuable than knowing how to produce a complete set.

IAF: cross-domain modeling

The Integrated Architecture Framework (IAF) is a methodology for enterprise architecture that structures architecture work across business, information, and technology domains [4]. It provides a consistent way to model how different aspects of an organization's architecture relate to each other. Architects use IAF in organizations that require formal architecture governance — the kind of place where an architecture decision needs to trace back through business, information, and technology layers before it's approved. IAF is rarer than TOGAF day-to-day, but it shows up in consultancies and large enterprises with mature governance.

BABOK: business analysis body of knowledge

The BABOK Guide (A Guide to the Business Analysis Body of Knowledge), from the International Institute of Business Analysis, provides business analysts with strategies for using data to improve an organization's workflow processes, technology, products, and services [5]. It sits adjacent to architecture — where the architect owns the technical design, the business analyst owns the requirements and process analysis that feed it. An architect working in a formal enterprise needs to speak BABOK's vocabulary because the requirements arriving at the architecture stage will be framed in it. Understanding BABOK is mostly about interoperability with the analysis side of the project.

The single thread

What connects TOGAF, UML, IAF, and BABOK is that none of them run in production. They're communication and governance tools — shared languages that let large numbers of people describe, debate, and approve architecture in a consistent way. Their cost is the ceremony of learning and applying them; their payoff is coordination at scale. Below a certain org size, that payoff doesn't exceed the cost, and a lighter approach (a few well-drawn diagrams and a decision log) is better. Above it, the absence of a shared framework is chaos — every team invents its own notation and its own process, and integration becomes impossible.

How I use this

I calibrate the weight of these frameworks to the organization. In small teams, I use UML notation informally (a sequence diagram in a design doc) and skip TOGAF/IAF/BABOK entirely. In a large enterprise, I learn whichever framework the org has standardized on, because interoperating with existing governance is faster than fighting it. The test for adopting any of them is whether the scale of coordination actually requires a shared language — if three people can fit in a room and agree, a framework is overhead; if three hundred can't, it's infrastructure.

References

[1] "Architect Frameworks," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/frameworks

[2] "TOGAF," The Open Group. [Online]. Available: https://www.opengroup.org/togaf

[3] "Unified Modeling Language," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Unified_Modeling_Language

[4] "Integrated Architecture Framework," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Integrated_Architecture_Framework

[5] "A Guide to the Business Analysis Body of Knowledge," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/A_Guide_to_the_Business_Analysis_Body_of_Knowledge