Arch Day 5: Wardley Map战略推演 — Build/Buy/Partner的决策引擎

日期: 2026-04-03 阶段: 第一阶段 - 架构基础 标签: #WardleyMap #技术战略 #BuildBuyPartner #演进 #博弈

---

核心概念

一句话定义

Wardley Map不是"画一张图"，而是一种用"价值链位置+演进阶段"二维坐标来做战略推演的思维工具 — 它的核心价值在于帮你判断每个组件应该build(自建)、buy(采购)还是partner(合作)，以及预测组件的演进方向来提前布局。

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

1. 技术选型的战略依据: 很多技术选型争论(用Kafka还是RabbitMQ？上K8s还是Serverless？)本质上是"这个组件处于什么演进阶段"的判断问题
2. 架构师最被低估的能力 — 战略对话: Wardley Map是极少数能让架构师和CEO/CTO用同一张图对话的工具
3. 避免"为创新而创新": Map帮你判断什么该创新(Genesis/Custom)、什么该标准化(Product/Commodity)
4. 预测性价值: 通过气候模式和博弈分析，可以预测行业变化并提前做架构准备

常见误区与反模式

---

知识点详解

知识点1: Wardley Map的坐标系统深度理解

Y轴: 价值链(Visibility/Value Chain)

Y轴表示对用户的可见性/价值链位置:

最高(用户直接感知):
  ┌─────────────────┐
  │ 用户界面/APP     │ ← 用户直接触碰
  │ 业务服务         │ ← 用户间接感知(速度/体验)
  │ 平台服务         │ ← 用户无感知
  │ 基础设施         │ ← 用户完全不知道
  └─────────────────┘
最低(基础设施层):

关键理解:
- 越高 = 越接近用户价值，变更影响越大
- 越低 = 越基础，但不代表不重要
- 位置高的组件依赖位置低的组件
- 画Map时从上到下画依赖关系

X轴: 演进阶段(Evolution)

这是Wardley Map最核心也最难判断的维度:

X轴的四个演进阶段:

Genesis ──→ Custom ──→ Product ──→ Commodity
 (创世)     (定制)     (产品)     (商品)

每个阶段的特征:
┌──────────┬───────────┬──────────┬──────────┐
│ Genesis  │ Custom    │ Product  │ Commodity│
├──────────┼───────────┼──────────┼──────────┤
│ 全新发明  │ 定制开发   │ 标准产品  │ 公用事业  │
│ 不确定性高│ 部分理解   │ 充分理解  │ 完全理解  │
│ 独特的    │ 差异化的   │ 可比较的  │ 无差异的  │
│ 快速变化  │ 持续改进   │ 渐进改进  │ 极少变化  │
│ 高失败率  │ 中等风险   │ 低风险    │ 极低风险  │
│ 实验方法  │ 敏捷方法   │ 产品管理  │ 运维管理  │
│ 人才稀缺  │ 专业人才   │ 通用人才  │ 外包可能  │
│ 高利润    │ 中高利润   │ 中利润    │ 低利润    │
└──────────┴───────────┴──────────┴──────────┘

演进阶段判断方法论(关键技能)

判断一个组件在X轴的位置，不是靠"感觉"，而是看可观察的特征:

特征检查清单:

□ 市场供给:
  Genesis: 几乎没有供应商
  Custom: 少数专业供应商
  Product: 多个竞争产品
  Commodity: 标准化供给(云服务/开源)

□ 用户理解度:
  Genesis: 用户不知道需要它
  Custom: 用户知道需要但不知道最佳实践
  Product: 用户可以比较和选择
  Commodity: 用户视为理所当然

□ 确定性:
  Genesis: 不确定是否可行
  Custom: 可行但最佳实践未知
  Product: 最佳实践已建立
  Commodity: 完全标准化

□ 变化速度:
  Genesis: 快速迭代，频繁pivot
  Custom: 持续改进
  Product: 稳定，渐进式更新
  Commodity: 极少变化

