Arch Day 1: TOGAF深度 — 裁剪的艺术与金融落地

日期: 2026-03-30 阶段: 第一阶段 - 架构基础 标签: #TOGAF #ADM #架构框架 #金融架构 #裁剪

---

核心概念

一句话定义

TOGAF不是一套必须照搬的流程模板，而是一个可裁剪的架构方法论工具箱 — 它的价值不在于完整执行ADM的每个Phase，而在于为组织提供一种可重复、可治理的架构开发方式。

为什么资深架构师仍需关注

很多有经验的架构师对TOGAF持两种极端态度：要么视为"认证考试内容、实际没用"，要么过度依赖导致"架构象牙塔"。资深架构师需要关注TOGAF的真正原因有三：

1. 治理语言统一: 在大型金融机构中，架构治理委员会(Architecture Board)需要共同的评审标准和交付物定义。TOGAF提供了这套"协议层"
2. 裁剪能力本身是核心竞争力: 知道ADM的哪些环节可以跳过、合并、简化，这个判断力才是高级架构师的真正价值
3. 与其他框架的互操作: TOGAF的Content Framework和Enterprise Continuum概念，是连接Zachman分类法、BIAN银行模型、ArchiMate建模语言的"元框架"

常见误区与反模式

---

知识点详解

知识点1: ADM各Phase精要 — 裁剪视角

ADM(Architecture Development Method)包含Preliminary Phase加上Phase A-H和Requirements Management。以下不重复教科书内容，而是从裁剪视角讲每个Phase的核心判断点：

Preliminary Phase: 架构能力建立

核心问题: 组织是否已有架构能力？如果有，是增强还是重建？

裁剪要点:

• 如果组织已有成熟的架构治理(如银行)，这个Phase可以简化为差距评估 — 现有架构能力 vs 所需架构能力
• 如果是初创/中型企业首次引入架构实践，这个Phase反而是最重要的 — 决定了架构团队的定位、治理模型、工具链

金融行业特殊考量:

• 必须确认Architecture Board与Risk Committee、Compliance Committee的关系
• 需要明确架构决策与监管报送(如BCBS 239数据治理)的衔接

金融企业Preliminary Phase的关键输出:
├── Architecture Governance Framework (与三道防线对齐)
├── Architecture Principles (含监管约束)
│   ├── 原则: 客户数据主权 → 约束: GDPR/个保法
│   ├── 原则: 系统可审计 → 约束: 银保监会检查
│   └── 原则: 业务连续性 → 约束: RPO/RTO监管要求
├── Tailored ADM (裁剪后的开发方法)
└── Architecture Repository初始化

Phase A: Architecture Vision

核心问题: 业务诉求是什么？架构变革的范围和边界在哪？

裁剪要点:

• 对于战略级项目(数字化转型、核心系统重建)，Phase A需要完整执行，产出正式的Statement of Architecture Work
• 对于战术级项目(新增一个渠道、接入一个外部系统)，Phase A可以合并到Phase B，用一个Architecture Decision Record替代

关键技巧 — Stakeholder Map不是画完就算:

利益相关方分析的四象限(Power-Interest Grid):

           高影响力
              |
    管理预期   |   密切合作
   (CRO/CFO)  |  (CIO/业务负责人)
              |
  ──────────────────────── 高关注度
              |
    保持知情   |   及时响应
   (审计部门)  |  (开发团队/用户)
              |
           低影响力

金融行业特殊: 合规/风控部门虽然"不出钱"，
但拥有一票否决权，必须放在"密切合作"象限

Phase B/C/D: 三大架构域

裁剪核心原则: 这三个Phase的执行顺序和深度取决于项目类型：

Phase B (Business Architecture) — 裁剪判断:

• 如果组织已有Business Capability Model(如对标BIAN)，可以跳过能力建模，直接做Gap Analysis
• 如果是纯技术项目(如中间件升级)，可以只做Impact Assessment而非完整的业务架构

Phase C (Information Systems Architecture) — 裁剪判断:

• 数据架构和应用架构可以拆成两个子迭代
• 如果组织已有Enterprise Data Model，数据架构部分只需做增量映射

Phase D (Technology Architecture) — 裁剪判断:

• 云原生时代，很多技术选型已由云平台决定
• 关注哪些技术决策仍需架构治理(如多云策略、混合云网络、加密方案)

Phase E/F: 机会与迁移规划

核心观点: 这两个Phase在实际项目中经常被跳过，但在金融行业绝不能跳过。原因：

1. 金融系统的迁移涉及资金安全，必须有明确的cutover计划
2. 存量系统通常有强依赖(批量处理、日终清算)，迁移必须做dependency analysis
3. 监管要求回退(rollback)能力

