Arch Day 115

Arch Day 115: 业务架构面试专题

2026-07-23

第四阶段 - 高阶融合

面试业务架构TOGAF能力建模价值流WardleyBIAN

日期: 2026-07-23 (Day 115) 阶段: 第四阶段 - 高阶融合标签: #面试 #业务架构 #TOGAF #能力建模 #价值流 #Wardley Map #BIAN

概述

业务架构面试是高级架构师面试中最能体现"架构师 vs 高级开发"差距的环节。技术架构人人都会说微服务、DDD，但能清晰阐述业务能力建模、价值流分析、企业架构治理的候选人屈指可数。

本专题整理15道业务架构面试高频题，每道题包含：

30秒版本（电梯演讲）
2分钟版本（标准回答）
追问准备（深度展示）

题目 1：如何为一个企业做业务能力建模？

30秒版本

业务能力建模是将企业"能做什么"抽象为分层的能力树——Level 0是战略能力域（如"客户管理"），Level 1分解为具体能力（如"客户获取""客户服务""客户分析"），Level 2进一步细化。关键原则是"能力描述What，不描述How"，且能力应该稳定，不随组织架构变化而变化。

2分钟版本

什么是业务能力：业务能力是企业为交付价值而必须具备的"能力集"。它回答"企业能做什么"，而非"企业怎么做"。例如"定价管理"是能力，"用Excel做定价"是实现方式。

建模步骤：

步骤1: 确定范围和利益相关方
  └── 全企业 vs 某业务线？谁是输入方？

步骤2: 识别Level 0能力域 (通常5-8个)
  ├── 战略管理
  ├── 产品管理
  ├── 客户管理
  ├── 供应链管理
  ├── 财务管理
  └── 技术管理

步骤3: 逐层分解到Level 1-2 (通常30-80个能力)
  客户管理
  ├── 客户获取 (L1)
  │   ├── 客户资格验证 (L2)
  │   ├── 客户注册 (L2)
  │   └── KYC审核 (L2)
  ├── 客户服务 (L1)
  └── 客户分析 (L1)

步骤4: 评估能力成熟度 (热力图)
  每个能力评分: 1(初始) → 5(优化)
  识别差距: 战略目标要求的vs当前水平

步骤5: 关联业务价值
  将能力与价值流阶段映射
  确定投资优先级

常见方法：

自顶向下：从战略目标分解（适合新建）
自底向上：从现有系统/流程提取（适合现状建模）
参考框架：银行用BIAN，保险用ACORD，零售参考ARTS
Event Storming：通过领域事件反推能力（DDD方法）

关键原则：

能力与组织架构解耦（组织可能调整，能力应稳定）
能力与实现解耦（"支付处理"能力可以是自研也可以是外购）
每个能力有唯一Owner（即使跨部门共享）
粒度统一（同一Level的能力粒度应大致相当）

追问准备

追问: "能力建模和流程建模的区别？"

能力是"What"（企业能做什么），流程是"How"（具体怎么做）。能力稳定，流程可能经常优化。一个能力可能包含多个流程，一个流程可能涉及多个能力。能力建模适合做战略规划和投资分析，流程建模适合做运营优化和自动化。

追问: "在实践中，能力建模最大的挑战是什么？"

粒度控制——太粗了没有分析价值，太细了变成了流程。我的经验法则是Level 2能力应该能对应到1-3个业务服务/应用系统。另一个挑战是跨部门共识——不同部门对同一能力的理解不同，需要反复对齐。

题目 2：TOGAF ADM如何裁剪？

30秒版本

TOGAF ADM是一个通用框架，实际使用时必须裁剪。核心原则是"根据项目规模和组织成熟度裁剪"。小型项目可以合并Phase B/C/D为一个迭代；敏捷环境下可以将ADM嵌入Sprint周期，每个Sprint完成一个架构切片；成熟组织可以跳过需求管理（已有成熟流程）。关键是保留ADM的核心价值——利益相关方管理、架构治理、变更管理。

2分钟版本

ADM全周期回顾：

Preliminary → A(架构愿景) → B(业务架构) → C(信息系统架构)
→ D(技术架构) → E(机会和解决方案) → F(迁移规划) → G(实施治理) → H(变更管理)

裁剪策略矩阵：

场景	裁剪方式	保留重点
小项目(3个月内)	合并B+C+D为一个轻量迭代	架构愿景+关键决策记录
敏捷/SAFe环境	ADM嵌入PI Planning	架构Runway+ADR
成熟组织(已有EA)	跳过Preliminary，轻量Phase A	增量架构变更
新建组织	完整走一遍，但限时	能力基线+目标架构
技术现代化	重点Phase C+D，轻量Phase B	技术债清理+迁移路径

敏捷环境下的ADM裁剪（2025-2026最常问）：

传统ADM:        Phase A → B → C → D → E → F → G → H
                (瀑布式，6-12个月)

