# 21. 业务与产品

如何把架构决策与 product strategy、cost、revenue、risk、compliance 和 time-to-market 联系起来。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-21-business-product

---

## 1. 核心观点

一个好的技术决策必须有业务意义：速度、可靠性、风险下降、成本节省，或一种新的能力。

### 架构的代价必须是可见的

> 盖一栋楼的预算不只是砖块，还包括维护、维修、保险和停工损失。

Total cost of ownership 涵盖开发、运维、支持、培训、迁移、vendor lock-in、incident response 和 opportunity cost。一个决策可以"建造便宜，运行昂贵"。

架构师要把技术上的 trade-offs 翻译成 business terms："这种集成上线快一个月，但每周多出 10 小时的人工支持"，或者"这次 refactor 把丢失支付的风险降下来了"。

### Optionality 是有价格的

> 你可以把房子盖成将来能加第二层。但加固过的地基现在就要花钱。

有时候，架构是在买 future optionality：进入新区域的能力、加上 enterprise SSO 的能力、切换 payment provider 的能力、扩大团队的能力。当未来场景的概率和价值足够高时，这笔钱才值得花。

差的 optionality 是"以防万一"的抽象。好的 optionality 是为一个大概率会出现的业务场景，事先准备好迁移路径。

## 2. 例子与反例

架构师帮助产品不要把技术上的漂亮与经济上的效果混为一谈。

### 例子：先不做 multi-region

> 一家店在搞清楚第一个城市的需求之前，不会先去搭跨国物流。

创业公司从一个区域起步，但把 data model 设计成将来可以加 region 字段和 data residency。Multi-region deployment 现在不做，因为还没有 enterprise 客户。ADR 记下触发条件：第一份带 data residency requirement 的合同。

这是一个健康的平衡：现在不多花钱，也不堵死增长的路径。

### 反例：没有 product narrative 的 refactor

> 把车间地砖换一换可以。但如果机器停产一个月，你得告诉业务方，这换来的是什么。

团队要一个季度做 rewrite，理由是"代码不好"。业务方听到的是 roadmap 停摆而看不到明显回报。如果说不清这与 cycle time、incident rate、hiring、compliance 或 revenue 有什么关系，这就只像是工程师自己的愿望。

技术改进必须挂钩到一个可度量的 product 或 operational outcome。

#### 自检

- 这个决策买到的是哪一项 business property？
- 全生命周期的拥有成本是多少？
- 下降的是哪种风险，这种风险有多真实？
- 我要怎么不带技术细节地解释这个决策？

下一模块：[AI-native 架构师](./software-architect-22-ai-native)。