Arch Day 7: Week1综合实战 — 从战略到架构的完整推导

日期: 2026-04-05 阶段: 第一阶段 - 架构基础 标签: #综合实战 #端到端 #方法论工具箱 #自评 #架构推导

---

核心概念

一句话定义

今天不学新工具，而是综合运用Week1所有工具做一次完整的"从战略到架构"推导 — 验证你是否能将TOGAF、能力建模、价值流、流程架构、Wardley Map和商业模式分析串成一条连贯的架构推理链。

为什么需要综合实战

1. 工具之间的连接比单个工具更重要: 单独会用每个工具只是"会操作"，把它们串起来才是"会架构"
2. 暴露盲区: 综合练习会暴露你在某个工具上的薄弱环节
3. 建立个人方法论: 不是每个项目都需要所有工具，综合实战帮你判断"什么场景用什么工具"
4. 面试实战模拟: 架构面试经常给一个场景让你"从头推导"

Week1工具链全景

战略层                          操作层
  │                               │
  ▼                               ▼
Wardley Map ──→ 能力建模 ──→ 价值流分析 ──→ 流程架构
(build/buy/     (做什么)    (价值在哪)    (怎么做)
 partner)           │            │             │
  │                 │            │             │
  ▼                 ▼            ▼             ▼
商业模式 ←── 投资优先级 ←── 差距分析 ←── STP/KPI
(赚什么钱)   (花多少钱)   (缺什么)    (好不好)
  │
  ▼
牌照/合规约束 ──→ TOGAF裁剪 ──→ 架构治理
(必须做什么)      (怎么组织)     (怎么管)

全链路:
战略(Why) → 能力(What) → 价值(Where) → 流程(How) → 系统(With What)

---

综合实战: "跨境电商支付"端到端架构推导

业务场景

客户: 一家跨境电商平台(类似Shein/Temu)
现状:
- 日均订单: 50万笔
- 主要市场: 北美、欧洲、东南亚
- 当前支付: 接入了Stripe和支付宝国际版
- 痛点:
  1. 支付成功率只有78%(行业标杆>92%)
  2. 退款处理平均7天(目标<3天)
  3. 每年因欺诈损失>$5M
  4. 想拓展拉美和中东市场
  5. 支付团队只有5人(工程师3+PM1+运营1)
- IT预算: 年度$3M(支付相关)
- 战略目标: 1年内支付成功率>90%，2年内覆盖50+国家

Step 1: 商业模式分析(Day 6工具)

跨境电商支付的商业模式Canvas:

Value Proposition:
  对商户(电商平台自身): 高成功率+低成本+全球覆盖
  对消费者: 本地化支付方式+安全+便捷退款

Revenue Streams(支付部分):
  - 支付手续费(2-5%，含通道成本)
  - 外汇加价(1-2%汇率差)
  - 反欺诈增值服务

Licenses & Compliance:
  - 当前: 无自有牌照(通过Stripe/支付宝)
  - 约束: 不能自己做清算，依赖第三方
  - 机会: 如果自建支付能力，可以降低成本

关键问题:
  Q: 应该自建支付能力(申请牌照)还是继续依赖第三方？
  → 这是一个典型的Wardley Map分析场景

Step 2: Wardley Map分析(Day 5工具)

跨境电商支付的Wardley Map:

Y轴(价值链)  ↑
             |
消费者需求   | [便捷支付] [快速退款] [本地方式]
             |     |          |          |
电商服务     | [收银台] [退款服务] [支付路由]
             |     |       |        |
             | [风控引擎] [汇率管理] [对账引擎]
             |     |       |        |
支付通道     | [Stripe] [支付宝] [本地PSP]
             |     |       |        |
基础设施     | [卡组织] [银行网络] [清算系统]
             |
             └───────────────────────────→ X轴(演进)
              Genesis  Custom  Product  Commodity

组件演进分析:

┌───────────────┬───────────┬────────────────────┐
│ 组件           │ 演进阶段   │ Build/Buy决策       │
├───────────────┼───────────┼────────────────────┤
│ 收银台UI       │ Product   │ BUY(Stripe等提供)   │
│ 支付路由       │ Custom    │ BUILD(核心差异化)   │
│ 风控引擎       │ Custom    │ BUILD(数据是优势)   │
│ 退款服务       │ Product   │ BUY+定制             │
│ 汇率管理       │ Product   │ BUY(汇率API)        │
│ 对账引擎       │ Custom→Prod│ BUILD(与内部系统深耦合)│
│ Stripe通道     │ Commodity │ BUY(直接使用)       │
│ 本地PSP通道    │ Product   │ BUY(需要接入多个)   │
│ 卡组织/银行    │ Commodity │ N/A(行业基础设施)   │
└───────────────┴───────────┴────────────────────┘

关键战略推演:
1. 支付路由是核心差异化 → 自建
   为什么: 智能路由可以提升支付成功率5-10%

2. 风控引擎是数据壁垒 → 自建
   为什么: 电商有独特的交易数据(购物行为+支付行为)

3. 收银台不需要自建 → 用Stripe/Adyen的
   为什么: 已是Product/Commodity，自建无优势

4. 不需要申请支付牌照(短期)
   为什么: 聚合多个PSP比自建清算效率更高
   通过PSP聚合可以覆盖50+国家

Step 3: 能力建模(Day 2工具)

跨境电商支付能力地图(L0-L2):

L0: 支付处理
├── L1: 支付收单
│   ├── L2: 收银台管理 [战略:3 成熟:4 差距:-1 🟢]
│   ├── L2: 支付方式适配 [战略:5 成熟:2 差距:3 🔴]
│   ├── L2: 智能支付路由 [战略:5 成熟:1 差距:4 🔴]
│   └── L2: 3DS认证管理 [战略:4 成熟:2 差距:2 🟡]
├── L1: 资金管理
│   ├── L2: 多币种结算 [战略:4 成熟:3 差距:1 🟡]
│   ├── L2: 汇率管理 [战略:3 成熟:3 差距:0 🟢]
│   └── L2: 资金对账 [战略:4 成熟:1 差距:3 🔴]
├── L1: 退款处理
│   ├── L2: 退款审核 [战略:4 成熟:2 差距:2 🟡]
│   ├── L2: 退款执行 [战略:4 成熟:2 差距:2 🟡]
│   └── L2: 拒付(Chargeback)管理 [战略:5 成熟:1 差距:4 🔴]

L0: 风险控制
├── L1: 交易风控
│   ├── L2: 实时欺诈检测 [战略:5 成熟:2 差距:3 🔴]
│   ├── L2: 规则引擎 [战略:4 成熟:2 差距:2 🟡]
│   └── L2: 风险评分模型 [战略:5 成熟:1 差距:4 🔴]
├── L1: 合规管理
│   ├── L2: 多国KYC/AML [战略:4 成熟:2 差距:2 🟡]
│   └── L2: 制裁筛查 [战略:5 成熟:2 差距:3 🔴]

L0: 支付运营
├── L1: 通道管理
│   ├── L2: PSP接入管理 [战略:5 成熟:2 差距:3 🔴]
│   ├── L2: 通道健康监控 [战略:4 成熟:1 差距:3 🔴]
│   └── L2: 通道成本管理 [战略:3 成熟:2 差距:1 🟡]
├── L1: 数据分析
│   ├── L2: 支付成功率分析 [战略:5 成熟:1 差距:4 🔴]
│   └── L2: 资金流水报表 [战略:3 成熟:2 差距:1 🟡]

能力热力图投资优先级:

P0 — 立即投资(预算$1.2M):
1. 智能支付路由 [差距4×战略5=20] → $400K
   效果: 支付成功率从78%提升到85%+

2. 风险评分模型 [差距4×战略5=20] → $300K
   效果: 欺诈损失减少60%+