敏捷裁剪:
  ┌─────────────────────────────────────────────────┐
  │  架构Runway (持续)                               │
  │  ├── 愿景(A): PI Planning时刷新                  │
  │  ├── 业务架构(B): Epic分析时完成                 │
  │  ├── 技术架构(C+D): Enabler Story              │
  │  └── 治理(G): Architecture Review每Sprint       │
  │                                                 │
  │  Sprint 1  Sprint 2  Sprint 3 ... Sprint 5     │
  │  [分析]    [设计]    [实现]       [验证]        │
  │     └── 每个Sprint产出ADR记录架构决策            │
  └─────────────────────────────────────────────────┘

我在实践中的裁剪原则：

决不裁掉的：利益相关方分析（Phase A）、架构决策记录（贯穿全程）、架构评审（Phase G）
可以简化的：详细的架构描述文档（用ADR替代长文档）、正式的架构治理委员会（用轻量Review替代）
必须适配的：交付节奏（瀑布→Sprint）、评审频率（月→每Sprint）、文档形式（Word→Wiki+ADR）

追问准备

追问: "你在项目中实际怎么用TOGAF？"

我不会说"我们严格按TOGAF执行"，而是说"我们借鉴TOGAF的能力基线方法和变更管理框架"。具体来说，我在项目中用ADM的Phase A做利益相关方对齐，用Phase B的能力建模做业务分析，用ADR替代完整的架构文档。TOGAF给我的最大价值不是流程，而是思维框架。

题目 3：价值流分析如何驱动IT投资？

30秒版本

价值流是端到端的价值交付过程——从客户需求到客户满足。每个价值流阶段映射到业务能力，通过评估各能力的成熟度和战略重要性，识别"高价值+低成熟度"的能力缺口，这些缺口就是IT投资的优先方向。这比传统的"业务需求驱动IT项目"更系统化，因为它从价值交付视角而非部门视角做投资决策。

2分钟版本

价值流驱动投资的步骤：

步骤1: 识别核心价值流

  示例(零售银行):
  ┌─────┐   ┌─────┐   ┌─────┐   ┌─────┐   ┌─────┐
  │客户 │→ │需求 │→ │产品│→ │ 服务│→ │ 深化│
  │获取 │   │识别 │   │开通 │   │ 交付│   │ 关系│
  └──┬──┘   └──┬──┘   └──┬──┘   └──┬──┘   └──┬──┘
     │         │         │         │         │
  能力映射:  能力映射:  能力映射:  能力映射:  能力映射:
  • 渠道管理  • 客户   • KYC   • 交易   • 交叉销售
  • 营销     • 需求分析 • 开户  • 客服   • 客户分析
  • 品牌     • 风险评估 • 合规  • 投诉   • 生命周期

步骤2: 评估每个阶段的"痛点"和"价值泄漏"

  客户获取: 转化率仅3% (行业均值5%) → 价值泄漏$2M/年
  产品开通: 平均7天 (竞品2天) → 客户流失15%
  服务交付: NPS 30 (行业均值45) → 续约率下降

步骤3: 将痛点映射到能力差距

  | 痛点 | 相关能力 | 当前成熟度 | 目标成熟度 | 差距 |
  |------|---------|-----------|-----------|------|
  | 转化率低 | 数字营销 | 2 | 4 | -2 |
  | 开户慢 | KYC自动化 | 1 | 4 | -3 |
  | NPS低 | 全渠道客服 | 2 | 4 | -2 |

步骤4: 计算投资优先级

  Priority = 价值影响 × 差距大小 / 实施难度

  KYC自动化: $3M收入影响 × 3差距 / 中等难度 → P0
  数字营销: $2M × 2 / 低难度 → P1
  全渠道客服: $1.5M × 2 / 高难度 → P2

步骤5: 形成投资路线图
  Q1-Q2: KYC自动化 (投资$500K，预期ROI 6x)
  Q3-Q4: 数字营销升级 (投资$300K，预期ROI 7x)
  Next Year: 全渠道客服 (投资$800K，预期ROI 4x)

价值流分析的优势：

从客户视角而非部门视角做决策
用数据量化"投资这个能力值多少钱"
避免"会哭的孩子有奶吃"——谁声音大谁拿到预算

追问准备

追问: "价值流分析和CBAM有什么关系？"

CBAM（基于成本的架构分析方法）是在架构方案层面做经济分析，而价值流分析是在战略层面做投资决策。两者互补——价值流分析决定"投资哪个能力"，CBAM决定"这个能力的架构方案怎么选"。在实践中，我通常先做价值流分析确定投资方向，再用CBAM评估具体技术方案的ROI。

题目 4：Wardley Map如何辅助技术战略？

30秒版本

Wardley Map通过两个维度——价值链（纵轴：用户可见度）和演化阶段（横轴：Genesis→Custom→Product→Commodity）——来可视化技术组件的战略定位。它能帮助回答三个关键问题：哪些该自建（Genesis/Custom阶段）、哪些该买/用SaaS（Product阶段）、哪些该用云服务/开源（Commodity阶段），以及哪些组件即将演化到下一阶段需要提前布局。