金融行业举例:
- 区块链清算(2026): Custom→Product过渡
- 核心银行系统: Product(成熟但仍有差异)
- 支付网关: Product→Commodity过渡
- 云计算(IaaS): Commodity
- AI风控模型: Custom(仍需大量定制)
- eKYC: Product(多个标准方案)
- CBDC支付: Genesis→Custom(早期)

知识点2: Build/Buy/Partner决策模型

Wardley Map最直接的应用就是指导build/buy/partner决策:

演进阶段 → 策略映射:

Genesis    → BUILD (自建+创新)
  理由: 市场没有现成方案，只能自建
  方法: 小团队实验，快速迭代，接受失败
  案例: 全新的DeFi清算算法

Custom     → BUILD or PARTNER (自建或合作)
  理由: 有参考但需要深度定制
  方法: 基于开源/框架定制开发
  案例: 定制化的AI风控模型(基于开源ML框架)

Product    → BUY or BUILD (采购或自建)
  理由: 市场有成熟产品，需要评估make or buy
  方法: RFP评估，关注差异化需求能否满足
  案例: CRM系统(Salesforce vs 自建)

Commodity  → BUY (采购/使用公用服务)
  理由: 自建没有任何竞争优势
  方法: 选择最低成本的标准化服务
  案例: 邮件服务(AWS SES)、CDN(CloudFlare)

Build/Buy决策矩阵(高级版)

实际决策示例(银行):

组件: 反欺诈系统
  竞争差异化: 是(30% × 1.0 = 0.30) → Build
  定制需求: 高(25% × 0.8 = 0.20) → Build
  数据敏感性: 核心(20% × 1.0 = 0.20) → Build
  演进阶段: Custom(15% × 0.8 = 0.12) → Build
  团队能力: 有(10% × 1.0 = 0.10) → Build
  Build得分: 0.92 → 强烈建议Build

组件: 邮件通知服务
  竞争差异化: 否(30% × 0 = 0.00) → Buy
  定制需求: 低(25% × 0.2 = 0.05) → Buy
  数据敏感性: 低(20% × 0.2 = 0.04) → Buy
  演进阶段: Commodity(15% × 0 = 0.00) → Buy
  团队能力: 不想投入(10% × 0 = 0.00) → Buy
  Build得分: 0.09 → 强烈建议Buy

知识点3: 气候模式(Climatic Patterns)

气候模式是Wardley Map中最具预测力的部分——它描述了演进的自然规律，就像天气预报一样，虽然不能精确预测，但可以判断大趋势:

核心气候模式

模式1: 所有组件都会向Commodity演进(不可阻挡)
  影响: 今天的差异化明天就是标准化
  架构启示: 不要在注定变成Commodity的组件上过度投资
  案例: 私有云 → 公有云，定制OA → SaaS OA

模式2: 组件演进为Commodity时，会催生新的Genesis
  影响: 云计算(Commodity)催生了Serverless(Genesis→Product)
  架构启示: 关注"Commodity化"之后的创新机会
  案例: 互联网(Commodity)催生了移动互联网(Genesis→Commodity)

模式3: 惯性(Inertia)是组织抵抗演进的力量
  影响: 大型组织倾向于保持现状，即使外部环境已经变化
  架构启示: 架构变革的最大阻力不是技术，是组织惯性
  案例: 银行核心系统"跑了20年，改什么改？"

模式4: 过去的成功是未来的牢笼
  影响: 在Custom/Product阶段成功的方法，在Commodity阶段会失败
  架构启示: 不同演进阶段需要不同的管理方法
  案例: 定制化核心银行(曾经的优势)在云原生时代变成负担

模式5: 高阶系统创造新的需求
  影响: 新技术的出现会创造之前不存在的需求
  架构启示: 预测"下一层"的需求
  案例: 智能手机创造了移动支付需求

知识点4: 博弈策略(Gameplay)

博弈策略是基于Map位置的主动战略行为:

策略1: 开放(Open) — 加速Commodity化
  方法: 开源核心技术，让行业标准化
  何时用: 你在上层有优势时，推动下层Commodity化降低成本
  案例: Google开源Kubernetes → 降低云计算壁垒 → 卖GCP上层服务
  金融案例: 蚂蚁开放支付接口 → 降低商户接入成本 → 建立平台优势

策略2: ILC(知识产权锁定) — 减缓Commodity化
  方法: 用专利/标准锁定技术
  何时用: 你的优势在当前演进阶段
  案例: SWIFT的报文标准锁定跨境支付生态
  风险: 只能延缓不能阻止，且可能被颠覆

策略3: 生态系统(Ecosystem) — 建立依赖
  方法: 让其他公司在你的平台上构建
  何时用: Product→Commodity过渡期
  案例: AWS Marketplace、Stripe Connect
  金融案例: 银行开放银行API(PSD2) → 建立金融服务超市

策略4: 先行者/快速跟随者
  何时当先行者: Genesis阶段，你有技术优势
  何时当快速跟随者: Custom→Product过渡，等市场验证后快速跟进
  金融案例:
    先行者: 第一批做移动支付的(支付宝)
    快速跟随者: 微信支付(等支付宝教育市场后快速跟进)

策略5: 绕道(Bypass) — 跳过中间阶段
  方法: 直接从Genesis跳到Commodity(通过外部创新)
  案例: 新兴市场银行跳过PC时代直接进入移动银行
  Web3案例: DeFi跳过传统清算体系直接实现链上结算

---

对比分析

战略分析工具对比

关键洞察: 只有Wardley Map同时处理"价值链位置"和"演进阶段"两个维度。其他工具要么只看竞争(Porter)，要么只看内部(SWOT)，要么不处理时间维度(Canvas)。

Build/Buy/Partner决策方法对比

---

架构设计实操

实操: 为"银行数字化转型"画Wardley Map→推演build/buy/partner决策

设计背景

场景: 一家中型城商行(资产规模2000亿)的数字化转型
当前状态:
- 核心银行系统: 用了15年的IBM AS/400
- 渠道: 手机银行(自建，体验一般)、网银(即将下线)
- 数据能力: 基本为零(报表靠Excel)
- 客户: 300万零售客户，主要是本地中老年
- 目标: 3年内完成数字化转型，吸引年轻客群
- IT预算: 每年5000万

设计方案

Step 1: 识别用户需求(锚点)

核心用户需求(Map的顶部):
1. 便捷转账汇款(高频刚需)
2. 理财投资(收益驱动)
3. 贷款融资(资金需求)
4. 账户管理(基础需求)
5. 生活缴费(便利性)

Step 2: 画Wardley Map

Wardley Map: 城商行数字化转型

Y轴(价值链)  ↑
             |
用户需求     | [便捷转账] [理财投资] [贷款融资] [账户管理]
             |     |          |          |          |
业务服务     | [移动银行] [财富管理] [信贷审批] [客户服务]
             |     |     |    |     |    |     |
             |     |  [智能推荐] |  [AI风控] |
             |     |     |    |     |    |     |
平台服务     | [支付引擎] [产品工厂] [数据平台] [统一用户]
             |     |          |          |          |
基础设施     | [核心银行] [消息中间件] [云基础设施] [安全认证]
             |
             └────────────────────────────────────────→ X轴(演进)
              Genesis   Custom    Product   Commodity

各组件在X轴的位置:
─────────────────────────────────────────────
Genesis区域:
  (无 — 城商行不做原创性创新)

Custom区域:
  - AI风控模型 (需要基于本地客群定制)
  - 智能推荐 (需要结合本地特色)
  - 数据平台 (需要整合内部多源数据)

Product区域:
  - 移动银行 (成熟方案但需定制)
  - 信贷审批 (标准产品+定制规则)
  - 财富管理 (标准代销平台)
  - 产品工厂 (少数供应商提供)
  - 支付引擎 (成熟产品)
  - 统一用户 (IAM标准方案)

Commodity区域:
  - 核心银行 (标准化产品，15年已证明)
  - 消息中间件 (Kafka/RabbitMQ标准化)
  - 云基础设施 (公有云/金融云)
  - 安全认证 (HSM/PKI标准化)