3. 支付成功率分析 [差距4×战略5=20] → $200K
   效果: 数据驱动的持续优化基础

4. 拒付管理 [差距4×战略5=20] → $300K
   效果: 减少拒付损失，保护商户账号

P1 — 6个月内($1.0M):
5. PSP接入管理(标准化接入框架) → $300K
6. 支付方式适配(本地化支付) → $400K
7. 资金对账引擎 → $300K

P2 — 12个月内($0.8M):
8. 通道健康监控
9. 实时欺诈检测(升级)
10. 退款流程优化

Step 4: 价值流分析(Day 3工具)

跨境电商支付价值流(消费者视角):

Stage 1: 选品下单
  "消费者在电商平台选好商品，点击支付"

Stage 2: 支付发起
  "选择支付方式，输入支付信息"
  处理时间: 30s(用户操作)
  痛点: 看不到本地支付方式 → 放弃支付

Stage 3: 风控筛查
  "实时检测是否欺诈交易"
  处理时间: 200ms(系统)
  等待时间: 0(实时)
  痛点: 误拒率高(10%) → 丢失真实订单

Stage 4: 通道路由
  "选择最优支付通道处理"
  处理时间: 100ms(系统)
  等待时间: 0(实时)
  痛点: 当前只有2个通道，无failover

Stage 5: 支付处理
  "通道处理支付并返回结果"
  处理时间: 3-30s(取决于3DS/银行)
  等待时间: 0-5s
  痛点: 3DS认证失败率高(15%)

Stage 6: 结果确认
  "消费者看到支付成功/失败"
  处理时间: 1s
  痛点: 失败时错误信息不友好

价值流度量(当前):
  总支付成功率: 78%
  平均支付耗时: 15s(成功) / 30s(失败后重试)

失败分布:
  风控误拒: 10% → 贡献了45%的失败
  通道拒绝: 8% → 贡献了36%的失败
  3DS失败: 3% → 贡献了14%的失败
  其他(超时/网络): 1% → 贡献了5%的失败

价值流→能力→投资的三角映射:

Bottleneck分析:

Bottleneck #1: 风控误拒(贡献45%失败)
  对应能力: 风险评分模型(差距4) + 规则引擎(差距2)
  投资方向: 建设ML风控模型，降低误拒率
  预期效果: 误拒率从10%降到3% → 成功率提升7%

Bottleneck #2: 通道拒绝(贡献36%失败)
  对应能力: 智能支付路由(差距4) + PSP接入(差距3)
  投资方向: 多通道failover + 智能路由
  预期效果: 通道拒绝从8%降到3% → 成功率提升5%

Bottleneck #3: 3DS认证失败(贡献14%失败)
  对应能力: 3DS认证管理(差距2)
  投资方向: 3DS优化(frictionless flow)
  预期效果: 3DS失败从3%降到1% → 成功率提升2%

综合优化效果:
  当前成功率: 78%
  优化后预期: 78% + 7% + 5% + 2% = 92% ✓ 达到目标

Step 5: 流程架构(Day 4工具)

以"智能支付路由"为例，做详细的流程设计:

智能支付路由流程:

[支付请求]
    │
    ▼
┌──────────────────┐
│ 1. 请求解析       │ <1ms
│ (币种/金额/国家)  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ 2. 通道筛选       │ <5ms
│ (哪些通道可用?)   │
│ - 支持该币种?     │
│ - 支持该支付方式? │
│ - 通道是否健康?   │
│ - 金额在限制内?   │
└────────┬─────────┘
         │
    可用通道列表
         │
         ▼
┌──────────────────┐
│ 3. 路由评分       │ <10ms
│ 每个通道计算:     │
│ score =           │
│   w1×成功率       │ (历史成功率，按国家/支付方式/金额段)
│ + w2×(1-成本)     │ (通道手续费率)
│ + w3×速度         │ (平均响应时间)
│ + w4×风控评分     │ (该通道对该交易的风控通过概率)
└────────┬─────────┘
         │
    选择最高分通道
         │
         ▼