2分钟版本

Wardley Map的构建：

可见度
  高 │  [用户需求]
     │       │
     │  [Web前端] ─── [移动App]
     │       │            │
     │  [业务逻辑层]───────┘
     │       │
     │  [订单管理]  [支付处理]  [推荐引擎]
     │       │          │           │
     │  [数据库]   [支付网关]  [ML模型]
     │       │          │           │
  低 │  [云基础设施]────────────────┘
     │
     └───┬──────┬──────┬──────┬───→ 演化
       Genesis Custom Product Commodity

战略决策应用：

演化阶段	特征	策略	示例
Genesis	新颖/不确定	自建+试验	AI推荐算法
Custom	定制化/差异化	自建+核心团队	订单路由引擎
Product	成熟/有现成方案	买/SaaS	CRM/ERP
Commodity	标准化/无差异	云服务/开源	数据库/消息队列

2025-2026最新应用——AI时代的Wardley Map：

根据2026年David Haberlah的分析，Agentic AI正在改变Build vs Buy的经济学——曾经明确属于"Buy"（Product/Commodity阶段）的SaaS组件，由于AI降低了开发成本，部分正在回归"Build"。具体而言：

**SaaS平台（Product阶段）**原来是明确的"Buy"，但现在AI编码让定制化构建成本暴降
评估标准变化：不是"这个产品够不够好"，而是"它与我工作流的匹配程度值不值得我付出集成成本"

我在实际项目中的应用：

场景: 为一家零售银行做3年技术战略

1. 画出当前Wardley Map
   - 核心银行: Custom (自研老系统)
   - 手机银行: Product (外购)
   - 风控引擎: Custom (自研)
   - 基础设施: Commodity (IDC)

2. 预测演化方向(3年)
   - 核心银行: Custom → Product (云原生核心银行成熟)
   - 手机银行: Product → Commodity (低代码可搭建)
   - 风控引擎: Custom → Custom (仍需差异化)
   - 基础设施: Commodity → Commodity (全面上云)
   - AI Agent: Genesis → Custom (新赛道)

3. 得出战略
   - 核心银行: 准备迁移到Thought Machine等云原生平台
   - 手机银行: 降低投入，用低代码平台快速迭代
   - 风控引擎: 继续投资，融入AI能力
   - AI Agent: 组建创新团队试验

追问准备

追问: "Wardley Map和波特五力模型有什么区别？"

波特五力分析的是行业结构和竞争格局（静态），Wardley Map分析的是价值链组件的演化方向（动态）。波特告诉你"行业有多激烈"，Wardley告诉你"接下来会发生什么"。在战略规划中，我先用波特五力理解竞争环境，再用Wardley Map规划技术演进。

题目 5：如何用BIAN标准规划银行架构？

30秒版本

BIAN（Banking Industry Architecture Network）提供了银行业的标准服务目录——约300+个Service Domain覆盖银行全业务。它的价值不是"照搬"，而是作为参考模型来检查自己的架构是否有遗漏、服务粒度是否合理。实践中我会先用BIAN Service Landscape做能力对标，识别差距，然后选择性采纳——核心域保留自己的建模，通用域对齐BIAN标准。

2分钟版本

BIAN框架核心结构：

BIAN Service Landscape (约300+ Service Domains)

┌─────────────────────────────────────────────┐
│  业务领域 (Business Areas)                   │
│                                             │
│  ┌──────────────┐  ┌──────────────┐         │
│  │ 客户管理      │  │ 产品管理      │         │
│  │ • Party       │  │ • Product    │         │
│  │ • Contact     │  │ • Design     │         │
│  │ • Directory   │  │ • Directory  │         │
│  └──────────────┘  └──────────────┘         │
│                                             │
│  ┌──────────────┐  ┌──────────────┐         │
│  │ 销售服务      │  │ 运营服务      │         │
│  │ • Offer       │  │ • Payment    │         │
│  │ • Agreement   │  │ • Settlement │         │
│  │ • Fulfillment │  │ • Accounting │         │
│  └──────────────┘  └──────────────┘         │
│                                             │
│  ┌──────────────┐  ┌──────────────┐         │
│  │ 风险合规      │  │ 基础服务      │         │
│  │ • Compliance  │  │ • Reference  │         │
│  │ • Fraud       │  │ • Transaction│         │
│  │ • Credit Risk │  │ • Security   │         │
│  └──────────────┘  └──────────────┘         │
└─────────────────────────────────────────────┘

BIAN的实际应用方式：

方式1: 能力对标
  将自己的服务目录和BIAN对比
  → 发现缺少"Customer Behavioral Insights"服务
  → 纳入规划

方式2: 服务粒度参考
  自己的"客户管理"是一个大单体
  BIAN分解为: Party Reference, Customer Profile,
  Customer Behavior Models, Customer Access Entitlement...
  → 参考BIAN做微服务拆分