Step 3: Build/Buy/Partner决策推演

决策矩阵:

组件              演进阶段    决策     理由
──────────────────────────────────────────────────────
AI风控模型        Custom     BUILD    核心竞争力，本地客群数据独特
智能推荐          Custom     BUILD    差异化体验的关键
数据平台          Custom     PARTNER  基于开源/云方案定制(不自研底座)
移动银行          Product    BUY+定制  采购成熟方案(如蚂蚁/京东)+定制UI
信贷审批          Product    BUY+定制  采购标准审批引擎+自建规则
财富管理          Product    BUY      代销平台直接采购
产品工厂          Product    BUY      核心银行供应商配套
支付引擎          Product    BUY      成熟方案，无需自建
统一用户          Product    BUY      IAM标准方案
核心银行          Commodity  BUY(换新) 老AS/400→新一代分布式核心
消息中间件        Commodity  BUY(云服务) 直接用云上的Kafka
云基础设施        Commodity  BUY      金融云(阿里云/华为云)
安全认证          Commodity  BUY      HSM硬件+PKI标准方案

Step 4: 战略推演(Gameplay)

气候模式分析:

1. 核心银行向Commodity演进
   趋势: 分布式核心银行正在标准化(如阿里云的mPaaS、华为的FusionBank)
   策略: 不要在核心银行上过度定制，选择标准化程度高的方案
   避坑: 不要被供应商锁定在定制化方案中

2. AI能力从Custom向Product演进
   趋势: AI模型训练平台(如PAI、ModelArts)正在产品化
   策略: 自建模型但利用云平台的训练和推理基础设施
   时机: 当前处于Custom，2-3年后可能出现行业通用的金融AI产品

3. 数据平台从Custom向Product演进
   趋势: 湖仓一体(Lakehouse)正在标准化
   策略: 不自研数据底座，用Databricks/云原生数据湖+自建数据应用层

博弈策略:

策略1: 快速跟随者(不做先行者)
  城商行规模不够做先行者。等大行验证后快速跟进。
  具体: 观察大行的数字化转型实践，2年后采购他们验证过的方案。

策略2: 生态借力
  加入金融科技公司的生态(如蚂蚁的OceanBase生态、腾讯的微众生态)
  获取技术能力的同时控制成本。

策略3: 专注本地差异化
  不做全面数字化(做不过大行)，聚焦"本地客群服务":
  - 本地中小企业融资(大行看不上)
  - 本地生活场景(缴费/停车/公交)
  - 老年客群数字化(大行不重视)

Step 5: 投资规划(基于Map决策)

3年投资规划(总预算1.5亿):

Year 1 (5000万) — 地基:
├── 核心银行更换: 2000万(采购新一代分布式核心)
├── 云基础设施: 1000万(上云迁移)
├── 数据平台(基础): 1500万(湖仓一体+基础数据治理)
└── 统一用户/安全: 500万

Year 2 (5000万) — 能力:
├── 移动银行重建: 1500万(采购方案+深度定制)
├── AI风控模型(v1): 1000万(自建团队+模型开发)
├── 信贷审批系统: 1000万(采购+规则定制)
├── 数据平台(进阶): 1000万(数据应用层建设)
└── 支付引擎: 500万

Year 3 (5000万) — 差异化:
├── 智能推荐: 1000万(自建，基于数据平台)
├── AI风控模型(v2): 800万(持续优化)
├── 财富管理/产品工厂: 1200万
├── 本地场景生态: 1000万(本地生活接入)
└── 持续优化: 1000万

关键: Year 1做地基，Year 2建能力，Year 3做差异化
如果颠倒顺序(先做差异化再做地基)，99%会失败

ADR

ADR-005: 城商行数字化转型技术战略

状态: 待审批
日期: 2026-04-03

背景:
城商行面临数字化转型，资产规模2000亿，IT年预算5000万，
需要在3年内完成主要数字化转型。