┌──────────────────┐
│ 4. 提交通道       │
└────────┬─────────┘
         │
    ┌────┴────┐
    │ 成功?   │
    └────┬────┘
    Y/   │   \N
   /     │    \
  ▼      │     ▼
[成功]   │  ┌──────────────────┐
返回     │  │ 5. Failover       │
         │  │ 选择次高分通道    │
         │  │ (最多重试2次)     │
         │  └────────┬─────────┘
         │           │
         │      ┌────┴────┐
         │      │ 成功?   │
         │      └────┬────┘
         │      Y/   │   \N
         │      /    │    \
         │     ▼     │     ▼
         │  [成功]   │  [最终失败]
         │           │   返回错误码
         │           │   + 建议(换支付方式?)

异常处理:
- 通道超时(5s): 自动failover到下一通道
- 所有通道不可用: 降级到默认通道(Stripe)
- 汇率过期(超过锁定时间): 重新获取汇率
- 重复提交: 幂等性检查(用交易ID)

STP率分析:
- 当前: ~78%(只有主通道，无failover)
- 目标: ~92%(智能路由+failover)
  首选通道成功: 85%(路由优化)
  Failover成功: 7%(第二通道)
  总成功: 92%

流程KPI:
│ 指标              │ 当前   │ 目标  │
├──────────────────┼───────┼──────┤
│ 支付成功率        │ 78%   │ 92%  │
│ 平均路由耗时      │ N/A   │ <20ms│
│ Failover触发率    │ N/A   │ <20% │
│ Failover成功率    │ N/A   │ >50% │
│ 误拒率(风控)      │ 10%   │ <3%  │
│ 单笔路由成本      │ 固定   │ 动态 │

Step 6: TOGAF裁剪与治理(Day 1工具)

项目特征评估:
- 项目类型: 技术现代化(支付系统升级)
- 业务影响: 高(直接影响收入)
- 团队规模: 5人
- 周期: 12个月
- 合规要求: PCI-DSS(已有)

TOGAF ADM裁剪方案:

Preliminary Phase: 跳过
  理由: 小团队，不需要建立架构治理框架
  替代: 用ADR + Weekly Architecture Review

Phase A (Vision): 简化(1周)
  产出: 架构愿景声明 + Stakeholder Map
  方法: 1天Workshop

Phase B (Business): 简化(2周)
  产出: 能力地图 + 价值流(已完成)
  方法: 基于本次分析的输出

Phase C (Data/App): 合并执行(3周)
  产出: 数据流图 + 应用架构图 + ADR
  方法: 聚焦支付路由和风控两个核心域

Phase D (Technology): 简化(1周)
  产出: 技术选型ADR
  方法: 已有技术栈(Node.js)的增量选型

Phase E/F (Migration): 合并(2周)
  产出: 3波次上线计划
  方法: 波次1=路由引擎 波次2=风控模型 波次3=通道扩展

Phase G (Governance): 融入Sprint
  方法: Architecture Review在Sprint Review中进行

Phase H (Change): 持续
  方法: 每月回顾架构决策

总ADM周期: 约10周(不含实施)

Step 7: 最终架构需求汇总

基于全链路分析的架构需求:

1. 智能支付路由引擎(P0 — Month 1-3)
   ┌────────────────────────────────────┐
   │ 技术方案:                          │
   │ - 路由评分算法(多因子加权)          │
   │ - 通道适配器模式(Adapter Pattern)  │
   │ - Failover机制(Circuit Breaker)   │
   │ - A/B测试框架(路由策略对比)        │
   │                                    │
   │ 技术选型:                          │
   │ - 语言: Go(高性能低延迟)           │
   │ - 缓存: Redis(通道状态/成功率缓存) │
   │ - 监控: Prometheus+Grafana         │
   │                                    │
   │ 预期效果:                          │
   │ - 支付成功率: 78% → 87%            │
   │ - 路由延迟: <20ms                  │
   └────────────────────────────────────┘

