企业架构的V模型：业务与技术'双轮驱动'到底怎么转

Thu, 18 Jun 2026 21:10:00 +0800

业务和 IT 为什么总是"两张皮"

做过甲方项目的人都有体感：业务部门提需求像写许愿信，IT 部门交付像开盲盒。两边各有各的 KPI，各有各的排期，中间隔着一条看不见的需求鸿沟。

一个典型场景：市场部要搞一场限时促销，运营说"三天内上线"，IT 排期一看——涉及订单系统、库存系统、支付系统三个团队的改动，最快两周。业务等不了，自己找外包用 Excel + 微信群搞了一套土办法。三个月后数据对不上，又得 IT 来擦屁股。

某大型科技企业在推进自身数字化转型时，把这个问题总结得很直白——非云/数字原生企业的 IT 架构是一座"围城"：

症状	表现
封闭 IT 架构	系统之间数据不通，接口靠人肉对接
烟囱式应用	每个业务线自建一套，重复造轮子
缺少实时感知	经营数据 T+1 甚至 T+7 才能看到

结果就是：业务觉得 IT 拖后腿，IT 觉得业务乱提需求。两边都没错，错的是中间缺一层能把需求和技术对齐的架构语言。

V 模型：一个字母对应一个解法

V 模型的核心思路是"双轮驱动"——左边是业务侧的拉力，右边是技术侧的推力，两边要同步转起来。只拉不推，业务需求落不了地；只推不拉，技术投入找不到商业回报。

具体来说，V 模型的三个字母在业务侧和技术侧各有一组对应，形成从 C→B→A 的镜像结构：

业务侧（拉力）	技术侧（推力）	含义
C = Customer	C = Cloud（云平台）	以客户为中心，云平台提供弹性底座
B = Business	B = Big Data（大数据）	回归业务本质，数据驱动决策
A = Architecture	A = AI（智能化）	架构牵引全局，AI 提升效率上限

❌ 传统做法：先买一套 ERP，然后把业务流程往里塞。 ✅ V 模型做法：先搞清楚客户要什么、业务流程怎么跑，再用架构把技术选型串起来。

这个模型要解决的底层问题是经济学里的鲍莫尔成本病——服务业的生产率提升天然比制造业慢，导致运营成本不断走高。制造业可以靠自动化把单位成本压到极低，但服务业高度依赖人的判断和沟通，效率提升空间有限。

数字化转型的目标不是"上个系统"，而是结构性地提升服务效率，让"产品好 + 体验优 + 成本低"这三件通常互相矛盾的事可以同时做到。

维度	传统模式	数字化模式
产品迭代	季度发布，瀑布式	持续交付，灰度验证
客户感知	季度调研，滞后反馈	实时埋点，行为分析
运营成本	人力堆叠，线性增长	平台复用，边际递减
决策依据	经验驱动，拍脑袋	数据驱动，看指标

三大业务流：把企业拆开来看

某大型科技企业把内部所有业务活动梳理成三条主业务流。这个分法匿名化之后，对大多数中大型企业都适用。你可以把它理解为企业的"主动脉"——所有价值创造活动最终都归入这三条流：

1. 面向市场创新的业务流（Insight to Product） 从市场洞察到产品上市。核心诉求是"快"——创意验证、灰度测试、快速迭代。对应的技术能力是 A/B 测试平台、用户画像、数据埋点。这条流决定了企业能不能抓住新机会。

2. 面向客户交易的业务流（Lead to Cash） 从线索到回款。核心诉求是"准"——订单不能错、库存不能乱、账要对得上。对应的技术能力是 CRM、OMS、结算引擎。这条流决定了企业的现金流健不健康。

3. 面向问题解决的业务流（Issue to Resolution） 从客户投诉到问题闭环。核心诉求是"通"——工单能流转、知识库能复用、SLA 能追踪。对应的技术能力是工单系统、知识图谱、智能路由。这条流决定了客户留不留得住。

❌ 烟囱模式：每条业务流各建一套独立系统，数据不互通。 ✅ 平台模式：三条流共享底座能力，上层按场景编排。

共同平台：给业务种一片"黑土地"

“黑土地"是某大型科技企业对共同平台的比喻——平台不管上面种什么庄稼，但土壤得够肥、够厚、够松。换句话说，平台提供的是确定性：不管业务怎么变，底层能力随时可调。

落到架构层面，这个"黑土地"就是中台。但这里说的中台不是前几年被炒烂的那个概念——不是把所有东西都堆到一个大系统里，而是有明确边界的：

场景化服务编排：基于规则引擎和流程引擎，把原子化的服务能力按业务场景快速组合。比如"新用户首单优惠"这个场景，需要调用用户服务、优惠服务、订单服务、通知服务，编排逻辑放在中台，各服务本身保持简单。
为 ERP 减负：只有最终交易结果才写入 ERP，中间过程全部在中台处理。ERP 从"什么都能干"退回到"只管账”。这不是否定 ERP，而是让它回到自己最擅长的位置。
能力复用：用户认证、支付、消息通知这些通用能力下沉到平台层，业务线不需要各自实现。新业务上线时，80% 的能力现成可用，只需要做 20% 的场景定制。