决策(基于Wardley Map分析):
1. 核心策略: "快速跟随者+本地差异化"
2. Build: AI风控、智能推荐(核心竞争力)
3. Buy: 核心银行、支付引擎、移动银行(成熟方案)
4. Partner: 数据平台(云厂商生态)
5. 投资节奏: 地基(Y1)→能力(Y2)→差异化(Y3)

理由:
1. 城商行规模不足以支撑全面自建
2. AI风控和智能推荐是唯一值得自建的差异化能力
3. 核心银行已是Commodity，自建无竞争优势
4. 先做地基再做上层，避免空中楼阁

风险:
- 核心银行更换是最大风险项(数据迁移、业务连续性)
- AI团队招聘困难(城商行吸引力有限)
- 云厂商锁定风险(需要多云策略或合同退出条款)

权衡取舍

---

AI增强实践

本日AI提效方法

1. 组件演进阶段判断: 让AI搜索和分析市场数据，辅助判断组件在X轴的位置
2. 竞品Map对比: 让AI分析竞品的技术栈和战略，生成竞品的Wardley Map
3. 气候模式预测: 让AI基于行业趋势预测组件的演进方向

AI辅助的具体Prompt示例

Prompt 1: 组件演进阶段判断

帮我判断以下金融科技组件在2026年的Wardley Map演进阶段
(Genesis/Custom/Product/Commodity):

1. 分布式核心银行系统
2. 实时风控引擎
3. 智能客服(基于大模型)
4. 区块链清结算
5. Open Banking API网关
6. 数字人民币(CBDC)接入
7. 生物识别认证(人脸/指纹)

对每个组件请分析:
- 当前市场上有多少供应商/开源方案？
- 最佳实践是否已建立？
- 是否已有标准化规范？
- 变化速度如何？
- 基于以上特征判断演进阶段
- 预测2-3年后的演进方向

Prompt 2: Build/Buy分析

我正在为一家城商行做技术选型决策。请帮我分析以下组件的
build vs buy决策:

组件: 反欺诈系统
上下文:
- 城商行，零售客户300万
- 当前无反欺诈系统(靠人工审查)
- 年度IT预算5000万(反欺诈预算约500万)
- 团队: 无AI/ML人才
- 数据: 有3年交易数据但未清洗
- 竞争环境: 大行已有成熟AI反欺诈

请从以下维度分析build vs buy:
1. 竞争差异化潜力
2. 定制化需求程度
3. 数据敏感性
4. 市场成熟度(有哪些供应商可选)
5. 团队能力差距
6. 成本对比(5年TCO)
7. 最终推荐(build/buy/partner)及理由

AI生成 vs 人工判断的边界

---

与Web3/DeFi的关联

Wardley Map视角看DeFi:

DeFi生态的Wardley Map:

用户需求: [借贷] [交易] [收益]
             |       |       |
业务协议: [Aave]  [Uniswap] [Yearn]
             |       |       |
平台层:   [EVM]  [Solidity] [Oracle]
             |       |        |
基础设施: [Ethereum] [L2(Arbitrum)] [IPFS]

演进判断:
- Ethereum: Product→Commodity(最成熟的公链)
- L2: Custom→Product(多个竞品，正在标准化)
- DeFi协议: Product(Aave/Uniswap已是标准产品)
- Oracle: Product(Chainlink主导)
- DID: Genesis→Custom(早期)

战略启示:
对于DeFi创业者，在Commodity层(公链)上没有机会，
应该聚焦Custom/Genesis层(如新型AI+DeFi协议)

---

今日思考

思考1: Wardley Map最大的局限性是什么？

主观性。演进阶段的判断最终依赖人的经验和判断，不同的人可能对同一个组件给出不同的位置。这不是缺陷，而是特性——Map的价值不在于"准确"，而在于促进关于战略的结构化讨论。当团队对一个组件的位置有分歧时，讨论这个分歧本身就非常有价值。

思考2: 金融机构为什么经常做出错误的build/buy决策？

最常见的错误是在Commodity阶段的组件上Build。原因：

