考试代码OGEA-C103 | 成绩Part 190%/ Part 285%| 考试日期2025年9月作者Alice·Dong | 科技开发者 | Open CA Architect Master → TOGAF Enterprise Architecture Practitioner写作方法论说明本文遵循起因→思考→实践→反思→意识五段式结构。起因为什么一个已经拿到Open CA Master的架构师还要考TOGAF一个认知缺口已经拿到了The Open Group 认证架构师Open CAMaster级别的架构师能力认证为什么还要回头去考TOGAF这个问题本身暴露了一个常见误区把Open CA和TOGAF当成了同一赛道的高低级别实际上它们是两条完全不同的认证路径。而且——TOGAF看起来是入门框架真正学进去才发现门槛极高ADM九阶段 × 四大架构领域 × 内容元模型 × 治理框架 × 能力框架整个知识体系像一张精密的网任何一个节点理解不到位Part 2的情景分析题就会选错。维度Open CA (Certified Architect)TOGAF 认证本质能力认证证明你会做架构知识认证证明你懂方法论评估方式同行评审Peer Review提交真实项目案例接受3位资深架构师面试答辩标准化考试选择题情景分析题核心关注你在真实项目中展现的架构能力、领导力和影响力你对TOGAF标准知识体系的掌握程度层级三级Certified → Master → Distinguished三级总计全球5000持证者覆盖60国家、180企业两级Foundation知识级→ Practitioner应用级需双卷通过全球70,000持证者偏向“你能做什么”——实战能力“你知道什么”——方法论体系我的情况是先有了会做的能力证明Open CA Master但缺少一套体系化的为什么这样做的方法论框架。就像一位经验丰富的工匠——能打造精美的家具但说不清背后的设计原则和工艺体系。TOGAF正好填补了这个空白。TOGAF凭什么值得投入在选择投入之前我做了一轮数据验证——TOGAF到底是不是当下最流行的企业架构理论结论是全球80%的财富50强企业使用TOGAF框架管理企业架构[1]全球60%的财富500强企业采用TOGAF标准[1]全球70,000专业人士持有TOGAF认证分布在130国家持有TOGAF认证的架构师平均薪资高出45%[1]中国2025年企业架构师岗位需求预估120万现有供给仅30万[1]更重要的是TOGAF 10不是另一个认证而是企业架构领域的通用语言和操作系统。它提供了从战略到落地的完整方法论闭环——ADM架构开发方法、内容框架、能力框架、治理模型。这些恰恰是我在Open CA实战中感受到缺少理论锚点的地方。IBM Architect Thinking 埋下的种子备考TOGAF之前我已经系统学习过IBM的Architect ThinkingAT课程。先说一句定性的话AT不是一门教你怎么做架构的技术课而是一门教你怎么站在架构师角度思考的思维课——它给你的不是答案而是一套稳定的思考流程。AT 的七大组成部分AT 方法论的完整流程包含七个环节形成一条从理解问题到验证方案的闭环Requirements需求分析 ↓ Architecture Decisions Principles架构决策与原则 ↓ Architecture Overview架构概览 ←── 三大核心产出物 ↓ Functional功能建模即 Component Model ↓ Operational运维建模即 Operational Model ↓ Validation验证架构是否满足需求 ↓ Viability可行性方案是否可落地三大核心产出物AT 的架构表达围绕三个核心模型展开它们之间的关系是逐层细化模型定位核心问题Architecture Overview“信封背面的架构草图”这个系统整体长什么样向谁提供什么服务Component Model功能分解系统由哪些组件构成组件之间怎么交互接口怎么定义Operational Model部署映射这些组件跑在哪儿怎么保证 SLA网络、节点、容量怎么规划Architecture Overview 是高层描述——用来和不同利益干系人快速对齐认知有面向业务的服务视图、面向高管的业务视图、面向技术团队的 IT 系统视图三种画法。Component Model 将 Overview 中的逻辑组件展开为正式的功能分解静态结构 动态时序 事件流协作。Operational Model 再将组件通过 Deployment Units 映射到逻辑节点和物理节点上——从系统做什么到系统怎么部署形成一条完整的追溯链。需求分类先把要做什么结构化在进入三大模型之前AT 要求先把需求分清楚而不是混在一起讨论需求类型内容在AT中的表达方式功能性需求系统要做什么浏览、下单、支付、对账……用例图 用例描述表质量需求NFR系统要做到多好可用性、扩展性、性能、安全性……质量属性矩阵约束需求不可逾越的边界预算、法规、技术栈限制……约束清单这套分类的意义远超整理需求——它本质上是在做架构决策之前先建立**“问题空间的坐标系”**。很多架构争论的根源就是把功能性需求和质量需求、约束需求混在一起讨论导致每个人在说不同维度的事。AT 的架构师定位与核心价值观AT 对架构师的角色定位非常明确架构师是业务与技术之间、客户与交付团队之间的桥梁。技术深度是入场券但真正区分架构师和高级开发者的是从更宏观的视野综合权衡多种因素来做决策的能力。AT 中反复强调的几个核心价值观对我影响很深避免 Golden Hammer 反模式不要想着用一个方案解决所有问题——没有银弹只有适合当前上下文的权衡。不要期待快速出方案合理的架构方案是经过详尽调研和综合权衡后做出的选择Architecture Decisions每一个决策都应该是可追溯的。修复一个问题通常会引入新问题架构师的工作不是找到完美方案而是清楚知道每个选择的代价。敏捷不等于不写文档关键节点的架构文档必须有做到所有 decision 可追溯。此外AT 课程本身是以纯技术导向设计的但在实际工作中架构师还需要面对一个课程没有覆盖的现实因素——组织中的权力结构和办公室政治它既是非功能需求NFR也是约束条件Constraint。这个认知与 TOGAF 的 Preliminary Phase 不谋而合。IBM AT 和 TOGAF 的关系维度IBM ATTOGAF核心定位架构思维框架——“如何思考一个解决方案的架构”企业架构方法论——“如何治理和交付企业级架构”需求处理三分类法功能/质量/约束结构清晰、可操作性强通过业务场景和架构愿景驱动需求分析视角建模三大模型Architecture Overview → Component Model → Operational Model纵向细化四大架构领域BDAT横向分层产出物Architecture Overview Component Model Operational Model ADR22种标准架构制品完整的ADM各阶段交付物治理机制依赖架构决策记录ADR和团队共识标准化架构委员会、合规评审、例外处理、架构契约适用场景解决方案级架构设计快速上手适合日常架构决策企业级架构规划与治理适合大型组织的体系化建设课程性质一门教你怎么思考的思维课战略多于战术一套教你怎么做的方法论战术与战略并重两者的关系不是谁高谁低而是互补AT 提供了思考的流程——从需求分析到方案验证的完整思维闭环TOGAF 提供了行动的框架——从架构愿景到实施治理的完整组织闭环。学习 AT 之后再学 TOGAF我的感受是——AT 让我知道怎么想清楚一个方案TOGAF 让我知道怎么把一群人的架构工作组织起来、并让架构决策在企业中有法可依。一句话定位这不是一篇怎么背过TOGAF的备考攻略而是一个已经有架构实战经验的从业者如何用TOGAF把零散的认知组装成一套系统化的思维操作系统并在这个过程中完成从应用架构到企业架构的认知跃迁。思考从术到道——备考中的四层认知升级TOGAF的知识体系极度宏大。ADM九个阶段 × 四大架构领域业务/数据/应用/技术× 内容元模型 × 能力框架 × 治理模型……如果只盯着考试很容易陷入术语的死记硬背。我的策略是不只学是什么更要追问为什么和凭什么。备考过程中我经历了四层认知升级第〇层愿景先行——从看地图到会导航备考初期我的关注点在学知识——ADM有几个阶段、每个阶段的输入输出是什么、术语怎么辨析。但随着学习深入我意识到一个关键问题深度理解TOGAF和用好TOGAF是两件完全不同的事。打个比方深度理解 看地图。给你一张详尽的地图你知道了每条路的名字、每个节点的位置——ADM九阶段、BDAT四层架构、治理框架、能力框架所有这些构成了一张企业架构的全景地图。战略与决断力 会导航。拿到地图不意味着你能到达目的地。你需要判断当前在哪要去哪哪条路最快前方有没有封路什么时候该绕行TOGAF是地图架构师的判断力是导航仪。地图可以背下来但导航能力只能在真实的决策场景中练出来。比如你知道 Phase A 要做架构愿景但面对真实的业务场景——一个跨部门的大型项目涉及业务合规、数据安全、系统容量——你能判断这个变更值不值得启动完整的架构工作吗还是应该走简化流程这个判断TOGAF 的教材不会替你做出。这就是我备考中最大的认知转变顶层设计的认知构建是第一位的。先建立往哪个方向走的判断力然后才谈得上怎么走的方法论。没有导航的地图只是一张纸没有顶层设计的方法论只是一堆术语。这个认知贯穿了后续所有学习层次。第一层组织架构——企业骨架对架构的深层塑造有了方向感之后接下来要面对的是最现实的问题架构不是在空中搭建的它必须嵌入企业现有的组织权力结构中才能落地。这是备考中最容易被忽视、但对我冲击最大的一层认知企业的组织架构就是企业架构的源代码。TOGAF 中有两个关键视角支撑这个论点视角一Preliminary Phase 的组织模型ADM 的第一步不是做架构而是先回答一个问题——“在我们这个企业里谁来定义架构、谁来做架构、谁来审批、谁来执行、谁来负责”这就是 Preliminary Phase 的核心产出之一组织模型Organizational Model for EA。这听起来像是一份普通的架构团队职责说明书但它的深远影响在于这个组织模型直接决定了后续所有 ADM 阶段能否有效推进。如果组织模型里没有给架构委员会真正的决策权那 Phase G实施治理就是走过场如果组织模型里架构团队被定位为支持角色而非赋能角色那 Phase A 的架构愿景就没人当回事。视角二业务架构四大核心元素之组织映射TOGAF 的业务架构有四个核心元素核心元素回答的问题业务能力Business Capability企业能做什么价值流Value Stream企业如何为利益干系人创造价值信息映射Information Map信息如何在企业中流转组织映射Organization Map谁负责什么权力边界在哪汇报线怎么走这四个元素是平级的——组织映射不是辅助信息而是业务架构的支柱之一。它回答的问题恰恰是其他三个元素无法回答的执行能力的人在哪决策权怎么分布从战略到落地组织架构的四层穿透一旦理解了组织映射的重要性再看企业中的架构问题就会发现一条清晰的因果链科技战略层 └── 组织架构决定了科技的定位是成本中心还是利润中心 这决定了架构工作的天花板——成本中心的架构能做优化 利润中心的架构能做创新。 技术架构层 └── 组织架构决定了架构决策权的分布是集中式架构委员会统一管理 还是各部门各自为政这决定了技术架构是一张总图还是一堆拼图。 项目构建层 └── 组织架构决定了信息传递路径跨部门协作要走几条汇报线 审批要过几道关信息每经过一层组织边界就衰减一次。 这才是跨部门项目推进慢的根因——不是技术问题是组织问题。 落地执行层 └── 组织架构决定了框架搭建效率如果有统一的架构治理组织 标准、规范、工具可以一次性铺开如果各部门独立运作 同样的框架要适配 N 套组织语境落地成本指数级上升。核心认知不理解企业的组织架构就永远在表层做架构。因为任何架构方案最终都要嵌入现有的组织权力结构中才能落地——一个在技术上完美的架构如果违背了组织的权力分布和信息流习惯大概率会被架空。备考 TOGAF 的过程中我反复体会到Preliminary Phase 不是热身而是整个 ADM 的根基——没有组织模型的确认后面的八个阶段都是空中楼阁。第二层元架构——先理解架构的架构理解了组织的约束之后接下来搭建方法论骨架。TOGAF给我的第一个冲击来自**元架构Meta-Architecture**概念。在接触TOGAF之前我对架构的理解停留在应用架构层面——服务怎么拆、接口怎么定、数据怎么流。但TOGAF让我意识到架构本身也需要一个架构来定义。元架构Enterprise Meta-Architecture ├── 架构原则Architecture Principles—— 不可妥协的约束 │ 例数据所有权归属于业务部门IT部门负责数据管理 ├── 架构愿景Architecture Vision—— 目标状态的概要描述 │ 例3年内建成以客户为中心的全渠道服务平台 ├── 架构方法ADM—— 怎么一步步做架构 │ 例Preliminary → A → B → C → D → E → F → G → H └── 架构治理Architecture Governance—— 谁说了算、怎么说了算 例架构委员会、架构合规评审、架构契约IBM AT 的三大模型与 TOGAF 的四层架构有天然的映射关系——AT 的 Architecture Overview 和 Component Model 关注解决方案怎么做对应 TOGAF 的应用架构和技术架构而 TOGAF 在此基础上向上延伸了业务架构和数据架构形成了更完整的从战略到基础设施的全景视图。两者结合形成了从战略到代码的完整思维链路。第三层四层架构——从我只管应用层到每一层都重要TOGAF定义的四大架构领域BDAT是我备考中反复咀嚼的核心概念业务架构Business Architecture ↑ 定义业务战略、治理、组织和关键业务流程 ↑ 为什么做和做什么 数据架构Data Architecture ↑ 定义数据资产的结构、数据管理资源和数据生命周期 ↑ 数据怎么组织和流转 应用架构Application Architecture ↑ 定义应用系统的蓝图、交互关系和对核心业务流程的支撑 ↑ 用什么系统来做——这是我之前的舒适区 技术架构Technology Architecture ↑ 定义支撑应用和数据部署所需的软硬件基础设施 ↑ 跑在什么上面关键认知转变在接触TOGAF之前我的注意力主要集中在应用架构层——技术栈选型、服务拆分、接口契约设计。TOGAF让我看到业务架构是源头如果业务目标、业务流程、业务能力没有梳理清楚技术方案再优雅也是在错误的方向上跑得更快。数据架构是命脉在大型企业中数据治理谁拥有数据、谁可以使用、如何保证一致性往往比应用架构更重要。技术架构是地基云部署、消息中间件、微服务治理——这些本质上都是技术架构决策它们应该在业务架构和应用架构的约束下做出。一句话总结从聚焦应用架构到理解企业架构的跃迁就是从只关注技术实现到理解每一层的关系和约束——不是放弃技术深度而是在技术深度的基础上增加业务宽度和战略高度。图的认知架构师的通用语言四层架构如果只停留在文字描述很容易变成四堆术语。真正让 BDAT 活起来的是图。一个能让人看懂的架构图抵得上 100 句文字解释。这不是夸张——文字是线性的架构是多维的。用文字描述业务能力→应用服务→技术节点之间的映射关系几百字也说不清一张 ArchiMate 图30 秒就能让所有人对齐认知。TOGAF 和 IBM AT 在用图表达架构上殊途同归——不同阶段画不同的图面对不同的角色用不同的画法。但两者的侧重点和表达体系不同放在一起对比更有启发维度TOGAFArchiMateIBM AT三大产出物建模标准ArchiMateThe Open Group 官方企业架构建模语言无独立建模语言以 UML/类图/组件图/部署图等通用建模手段承载面向高管动机视图Stakeholder/Driver/Goal、业务层全景图Architecture Overview —— 一张图说清我们做什么高层抽象屏蔽技术细节面向技术团队应用层图应用组件/接口/数据流、技术层图节点/设备/网络Component Model —— 静态结构图 动态交互图时序/协作接口、事件流全部展开面向运维技术层部署视图、迁移视图现状→目标Operational Model —— 逻辑部署图 物理部署图哪个节点跑在哪个机房、网络 SLA 怎么保障面向变更管理迁移视图Transition Architecture多阶段路线图隐式体现在 Architecture Decisions 和 Viability 评估中无独立视图两者的核心思路一致不同角色看不同层级的图但所有图共享同一套架构模型。高层用 Architecture Overview / 动机视图快速对齐业务意图技术人员用 Component Model / 应用层图深入细节运维用 Operational Model / 技术层图落实部署——图是架构认知从抽象到具体的桥梁。图的核心价值有三层术语统一当所有人盯着一张图讨论时概念歧义无处藏身。你说客户域我指着图上的边界说是这个吗——对齐只需要一秒钟。这是文字永远做不到的。思路对齐不同角色业务、开发、测试、运维在同一张图的不同视角上找到自己的位置。业务人员看 ArchiMate 业务层的流程和角色技术人员看应用层的组件和接口——各取所需但共享同一个模型。决策可视化架构决策不是写在文档里的文字而是画在图上的选择。“为什么这个服务放在这一层而不是那一层”——图上的位置本身就是决策的视觉化表达比 Architecture Decision Record 更直观。学习 TOGAF 时也花了不少时间学习 ArchiMate 的基本符号体系——不是为了考试OGEA-C103 不考 ArchiMate而是因为能画出清晰的架构图是架构师将复杂认知外化为可沟通成果的核心能力。这个认知是从学会四层架构过渡到用好四层架构的关键一步。第四层道——知道为什么做比知道怎么做更重要这是备考过程中最深层的收获也是我认为TOGAF最有价值的地方——它不是给你一个做架构的配方而是给你一套思考为什么要做架构的哲学。我把它归纳为道层面的三个核心认知认知一暂停一下判断该不该做“在做之前暂停一下先判断是否应该做是架构师最关键的能力。”这是我在学完ADM Phase A架构愿景后的最大感触。Phase A的核心产出是架构工作声明Statement of Architecture Work——本质上就是一份我们为什么要启动这个架构变更的论证文档。在我们的日常工作中经常是业务提一个需求技术直接开始做方案。但TOGAF教会我一个关键动作在动手之前先问这个变更对齐了业务战略吗有替代方案吗不做会怎样这个暂停-判断的动作在涉及多方系统集成的复杂项目中尤其重要。比如一个跨部门的业务联调项目——这不是一个简单的加个接口的技术决策而是涉及业务合规、数据安全、系统容量的综合判断。如果跳过该不该做的思考直接进入怎么做风险是巨大的。认知二战略认知——从做项目到做正确的事TOGAF特别强调战略对齐每一个架构决策都应该回溯到业务战略。这听起来像是正确的废话但真正落地时才发现——大部分技术决策和业务战略之间的链路是断裂的。举一个反例团队曾经为了技术先进性选择了某个框架但该框架的人才市场供给极少导致招聘困难、维护成本高。如果从TOGAF的视角审视——这个决策违背了技术架构应服务于业务能力的原则属于为了技术而技术。战略认知的核心就是架构师的每一次技术选型本质上都是在回答这个选择如何帮助业务成功认知三业务层解读——技术人员的翻译能力TOGAF的四层架构中业务架构是第一层也是我最薄弱的一层。备考中反复学习业务架构相关的内容业务能力模型、价值流、组织映射、业务场景让我意识到一个关键能力缺口技术人员需要具备业务翻译能力——把业务目标翻译为技术需求把技术约束翻译为业务影响。这个能力在跨部门协作中至关重要。比如当多个技术团队协作时如果只会说这个接口QPS要到1000对方可能不理解为什么。但如果能说这个QPS要求是因为业务方预计高峰时段用户并发可能达到X万——沟通效率完全不同。实践备考执行方案——从2月到9月的7个月之旅整体时间线2025年2月 → 启动备考报名艾威培训机构 2025年2月-4月 → 第一阶段TOGAF 9.2 课程完整学习 2025年5月-6月 → 第二阶段TOGAF 10 课程完整学习 2025年7月-8月 → 第三阶段口袋书精读 笔记体系建立 持续刷题 2025年9月 → 参加OGEA-C103考试Part 1 90% / Part 2 85%⚠️关于时间跨度从2025年2月启动到9月考试约7个月。在职备考需要合理规划节奏工作繁忙时段可以适当放缓但不要完全中断保持知识的连续性很重要。第一步选机构——为什么是艾威维度艾威培训自学知识体系完整性✅ 系统化讲解TOGAF 9 10双版本讲师现场答疑⚠️ 需自己拼凑资料容易遗漏重点行业案例✅ 讲师分享多年企业架构咨询经验覆盖金融、保险、制造业等真实案例❌ 缺乏实战场景停留在理论层题库质量✅ 提供10套仿真模拟题 视频讲解⚠️ 网上的免费题目质量参差不齐时间效率中等集中学习 题库训练高摸索时间难以预估适合人群在职人士希望高效通过并学以致用在校学生时间充裕且有自学能力个人感受TOGAF的概念密度极高——Enterprise Continuum、Architecture Repository、Capability-Based Planning、Business Scenario……每个术语背后都有严格定义和关联网络。有经验的讲师能帮你快速建立概念地图这是自学的最大难点。第二步听课——两遍课程两个目的第一遍TOGAF 9.2 课程 → 建立骨架目标不是记住细节而是搞清楚TOGAF的世界长什么样ADM九个阶段Preliminary → A → B → C → D → E → F → G → H → Requirements Management各自的定位四大架构领域BDAT的关系内容元模型中构件之间的关联第二遍TOGAF 10 课程 → 填充血肉有了9.2的基础后重点学习10版的结构性变化。以下是备考中我整理的TOGAF 9 vs 10 六大关键差异变化维度TOGAF 9.2TOGAF 10实践影响文档结构单一巨型文档近千页Fundamental Content Series Guides模块化结构学习门槛大幅降低核心内容精炼指南按需查阅敏捷支持态度模糊留给实践者自行摸索Sprint驱动ADM四种协作模式 DORP节奏机制DevOps/CI/CD一等公民架构师终于有了如何在Sprint中做架构的具体方法数字企业默认面向有正式IT部门的大型企业DPBoK数字从业者知识体系四种组织语境Individual/Team/Team of Teams/Enduring Enterprise创业公司到跨国企业都有适配方案不再是大厂专属架构产出强调完整架构文档和正式评审MVA最小可行架构“Just Enough Architecture, Just in Time”从过度设计vs不设计的两难中找到平衡点EA角色审批门卫gate-keeper项目提交文档→等待审批EA即服务从审批者转型为赋能者按需提供指导解决敏捷团队视架构为阻碍而非助力的老问题ADM灵活性阶段间顺序箭头暗示线性推进取消顺序箭头允许灵活跳转和迭代更贴近实际——架构工作从来不是一步到位的备考需额外掌握的新概念MVA最小可行架构与MVP类比记忆——MVP面向客户MVA面向内部。价值链MVBD最小业务变更→ MVA → MVPPeek-Ahead策略在当前语境下做刚好够用的架构同时确保今天决策不阻碍向更成熟语境的过渡四种敏捷协作模式EA Development Agility → Solution Collaboration → Cross-Development Collaboration → Cross-Functional AgilityDORP节奏每个Sprint结束——Demo演示→ Outcome Management成果管理→ Retrospective回顾→ Planning规划术语更新“内容框架和元模型→TOGAF内容框架和TOGAF企业元模型”“标准信息库→标准库”“治理日志→治理存储库”第三步啃口袋书——两遍法《The TOGAF Standard, 10th Edition - A Pocket Guide》中文版是备考核心。第一遍通读约3-4天快速过一遍把课堂上学到的碎片知识串联起来。遇到不懂的做标记不要卡住——后面的内容往往能帮理解前面的概念。第二遍精读约1周每读完一章问自己三个问题这一章解决了什么问题和其他章节是什么关系在我的实际工作中能找到对应的场景吗同时建立笔记体系笔记结构 ├── 一、核心概念词典 │ ├── 术语名英文中文 │ ├── 官方定义用自己的话复述 │ ├── 所属ADM阶段/领域 │ └── 与相关概念的区分⚠️易混淆项 │ ├── 二、ADM阶段速查表 │ ├── Phase名称 → 目标一句话→ 关键输入/输出 → 常见陷阱 │ ├── 三、错题本 │ ├── 题目摘要 → 我的答案 vs 正确答案 → 错因分析 → 知识点回溯 │ └── 四、TOGAF 9→10差异清单 ├── 新增概念 / 修改内容 / 已废弃术语这套笔记在考前最后一周发挥了决定性作用——我只复习笔记不再翻书。第四步刷题——10套模拟题三轮打法艾威培训提供了10套模拟题覆盖Part 1知识级和Part 2应用级。刷题节奏第一轮裸刷不看答案严格计时 ├── 目的检验真实水平暴露知识盲区 └── 结果第一轮正确率约60%-70%正常现象 第二轮带解析刷 ├── 目的理解出题意图和解题思路 ├── 错题分类 │ A类 - 概念混淆如 Governance vs Implementation Governance │ B类 - 细节遗漏如某个阶段的输出物记不全 │ C类 - 场景误判L2情景题没匹配到正确的ADM阶段 └── 重点不仅知道正确答案还要知道错误选项为什么错 第三轮只刷错题 ├── 目的消灭盲区 ├── 方式隔几天重做连续两次做对 → 标记已掌握 └── 标准如果第三次还错 → 回到口袋书重新理解对应知识点Part 1 vs Part 2 差异化策略考试部分题型策略Part 1知识级40道单选题60分钟60%及格24/40概念为王。术语辨析、ADM各阶段目标/输出物、元模型构件关系。多刷题形成肌肉记忆Part 2应用级8道情景分析题90分钟60%及格24/40分场景匹配为核心。每题给企业场景需判断处于ADM哪个阶段、该做什么决策。选项分值递减5分→3分→1分→0分必须选最优Part 2解题心法快速定位关键词 → 匹配ADM阶段 → 排除干扰项 → 选最优解。例如“架构团队正在与业务高管确认战略目标和约束条件” → Phase A架构愿景“识别现有系统的能力和差距” → Phase B-G具体架构领域分析。反思回头看——哪些做得好哪些可以更好做得好的三件事1. 先9后10的学习顺序是对的虽然最终考的是TOGAF 10但先学9.2再学10非常有效。9.2的结构更经典、社区讨论更丰富打好底子后再理解10的变化就像站在坚实的地基上看新楼层——一目了然。2. 口袋书的两遍法性价比极高很多人推荐直接刷题但我发现不读透口袋书就刷题是事倍功半的。TOGAF的题目不是靠记住答案能应付的——特别是Part 2的情景分析题必须真正理解ADM逻辑才能选对。口袋书虽然不到200页但每句都是精华。3. 错题分类比反复刷有效得多最初想过把10套题刷到全对但效率很低——有些题确实懂了反复做是浪费时间。分类之后可以把精力集中在真正的薄弱环节。如果重来可以优化的地方1. 更早开始结合实际工作思考备考期间我主要聚焦于通过考试但考完后才意识到——如果边学边在工作中找对应场景理解会深刻得多。比如我做Harness Engineering框架落地时回头看发现Phase A架构愿景对应Spec制品定义Phase B-G架构开发对应Rule/Skill/Agent设计Phase H架构变更管理对应Hook机制。2. Part 2情景题应该更早开始练习我把大部分时间花在Part 1的概念记忆上Part 2练习偏晚。实际上Part 2才是真正拉开差距的地方——它考察的是对方法论的理解深度和应用能力。3. 可以做一个知识点→题目反向索引备考后期发现某些知识点反复出现在不同套题中但散落各处。如果一开始就建立知识点→涉及题目编号的反向索引复习效率会更高。意识考完之后我真正获得了什么不只是一张证书坦率地说TOGAF认证本身不会帮你写出更好的代码也不会自动让你的方案被采纳。它给你的东西更底层一种看待系统的方式。“道”理解为什么做“做之前暂停一下先判断是否应该做。”这是TOGAF给我最深层的认知改变。架构师的核心价值不是能设计出多复杂的系统而是能在正确的时间做出正确的设计决策。ADM Phase A的存在本身就说明了这一点——在开始任何架构工作之前先确认这件事对齐了战略目标、有足够的业务价值、并且我们真的需要做。在日常工作中这意味着接到需求时先问这个变更对齐了哪个业务目标技术选型时先问这个选择如何帮助业务成功设计方案时先问有没有更简单的方案过度设计是不是一种风险“法”知道怎么做ADM方法论给了我一套完整的架构动作框架。这里展开几个我备考中最有收获的具体技术1. 利益干系人管理Stakeholder Management——最重要也最容易被忽视TOGAF反复强调不同的利益干系人关心不同的视角需要不同的沟通产物。利益干系人类型关心什么应提供的架构产物沟通方式C-Level高管战略对齐、投资回报、风险架构愿景、业务能力模型一页纸摘要高层简报用业务语言业务部门负责人流程影响、能力提升、KPI业务架构、差距分析、迁移计划业务场景演示技术团队技术选型、接口规范、实施细节应用/数据/技术架构、解决方案构建块SBB技术文档架构评审合规/安全法规遵循、风险评估架构原则、安全架构、合规矩阵正式评审会议运维团队部署方案、监控策略、SLA技术架构、部署图、运营模型运维手册演练我在实际工作中的应用在代销基金项目中利益干系人管理贯穿始终——对外需要与中登中国证券登记结算公司、国泰基金等多个外围渠道协调联调节奏每个渠道有自己的排期窗口和对接规范对内涉及业务部门产品、合规、科技部门多个中心及多个科室的跨组织协作每个团队关注点完全不同。如果不做利益干系人矩阵——谁来定方案谁来确认联调窗口谁对合规负责——信息同步会断裂、预期管理会失控。TOGAF 的 Stakeholder Management 方法论让我在每个节点都能回答这个阶段应该让谁参与、给谁看什么。2. 架构治理Architecture Governance——让架构决策有法可依TOGAF的治理框架包括三个层次架构治理体系 ├── 架构委员会Architecture Board │ └── 跨部门决策机构审批重大架构变更和例外处理 ├── 架构契约Architecture Contract │ └── 开发团队和架构团队之间的合同明确各自的义务和交付标准 └── 架构合规评审Architecture Compliance Review └── 在关键里程碑检查项目是否遵循架构规范反思在实际项目中虽然有一定程度的架构评审但缺乏正式的治理机制。TOGAF让我意识到——没有治理的架构只是建议有治理的架构才是标准。3. 架构原则Architecture Principles——不可妥协的边界TOGAF要求每个企业定义自己的架构原则。原则不是最佳实践建议而是不可妥协的约束。例如原则示例“数据所有权归属于业务部门IT部门负责数据管理和技术实现。”一旦定义了原则所有架构决策都必须在原则框架内进行。这解决了每个人都有自己的’最佳实践’的混乱局面。4. 架构能力框架Architecture Capability Framework——不止是做事更要建立做事的能力TOGAF强调组织不仅要做好单个架构项目更要建立持续的架构能力。包括架构团队的技能矩阵和角色定义架构工具和存储库的建设架构方法论在组织内的推广和培训这让我对Harness Engineering框架的推广有了新的理解——它不只是一套工具更是团队架构能力的系统化建设。5. 差距分析Gap Analysis——所有架构工作的核心动作TOGAF中几乎所有ADM阶段都会涉及差距分析Baseline Architecture当前状态 ↓ 差距分析 → 识别 Gap Items ↓ Target Architecture目标状态 ↓ 迁移规划 → Roadmap 和 Transition Architectures这个简单的方法论可以迁移到很多场景技术债治理现状 vs 目标、团队能力建设当前技能 vs 需要技能、UX优化当前体验 vs 目标体验。“术”回到日常工作中的具体改变1. 通用语言——减少沟通摩擦以前和后端团队讨论架构时经常鸡同鸭讲。TOGAF提供了标准化的词汇体系和分层视角让我们能在同一个语义空间对话“这个变更属于Phase B业务架构层面不需要动应用架构和技术架构”“这个接口定义属于Architecture Building BlockABB需要在Solution Building BlockSBB实现之前确定”2. 结构化检查清单——不再遗漏关键步骤ADM的九个阶段是我做架构决策时的检查清单有没有明确的架构愿景Phase A当前状态和目标状态的差距分析做了吗Gap Analysis利益干系人的期望管理了吗Stakeholder Management迁移计划可行吗风险考虑了吗Phase E-F3. MVA思维——从完美主义到刚好够用TOGAF 10的MVA理念对我触动最大。在快速迭代的业务环境中过度设计本身就是风险。架构师的工作是在每个节点提供刚好够用的架构指导不多也不少。你可以带走的三件事1. 不要试图一次记住所有概念TOGAF体系庞大——ADM九个阶段 × 四大架构领域 × 内容元模型 × 治理框架 × 参考模型。正确的做法是先建立整体地图知道有哪些东西再逐步深入细节理解它们的关系。2. 把学习和工作绑在一起每学到一个概念就问自己“在我的项目中哪里用到了类似的东西”Stakeholder Management → 代销基金项目对外多渠道协调中登、国泰等对内多部门多中心多科室信息同步与预期管理Architecture Repository → 团队正在建设的知识库和规范文档体系Gap Analysis → 技术债梳理时的现状-目标差距分析3. 考证只是起点不是终点TOGAF证书永久有效不像PMP需要续证但这不代表考完就万事大吉。真正有价值的是备考中建立的思维方式以及后续在实践中不断深化的认知。我现在的习惯是每做完一个重要架构决策回头看看它对应TOGAF的哪个阶段——这种事后审计比任何考试都更能提升能力。更重要的是TOGAF 本质上是一个方法论框架和索引Index而不是一套自给自足的全家桶。它告诉你在什么阶段应该关注什么但具体怎么执行需要配合更多不同层面的知识和技术领域配套方法论/知识体系与 TOGAF 的互补关系项目管理PMBOK、PRINCE2TOGAF 负责做什么架构PMBOK 负责怎么管理架构项目的进度和资源业务架构BIZBOK业务架构知识体系TOGAF 定义了业务架构的位置BIZBOK 提供了业务架构的深度方法论安全架构SABSATOGAF 在 ADM 各阶段埋了安全关注点SABSA 是专门的安全架构框架与 TOGAF 天然互补敏捷交付Scrum、SAFeTOGAF 10 已内置敏捷协作模式但具体的 Sprint 节奏、需求拆分、持续交付需要敏捷框架支撑IT 治理COBITTOGAF 的架构治理 COBIT 的 IT 治理覆盖从架构决策到 IT 运营的全链路TOGAF 的价值不在于它包办一切而在于它给了你一张全景地图——让你知道每个问题应该去哪个领域找答案每个领域的方法论应该放在架构的哪个阶段使用。就像一本索引它不替代任何一本具体的书但让你知道该去翻哪一本。附录备考资源清单资源说明推荐度艾威TOGAF 10培训课程系统化讲解行业案例10套题库⭐⭐⭐⭐⭐ 必选《TOGAF Standard, 10th Edition - A Pocket Guide》中文版官方精简版备考核心⭐⭐⭐⭐⭐ 必选艾威10套模拟题Part 1 Part 2覆盖全部考点含视频讲解⭐⭐⭐⭐⭐ 必选TOGAF 9.2课程视频作为前置基础学习⭐⭐⭐⭐ 推荐The Open Group官网标准文档权威参考深入研究者选读⭐⭐⭐ 选读参考资料[1] TOGAF认证价值与市场需求数据综合来源The Open Group官方统计、搜狐教育TOGAF认证分析写在最后90%和85%的成绩让人开心但更重要的收获是从一个会做架构的实践者变成了一个知道为什么这样做、还能判断该不该做的思考者。如果你也拿到了Open CA或者正在用IBM Architect Thinking指导日常工作但总觉得缺少一套系统化的方法论框架——那么TOGAF值得你投入这7个月。不是为了那张纸而是为了获得一种更清晰的思维方式以及一套与全球70,000架构师共享的通用语言。架构师的成长从来不是证书的堆叠而是认知的跃迁。从术到法再到道——这条路TOGAF帮我走完了第一程。关于TOGAF备考或企业架构实践的交流欢迎在评论区讨论。
考试代码OGEA-C103 | 成绩Part 190%/ Part 285%| 考试日期2025年9月作者Alice·Dong | 科技开发者 | Open CA Architect Master → TOGAF Enterprise Architecture Practitioner写作方法论说明本文遵循起因→思考→实践→反思→意识五段式结构。起因为什么一个已经拿到Open CA Master的架构师还要考TOGAF一个认知缺口已经拿到了The Open Group 认证架构师Open CAMaster级别的架构师能力认证为什么还要回头去考TOGAF这个问题本身暴露了一个常见误区把Open CA和TOGAF当成了同一赛道的高低级别实际上它们是两条完全不同的认证路径。而且——TOGAF看起来是入门框架真正学进去才发现门槛极高ADM九阶段 × 四大架构领域 × 内容元模型 × 治理框架 × 能力框架整个知识体系像一张精密的网任何一个节点理解不到位Part 2的情景分析题就会选错。维度Open CA (Certified Architect)TOGAF 认证本质能力认证证明你会做架构知识认证证明你懂方法论评估方式同行评审Peer Review提交真实项目案例接受3位资深架构师面试答辩标准化考试选择题情景分析题核心关注你在真实项目中展现的架构能力、领导力和影响力你对TOGAF标准知识体系的掌握程度层级三级Certified → Master → Distinguished三级总计全球5000持证者覆盖60国家、180企业两级Foundation知识级→ Practitioner应用级需双卷通过全球70,000持证者偏向“你能做什么”——实战能力“你知道什么”——方法论体系我的情况是先有了会做的能力证明Open CA Master但缺少一套体系化的为什么这样做的方法论框架。就像一位经验丰富的工匠——能打造精美的家具但说不清背后的设计原则和工艺体系。TOGAF正好填补了这个空白。TOGAF凭什么值得投入在选择投入之前我做了一轮数据验证——TOGAF到底是不是当下最流行的企业架构理论结论是全球80%的财富50强企业使用TOGAF框架管理企业架构[1]全球60%的财富500强企业采用TOGAF标准[1]全球70,000专业人士持有TOGAF认证分布在130国家持有TOGAF认证的架构师平均薪资高出45%[1]中国2025年企业架构师岗位需求预估120万现有供给仅30万[1]更重要的是TOGAF 10不是另一个认证而是企业架构领域的通用语言和操作系统。它提供了从战略到落地的完整方法论闭环——ADM架构开发方法、内容框架、能力框架、治理模型。这些恰恰是我在Open CA实战中感受到缺少理论锚点的地方。IBM Architect Thinking 埋下的种子备考TOGAF之前我已经系统学习过IBM的Architect ThinkingAT课程。先说一句定性的话AT不是一门教你怎么做架构的技术课而是一门教你怎么站在架构师角度思考的思维课——它给你的不是答案而是一套稳定的思考流程。AT 的七大组成部分AT 方法论的完整流程包含七个环节形成一条从理解问题到验证方案的闭环Requirements需求分析 ↓ Architecture Decisions Principles架构决策与原则 ↓ Architecture Overview架构概览 ←── 三大核心产出物 ↓ Functional功能建模即 Component Model ↓ Operational运维建模即 Operational Model ↓ Validation验证架构是否满足需求 ↓ Viability可行性方案是否可落地三大核心产出物AT 的架构表达围绕三个核心模型展开它们之间的关系是逐层细化模型定位核心问题Architecture Overview“信封背面的架构草图”这个系统整体长什么样向谁提供什么服务Component Model功能分解系统由哪些组件构成组件之间怎么交互接口怎么定义Operational Model部署映射这些组件跑在哪儿怎么保证 SLA网络、节点、容量怎么规划Architecture Overview 是高层描述——用来和不同利益干系人快速对齐认知有面向业务的服务视图、面向高管的业务视图、面向技术团队的 IT 系统视图三种画法。Component Model 将 Overview 中的逻辑组件展开为正式的功能分解静态结构 动态时序 事件流协作。Operational Model 再将组件通过 Deployment Units 映射到逻辑节点和物理节点上——从系统做什么到系统怎么部署形成一条完整的追溯链。需求分类先把要做什么结构化在进入三大模型之前AT 要求先把需求分清楚而不是混在一起讨论需求类型内容在AT中的表达方式功能性需求系统要做什么浏览、下单、支付、对账……用例图 用例描述表质量需求NFR系统要做到多好可用性、扩展性、性能、安全性……质量属性矩阵约束需求不可逾越的边界预算、法规、技术栈限制……约束清单这套分类的意义远超整理需求——它本质上是在做架构决策之前先建立**“问题空间的坐标系”**。很多架构争论的根源就是把功能性需求和质量需求、约束需求混在一起讨论导致每个人在说不同维度的事。AT 的架构师定位与核心价值观AT 对架构师的角色定位非常明确架构师是业务与技术之间、客户与交付团队之间的桥梁。技术深度是入场券但真正区分架构师和高级开发者的是从更宏观的视野综合权衡多种因素来做决策的能力。AT 中反复强调的几个核心价值观对我影响很深避免 Golden Hammer 反模式不要想着用一个方案解决所有问题——没有银弹只有适合当前上下文的权衡。不要期待快速出方案合理的架构方案是经过详尽调研和综合权衡后做出的选择Architecture Decisions每一个决策都应该是可追溯的。修复一个问题通常会引入新问题架构师的工作不是找到完美方案而是清楚知道每个选择的代价。敏捷不等于不写文档关键节点的架构文档必须有做到所有 decision 可追溯。此外AT 课程本身是以纯技术导向设计的但在实际工作中架构师还需要面对一个课程没有覆盖的现实因素——组织中的权力结构和办公室政治它既是非功能需求NFR也是约束条件Constraint。这个认知与 TOGAF 的 Preliminary Phase 不谋而合。IBM AT 和 TOGAF 的关系维度IBM ATTOGAF核心定位架构思维框架——“如何思考一个解决方案的架构”企业架构方法论——“如何治理和交付企业级架构”需求处理三分类法功能/质量/约束结构清晰、可操作性强通过业务场景和架构愿景驱动需求分析视角建模三大模型Architecture Overview → Component Model → Operational Model纵向细化四大架构领域BDAT横向分层产出物Architecture Overview Component Model Operational Model ADR22种标准架构制品完整的ADM各阶段交付物治理机制依赖架构决策记录ADR和团队共识标准化架构委员会、合规评审、例外处理、架构契约适用场景解决方案级架构设计快速上手适合日常架构决策企业级架构规划与治理适合大型组织的体系化建设课程性质一门教你怎么思考的思维课战略多于战术一套教你怎么做的方法论战术与战略并重两者的关系不是谁高谁低而是互补AT 提供了思考的流程——从需求分析到方案验证的完整思维闭环TOGAF 提供了行动的框架——从架构愿景到实施治理的完整组织闭环。学习 AT 之后再学 TOGAF我的感受是——AT 让我知道怎么想清楚一个方案TOGAF 让我知道怎么把一群人的架构工作组织起来、并让架构决策在企业中有法可依。一句话定位这不是一篇怎么背过TOGAF的备考攻略而是一个已经有架构实战经验的从业者如何用TOGAF把零散的认知组装成一套系统化的思维操作系统并在这个过程中完成从应用架构到企业架构的认知跃迁。思考从术到道——备考中的四层认知升级TOGAF的知识体系极度宏大。ADM九个阶段 × 四大架构领域业务/数据/应用/技术× 内容元模型 × 能力框架 × 治理模型……如果只盯着考试很容易陷入术语的死记硬背。我的策略是不只学是什么更要追问为什么和凭什么。备考过程中我经历了四层认知升级第〇层愿景先行——从看地图到会导航备考初期我的关注点在学知识——ADM有几个阶段、每个阶段的输入输出是什么、术语怎么辨析。但随着学习深入我意识到一个关键问题深度理解TOGAF和用好TOGAF是两件完全不同的事。打个比方深度理解 看地图。给你一张详尽的地图你知道了每条路的名字、每个节点的位置——ADM九阶段、BDAT四层架构、治理框架、能力框架所有这些构成了一张企业架构的全景地图。战略与决断力 会导航。拿到地图不意味着你能到达目的地。你需要判断当前在哪要去哪哪条路最快前方有没有封路什么时候该绕行TOGAF是地图架构师的判断力是导航仪。地图可以背下来但导航能力只能在真实的决策场景中练出来。比如你知道 Phase A 要做架构愿景但面对真实的业务场景——一个跨部门的大型项目涉及业务合规、数据安全、系统容量——你能判断这个变更值不值得启动完整的架构工作吗还是应该走简化流程这个判断TOGAF 的教材不会替你做出。这就是我备考中最大的认知转变顶层设计的认知构建是第一位的。先建立往哪个方向走的判断力然后才谈得上怎么走的方法论。没有导航的地图只是一张纸没有顶层设计的方法论只是一堆术语。这个认知贯穿了后续所有学习层次。第一层组织架构——企业骨架对架构的深层塑造有了方向感之后接下来要面对的是最现实的问题架构不是在空中搭建的它必须嵌入企业现有的组织权力结构中才能落地。这是备考中最容易被忽视、但对我冲击最大的一层认知企业的组织架构就是企业架构的源代码。TOGAF 中有两个关键视角支撑这个论点视角一Preliminary Phase 的组织模型ADM 的第一步不是做架构而是先回答一个问题——“在我们这个企业里谁来定义架构、谁来做架构、谁来审批、谁来执行、谁来负责”这就是 Preliminary Phase 的核心产出之一组织模型Organizational Model for EA。这听起来像是一份普通的架构团队职责说明书但它的深远影响在于这个组织模型直接决定了后续所有 ADM 阶段能否有效推进。如果组织模型里没有给架构委员会真正的决策权那 Phase G实施治理就是走过场如果组织模型里架构团队被定位为支持角色而非赋能角色那 Phase A 的架构愿景就没人当回事。视角二业务架构四大核心元素之组织映射TOGAF 的业务架构有四个核心元素核心元素回答的问题业务能力Business Capability企业能做什么价值流Value Stream企业如何为利益干系人创造价值信息映射Information Map信息如何在企业中流转组织映射Organization Map谁负责什么权力边界在哪汇报线怎么走这四个元素是平级的——组织映射不是辅助信息而是业务架构的支柱之一。它回答的问题恰恰是其他三个元素无法回答的执行能力的人在哪决策权怎么分布从战略到落地组织架构的四层穿透一旦理解了组织映射的重要性再看企业中的架构问题就会发现一条清晰的因果链科技战略层 └── 组织架构决定了科技的定位是成本中心还是利润中心 这决定了架构工作的天花板——成本中心的架构能做优化 利润中心的架构能做创新。 技术架构层 └── 组织架构决定了架构决策权的分布是集中式架构委员会统一管理 还是各部门各自为政这决定了技术架构是一张总图还是一堆拼图。 项目构建层 └── 组织架构决定了信息传递路径跨部门协作要走几条汇报线 审批要过几道关信息每经过一层组织边界就衰减一次。 这才是跨部门项目推进慢的根因——不是技术问题是组织问题。 落地执行层 └── 组织架构决定了框架搭建效率如果有统一的架构治理组织 标准、规范、工具可以一次性铺开如果各部门独立运作 同样的框架要适配 N 套组织语境落地成本指数级上升。核心认知不理解企业的组织架构就永远在表层做架构。因为任何架构方案最终都要嵌入现有的组织权力结构中才能落地——一个在技术上完美的架构如果违背了组织的权力分布和信息流习惯大概率会被架空。备考 TOGAF 的过程中我反复体会到Preliminary Phase 不是热身而是整个 ADM 的根基——没有组织模型的确认后面的八个阶段都是空中楼阁。第二层元架构——先理解架构的架构理解了组织的约束之后接下来搭建方法论骨架。TOGAF给我的第一个冲击来自**元架构Meta-Architecture**概念。在接触TOGAF之前我对架构的理解停留在应用架构层面——服务怎么拆、接口怎么定、数据怎么流。但TOGAF让我意识到架构本身也需要一个架构来定义。元架构Enterprise Meta-Architecture ├── 架构原则Architecture Principles—— 不可妥协的约束 │ 例数据所有权归属于业务部门IT部门负责数据管理 ├── 架构愿景Architecture Vision—— 目标状态的概要描述 │ 例3年内建成以客户为中心的全渠道服务平台 ├── 架构方法ADM—— 怎么一步步做架构 │ 例Preliminary → A → B → C → D → E → F → G → H └── 架构治理Architecture Governance—— 谁说了算、怎么说了算 例架构委员会、架构合规评审、架构契约IBM AT 的三大模型与 TOGAF 的四层架构有天然的映射关系——AT 的 Architecture Overview 和 Component Model 关注解决方案怎么做对应 TOGAF 的应用架构和技术架构而 TOGAF 在此基础上向上延伸了业务架构和数据架构形成了更完整的从战略到基础设施的全景视图。两者结合形成了从战略到代码的完整思维链路。第三层四层架构——从我只管应用层到每一层都重要TOGAF定义的四大架构领域BDAT是我备考中反复咀嚼的核心概念业务架构Business Architecture ↑ 定义业务战略、治理、组织和关键业务流程 ↑ 为什么做和做什么 数据架构Data Architecture ↑ 定义数据资产的结构、数据管理资源和数据生命周期 ↑ 数据怎么组织和流转 应用架构Application Architecture ↑ 定义应用系统的蓝图、交互关系和对核心业务流程的支撑 ↑ 用什么系统来做——这是我之前的舒适区 技术架构Technology Architecture ↑ 定义支撑应用和数据部署所需的软硬件基础设施 ↑ 跑在什么上面关键认知转变在接触TOGAF之前我的注意力主要集中在应用架构层——技术栈选型、服务拆分、接口契约设计。TOGAF让我看到业务架构是源头如果业务目标、业务流程、业务能力没有梳理清楚技术方案再优雅也是在错误的方向上跑得更快。数据架构是命脉在大型企业中数据治理谁拥有数据、谁可以使用、如何保证一致性往往比应用架构更重要。技术架构是地基云部署、消息中间件、微服务治理——这些本质上都是技术架构决策它们应该在业务架构和应用架构的约束下做出。一句话总结从聚焦应用架构到理解企业架构的跃迁就是从只关注技术实现到理解每一层的关系和约束——不是放弃技术深度而是在技术深度的基础上增加业务宽度和战略高度。图的认知架构师的通用语言四层架构如果只停留在文字描述很容易变成四堆术语。真正让 BDAT 活起来的是图。一个能让人看懂的架构图抵得上 100 句文字解释。这不是夸张——文字是线性的架构是多维的。用文字描述业务能力→应用服务→技术节点之间的映射关系几百字也说不清一张 ArchiMate 图30 秒就能让所有人对齐认知。TOGAF 和 IBM AT 在用图表达架构上殊途同归——不同阶段画不同的图面对不同的角色用不同的画法。但两者的侧重点和表达体系不同放在一起对比更有启发维度TOGAFArchiMateIBM AT三大产出物建模标准ArchiMateThe Open Group 官方企业架构建模语言无独立建模语言以 UML/类图/组件图/部署图等通用建模手段承载面向高管动机视图Stakeholder/Driver/Goal、业务层全景图Architecture Overview —— 一张图说清我们做什么高层抽象屏蔽技术细节面向技术团队应用层图应用组件/接口/数据流、技术层图节点/设备/网络Component Model —— 静态结构图 动态交互图时序/协作接口、事件流全部展开面向运维技术层部署视图、迁移视图现状→目标Operational Model —— 逻辑部署图 物理部署图哪个节点跑在哪个机房、网络 SLA 怎么保障面向变更管理迁移视图Transition Architecture多阶段路线图隐式体现在 Architecture Decisions 和 Viability 评估中无独立视图两者的核心思路一致不同角色看不同层级的图但所有图共享同一套架构模型。高层用 Architecture Overview / 动机视图快速对齐业务意图技术人员用 Component Model / 应用层图深入细节运维用 Operational Model / 技术层图落实部署——图是架构认知从抽象到具体的桥梁。图的核心价值有三层术语统一当所有人盯着一张图讨论时概念歧义无处藏身。你说客户域我指着图上的边界说是这个吗——对齐只需要一秒钟。这是文字永远做不到的。思路对齐不同角色业务、开发、测试、运维在同一张图的不同视角上找到自己的位置。业务人员看 ArchiMate 业务层的流程和角色技术人员看应用层的组件和接口——各取所需但共享同一个模型。决策可视化架构决策不是写在文档里的文字而是画在图上的选择。“为什么这个服务放在这一层而不是那一层”——图上的位置本身就是决策的视觉化表达比 Architecture Decision Record 更直观。学习 TOGAF 时也花了不少时间学习 ArchiMate 的基本符号体系——不是为了考试OGEA-C103 不考 ArchiMate而是因为能画出清晰的架构图是架构师将复杂认知外化为可沟通成果的核心能力。这个认知是从学会四层架构过渡到用好四层架构的关键一步。第四层道——知道为什么做比知道怎么做更重要这是备考过程中最深层的收获也是我认为TOGAF最有价值的地方——它不是给你一个做架构的配方而是给你一套思考为什么要做架构的哲学。我把它归纳为道层面的三个核心认知认知一暂停一下判断该不该做“在做之前暂停一下先判断是否应该做是架构师最关键的能力。”这是我在学完ADM Phase A架构愿景后的最大感触。Phase A的核心产出是架构工作声明Statement of Architecture Work——本质上就是一份我们为什么要启动这个架构变更的论证文档。在我们的日常工作中经常是业务提一个需求技术直接开始做方案。但TOGAF教会我一个关键动作在动手之前先问这个变更对齐了业务战略吗有替代方案吗不做会怎样这个暂停-判断的动作在涉及多方系统集成的复杂项目中尤其重要。比如一个跨部门的业务联调项目——这不是一个简单的加个接口的技术决策而是涉及业务合规、数据安全、系统容量的综合判断。如果跳过该不该做的思考直接进入怎么做风险是巨大的。认知二战略认知——从做项目到做正确的事TOGAF特别强调战略对齐每一个架构决策都应该回溯到业务战略。这听起来像是正确的废话但真正落地时才发现——大部分技术决策和业务战略之间的链路是断裂的。举一个反例团队曾经为了技术先进性选择了某个框架但该框架的人才市场供给极少导致招聘困难、维护成本高。如果从TOGAF的视角审视——这个决策违背了技术架构应服务于业务能力的原则属于为了技术而技术。战略认知的核心就是架构师的每一次技术选型本质上都是在回答这个选择如何帮助业务成功认知三业务层解读——技术人员的翻译能力TOGAF的四层架构中业务架构是第一层也是我最薄弱的一层。备考中反复学习业务架构相关的内容业务能力模型、价值流、组织映射、业务场景让我意识到一个关键能力缺口技术人员需要具备业务翻译能力——把业务目标翻译为技术需求把技术约束翻译为业务影响。这个能力在跨部门协作中至关重要。比如当多个技术团队协作时如果只会说这个接口QPS要到1000对方可能不理解为什么。但如果能说这个QPS要求是因为业务方预计高峰时段用户并发可能达到X万——沟通效率完全不同。实践备考执行方案——从2月到9月的7个月之旅整体时间线2025年2月 → 启动备考报名艾威培训机构 2025年2月-4月 → 第一阶段TOGAF 9.2 课程完整学习 2025年5月-6月 → 第二阶段TOGAF 10 课程完整学习 2025年7月-8月 → 第三阶段口袋书精读 笔记体系建立 持续刷题 2025年9月 → 参加OGEA-C103考试Part 1 90% / Part 2 85%⚠️关于时间跨度从2025年2月启动到9月考试约7个月。在职备考需要合理规划节奏工作繁忙时段可以适当放缓但不要完全中断保持知识的连续性很重要。第一步选机构——为什么是艾威维度艾威培训自学知识体系完整性✅ 系统化讲解TOGAF 9 10双版本讲师现场答疑⚠️ 需自己拼凑资料容易遗漏重点行业案例✅ 讲师分享多年企业架构咨询经验覆盖金融、保险、制造业等真实案例❌ 缺乏实战场景停留在理论层题库质量✅ 提供10套仿真模拟题 视频讲解⚠️ 网上的免费题目质量参差不齐时间效率中等集中学习 题库训练高摸索时间难以预估适合人群在职人士希望高效通过并学以致用在校学生时间充裕且有自学能力个人感受TOGAF的概念密度极高——Enterprise Continuum、Architecture Repository、Capability-Based Planning、Business Scenario……每个术语背后都有严格定义和关联网络。有经验的讲师能帮你快速建立概念地图这是自学的最大难点。第二步听课——两遍课程两个目的第一遍TOGAF 9.2 课程 → 建立骨架目标不是记住细节而是搞清楚TOGAF的世界长什么样ADM九个阶段Preliminary → A → B → C → D → E → F → G → H → Requirements Management各自的定位四大架构领域BDAT的关系内容元模型中构件之间的关联第二遍TOGAF 10 课程 → 填充血肉有了9.2的基础后重点学习10版的结构性变化。以下是备考中我整理的TOGAF 9 vs 10 六大关键差异变化维度TOGAF 9.2TOGAF 10实践影响文档结构单一巨型文档近千页Fundamental Content Series Guides模块化结构学习门槛大幅降低核心内容精炼指南按需查阅敏捷支持态度模糊留给实践者自行摸索Sprint驱动ADM四种协作模式 DORP节奏机制DevOps/CI/CD一等公民架构师终于有了如何在Sprint中做架构的具体方法数字企业默认面向有正式IT部门的大型企业DPBoK数字从业者知识体系四种组织语境Individual/Team/Team of Teams/Enduring Enterprise创业公司到跨国企业都有适配方案不再是大厂专属架构产出强调完整架构文档和正式评审MVA最小可行架构“Just Enough Architecture, Just in Time”从过度设计vs不设计的两难中找到平衡点EA角色审批门卫gate-keeper项目提交文档→等待审批EA即服务从审批者转型为赋能者按需提供指导解决敏捷团队视架构为阻碍而非助力的老问题ADM灵活性阶段间顺序箭头暗示线性推进取消顺序箭头允许灵活跳转和迭代更贴近实际——架构工作从来不是一步到位的备考需额外掌握的新概念MVA最小可行架构与MVP类比记忆——MVP面向客户MVA面向内部。价值链MVBD最小业务变更→ MVA → MVPPeek-Ahead策略在当前语境下做刚好够用的架构同时确保今天决策不阻碍向更成熟语境的过渡四种敏捷协作模式EA Development Agility → Solution Collaboration → Cross-Development Collaboration → Cross-Functional AgilityDORP节奏每个Sprint结束——Demo演示→ Outcome Management成果管理→ Retrospective回顾→ Planning规划术语更新“内容框架和元模型→TOGAF内容框架和TOGAF企业元模型”“标准信息库→标准库”“治理日志→治理存储库”第三步啃口袋书——两遍法《The TOGAF Standard, 10th Edition - A Pocket Guide》中文版是备考核心。第一遍通读约3-4天快速过一遍把课堂上学到的碎片知识串联起来。遇到不懂的做标记不要卡住——后面的内容往往能帮理解前面的概念。第二遍精读约1周每读完一章问自己三个问题这一章解决了什么问题和其他章节是什么关系在我的实际工作中能找到对应的场景吗同时建立笔记体系笔记结构 ├── 一、核心概念词典 │ ├── 术语名英文中文 │ ├── 官方定义用自己的话复述 │ ├── 所属ADM阶段/领域 │ └── 与相关概念的区分⚠️易混淆项 │ ├── 二、ADM阶段速查表 │ ├── Phase名称 → 目标一句话→ 关键输入/输出 → 常见陷阱 │ ├── 三、错题本 │ ├── 题目摘要 → 我的答案 vs 正确答案 → 错因分析 → 知识点回溯 │ └── 四、TOGAF 9→10差异清单 ├── 新增概念 / 修改内容 / 已废弃术语这套笔记在考前最后一周发挥了决定性作用——我只复习笔记不再翻书。第四步刷题——10套模拟题三轮打法艾威培训提供了10套模拟题覆盖Part 1知识级和Part 2应用级。刷题节奏第一轮裸刷不看答案严格计时 ├── 目的检验真实水平暴露知识盲区 └── 结果第一轮正确率约60%-70%正常现象 第二轮带解析刷 ├── 目的理解出题意图和解题思路 ├── 错题分类 │ A类 - 概念混淆如 Governance vs Implementation Governance │ B类 - 细节遗漏如某个阶段的输出物记不全 │ C类 - 场景误判L2情景题没匹配到正确的ADM阶段 └── 重点不仅知道正确答案还要知道错误选项为什么错 第三轮只刷错题 ├── 目的消灭盲区 ├── 方式隔几天重做连续两次做对 → 标记已掌握 └── 标准如果第三次还错 → 回到口袋书重新理解对应知识点Part 1 vs Part 2 差异化策略考试部分题型策略Part 1知识级40道单选题60分钟60%及格24/40概念为王。术语辨析、ADM各阶段目标/输出物、元模型构件关系。多刷题形成肌肉记忆Part 2应用级8道情景分析题90分钟60%及格24/40分场景匹配为核心。每题给企业场景需判断处于ADM哪个阶段、该做什么决策。选项分值递减5分→3分→1分→0分必须选最优Part 2解题心法快速定位关键词 → 匹配ADM阶段 → 排除干扰项 → 选最优解。例如“架构团队正在与业务高管确认战略目标和约束条件” → Phase A架构愿景“识别现有系统的能力和差距” → Phase B-G具体架构领域分析。反思回头看——哪些做得好哪些可以更好做得好的三件事1. 先9后10的学习顺序是对的虽然最终考的是TOGAF 10但先学9.2再学10非常有效。9.2的结构更经典、社区讨论更丰富打好底子后再理解10的变化就像站在坚实的地基上看新楼层——一目了然。2. 口袋书的两遍法性价比极高很多人推荐直接刷题但我发现不读透口袋书就刷题是事倍功半的。TOGAF的题目不是靠记住答案能应付的——特别是Part 2的情景分析题必须真正理解ADM逻辑才能选对。口袋书虽然不到200页但每句都是精华。3. 错题分类比反复刷有效得多最初想过把10套题刷到全对但效率很低——有些题确实懂了反复做是浪费时间。分类之后可以把精力集中在真正的薄弱环节。如果重来可以优化的地方1. 更早开始结合实际工作思考备考期间我主要聚焦于通过考试但考完后才意识到——如果边学边在工作中找对应场景理解会深刻得多。比如我做Harness Engineering框架落地时回头看发现Phase A架构愿景对应Spec制品定义Phase B-G架构开发对应Rule/Skill/Agent设计Phase H架构变更管理对应Hook机制。2. Part 2情景题应该更早开始练习我把大部分时间花在Part 1的概念记忆上Part 2练习偏晚。实际上Part 2才是真正拉开差距的地方——它考察的是对方法论的理解深度和应用能力。3. 可以做一个知识点→题目反向索引备考后期发现某些知识点反复出现在不同套题中但散落各处。如果一开始就建立知识点→涉及题目编号的反向索引复习效率会更高。意识考完之后我真正获得了什么不只是一张证书坦率地说TOGAF认证本身不会帮你写出更好的代码也不会自动让你的方案被采纳。它给你的东西更底层一种看待系统的方式。“道”理解为什么做“做之前暂停一下先判断是否应该做。”这是TOGAF给我最深层的认知改变。架构师的核心价值不是能设计出多复杂的系统而是能在正确的时间做出正确的设计决策。ADM Phase A的存在本身就说明了这一点——在开始任何架构工作之前先确认这件事对齐了战略目标、有足够的业务价值、并且我们真的需要做。在日常工作中这意味着接到需求时先问这个变更对齐了哪个业务目标技术选型时先问这个选择如何帮助业务成功设计方案时先问有没有更简单的方案过度设计是不是一种风险“法”知道怎么做ADM方法论给了我一套完整的架构动作框架。这里展开几个我备考中最有收获的具体技术1. 利益干系人管理Stakeholder Management——最重要也最容易被忽视TOGAF反复强调不同的利益干系人关心不同的视角需要不同的沟通产物。利益干系人类型关心什么应提供的架构产物沟通方式C-Level高管战略对齐、投资回报、风险架构愿景、业务能力模型一页纸摘要高层简报用业务语言业务部门负责人流程影响、能力提升、KPI业务架构、差距分析、迁移计划业务场景演示技术团队技术选型、接口规范、实施细节应用/数据/技术架构、解决方案构建块SBB技术文档架构评审合规/安全法规遵循、风险评估架构原则、安全架构、合规矩阵正式评审会议运维团队部署方案、监控策略、SLA技术架构、部署图、运营模型运维手册演练我在实际工作中的应用在代销基金项目中利益干系人管理贯穿始终——对外需要与中登中国证券登记结算公司、国泰基金等多个外围渠道协调联调节奏每个渠道有自己的排期窗口和对接规范对内涉及业务部门产品、合规、科技部门多个中心及多个科室的跨组织协作每个团队关注点完全不同。如果不做利益干系人矩阵——谁来定方案谁来确认联调窗口谁对合规负责——信息同步会断裂、预期管理会失控。TOGAF 的 Stakeholder Management 方法论让我在每个节点都能回答这个阶段应该让谁参与、给谁看什么。2. 架构治理Architecture Governance——让架构决策有法可依TOGAF的治理框架包括三个层次架构治理体系 ├── 架构委员会Architecture Board │ └── 跨部门决策机构审批重大架构变更和例外处理 ├── 架构契约Architecture Contract │ └── 开发团队和架构团队之间的合同明确各自的义务和交付标准 └── 架构合规评审Architecture Compliance Review └── 在关键里程碑检查项目是否遵循架构规范反思在实际项目中虽然有一定程度的架构评审但缺乏正式的治理机制。TOGAF让我意识到——没有治理的架构只是建议有治理的架构才是标准。3. 架构原则Architecture Principles——不可妥协的边界TOGAF要求每个企业定义自己的架构原则。原则不是最佳实践建议而是不可妥协的约束。例如原则示例“数据所有权归属于业务部门IT部门负责数据管理和技术实现。”一旦定义了原则所有架构决策都必须在原则框架内进行。这解决了每个人都有自己的’最佳实践’的混乱局面。4. 架构能力框架Architecture Capability Framework——不止是做事更要建立做事的能力TOGAF强调组织不仅要做好单个架构项目更要建立持续的架构能力。包括架构团队的技能矩阵和角色定义架构工具和存储库的建设架构方法论在组织内的推广和培训这让我对Harness Engineering框架的推广有了新的理解——它不只是一套工具更是团队架构能力的系统化建设。5. 差距分析Gap Analysis——所有架构工作的核心动作TOGAF中几乎所有ADM阶段都会涉及差距分析Baseline Architecture当前状态 ↓ 差距分析 → 识别 Gap Items ↓ Target Architecture目标状态 ↓ 迁移规划 → Roadmap 和 Transition Architectures这个简单的方法论可以迁移到很多场景技术债治理现状 vs 目标、团队能力建设当前技能 vs 需要技能、UX优化当前体验 vs 目标体验。“术”回到日常工作中的具体改变1. 通用语言——减少沟通摩擦以前和后端团队讨论架构时经常鸡同鸭讲。TOGAF提供了标准化的词汇体系和分层视角让我们能在同一个语义空间对话“这个变更属于Phase B业务架构层面不需要动应用架构和技术架构”“这个接口定义属于Architecture Building BlockABB需要在Solution Building BlockSBB实现之前确定”2. 结构化检查清单——不再遗漏关键步骤ADM的九个阶段是我做架构决策时的检查清单有没有明确的架构愿景Phase A当前状态和目标状态的差距分析做了吗Gap Analysis利益干系人的期望管理了吗Stakeholder Management迁移计划可行吗风险考虑了吗Phase E-F3. MVA思维——从完美主义到刚好够用TOGAF 10的MVA理念对我触动最大。在快速迭代的业务环境中过度设计本身就是风险。架构师的工作是在每个节点提供刚好够用的架构指导不多也不少。你可以带走的三件事1. 不要试图一次记住所有概念TOGAF体系庞大——ADM九个阶段 × 四大架构领域 × 内容元模型 × 治理框架 × 参考模型。正确的做法是先建立整体地图知道有哪些东西再逐步深入细节理解它们的关系。2. 把学习和工作绑在一起每学到一个概念就问自己“在我的项目中哪里用到了类似的东西”Stakeholder Management → 代销基金项目对外多渠道协调中登、国泰等对内多部门多中心多科室信息同步与预期管理Architecture Repository → 团队正在建设的知识库和规范文档体系Gap Analysis → 技术债梳理时的现状-目标差距分析3. 考证只是起点不是终点TOGAF证书永久有效不像PMP需要续证但这不代表考完就万事大吉。真正有价值的是备考中建立的思维方式以及后续在实践中不断深化的认知。我现在的习惯是每做完一个重要架构决策回头看看它对应TOGAF的哪个阶段——这种事后审计比任何考试都更能提升能力。更重要的是TOGAF 本质上是一个方法论框架和索引Index而不是一套自给自足的全家桶。它告诉你在什么阶段应该关注什么但具体怎么执行需要配合更多不同层面的知识和技术领域配套方法论/知识体系与 TOGAF 的互补关系项目管理PMBOK、PRINCE2TOGAF 负责做什么架构PMBOK 负责怎么管理架构项目的进度和资源业务架构BIZBOK业务架构知识体系TOGAF 定义了业务架构的位置BIZBOK 提供了业务架构的深度方法论安全架构SABSATOGAF 在 ADM 各阶段埋了安全关注点SABSA 是专门的安全架构框架与 TOGAF 天然互补敏捷交付Scrum、SAFeTOGAF 10 已内置敏捷协作模式但具体的 Sprint 节奏、需求拆分、持续交付需要敏捷框架支撑IT 治理COBITTOGAF 的架构治理 COBIT 的 IT 治理覆盖从架构决策到 IT 运营的全链路TOGAF 的价值不在于它包办一切而在于它给了你一张全景地图——让你知道每个问题应该去哪个领域找答案每个领域的方法论应该放在架构的哪个阶段使用。就像一本索引它不替代任何一本具体的书但让你知道该去翻哪一本。附录备考资源清单资源说明推荐度艾威TOGAF 10培训课程系统化讲解行业案例10套题库⭐⭐⭐⭐⭐ 必选《TOGAF Standard, 10th Edition - A Pocket Guide》中文版官方精简版备考核心⭐⭐⭐⭐⭐ 必选艾威10套模拟题Part 1 Part 2覆盖全部考点含视频讲解⭐⭐⭐⭐⭐ 必选TOGAF 9.2课程视频作为前置基础学习⭐⭐⭐⭐ 推荐The Open Group官网标准文档权威参考深入研究者选读⭐⭐⭐ 选读参考资料[1] TOGAF认证价值与市场需求数据综合来源The Open Group官方统计、搜狐教育TOGAF认证分析写在最后90%和85%的成绩让人开心但更重要的收获是从一个会做架构的实践者变成了一个知道为什么这样做、还能判断该不该做的思考者。如果你也拿到了Open CA或者正在用IBM Architect Thinking指导日常工作但总觉得缺少一套系统化的方法论框架——那么TOGAF值得你投入这7个月。不是为了那张纸而是为了获得一种更清晰的思维方式以及一套与全球70,000架构师共享的通用语言。架构师的成长从来不是证书的堆叠而是认知的跃迁。从术到法再到道——这条路TOGAF帮我走完了第一程。关于TOGAF备考或企业架构实践的交流欢迎在评论区讨论。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