方式3: API标准化
  BIAN定义了Service Operation (CRUD+Execute+Request+Notify)
  → 统一团队的API设计规范

方式4: 厂商评估
  用BIAN Service Domain覆盖率评估核心银行供应商
  → 某厂商覆盖80%的BIAN域 → 差距20%需要定制

注意事项：

BIAN是参考不是标准——不必100%对齐
大型银行用BIAN做架构治理最有价值
中小银行可以选择性采纳核心域
BIAN与TOGAF互补——TOGAF是方法论，BIAN是银行业参考内容

追问准备

追问: "BIAN和DDD限界上下文如何结合？"

BIAN的Service Domain可以近似映射为DDD的限界上下文，但粒度通常更细。我的做法是以BIAN的Service Domain为参考划分微服务边界，但内部建模仍用DDD方法（聚合根/实体/值对象）。例如BIAN的"Current Account"Service Domain → DDD的"活期账户"限界上下文。

题目 6：如何向非技术高管解释架构决策？

30秒版本

关键是"翻译"——将技术决策翻译为业务影响。我用"三明治法"：先说业务目标（"我们要支撑双11 10倍流量"），再用类比解释技术方案（"就像高速公路扩容，我们需要从4车道变8车道"），最后说投资和收益（"投入200万，避免宕机损失2000万"）。永远不要用技术术语，用业务语言。

2分钟版本

高管沟通框架：

1. 业务语境 (Business Context) - 30秒
   "我们的战略目标是支撑未来3年5倍业务增长"

2. 当前痛点 (Pain Points) - 30秒
   "现在系统每次大促都会宕机2小时，直接损失500万"

3. 方案选项 (Options) - 30秒
   "方案A: 投入200万，优化现有系统（短期有效，1年后还是不行）
    方案B: 投入800万，重建云原生架构（一次到位，支撑5倍增长）
    方案C: 投入500万，分阶段迁移（平衡风险和收益）"

4. 推荐理由 (Recommendation) - 20秒
   "推荐方案C，因为：
    • 风险可控（分阶段，每阶段可验证）
    • ROI最优（18个月回本）
    • 不影响在线业务"

5. 决策请求 (Ask) - 10秒
   "需要批准500万预算和6个月第一阶段"

实用技巧：

用类比而非术语（微服务→"乐高积木式组装"）
用数字量化影响（"每次宕机损失500万"而非"可用性降低"）
用风险引起关注（"不做的风险是什么"）
用竞品制造紧迫感（"竞品已经完成了云迁移"）

追问准备

追问: "高管说'太贵了'怎么回应？"

我会展示"不投资的成本"：按照当前每年宕机损失500万×5年=2500万，加上因系统慢导致的客户流失率增加3%=年损失1000万。500万投资对比这些损失，ROI非常明确。另外我会提供分阶段方案——第一阶段只需200万，3个月见效。

题目 7：业务流程建模用BPMN还是Event Storming？

30秒版本

BPMN适合建模"已知的、需要精确定义的"流程（如合规流程、审批流程），强调控制流和网关条件。Event Storming适合"探索的、需要发现的"领域（如新产品设计、系统重构），强调领域事件和聚合发现。两者互补——先用Event Storming探索业务全貌，再用BPMN精确定义关键流程。

2分钟版本

对比分析：

维度	BPMN	Event Storming
目的	精确定义流程	探索和发现领域
受众	业务分析师/流程自动化	架构师/开发/业务
产出	流程图(可执行)	领域模型/限界上下文
协作模式	一人画多人审	多人协作(贴便利贴)
粒度	任务级(Task/Activity)	事件级(Domain Event)
工具	Camunda/Activiti	便利贴/Miro
适用场景	审批流/工作流/合规	新项目/重构/探索

何时用BPMN：

需要流程自动化（Camunda/Zeebe执行引擎）
需要精确的控制流（网关/条件/并行/补偿）
合规要求流程可审计
跨部门流程需要精确定义职责（泳道图）

何时用Event Storming：

项目初期，领域不清晰
需要技术和业务对齐
识别限界上下文和聚合
发现隐藏的业务规则

我的实践方法：

Phase 1: Big Picture Event Storming (半天工作坊)
  → 发现核心领域事件和限界上下文
  → 产出: 领域事件流 + 限界上下文地图

Phase 2: Process-Level Event Storming (每个上下文1-2天)
  → 深入每个上下文，发现命令/聚合/策略
  → 产出: 聚合设计 + 关键业务规则

Phase 3: BPMN精确建模 (关键流程)
  → 对需要流程引擎驱动的流程用BPMN建模
  → 产出: 可执行的流程定义

结论: Event Storming先行探索，BPMN后行精确化

追问准备

追问: "Event Storming效果好，但很多团队做不好，为什么？"

三个常见问题：(1) 没有真正的领域专家参与——只有开发人员"自嗨"；(2) 引导师技能不够——不会控场，被细节带跑；(3) 后续没有跟进——热闹完回去还是老样子写代码。解决方法：确保业务方参与、找有经验的引导师、Event Storming产出直接转化为Backlog。

