业务和 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 的对应关系说白了就是个记忆框架。它真正的价值在于用架构这个概念把两边拉到了同一张桌子上。架构师的工作不是画漂亮的方框图，而是把业务意图翻译成技术决策，再把技术约束翻译成业务方能听懂的风险提示。
好的企业架构应该像一座桥——业务从这头走过去能看到技术的可能性，技术从那头走过来能理解业务的真实诉求。桥建好了，双轮自然能转起来；桥没建好，两个轮子各转各的，企业就在原地打转。
双轮驱动要转起来，靠的不是哪一边更努力，而是中间那座桥够不够结实。