2. ML风控模型(P0 — Month 2-5)
   ┌────────────────────────────────────┐
   │ 技术方案:                          │
   │ - 特征工程(交易+用户+设备+行为)    │
   │ - XGBoost模型(v1) → 深度学习(v2)  │
   │ - 实时推理(p99<100ms)              │
   │ - 规则引擎(处理已知模式)            │
   │                                    │
   │ 技术选型:                          │
   │ - 训练: Python + AWS SageMaker     │
   │ - 推理: Go + ONNX Runtime          │
   │ - 规则: 自建轻量规则引擎            │
   │                                    │
   │ 预期效果:                          │
   │ - 误拒率: 10% → 3%                 │
   │ - 欺诈损失: $5M → $2M              │
   └────────────────────────────────────┘

3. 通道管理平台(P1 — Month 4-8)
   ┌────────────────────────────────────┐
   │ 技术方案:                          │
   │ - 标准化通道接入框架(Adapter)       │
   │ - 通道健康监控(实时)                │
   │ - 通道成本分析(自动)                │
   │ - 新国家/支付方式快速上线           │
   │                                    │
   │ 预期效果:                          │
   │ - 新通道接入: 3月→2周              │
   │ - 支持国家: 10→30                  │
   └────────────────────────────────────┘

4. 支付数据分析平台(P0 — Month 1-4)
   ┌────────────────────────────────────┐
   │ 技术方案:                          │
   │ - 实时数据管道(支付事件→分析)       │
   │ - 支付成功率多维分析                │
   │ - 异常检测和告警                    │
   │ - 运营Dashboard                    │
   │                                    │
   │ 技术选型:                          │
   │ - 管道: Kafka → ClickHouse         │
   │ - 可视化: Grafana + 自建Dashboard  │
   │                                    │
   │ 预期效果:                          │
   │ - 从"凭感觉"到"凭数据"决策        │
   │ - 问题发现时间: 天级→分钟级        │
   └────────────────────────────────────┘

12个月实施路线:
Month 1-3:  路由引擎(v1) + 数据平台(v1)
Month 4-6:  风控模型(v1) + 通道管理(v1)
Month 7-9:  路由引擎(v2) + 新通道接入(拉美)
Month 10-12: 风控模型(v2) + 3DS优化 + 全面优化

---

Week1方法论工具箱总结

工具选择决策树

面对一个新的架构任务，问以下问题:

Q1: 需要做战略决策还是执行层设计？
├── 战略决策 → Q2
└── 执行层设计 → Q4

Q2: 需要判断build/buy/partner？
├── 是 → 用Wardley Map(Day 5)
└── 否 → Q3

Q3: 需要理解商业模式约束？
├── 是 → 用Business Model Canvas + 牌照分析(Day 6)
└── 否 → 用TOGAF Phase A做Architecture Vision(Day 1)

Q4: 需要确定做什么(What)还是怎么做(How)？
├── 做什么 → Q5
└── 怎么做 → Q6

Q5: 需要全景视图还是深入分析？
├── 全景 → 用能力建模(Day 2)
└── 深入 → 用价值流分析(Day 3)

Q6: 需要流程设计还是系统设计？
├── 流程 → 用业务流程架构(Day 4)
└── 系统 → 进入Week2(应用/数据/技术架构)

Q7: 如何确定投资优先级？
→ 用"价值流×能力×投资三角"(Day 3)
→ 叠加能力热力图(Day 2)

工具组合推荐

每个工具的"一句话使用指南"

---

自评能力雷达图

评估维度与评分标准

维度1: TOGAF与架构治理(Day 1)
  1分: 知道TOGAF是什么
  2分: 了解ADM各Phase
  3分: 能做Phase级别的裁剪
  4分: 能设计完整的架构治理体系
  5分: 能指导组织级的架构能力建设

维度2: 业务能力建模(Day 2)
  1分: 知道能力和功能的区别
  2分: 能画L0-L2能力地图
  3分: 能做能力热力图和差距分析
  4分: 能用BIAN等参考模型做行业对标
  5分: 能驱动投资决策和微服务边界设计