题目 8：企业架构治理如何落地？

30秒版本

架构治理 = 规则 + 流程 + 工具 + 文化。规则是架构原则和标准（如"所有服务必须通过API Gateway"），流程是评审机制（如"每个Sprint有Architecture Review"），工具是ADR和架构适应度函数（自动检查合规），文化是让团队理解"架构治理不是限制自由，而是确保方向一致"。最重要的是轻量级——过重的治理没人遵守。

2分钟版本

架构治理框架：

┌─────────────────────────────────────────────┐
│             架构治理四个支柱                   │
├─────────────────────────────────────────────┤
│                                             │
│  1. 架构原则 (Principles)                    │
│     ├── 业务原则: "客户优先""数据驱动"       │
│     ├── 架构原则: "API First""事件驱动"      │
│     ├── 技术原则: "Cloud Native""开源优先"   │
│     └── 安全原则: "零信任""最小权限"         │
│                                             │
│  2. 评审流程 (Review Process)                │
│     ├── L1: 团队自评 (每Sprint, ADR)         │
│     ├── L2: 架构评审 (每月, 跨团队)          │
│     ├── L3: 架构委员会 (季度, 重大决策)       │
│     └── 触发条件: 新服务/技术选型/大变更      │
│                                             │
│  3. 合规工具 (Compliance Tools)              │
│     ├── ADR系统: 决策记录和搜索              │
│     ├── ArchUnit: 代码级架构约束自动检查     │
│     ├── 适应度函数: CI/CD中自动验证          │
│     └── 技术雷达: 技术选型指导(Hold/Assess/  │
│         Trial/Adopt)                        │
│                                             │
│  4. 架构文化 (Culture)                       │
│     ├── 内部Tech Talk (每月分享)             │
│     ├── 架构决策透明 (ADR全员可见)           │
│     ├── 允许实验 (Innovation Sprint)         │
│     └── 奖励优秀架构实践                     │
└─────────────────────────────────────────────┘

落地关键：

从小做起：先推ADR，再推评审，最后推适应度函数
自动化优于人工：用ArchUnit自动检查，而非开会Review
引导优于强制：用技术雷达引导选型，而非禁止清单
度量优于感觉：统计ADR数量、评审覆盖率、合规率

追问准备

追问: "架构治理和开发自由度如何平衡？"

我的原则是"大方向管控，小细节自由"。架构原则和技术选型（如"用Kafka做消息队列"）是必须遵守的——这是"高速公路的车道线"。但具体实现（如"用Kotlin还是Java写服务"）是团队自主的——这是"车道内怎么开"。治理的目的是让100个团队的系统能互操作，而非统一编码风格。

题目 9：商业模式画布如何映射到架构设计？

30秒版本

商业模式画布的9个要素直接影响架构关键决策：价值主张决定核心域设计，客户细分决定多租户/个性化架构，渠道决定接入层设计，收入模式决定计费/结算系统，关键资源决定技术平台选择，关键伙伴决定集成架构，成本结构决定自研/外购/云策略。架构师必须理解商业模式，否则设计出的架构和业务脱节。

2分钟版本

映射关系：

商业模式要素	架构影响	示例
价值主张	核心域设计	"最快配送"→投资路由引擎和调度系统
客户细分	多租户/SaaS架构	B端+C端→不同的BFF和数据隔离
渠道	接入层/BFF	全渠道→统一API Gateway+多BFF
客户关系	CRM/会员系统	自助→在线客服系统 / 专属→客户经理系统
收入模式	计费/结算引擎	订阅→Billing系统 / 佣金→清结算系统
关键资源	技术平台选择	数据驱动→投资数据平台 / IP驱动→保护算法
关键活动	核心流程自动化	物流→WMS/TMS / 制造→MES/ERP
关键伙伴	集成架构	多供应商→开放API平台 / 生态→SDK
成本结构	自研vs外购策略	成本敏感→SaaS/开源 / 差异化→自研

实践方法：

和业务方一起画商业模式画布
对每个要素问："这对系统架构意味着什么？"
标记哪些是核心域（差异化竞争力）、哪些是通用域（标准化）
根据收入模式推导系统的可靠性/性能/安全要求
根据成本结构推导技术选型策略

追问准备

追问: "平台型商业模式对架构有什么特殊要求？"

平台模式（如淘宝/美团）的架构核心是"供需撮合+交易信任+规则引擎"。技术上需要：多租户隔离（每个商家一个"虚拟空间"）、开放API平台（商家接入）、规则引擎（平台规则动态调整）、分账结算系统（多方分润）、信用/评价体系。平台架构的关键词是"开放、弹性、治理"。

题目 10：如何评估业务架构的成熟度？

30秒版本

我用五级成熟度模型评估：Level 1-无架构（各做各的），Level 2-被动响应（项目驱动的临时架构），Level 3-主动规划（有能力基线和目标架构），Level 4-度量优化（架构决策可追溯、合规率可度量），Level 5-持续演进（架构与战略紧密联动，自动化治理）。大多数企业在Level 2-3，达到Level 4就已经是行业前10%。