层次	职责	典型组件
业务应用层	面向具体场景	商城 App、客服工作台
中台服务层	能力编排与复用	规则引擎、流程引擎、结算中心
平台底座层	基础设施	云平台、数据湖、DevOps 工具链

关键一点：共同平台不是"大锅饭"。平台提供的是能力菜单，业务线按需取用。如果平台团队开始替业务做决策、规定"你必须用我的方式"，那就从黑土地变成了水泥地——什么都长不出来。平台的 KPI 应该是"业务上线速度"和"能力复用率"，而不是"平台用户数"。

完整公式：信息化不是买软件

某大型科技企业把信息化建设总结成一个六段式公式：

信息化 = 战略牵引 + 架构为纲 + 需求为准 + 项管为法 + 无缝运维 + 治理全程

拆开看：

阶段	核心问题	输出物
战略牵引	我们要去哪？	数字化战略蓝图
架构为纲	路线怎么走？	企业架构（业务/应用/数据/技术）
需求为准	具体做什么？	需求规格与优先级排序
项管为法	怎么交付？	项目计划、里程碑、验收标准
无缝运维	怎么保障运行？	SRE 体系、监控告警、容灾预案
治理全程	怎么管得住？	数据治理、安全合规、变更管控

❌ 很多公司只做中间两段（需求 + 项管），相当于只有"做什么"和"怎么做"，没有"为什么做"和"做完怎么管"。 ✅ 六段全走通，才能保证技术投入和业务目标不脱节。

这个公式里最容易被跳过的是"架构为纲"。很多公司的做法是老板拍个方向（战略），然后直接跳到需求评审和项目管理，中间没有架构设计这一层。结果就是每个项目都在局部最优，但系统整体越来越乱——功能越加越多，系统越来越慢，改一个地方崩三个地方。架构为纲的意义在于：在动手之前，先把全局的结构想清楚。

中型企业怎么借鉴

不是每家公司都有某大型科技企业的体量和预算。但 V 模型的思路是可以降维使用的，关键是抓住几个核心原则而不是照搬全套方法论：

第一步：画清楚你的业务流。 不用三条，可能你只有一条核心业务流。但要把端到端流程画出来，找到断点和堵点。找业务负责人聊半天，比看一百页需求文档管用。

第二步：识别可复用的能力。 支付、通知、权限——这些是不是每个系统都在重复实现？如果是，就是中台化的起点。先别急着建平台，把重复最多的两三个能力抽出来做成共享服务就够了。

第三步：给 ERP 瘦身。 很多中小企业的 ERP 被当成万能工具箱，什么流程都往里塞。先把它退回到"财务核心系统"的定位，中间层用轻量级服务补上。这步做完你会发现 ERP 的运维成本直接砍半。

第四步：数据要实时。 哪怕只做到核心经营指标 T+0，也比 T+7 强十倍。实时感知是"双轮驱动"能转起来的前提——业务看不到实时数据，就不可能做到"回归业务、实时感知"。

第五步：建立架构评审机制。 每个新项目启动前，花两小时做一次架构评审，看看它和现有系统的关系、数据怎么流转、哪些能力可以复用。这两小时能省下后面两个月的返工。

❌ 一步到位搞大中台：预算不够、人不够、最后烂尾。 ✅ 从一个业务流开始，小步验证，逐步扩展。

做法	适合	不适合
全面中台化	万人级企业、充足预算	百人团队、预算紧张
轻量服务抽取	中型企业、渐进式改造	只有三五个系统的小公司
保持现状	系统不多、业务稳定	系统林立、业务多变

架构是桥，不是瓶颈

回到开头的问题：业务和 IT 为什么总是两张皮？

根本原因是缺一个翻译层。业务说的是"客户满意度"“转化率"“复购”，IT 说的是"微服务"“消息队列"“分库分表”。这两套语言之间如果没有翻译，沟通成本会高到让双方都不想说话。

V 模型的价值不在于它提出了什么新东西——CBA 和 ABC 的对应关系说白了就是个记忆框架。它真正的价值在于用架构这个概念把两边拉到了同一张桌子上。架构师的工作不是画漂亮的方框图，而是把业务意图翻译成技术决策，再把技术约束翻译成业务方能听懂的风险提示。

好的企业架构应该像一座桥——业务从这头走过去能看到技术的可能性，技术从那头走过来能理解业务的真实诉求。桥建好了，双轮自然能转起来；桥没建好，两个轮子各转各的，企业就在原地打转。

双轮驱动要转起来，靠的不是哪一边更努力，而是中间那座桥够不够结实。

V模型 on 文艺技术笔记