维度3: 价值流分析(Day 3)
  1分: 知道价值流和流程的区别
  2分: 能画基本的价值流
  3分: 能做Stage级的度量和分析
  4分: 能做价值流×能力×投资三角映射
  5分: 能量化并指导组织级投资决策

维度4: 业务流程架构(Day 4)
  1分: 能画基本的流程图
  2分: 了解STP和异常处理概念
  3分: 能设计完整的异常处理框架
  4分: 能设计流程KPI体系和自动化策略
  5分: 能从流程架构推导系统架构

维度5: 战略推演(Wardley Map)(Day 5)
  1分: 能画基本的Wardley Map
  2分: 能判断组件的演进阶段
  3分: 能做build/buy/partner决策
  4分: 能分析气候模式和博弈策略
  5分: 能用Map做多场景战略推演

维度6: 商业模式分析(Day 6)
  1分: 能填写Business Model Canvas
  2分: 了解金融牌照和合规约束
  3分: 能分析牌照对架构的影响
  4分: 能做平台商业模式和网络效应分析
  5分: 能从商业模式推导架构需求

维度7: 综合应用(Day 7)
  1分: 能使用单个工具
  2分: 能组合使用2-3个工具
  3分: 能做端到端的架构推导
  4分: 能判断不同场景用哪些工具
  5分: 能指导团队使用这些工具做架构

自评模板

Week1能力自评(诚实填写):

维度                     自评(1-5)  目标  差距  改进计划
──────────────────────────────────────────────────────
TOGAF与架构治理           [  ]      4     [  ]
业务能力建模              [  ]      4     [  ]
价值流分析                [  ]      4     [  ]
业务流程架构              [  ]      4     [  ]
战略推演(Wardley Map)     [  ]      3     [  ]
商业模式分析              [  ]      4     [  ]
综合应用                  [  ]      4     [  ]

总体评估:
- 最强的维度: _________
- 最弱的维度: _________
- Week2重点补强: _________

金融行业特色维度:
- 金融牌照理解: [  ]/5
- 风控流程设计: [  ]/5
- 合规约束分析: [  ]/5
- 金融数据治理: [  ]/5

---

对比分析: 不同场景的工具组合效果

---

AI增强实践

本日AI提效方法

1. 全链路检查: 让AI审查你的推导链路是否有断裂(商业模式→能力→价值流→流程的一致性)
2. 方案review: 让AI做"红队"角色，挑战你的架构决策
3. 报告生成: 让AI基于分析数据生成Executive Summary

AI辅助的具体Prompt示例

Prompt 1: 推导链路检查

我做了一个跨境电商支付系统的端到端架构分析。请帮我检查
推导链路的一致性:

商业模式: [粘贴BMC分析]
Wardley Map: [粘贴组件和演进分析]
能力建模: [粘贴能力热力图]
价值流: [粘贴价值流度量]
投资方案: [粘贴P0/P1/P2方案]

请检查:
1. 投资优先级是否与价值流bottleneck一致?
2. Build/Buy决策是否与Wardley Map位置一致?
3. 能力差距是否覆盖了所有价值流bottleneck?
4. 有没有遗漏的关键能力?
5. 商业模式约束(牌照/合规)是否在架构中体现?

Prompt 2: 红队挑战

请作为一个资深架构评审委员会成员，对以下架构方案提出挑战:

[粘贴架构方案]

请从以下角度提出至少5个挑战性问题:
1. 技术可行性(这个方案真的能做到吗?)
2. 投资效率(钱花在刀刃上了吗?)
3. 风险盲区(最可能失败的环节是什么?)
4. 替代方案(有没有更好的做法?)
5. 组织约束(5人团队能做到这些吗?)

对每个问题，也给出你的建议答案。

Prompt 3: 个人方法论总结