2分钟版本

五级成熟度模型：

Level 5: 持续演进 ────────────── 极少数标杆企业
  • 架构与战略实时联动
  • 自动化架构适应度检查
  • 数据驱动的架构决策
  • 架构创新引领业务创新

Level 4: 度量优化 ────────────── 行业领先(Top 10%)
  • ADR覆盖所有重大决策
  • 架构合规率可度量(>90%)
  • 技术债可量化和管理
  • 定期ATAM评审

Level 3: 主动规划 ────────────── 多数成熟企业目标
  • 有能力基线和目标架构
  • 有架构原则和标准
  • 架构评审流程建立
  • 但执行不够一致

Level 2: 被动响应 ────────────── 多数企业现状
  • 项目驱动的架构决策
  • 依赖个别架构师经验
  • 缺乏统一标准
  • 技术债积累

Level 1: 无架构  ────────────── 初创/小团队
  • 没有架构师角色
  • 没有架构文档
  • 完全依赖开发经验

评估维度和度量：

维度	度量指标	L2标准	L4标准
架构文档	ADR覆盖率	<20%	>90%
架构评审	重大变更评审率	<30%	>95%
技术标准	技术栈合规率	无标准	>85%
技术债	债务量化率	不知道有多少	全部量化
架构可观测	依赖图准确率	没有图	自动生成
战略对齐	架构路线图覆盖率	没有路线图	年度更新

追问准备

追问: "如何在6个月内将成熟度从Level 2提升到Level 3？"

三步走：(1) 第1-2月——建立架构原则和ADR制度（所有新决策必须写ADR）；(2) 第3-4月——做一次现状能力建模（As-Is），建立能力基线；(3) 第5-6月——制定目标架构和差距分析，形成第一版架构路线图。核心是"先建制度，再填内容"。

题目 11：数字化转型中架构师的角色是什么？

30秒版本

架构师在数字化转型中扮演"翻译官+设计师+守护者"三重角色：翻译业务战略为技术架构方向，设计现代化的目标架构和迁移路径，守护架构演进过程中的一致性和质量。最关键的是做好"遗留系统现代化"的规划——80%的转型失败都源于低估了遗留系统改造的复杂性。

2分钟版本

三重角色详解：

角色1: 翻译官 (Business ↔ Technology)
  ├── 将CEO的"我们要数字化"翻译为具体架构目标
  ├── 将技术约束翻译为业务影响（"老系统限制了..."）
  └── 建立业务能力到技术系统的映射

角色2: 设计师 (Architecture Design)
  ├── 设计目标架构（Cloud-Native/Microservices/Event-Driven）
  ├── 设计迁移路径（Big Bang vs Strangler vs Parallel Run）
  ├── 设计数据迁移策略（最容易被忽视的部分）
  └── 设计组织架构变化（Conway's Law）

角色3: 守护者 (Architecture Governance)
  ├── 确保转型过程不偏离架构方向
  ├── 管控技术债（新系统不能再堆债）
  ├── 平衡短期交付压力和长期架构目标
  └── 建立架构度量和反馈机制

2025-2026趋势：数字化转型已进入"第二波"——从"上云/上线"到"AI驱动的智能化"。架构师的新挑战是将AI能力嵌入现有架构，包括AI Agent编排、数据治理（AI需要高质量数据）、模型运维（MLOps/LLMOps）。

追问准备

追问: "数字化转型中最常见的架构反模式？"

(1) "分布式单体"——拆了微服务但耦合没解开；(2) "技术驱动转型"——没有业务目标，为了微服务而微服务；(3) "忽视数据"——系统换了但数据还是一团糟；(4) "Big Bang"——想一步到位，结果一步到坑。

题目 12：如何做架构现状评估（As-Is Assessment）？

30秒版本

架构现状评估的核心产出是三张图和一份报告：系统全景图（有哪些系统、怎么交互）、能力覆盖热力图（哪些能力强、哪些弱）、技术债分布图（哪些系统债务最重），以及一份差距分析报告（现状vs目标的差距）。方法上结合文档审查、利益相关方访谈、代码/系统分析三个维度。

2分钟版本

评估框架：

输入:
  ├── 现有架构文档（如果有的话）
  ├── 系统运维记录（故障/性能/变更）
  ├── 利益相关方诉求
  └── 业务战略目标

评估维度:
  1. 系统拓扑: 有多少系统？怎么交互？数据怎么流转？
  2. 技术栈: 用了什么技术？版本？EOL？
  3. 质量属性: 性能/可用性/安全/可维护性 当前水平
  4. 业务覆盖: 哪些业务能力有系统支撑？哪些还是手工？
  5. 技术债: 代码质量/架构债务/基础设施债务
  6. 组织能力: 团队技术栈/人员配比/DevOps成熟度