裁剪方法: 将E/F合并为一个"Implementation & Migration Planning"阶段，但必须包含:

• 迁移波次(Wave)规划
• 每波次的Go/No-Go检查点
• 数据迁移验证策略
• 业务连续性保障方案

Phase G/H: 实施治理与变更管理

裁剪要点:

• Phase G可以与项目管理办公室(PMO)的工作合并
• Phase H是架构持续治理的关键 — 如果只做一次ADM就不管了，架构债务会迅速积累

知识点2: TOGAF vs Zachman vs FEAF — 何时用哪个

这三个框架不是竞争关系，而是不同抽象层次的工具：

实践建议:

• 大型银行/保险: TOGAF ADM + Zachman分类 + BIAN行业参考。用TOGAF做流程，Zachman做架构资产管理，BIAN做行业对标
• 金融科技: TOGAF裁剪版(只用Phase A/B/D) + 轻量级ADR。不需要Zachman的完整分类
• 政府金融监管: FEAF + TOGAF治理。FEAF提供合规参考，TOGAF提供治理流程

补充框架: ArchiMate

ArchiMate不是与TOGAF对标的框架，而是TOGAF的建模语言补充:

• TOGAF说"做什么"(交付物)
• ArchiMate说"怎么画"(建模符号)
• 二者的关系类似于"软件工程方法论"与"UML"的关系

ArchiMate三层模型与TOGAF ADM的映射:

ArchiMate层     TOGAF Phase    核心视图
──────────────────────────────────────────
Business Layer  Phase B        Business Process Cooperation
                               Business Function Viewpoint
Application Layer Phase C      Application Cooperation
                               Application Usage Viewpoint
Technology Layer  Phase D      Technology Usage
                               Infrastructure Viewpoint
Strategy Layer   Phase A       Strategy Viewpoint
                               Capability Map
Implementation   Phase E/F     Project Viewpoint
& Migration                    Migration Viewpoint

知识点3: TOGAF Content Framework深度

Content Framework定义了架构交付物的标准分类。资深架构师需要理解的不是"有哪些交付物"，而是哪些交付物在什么场景下是必须的：

Tier 1 — 始终需要(任何项目):

• Architecture Principles
• Stakeholder Map
• Architecture Decision Records (ADR)
• Gap Analysis

Tier 2 — 战略项目需要:

• Business Capability Map
• Value Stream Map
• Solution Concept Diagram
• Architecture Roadmap

Tier 3 — 大型复杂项目需要:

• Application Portfolio Catalog
• Technology Standards List
• Data Entity/Data Component Catalog
• Detailed Architecture Models (ArchiMate)

Tier 4 — 按需(特定治理要求):

• Architecture Compliance Report
• Architecture Contract
• Implementation Governance Model

---

对比分析

架构框架综合对比

TOGAF裁剪场景决策表

---

架构设计实操

实操: 为一家金融科技公司提取架构愿景(Phase A输出)

设计背景

假设你是一家中型金融科技公司(做跨境支付)的架构师，公司要从单体应用向微服务架构演进，同时需要拿到新的市场牌照(如欧盟PSD2)。

设计方案

Step 1: Stakeholder Analysis

利益相关方清单:
┌─────────────────────────────────────────────┐
│ 密切合作(高影响+高关注):                       │
│  - CTO: 技术战略决策者                         │
│  - 合规总监: 牌照申请要求明确                    │
│  - 支付业务负责人: 核心业务owner                 │
├─────────────────────────────────────────────┤
│ 管理预期(高影响+低关注):                       │
│  - CEO: 只关注进度和ROI                        │
│  - CFO: 关注投资回报                           │
├─────────────────────────────────────────────┤
│ 及时响应(低影响+高关注):                       │
│  - 开发团队: 日常执行者                         │
│  - 运维团队: 关心运维复杂度                      │
│  - QA团队: 关心测试策略                         │
├─────────────────────────────────────────────┤
│ 保持知情(低影响+低关注):                       │
│  - 外部审计: 年度合规审计                       │
│  - 合作银行: 接口变更影响                       │
└─────────────────────────────────────────────┘

Step 2: Architecture Vision Statement

架构愿景声明(Architecture Vision):

"在未来18个月内，将现有单体支付系统演进为基于领域驱动设计的
微服务架构，实现：
1. 支付处理能力从100TPS提升至2000TPS
2. 新市场(欧盟)上线时间从6个月缩短至6周
3. 满足PSD2/PCI-DSS的合规要求
4. 核心系统可用性达到99.99%

约束条件：
- 迁移期间不中断现有业务
- 总投资预算不超过$5M
- 第一波次必须在6个月内完成"