基于本周的学习(TOGAF、能力建模、价值流、流程架构、
Wardley Map、商业模式)，帮我整理一个"个人架构方法论手册"。

我的背景: 10年金融零售软件PM+BA+开发经验。
我的目标角色: Web3/金融科技高级架构师或产品经理。

手册要求:
1. 一页纸的方法论流程图(从接到任务到产出架构方案)
2. 每个工具的"何时用、何时不用"决策规则
3. 金融行业特化的注意事项清单
4. 我的差异化优势(基于10年金融经验)如何发挥
5. 常见面试场景下如何快速展示方法论

AI生成 vs 人工判断的边界

---

与Web3/DeFi的关联

本周工具在Web3中的应用

Web3项目的端到端架构推导

如果用Week1方法论分析一个DeFi借贷协议:

Step 1(BMC):
  收入=借贷利差+清算罚金
  "牌照"=智能合约审计+TVL信任
  网络效应=流动性越深→利率越优→用户越多

Step 2(Wardley Map):
  Build: 借贷算法(利率模型)、清算机制 → 核心差异化
  Buy(Import): EVM、Oracle(Chainlink)、前端框架

Step 3(能力建模):
  核心能力: 利率管理、清算管理、风险参数治理
  基础能力: 合约部署、预言机集成、前端

Step 4(价值流):
  用户旅程: 连接钱包→存入资产→借出资产→管理头寸→偿还
  Bottleneck: 连接钱包(新用户最大障碍)

Step 5(流程):
  清算流程: 天然STP=100%(合约自动执行)
  治理流程: 提案→投票→Timelock→执行

关键洞察:
  DeFi的"架构"更多是"协议设计"而非"系统设计"
  一旦部署就不可变(除非Proxy模式)
  所以架构决策的质量比传统金融更重要(错误成本更高)

---

今日思考

思考1: 架构方法论最大的价值不是"方法"本身

回顾一周的学习，我最大的感悟是：这些工具(TOGAF、能力建模、价值流等)的最大价值不是"如何使用它们"，而是它们提供了一种结构化的思维方式。即使不画任何图，当你面对一个架构问题时，你会自然地思考：

• 这个组件在什么演进阶段？(Wardley)
• 它支撑了什么价值流？(价值流)
• 它的成熟度差距是什么？(能力建模)
• 有什么商业模式约束？(BMC)

思考2: 10年金融经验在架构工作中的独特价值

作为有10年金融零售经验的人，我在以下方面有独特优势：

1. 理解牌照约束: 很多纯技术背景的架构师不理解金融牌照的约束，我天然理解
2. 理解业务流程: 清算、对账、日终处理——这些不需要学，已经是"肌肉记忆"
3. 理解合规要求: AML、KYC、数据治理——知道哪些是"必须做"而非"最好做"
4. 理解用户痛点: 在一线做了10年，知道真实用户的痛点而非纸上谈兵

这些经验需要有意识地在架构工作中展现出来。

思考3: 下一步应该补强什么？

基于本周的自评，我的优先补强方向：

1. Wardley Map的实战: 理论理解了，但缺少反复练习。建议每周画一张不同场景的Map
2. 流程→系统的转化: 会画流程，但从流程推导到系统架构(微服务边界、API设计)还需要练习
3. AI工具的深度使用: 本周用AI辅助生成和检查，但还可以更深入(如用AI做竞品分析、用AI做架构文档生成)

---

面试题准备

Q1: 请用一个实际案例，展示你如何从业务需求推导出架构方案

30秒版本: 我用"战略→能力→价值→流程→系统"的五步推导法。以跨境电商支付为例：先用Wardley Map判断build/buy(支付路由自建、收银台采购)，然后用能力建模识别差距(智能路由差距最大)，用价值流分析找bottleneck(风控误拒贡献45%失败)，用流程架构设计路由引擎(含failover和异常处理)，最终产出分波次的架构实施方案。

2分钟版本:

我有一套端到端的架构推导方法论，拿跨境电商支付场景来说明：