方法:
  Week 1: 文档收集 + 系统清单梳理
  Week 2: 利益相关方访谈 (业务+技术, 10-15人)
  Week 3: 技术深潜 (代码审查/架构分析/性能测试)
  Week 4: 差距分析 + 报告撰写

产出:
  ├── 系统全景图 (ArchiMate)
  ├── 能力覆盖热力图
  ├── 技术债登记簿
  ├── 差距分析矩阵
  └── 改进建议优先级排序

追问准备

追问: "如果企业没有任何架构文档怎么办？"

这其实是常见情况。三个办法：(1) 从运维监控反推——看Zabbix/Prometheus/日志，能知道系统拓扑；(2) 从数据库反推——ER图暴露了业务模型；(3) 从代码反推——用工具（如Lattix/Structure101）分析代码依赖。最有效的是"一小时白板会"——请系统负责人花1小时画出他负责的系统和上下游。

题目 13：能力热力图如何辅助投资决策？

30秒版本

能力热力图在二维矩阵上展示每个业务能力的"战略重要性"和"当前成熟度"。右下角（高重要性+低成熟度）是优先投资区；左上角（低重要性+高成熟度）是过度投资区。这个可视化工具帮助管理层直观看到"把钱花在哪里回报最大"。

2分钟版本

                    战略重要性
              低          中          高
         ┌──────────┬──────────┬──────────┐
    高   │ 过度投资  │  维持     │  保持领先  │
         │ → 降低投入│  → 稳定   │  → 持续优化│
  成 ├──────────┼──────────┼──────────┤
  熟    中   │ 非优先    │ 按需提升  │  重点关注  │
  度    │ → 维持   │  → 择机   │  → 快速补齐│
         ├──────────┼──────────┼──────────┤
    低   │ 暂不投资  │ 评估价值  │  紧急投资  │
         │ → 观望   │  → 论证   │  → 立即启动│
         └──────────┴──────────┴──────────┘

示例(零售企业):
  紧急投资: 全渠道库存(高重要×低成熟) → 投入$1M
  重点关注: AI推荐(高重要×中成熟) → 投入$500K
  过度投资: 传统报表(低重要×高成熟) → 减少投入

制作步骤：

列出所有L1级业务能力（通常20-30个）
业务方评估"战略重要性"（1-5分）
IT评估"当前成熟度"（1-5分）
绘制热力图，标识象限
计算投资优先级 = (重要性 - 成熟度) × 影响系数

追问准备

追问: "评分主观怎么办？"

三个办法降低主观性：(1) 多人评分取均值（至少5人）；(2) 用数据支撑——"成熟度"可以用系统可用性/客户满意度/效率指标量化；(3) 和竞品对标——竞品有而我们没有=低成熟度。最终评分不需要精确，能区分出"高/中/低"三档就够了。

题目 14：如何做技术雷达（Technology Radar）？

30秒版本

技术雷达借鉴ThoughtWorks的实践——将技术分为四个象限（语言框架/工具/平台/技术实践），每项技术标注四个状态（Adopt-推荐使用/Trial-可以试用/Assess-观望评估/Hold-停止使用）。每季度更新，由架构团队+资深开发共同评审。它的核心价值是"统一选型标准"——新项目选技术时先查雷达，不在雷达上的需要申请评审。

2分钟版本

技术雷达结构：

          ┌──────────────────────────┐
          │      Technology Radar     │
          ├──────────────────────────┤
          │                          │
  Adopt ──┤  Kotlin  React  K8s     │
          │  Go     PostgreSQL       │
          │                          │
  Trial ──┤  Rust   Pulsar  Dapr    │
          │  WASM   Temporal         │
          │                          │
 Assess ──┤  Zig    Mojo   Valkey   │
          │  AI Agent Framework      │
          │                          │
   Hold ──┤  jQuery  Oracle→PG迁移  │
          │  自研RPC→gRPC迁移       │
          └──────────────────────────┘

四个象限:
  ├── Languages & Frameworks (语言和框架)
  ├── Tools (工具链)
  ├── Platforms (平台和基础设施)
  └── Techniques (技术实践和方法)

运营机制：

更新频率：每季度一次
评审团：首席架构师 + 各团队Tech Lead（8-12人）
评审标准：社区活跃度/生产验证/团队掌握程度/与现有栈兼容性
例外流程：使用非雷达技术需要提交ADR，经架构评审通过

追问准备

追问: "团队不遵守技术雷达怎么办？"

先理解原因——是不知道？还是有合理理由？如果是合理理由（如特定场景确实需要），走例外流程记录ADR。如果是不遵守制度，通过代码审查和CI检查（如ArchUnit限制依赖）自动拦截。治理的终极目标不是100%合规，而是让每个"例外"都有记录和理由。

题目 15：业务架构和企业架构的关系是什么？

30秒版本

