识别公司业务发展特点，找到架构问题的「根本解」
架构不是从技术开始，而是从业务特点开始。
很多架构师一上来就想「用上最新的技术栈」「搞一个最先进的架构」，
但真正决定你该怎么架构的，其实是：你公司的业务长什么样、往哪儿发展。
这一章，通过几段阿里系的一线故事，带你看三件事：
- 技术如何助力业务：开源（开新局）和节流（降成本）
- 技术团队怎样真正「懂业务」，拿到话语权
- 在「自建 vs 采购 / 外包」之间，架构师要如何做平衡决策
如果你现在还只是一个「被业务喂需求」的一线开发，
这章会帮你迈出走向架构师的关键一步：从业务出发看技术。
一、技术助力业务：开源 + 节流两个方向
把「技术助力业务」拆开看，其实就是两个字：赚钱。
-
开源：开拓新业务 / 新玩法，让业务赚更多钱
- 运营 / 产品会提出各种新花样
- 技术要支撑快速试错、快速上线和扩展
-
节流：降低业务成本，让赚钱更高效
- 降人工：自动化、智能化，减少人肉操作
- 降错单：提高准确率，减少资损和人工处理
- 降资源：提升系统效率，降低机器和运维成本
这两件事看起来是「业务的事」，但技术团队完全不是只能被动执行：
- 你可以反向提出：
- 「如果我们有一套推荐系统 / 用户画像 / 风控系统，可以支持哪些新玩法？」
- 「如果某些环节自动化 / 智能化了，可以减少多少人力 / 差错？」
能从这两个角度思考，你的技术方案才真正算是围绕业务展开。
二、技术团队怎样拿到业务话语权？
在很多传统公司，技术团队常被称为 Cost Center（成本中心）：
- 业务 / 运营 / 产品：定战略、定玩法、定需求
- 技术：接需求、排期、实现、背锅
想打破这个局面，你要先解决一个核心问题：
别人凭什么听你的？
答案只有一个：你懂业务。
1. 从「不懂业务」到「参与业务决策」
业务方最常怼技术的一句话是：「你不懂业务」。
那技术想掌握话语权，就要变成：
-
能讲清自己业务的玩法：
- 核心主链路是什么？
- 钱从哪儿来？指标看什么？风险在哪里？
-
能从技术角度提出业务建议：
- 哪些功能可以抽象成可复用能力（中台 / 平台）？
- 哪些玩法可以通过技术降低成本，实现得更聪明？
阿里系绩效最顶的技术部门，就是这么玩的：
- 用各种方式组织技术同学深度参与业务：
- 轮岗到业务一线
- 跟业务一起看报表、跑数据
- 自己做产品的「深度用户」
当技术团队开始从「纯实现」变成「一起想业务怎么玩」，
你的架构就不再是纸上谈兵，而是贴着业务血肉长出来的。
三、「自建 vs 采购」：别只用情怀选架构
说到业务系统，绕不开一个现实问题：
这套系统是我们自己从 0 写，还是买 / 外包一套？
技术人的本能往往是：
- 自建 = 亲生的，灵活强大，有成就感
- 采购 = 「充话费送的」，不好定制，不够优雅
但从架构师视角，这个决策远远不只是「自建更牛」这么简单。
至少要考虑三个维度：
1. 投入 vs 收益曲线 + 风险隔离
画一条简单的时间线和成本曲线：
-
采购 / 外包：
- 初期接入成本高（一口气买个大系统，可能上百万 / 上千万）
- 但业务很快能跑起来，相对确定
- 出问题有时还可以「甩部分锅」给供应商（合同里约定 SLA / 赔偿）
-
自建：
- 初期投入是：团队人数 × 人均成本 × 开发周期
- 开发周期往往很难精确预估，风险大
- 业务何时能上线、能赚到钱，很不确定
所以要算一个**「拐点」**：
在多长时间后，自建系统的累计成本 + 未来弹性
才能明显优于采购系统？
架构师需要：
- 把这个时间点和成本差估出来
- 再结合业务战略，决定：
- 先采购启动业务，后续再逐步自建替换
- 还是从 Day 1 就咬牙自建（这通常只出现在核心命门业务上）
2. 技术资源的平衡：有限子弹打在哪？
技术团队资源永远有限：
- 核心主业务：需要最强的精力、最好的同学、最长的迭代
- 边缘 / 通用业务：完全可以交给供应商系统或平台团队
在一个新业务刚起步的时候，往往是：
- 小团队 + 小步快跑 + 快速试错
这时如果把大量人力砸到一个超大系统（比如供应链、ERP 全家桶），
很可能业务还没跑起来，人就先被消耗掉了。
更合理的方式是：
- 先用成熟的供应商系统把业务「跑起来」
- 业务模式验证 OK、有成长空间，再逐步收回到自建系统里
3. 同质化业务 vs 核心差异化业务
你要时刻问自己：
这块业务，是我们的核心差异化，还是别人也能干的基础活？
就像寿司之神：
- 真正核心的是「寿司怎么做得好吃」
- 大米 / 海苔 / 三文鱼，让更专业的供应链去搞就好
放到 IT 里也是一样：
-
核心业务（直接产生利润）：
- 比如新零售里的供应链、库存策略、履约系统
- 更适合通过自建来掌控主动权
-
同质化基础业务：
- 财务记账、通用 CRM、工单系统等
- 更适合采购成熟方案，用「术业有专攻」省心省力
一个真实例子是阿里在新零售供应链上的演进：
- 早期：团队只有二十来号人，先采购一套外部 ERP 来跑
- 业务跑起来后：切换到集团内部的供应链中台系统，做适配和集成
- 发展到一定规模、玩法越来越复杂：再自建一套真正适配自身业务的供应链系统
中间每一次切换都不是情怀，而是算过账和评估过风险后的选择。
四、从集团「中台化」看架构如何贴着业务长
再看一个更宏观的例子：阿里的「大中台，小前台」战略。
在早期：
- 天猫、淘宝、1688 等各条业务线各自为战
- 每条线都有自己的一整套系统：营销、搜索、订单、会员……
结果是：
- 各事业部重复造轮子：类似的优惠引擎、会员体系、搜索引擎，版本 N 多
- 成本高、维护难、新业务上线慢
但你回头看阿里的整体业务，会发现：
- 绝大多数业务都是围绕「电商场景」：
- 搜索 & 推荐
- 营销 & 优惠
- 订单 & 支付
- 会员 & 画像
这些都是可以沉淀成通用能力的。于是：
-
把电商领域「共性强、复用度高」的能力收拢成 业务中台：
- 营销优惠中台
- 订单 / 交易中台
- 商品中台 / 库存中台……
-
再用 技术中台 承载各种基础能力：
- 服务治理、配置中心、消息、缓存、链路追踪、持续集成等
最终形成：大中台，小前台：
- 前台业务团队只关注自己个性化玩法和用户体验
- 通用的电商能力，全部通过中台来「供给」
这就是一个典型的：
「先识别公司业务的共同特点，再用架构给出一个长期的根本解」的过程。
五、如何在你所在的公司复制这套思路？
你可能不在阿里，也没有「中台化」这种大工程要搞，
但你完全可以在自己的业务里做一个「小号版」的实践。
可以从这几步开始：
-
画出你们公司的业务主链路和关键系统
- 从用户进来，到付钱 / 完成一次业务闭环
- 看看哪些系统是通用的，哪些是某条业务线独有的
-
识别「高度重复」但又很重要的能力
- 比如各种活动玩法背后一堆「拼凑」的营销逻辑
- 各业务线自己搞一堆「小订单系统」「小库存系统」
-
思考：这些是不是应该被「中台化 / 平台化」？
- 哪些适合先抽出一层公共服务 / SDK？
- 哪些可以先用轻量级方式「统一策略」，再逐步统一实现？
-
再回到「自建 vs 采购」的决策模型里评估
- 是自己重写一套，还是用开源 / 商业产品 + 定制？
- 短期 vs 中长期的投入 / 收益拐点在哪？
你不需要一上来就有集团级视角，但只要在你负责的范围内，
能比别人多看半步，多问一句「这块是不是应该沉淀成通用能力」，
你就已经在向真正的架构师迈进了。
小结：架构问题的根本解，藏在业务里
这章想给你的核心认知是：
好架构不是凭空设计出来的，而是从业务特点里「长」出来的。
作为一线开发 / 准架构师，你可以从现在就开始练习：
- 看每一个技术决策：先问业务场景，再想技术方案
- 在自建和采购之间：多算一算时间线、成本和风险，而不是只凭技术情怀
- 在日常项目里：刻意识别哪些能力值得沉淀为平台 / 中台
当你习惯先从业务出发，再落回技术，
你就不再是那个被需求推着走的「实现者」，
而会逐渐成为那个能为公司找到「架构问题根本解」的人。
这，正是一个成熟架构师和普通高级工程师之间最大的差别之一。
