The Open Group Architecture Framework (TOGAF) is (probably) the most popular current-day framework for [[Enterprise Architecture]]. Unlike the [[Zachman]] and [[CSVLOD]] models,[^1] which are merely ways to frame a _description_ of an Enterprise Architecture, TOGAF contains descriptive elements AND a process for applying them. > [!success] Certified > I am TOGAF® Certified (Foundations and Practitioner) as of April 2026. > [!note] TOGAF != [[Archimate]] > - The Open Group also made [[Archimate]], which _can_ be used with TOGAF, but the two are not synonymous. > - Archimate includes diagrammatic constructs that can align with the TOGAF process, but both can be used without the other. The prototypical visual associated with TOGAF actually depicts the **Architecture Development Method** prescribed by TOGAF: ![[IMG_1543.png]] # Architecture Development Method (ADM) The whole process is iterative. ## Preliminary - Decide how you will customize the rest of the approach to fit the particulars of your situation. What does the business need and what do you need to do to achieve that. You can borrow ideas & practices from other frameworks if you like. - Where you establish the team, tools, [[Principles (index)|principles]] and process support structures (e.g. wiki, meeting cadences, etc) - Principles inform future [[Tradespace|trade offs]] - Determine power dynamics, level of architectural authority so, risk appetite - High level overviews of the business at hand, essentially - Typically includes review of existing governance practices & policies to ensure you know the constraints you operate within - Seeking **shared expectations of the expected role of the architects** - _Deliverables may include:_ - Request for Architecture Work (RAW) - Architecture [[Principles (index)|principles]] (which may not be verbs I guess[^2]) ## A) Vision - Define scope & stakeholders. - Consider constraints on timelines, budgets, business politics - Create a "vision" of the architecture - Includes a high-level, first-blush **target state** - Looks at alignment with business goals & values - Defines the scope of the practice itself - Describes expected outcomes of the architecture practice - Obtain buy-in from stakeholders - _Deliverables may include:_ - Communications plan - Architecture Vision - Statement of Architectural Work (SAW) --- B, C, and D can be done in parallel. They're also largely the same, except for across different [[BDAT]] layers, but also they collapse the middle two... whatever. ## B) Business Arch - Describe workflow changes, strategy changes necessary to support the [[#A) Vision]]. - [[Business Capability Models]] and assessments - Business agreement on priorities ## C) Information Systems Arch - The logical & physical data models necessary to support the [[#A) Vision]] - Understanding applications overlaps, integration dependencies, etc ## D) Technology Arch - Hardware, software, platforms, & infrastructure changes necessary to support the [[#A) Vision]] - Determine what patterns are acceptable and where we should standardize Collectively through B, C, & D - _deliverables may include:_ - Architecture Definition Document (ADD) - Including **target architecture** (in terms of capabilities & value streams) - **gap analysis** (current-to-target) - Reference architectures - **Guardrails** for solution design - Architecture Roadmap Candidates (ARC) - Architecture Requirements Specification (ARS) --- ## E) Opportunities & Solutions - Create roadmap & outline corresponding projects - Looking at solutions that balance risk & value - Understand business constraints on implementation - AKA "Interim states" & plans on how to get there - Include _dependencies_ and consider recommended _priorities_ (although stakeholders get to choose priorities) - Should be closing **gaps** - _Deliverables may include:_ - [[Work Bundle Names|Work packages]] - A good goal: incremental changes with value throughout - And confidence the approach is feasible - Architecture Roadmaps - coherent in rationalized - Implementation & Migration plans - close to finished, but not yet finalized ## F) Migration Planning - Expand on [[#E) Opportunities & Solutions]] to determine expected ROI (**business value**) of projects, their risks, dependencies, the specific logistics of implementation. - Seeking approval from stakeholders & **finalization** of the plans laid - Goal is to walk away knowing what you're doing to move through the interim states - _Deliverables may include:_ - Finalized work packages, fine-tuned with priorities and schedules... Milestones - Realistic expectations for stakeholders and those impacted - Cost-benefit analyses ## G) Implementation Governance - Defining acceptance criteria - "how are we done" - Tracks issues, unique constraints, & ensures alignment between implementation projects - **Guide solutions deployments** - to stay within guardrails and aligned to target architectures - _Deliverables may include:_ - Architecture compliance assessments - Issues tracked and related lifecycle artifacts ## H) Arch Change Management - Governs & manages project implementation - Manage risks - Are the projects on track? Are they actually delivering on the architectural [[#A) Vision]] - Deploy architectural monitoring tools - _Deliverables may include:_ - Change requests ## Requirements Management - Throughout the entire process, you'll be capturing and noting requirements for the architecture _practice_ and the architecture (across all the [[BDAT]] domains). - _Deliverables may include:_ - Change request - Requirements impact analyses # Architecture Documents ## ADD The architecture definition document. The magnum opus. Describes the architecture holistically and in pretty great detail, it seems. ## SAW Statement of architectural work. A document early on that scopes and charters the practice. # TOGAF Library ## Makeup There's the fundamental content, series guides, white papers, reference architectures, multi-hundred page "pocket guides" etc. - Contextual - why do the work, what's the scope of the work, its goals, drivers - Conceptual - requirements decomposed to understand the problem and whats needed to address it - Logical - what [[BDAT]] components are needed to achieve services, how can they be structured (w/o regard to specific implementation) - Physical - specific implementation details ## Enterprise Continuum The Enterprise Continuum is a classification model for architectural assets, showing how architectures evolve from **generic reference models to enterprise-specific solutions**. Factoring in existing architecture, external factors, and available resources. - Archtiecture continuum - Solutions continuum ## Architecture Repo Literally a repository of architectural assets. Typically in a tool or wiki or whatever. Includes: - Metamodel, reference libraries, standard libraries, architecture landscapes, governance materials, materials about the architecture practice, requirements repo, solutions landscapes, target architecture, etc. ## Enterprise Metamodel Basically a breakdown of terms. Nothing earthshaking here. [![[TOGAF_Content_Metamodel.jpg]] from [here](https://www.archimetric.com/what-is-togaf/) **** # More ## Source - https://www.opengroup.org/togaf - [[Wikipedia]] - https://togaf.visual-paradigm.com/2025/03/06/comprehensive-guide-navigating-the-preliminary-phase-of-togaf-10-for-enterprise-architecture-success/ - That whole series of articles - https://youtu.be/AihWJ3_klRQ?si=-diMFwQnDy4qNf5I - https://www.archimetric.com/what-is-togaf/ [^1]: and arguably [[UAF]] [^2]: COME ON GUYS