企业架构（EA）包含四个维度：业务架构、数据架构、应用架构、技术架构。业务架构是EA的"锚点"——它定义了企业需要什么能力、什么流程、什么数据，后三个架构都是为了支撑业务架构而存在。没有业务架构的EA就像没有需求的代码——技术可能很厉害但不知道在解决什么问题。TOGAF把Phase B（业务架构）放在C（信息系统）和D（技术）之前，正是这个原因。

2分钟版本

四维架构关系：

                 ┌──────────────┐
                 │  业务战略     │
                 │  (Why/What)  │
                 └──────┬───────┘
                        │ 驱动
                        ▼
                 ┌──────────────┐
                 │  业务架构     │
                 │  能力/流程/   │
                 │  组织/信息    │
                 └──────┬───────┘
                        │ 约束
           ┌────────────┼────────────┐
           ▼            ▼            ▼
    ┌──────────┐ ┌──────────┐ ┌──────────┐
    │ 数据架构  │ │ 应用架构  │ │ 技术架构  │
    │ 概念/逻辑│ │ 系统/集成│ │ 平台/网络│
    │ /物理模型│ │ /接口    │ │ /基础设施│
    └──────────┘ └──────────┘ └──────────┘
           │            │            │
           └────────────┼────────────┘
                        │ 实现
                        ▼
                 ┌──────────────┐
                 │  实施方案     │
                 │  项目/迁移/  │
                 │  路线图      │
                 └──────────────┘

核心观点：

业务架构是"需求侧"，其余三个是"供给侧"
业务架构决定IT投资方向（投什么）
应用架构决定系统边界（建什么）
数据架构决定信息流转（流什么）
技术架构决定平台支撑（用什么）

常见误区：

"EA就是画系统拓扑图" → EA核心是业务与技术的对齐
"业务架构是BA的事" → 架构师必须理解业务
"四个架构分开做" → 必须迭代推进，互相验证

追问准备

追问: "在敏捷组织中，EA是否还有价值？"

绝对有，但形式需要变化。传统EA产出厚厚的文档半年后才能用，敏捷EA产出的是"架构Runway"——提前1-2个Sprint做必要的架构决策，为团队铺路。SAFe中的"Architectural Runway"正是这个概念。EA的价值从"制定蓝图"变为"提供方向+确保一致性"。

面试技巧总结

如何在面试中展示业务架构思维

技巧1: 永远从业务出发
  ✗ "我建议用微服务架构..."
  ✓ "根据业务增长目标，核心系统需要支撑10倍扩展..."

技巧2: 用框架但不被框架困住
  ✗ "按照TOGAF ADM的Phase B..."
  ✓ "我通常用能力建模来理解业务全貌，这个方法论来自TOGAF..."

技巧3: 展示量化思维
  ✗ "这个能力很重要需要投资"
  ✓ "这个能力差距导致每年损失500万，投资200万6个月回本"

技巧4: 展示沟通能力
  ✗ 只画技术架构图
  ✓ 用价值流图、能力热力图这些"业务人也能看懂"的可视化

技巧5: 展示权衡思维
  ✗ "这是最佳实践"
  ✓ "方案A更快但技术债高，方案B更稳但周期长，我推荐B因为..."

业务架构面试评分维度

维度	权重	优秀表现
业务理解	30%	能清晰描述业务能力和价值流
方法论	20%	灵活运用TOGAF/BIAN/能力建模
量化能力	20%	用数据支撑架构决策
沟通表达	20%	不同受众不同语言
实战经验	10%	有真实项目案例

今日总结

关键收获

业务架构是架构师的"隐形门槛"——技术架构大家都会说，但业务架构能力才是区分高级和资深的关键
能力建模是业务架构的基石——能力稳定、与组织解耦、可度量
价值流是投资决策的依据——从客户视角分析价值泄漏，用数据驱动投资
Wardley Map是战略工具——在AI时代，Build vs Buy的边界正在被重新定义
治理要轻量——ADR+自动化检查+架构评审，不要搞成"架构审批委员会"

15题速查表

#	题目	核心关键词
1	业务能力建模	What not How / 分层 / 稳定
2	TOGAF裁剪	敏捷适配 / 保留核心 / ADR替代文档
3	价值流投资	价值泄漏 / 差距分析 / ROI
4	Wardley Map	演化阶段 / Build vs Buy
5	BIAN标准	银行参考模型 / 服务目录
6	高管沟通	翻译 / 类比 / 数字 / 风险
7	BPMN vs Event Storming	What vs How / 探索 vs 精确
8	架构治理	原则+流程+工具+文化
9	商业模式→架构	9要素映射 / 核心域识别
10	成熟度评估	五级模型 / 度量指标
11	数字化转型角色	翻译官+设计师+守护者
12	As-Is评估	三张图一报告 / 四周完成
13	能力热力图	重要性×成熟度 / 投资象限
14	技术雷达	Adopt/Trial/Assess/Hold
15	BA与EA关系	业务是锚点 / 四维迭代

明日预告: Day 116 - 软件架构面试专题，15道精选软件架构面试题，涵盖DDD、微服务、事件驱动、CQRS、Saga等核心主题。