Step 3: 关键架构原则(Architecture Principles)

ADR (Architecture Decision Record)

ADR-001: 采用TOGAF裁剪版作为架构方法论

状态: 已批准
日期: 2026-03-30

背景:
公司正在进行核心系统现代化，需要一个结构化的架构方法论来
指导转型。团队有15名开发人员，架构师2名。

决策:
采用TOGAF ADM裁剪版，具体裁剪方案:
- Preliminary Phase: 简化为2天workshop(已有基础架构治理)
- Phase A: 完整执行(战略项目)
- Phase B: 重点做能力建模和价值流(对齐BIAN参考模型)
- Phase C: 拆分为数据架构(优先)和应用架构(第二波次)
- Phase D: 云优先策略，技术选型做ADR而非完整技术架构文档
- Phase E/F: 合并，产出3波次迁移计划
- Phase G: 与现有PMO流程合并
- Phase H: 建立月度架构评审

理由:
1. 完整执行ADM对15人团队过于沉重
2. 核心需要的是架构决策的治理，而非完整文档
3. 保留Phase A/B/E/F的完整度，因为业务转型+迁移风险高

后果:
- 团队需要TOGAF基础培训(1天)
- 每个Phase产出ADR而非完整交付物
- 架构评审纳入月度管理会议

权衡取舍

---

AI增强实践

本日AI提效方法

1. 利益相关方分析: 用AI分析组织架构图和历史会议纪要，快速识别隐藏的利益相关方
2. 架构原则生成: 给AI提供行业监管要求，让它生成Architecture Principles初稿
3. 裁剪方案推荐: 描述项目特征，让AI推荐ADM裁剪方案

AI辅助的具体Prompt示例

Prompt 1: 架构原则生成

作为一名企业架构师，我正在为一家跨境支付金融科技公司制定架构原则。
公司背景：
- 当前：单体Java应用，日均处理50万笔交易
- 目标：微服务架构，支持欧盟市场扩展
- 监管：PSD2、PCI-DSS、GDPR、中国个保法

请生成8-10条架构原则(Architecture Principles)，每条包含：
1. 原则名称
2. 原则声明(一句话)
3. 理由(为什么需要这个原则)
4. 影响(这个原则对架构设计的具体约束)

要求：
- 不要泛泛的原则(如"安全性"这种太空)
- 要具体到跨境支付+金融合规场景
- 考虑中国和欧盟双市场的差异

Prompt 2: ADM裁剪方案

我需要为以下项目裁剪TOGAF ADM:
- 项目类型：核心系统微服务化改造
- 团队规模：2架构师 + 15开发 + 3QA
- 项目周期：18个月
- 行业：金融(跨境支付)
- 约束：迁移期间不中断业务

请对ADM的每个Phase给出裁剪建议:
1. 是否执行(完整/简化/跳过)
2. 如果简化，保留哪些关键活动
3. 每个Phase的建议时长
4. 每个Phase的最小交付物

AI生成 vs 人工判断的边界

关键洞察: AI在"生成结构化内容"方面非常强，但在"组织政治判断"和"风险优先级排序"方面需要人的经验和直觉。

---

与Web3/DeFi的关联

深度思考: TOGAF在Web3项目中的适用性

Web3项目通常不会正式采用TOGAF，但其核心思想仍然适用：

• Phase A的Architecture Vision → 对应Protocol的Whitepaper和Design Goals
• Phase B的Business Architecture → 对应Tokenomics和Incentive Design
• ADR(Architecture Decision Record) → 在Web3中更加重要，因为合约部署后不可变，决策成本极高

---

今日思考

思考1: TOGAF的裁剪标准到底是什么？

裁剪的核心标准不是"项目大小"，而是架构决策的不可逆程度。如果一个架构决策很容易回退(如选择哪个UI框架)，那相关的Phase可以简化。如果决策不可逆(如数据库选型、加密方案、牌照约束)，那必须完整执行对应的Phase。

这个原则在金融行业尤其重要：金融系统的很多决策(如对账模式、清结算架构、数据本地化)一旦确定就极难变更，因为涉及监管报备和业务连续性。

思考2: 为什么大多数TOGAF实施都失败了？

我观察到的最大原因不是框架本身的问题，而是架构师把自己定位为"文档产出者"而非"决策促进者"。成功的TOGAF实施中，架构师的角色是：

• 促进利益相关方对齐(不是自己写文档)
• 做trade-off分析(不是追求"最优方案")
• 建立治理机制(不是一次性产出)

失败的TOGAF实施中，架构团队像一个"文档工厂"，产出大量无人阅读的架构文档。

思考3: 在敏捷/DevOps时代，TOGAF还有未来吗？