1. "我们银行特殊"的心态(其实大多数需求是通用的)
2. IT部门有"帝国建设"倾向(人多预算大=价值大)
3. 历史惯性(以前Build的，现在也继续Build)

Wardley Map通过客观分析演进阶段，帮助打破这些认知偏差。

思考3: 如何处理"演进阶段判断不确定"的情况？

当你不确定一个组件是Custom还是Product时，采用双轨策略：

• 短期：先用Buy方案快速上线(降低风险)
• 中期：评估Buy方案是否满足需求
• 长期：如果Buy方案不够差异化，再转Build

这种策略的成本比"一开始就Build错了"低得多。

---

面试题准备

Q1: 如何用Wardley Map做技术战略？

30秒版本: Wardley Map通过"价值链位置"(Y轴)和"演进阶段"(X轴)两个维度，帮助判断每个技术组件应该build、buy还是partner。Genesis/Custom阶段的组件自建(差异化)，Product/Commodity阶段的组件采购(标准化)。再结合气候模式预测组件的演进方向，提前做架构准备。

2分钟版本:

我用Wardley Map做技术战略分三步：

第一步是画Map。从用户需求(锚点)出发，识别支撑需求的所有技术组件，按价值链排列(Y轴)。然后根据可观察的特征(市场供给数量、标准化程度、变化速度)判断每个组件的演进阶段(X轴)。

第二步是做决策。基于演进阶段做build/buy/partner决策：Genesis和Custom阶段的组件通常自建或合作(差异化价值高)，Product和Commodity阶段的组件通常采购(自建没有竞争优势)。同时考虑数据敏感性和竞争差异化等补充因素。

第三步是做推演。分析气候模式——"所有组件终将向Commodity演进"意味着今天的投资要考虑3-5年后的演进。同时分析博弈策略——是做先行者还是快速跟随者？是开放生态还是封闭壁垒？

实际案例：为城商行做数字化转型时，Wardley Map帮助我们做出了几个关键决策：核心银行更换而非修补(它已是Commodity)、AI风控自建(处于Custom，是差异化来源)、数据平台用云原生方案(自研数据底座在Custom→Product过渡中，未来会被标准化产品替代)。这些决策在3年5000万/年的预算约束下，最大化了投资回报。

追问准备:

• 追问: Wardley Map和技术雷达有什么区别？ → 技术雷达只判断"这个技术该不该用"，Map判断"这个组件在你的业务中处于什么位置、应该怎么获取"。前者是通用的，后者是定制的
• 追问: 如果团队对演进阶段的判断有分歧怎么办？ → 这正是Map的价值——讨论分歧本身。通常让各方列出判断依据(市场供给数量、标准化程度等客观特征)来对齐
• 追问: Map需要多久更新一次？ → 至少每季度review一次。技术演进可能比预期快(或慢)

Q2: 在金融企业中，有哪些组件经常被错误地Build而应该Buy？

30秒版本: 三个最常见的错误Build：一是OA/HR/财务系统(完全Commodity但很多银行自建)；二是数据底座(自研Hadoop集群而非用云原生方案)；三是中间件(自研消息队列或API网关)。根因是"我们银行特殊"的认知偏差和IT部门的帝国建设倾向。

2分钟版本:

(展开三个案例的详细分析，包括错误Build的成本和正确Buy的方案)

追问准备:

• 追问: 有没有反过来——应该Build却Buy了的？ → AI模型。很多银行买了通用的AI风控方案，但效果不如自建(因为本行数据和客群特殊)
• 追问: 如何说服管理层从Build转向Buy？ → TCO对比(5年总成本)+ 人才成本(维护自建系统需要持续投入人力)+ 机会成本(团队花在维护上的时间本可以用来做差异化)

---

学习资源

---

明日预告

Day 6: 商业模式架构 — 从技术战略延伸到商业模式设计。学习Business Model Canvas、Platform Canvas和双边市场设计，重点分析金融牌照约束对架构的影响。实操环节将解剖Stripe/蚂蚁/Nubank三者的商业模式，分析牌照和监管约束如何决定产品架构。