--- title: "12 — Enterprise Architecture Frameworks — TOGAF, UML, IAF, BABOK" uid: enterprise-architecture-frameworks tags: ["togaf", "frameworks", "roadmap:software-architect", "uml", "enterprise-architecture", "iaf", "babok"] excerpt: "TOGAF, UML, IAF, BABOK are shared languages for documenting and governing architecture — not technologies. Their value scales with how formal the organization is." date: 2026-08-13T03:27:40+0000 source: https://www.aveshina.my.id/en/blog/enterprise-architecture-frameworks --- 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. ```figure TOGAF a structured process (ADM) for developing and managing enterprise architecture value = shared, repeatable process across teams UML standardized visual modeling language class, sequence, use-case diagrams value = common notation for design reviews IAF modeling across business, information, and technology domains value = formal governance traceability BABOK business analysis body of knowledge requirements and process analysis value = shared vocab with the analysis side ``` ## 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](https://roadmap.sh/software-architect/frameworks) [2] "TOGAF," The Open Group. [Online]. Available: [https://www.opengroup.org/togaf](https://www.opengroup.org/togaf) [3] "Unified Modeling Language," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Unified_Modeling_Language](https://en.wikipedia.org/wiki/Unified_Modeling_Language) [4] "Integrated Architecture Framework," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Integrated_Architecture_Framework](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](https://en.wikipedia.org/wiki/A_Guide_to_the_Business_Analysis_Body_of_Knowledge) ```quiz Q: What do TOGAF, UML, IAF, and BABOK have in common? - They are runtime technologies that execute in production - They are shared languages for documenting and governing architecture, not technologies correct: 1 explain: None of these run in production. They are communication and governance frameworks — shared languages that let large organizations describe, debate, and approve architecture consistently. Q: TOGAF's centerpiece is the ADM. What does ADM provide? - A specific software product for drawing diagrams - A structured, repeatable process for creating and maintaining enterprise architecture aligned to business goals correct: 1 explain: The Architecture Development Method (ADM) is TOGAF's repeatable process. Its value is that two architects in different divisions produce comparable, consistent work. Q: In a small team of five people, the right approach to these frameworks is usually… - adopt all four fully for maximum rigor - use UML notation informally and skip the heavier governance frameworks correct: 1 explain: Below a certain org size, the coordination payoff doesn't exceed the ceremony. A few well-drawn diagrams and a decision log beat formal TOGAF/IAF/BABOK adoption for small teams. Q: Why would an architect learn BABOK even though it's a business-analysis framework? - Because requirements arriving at the architecture stage are framed in BABOK vocabulary, and interoperating is faster than fighting it - Because BABOK is required to deploy any production software correct: 0 explain: BABOK sits adjacent to architecture — the business analyst owns requirements and process analysis. An architect in a formal enterprise learns BABOK's vocabulary to interoperate with the analysis side. Q: UML in practice is most valuable for… - maintaining a complete, exhaustive set of diagrams for every system - reading and producing key diagrams (class, sequence) as a shared notation in design reviews correct: 1 explain: Full UML is rarely maintained end-to-end, but a class or sequence diagram in UML notation remains the lingua franca of architecture reviews. Knowing how to read one is the practical skill. ```