TOGAF的未来不在于ADM流程本身，而在于它的治理理念和元模型(Content Framework)。具体来说：

• ADM的瀑布式执行确实过时了，需要与SAFe的Architecture Runway、Spotify模型等融合
• 但Architecture Principles、Architecture Repository、Architecture Compliance Review这些概念，在微服务和云原生时代反而更重要(因为分布式系统的决策更分散，更需要治理)

---

面试题准备

Q1: 如何为一个金融企业做架构裁剪？

30秒版本: 架构裁剪的核心标准是"架构决策的不可逆程度"。对于金融企业，我会根据项目类型(转型/新建/迁移)确定哪些ADM Phase需要完整执行，哪些可以简化。不可逆决策(如清结算架构、数据合规)对应的Phase必须完整执行，可逆决策对应的Phase可以用ADR替代。

2分钟版本:

我的裁剪方法论有三步：

第一步是评估项目特征矩阵。我会从四个维度评估：业务影响范围(单系统/跨系统/企业级)、技术不可逆程度(高/中/低)、合规要求(有/无)、团队架构成熟度(高/中/低)。每个维度决定对应Phase的执行深度。

第二步是确定必须保留的Phase。在金融行业，Phase A(Vision)和Phase E/F(Migration)几乎不能跳过——Vision确保与业务战略对齐，Migration确保不中断运营。Phase B/C/D根据项目重心裁剪。

第三步是用ADR替代完整交付物。不是不做架构决策，而是用轻量的ADR(Architecture Decision Record)替代200页的架构文档。每个ADR包含：背景、决策、理由、后果。

实际案例：我在金融零售系统项目中，将18个月的完整ADM裁剪为6个月的迭代式架构开发。保留了Phase A(2周)、Phase B(3周重点做能力建模)、Phase D(4周重点做微服务划分)、Phase E/F(6周做3波次迁移)。Phase C的数据架构与Phase D并行。Phase G融入Sprint Review。产出了15个ADR而非完整架构文档。

追问准备:

• 追问: 如何处理裁剪后的合规审计？ → 每个裁剪决策本身就是一个ADR，审计时可以展示"我们做了有意识的裁剪，而非遗漏"
• 追问: 团队不懂TOGAF怎么办？ → 只需要培训两个概念：ADR和Architecture Principles。其他的由架构师负责
• 追问: 裁剪后如何保证质量？ → 质量保证从"交付物检查"变为"决策质量检查"——每个ADR必须经过Architecture Review

Q2: TOGAF的局限性是什么？你会如何弥补？

30秒版本: TOGAF最大的局限性是它是"瀑布式思维"在架构领域的映射，与敏捷/DevOps的持续交付理念冲突。我会用"轻量治理+持续架构"来弥补：保留TOGAF的治理框架(Principles/Repository/Compliance)，但用ADR和Architecture Fitness Functions替代Phase式的交付。

2分钟版本:

TOGAF有三个核心局限性：

第一，假设架构可以"设计完再开发"。这在敏捷时代不成立，特别是金融科技行业迭代速度快，等你做完Phase A到D，市场已经变了。弥补方法：采用"Just Enough Architecture"理念，每个Sprint都包含架构活动。

第二，缺少对技术演进的处理。TOGAF的Technology Architecture假设技术选型是相对稳定的，但云原生时代技术栈变化很快(今天用ECS明天可能转Serverless)。弥补方法：引入Architecture Fitness Functions——用自动化测试来验证架构约束是否被满足。

第三，低估了组织政治因素。TOGAF的Stakeholder Management很理想化，现实中架构决策受政治因素影响很大(谁有预算、谁有话语权)。弥补方法：架构师需要修炼"影响力技能"，不能只靠流程和文档。

我的补充工具箱：

• SAFe的Architectural Runway — 解决敏捷中的架构活动安排
• Architecture Fitness Functions — 自动化架构合规检查
• Wardley Map — 解决技术演进的战略判断
• Team Topologies — 解决组织与架构的映射

追问准备:

• 追问: 你觉得未来架构框架会怎么演进？ → 从"Phase-based"到"Event-driven Architecture Governance"，架构治理应该像监控告警一样是持续的
• 追问: TOGAF认证有价值吗？ → 对初级架构师有帮助(建立共同语言)，对资深架构师价值有限(裁剪能力更重要)

---

学习资源

---

明日预告

Day 2: 业务能力建模(高级) — 从TOGAF的架构框架深入到业务架构的核心工具。将学习L0-L3能力层级设计原则、BIAN银行业参考模型、能力热力图与投资决策映射。实操环节将对标BIAN为数字银行画完整的能力地图。