起点是商业模式分析。先理解业务约束：公司没有支付牌照，只能通过PSP聚合。这直接决定了系统边界——我们不做清算，只做路由和风控。

第二步是Wardley Map做战略判断。分析支付链路中每个组件的演进阶段。支付路由处于Custom阶段且是核心差异化→自建。收银台已是Commodity→采购。这避免了"在不该自建的地方花钱"。

第三步是能力建模确定投资方向。画出支付相关的20个L2能力，叠加热力图。最大差距在"智能支付路由"和"风险评分模型"——这就是投资优先级。

第四步是价值流分析验证。从消费者视角画支付价值流，度量每个Stage的失败贡献。数据显示风控误拒贡献了45%的支付失败——这验证了能力建模的优先级判断(风控模型确实是最该投资的)。

第五步是流程架构做详细设计。设计支付路由的完整流程，包括评分算法、failover机制、异常处理。同时定义STP率目标(78%→92%)和流程KPI。

最终产出是带有明确波次的实施方案：波次1做路由引擎和数据平台(3个月)，波次2做风控模型(3个月)，波次3扩展通道(3个月)。

这个方法论的核心价值是每一步都有上一步的输出作为输入，避免了"拍脑袋"做架构决策。

追问准备:

• 追问: 如果时间紧(只有1周做分析)怎么办？ → 只做Wardley Map + 价值流。Map决定大方向(build/buy)，价值流决定优先级(哪个bottleneck先解决)
• 追问: 这套方法论和敏捷冲突吗？ → 不冲突。分析阶段可以压缩到1-2个Sprint做"Just Enough Architecture"，然后在Sprint中迭代实施
• 追问: 团队不认可你的分析结果怎么办？ → 用数据说话(价值流的度量是客观的)，用Workshop让团队参与(能力评估是联合做的，不是架构师自己评的)

Q2: 请评价TOGAF、能力建模和Wardley Map三个工具的优劣

30秒版本: 三者解决不同层面的问题。TOGAF解决"如何组织架构工作"(方法论)，能力建模解决"应该做什么"(业务能力)，Wardley Map解决"应该怎么获取"(build/buy/partner)。最佳实践是组合使用：用TOGAF做治理框架，用能力建模定义范围，用Wardley Map做战略决策。它们的共同局限是都依赖人的判断，没有一个是"填表就能得到答案"的机械化工具。

2分钟版本:

(展开三个工具的优劣对比，结合金融行业实践案例)

追问准备:

• 追问: 如果只能选一个，选哪个？ → Wardley Map。因为它是唯一同时处理"价值链"和"演进"两个维度的工具，决策价值最高
• 追问: 有没有更现代的替代品？ → Team Topologies(组织架构)、C4 Model(技术架构)、Architecture Fitness Functions(架构治理) 是更现代的补充，但不是替代

---

学习资源

Week1综合推荐

Week2预告

Week2主题: 应用架构方法论 — 微服务、领域驱动与集成

---

Week1关键收获检查清单

完成Week1后，你应该能够：

□ 能根据项目特征裁剪TOGAF ADM(知道哪些Phase可以跳过)
□ 能画出金融业务的L0-L2能力地图并叠加热力图
□ 能画出端到端价值流并度量Lead Time/Wait Time
□ 能识别价值流bottleneck并映射到能力差距
□ 能做价值流×能力×投资三角的投资优先级分析
□ 能设计包含异常处理的完整业务流程(不只是Happy Path)
□ 能解释STP率的概念并提出优化方案
□ 能画Wardley Map并做build/buy/partner决策
□ 能判断组件的演进阶段(Genesis/Custom/Product/Commodity)
□ 能分析金融牌照对架构的约束
□ 能使用Business Model Canvas分析金融商业模式
□ 能从头到尾做"战略→能力→价值→流程→系统"的架构推导
□ 能在面试中用2分钟讲清楚你的架构方法论

如果以上有超过3个打不上勾，建议回顾对应Day的内容并重新做实操练习。