你好，我是灵犀。
在课程的开篇部分，我将用两节课的篇幅，带你梳理IT在业务响应力和业务体验性这两个核心维度上面临的典型困境，深入剖析问题根源，分析可行的解决思路。
在后续的“方法篇”和“实现篇”中，则会针对这些思路，进一步讨论具体的设计方法与技术方案。因此，整个专栏的内容都将围绕这两个维度进行阐述，不偏离核心主线。
今天我们先来看业务响应力。先想象一下，周末傍晚饥肠辘辘时，你点了一份外卖，半小时后却收到骑手消息：“抱歉，商家爆单出餐延迟，请耐心等候！”。满心的期待瞬间化为焦虑。
其实，这样类似的场景也经常发生在企业内，只不过那个焦虑的人变成了业务人员，而IT人员就像奔波在各个需求之间的“外卖员”，疲于应对，却也常常无法将产品准时“送达”。面对这样的困境。你是否有静下心思考过，究竟是什么绊住了业务响应力的脚步？
特别是大模型出来之后，给我们带来了不少颠覆传统的理念和工具，是否其中就有一些，藏着解决我们问题的“钥匙”呢？
如何理解业务响应力？
直观来说，业务响应力指的是从业务向IT提出需求，到业务使用到产品的速度，就类似于外卖例子中，客户从下订单到吃上饭的速度。业务响应力是从用户视角出发衡量的时效，通常业务响应力越高，需求转化越快，为用户带来价值也越大。
业务响应力面临的三大挑战
接下来，我们就来逐一分析业务响应力上面临的三大挑战。
一、研发门槛高
长期以来，软件研发被视为一种高度知识密集型的工作。大多数具有一定规模的企业都按照软件工程的模式，建立了分工明确的IT团队。
这种专业化分工提升了研发过程的规范性，但也逐渐在业务与IT之间筑起了一道明显的“围墙”——业务在“墙”外，IT在“墙”内，彼此之间界限分明。
在这样的研发模式下，即使不考虑项目管理效率、需求复杂度等主观因素，仅从流程的客观角度来看，一个业务需求从提出到最终转化为可运行的代码并成功上线，往往需要经历多轮沟通、多层信息转化。这种高度结构化、流程化但缺乏灵活性的研发流程，本质上就容易导致交付周期长的问题。
针对上述问题，业界也不断探索优化路径，提出了多种改进方案，其中最具代表性的两种是敏捷开发模式和业务架构方法。
1. 敏捷开发：优化沟通机制，但未打破“围墙”
敏捷开发的兴起，在一定程度上缓解了传统瀑布模型中存在的响应迟缓等问题。它通过高频的沟通和反馈机制，使团队能够在项目推进过程中及时识别并剔除已经过时或不再必要的需求，从而减少无效劳动、提升整体效率。
但从本质上看，敏捷并没有真正缩短单个需求从提出到交付的周期。这就好比，原来的“围墙”还在，只是把“围墙”通往外面的“小路”改成了“多车道”，让优先级高的“车”先进来，不用像原来一样都得在外面“堵”着，只能按顺序排队解决。
- 业务架构方法：打破外层“围墙”，但里面还有“围墙”
另一种方法是引入“业务架构”，其核心目标是构建一种机制，让业务和IT使用一套共同语言进行协作与沟通，从而降低理解偏差、提升协作效率。
然而，这种“共同语言”在向具体系统设计与开发实施层面转化时，难以保持一致性。最终，依然难以避免原有的沟通断层和协作障碍。
换句话说，“围墙”最外层被拆掉了，但进入具体实现阶段后，“围墙”里面还有“围墙”。
总体而言，这些方法并未真正打破业务与IT之间的壁垒，那道高耸的“围墙”依旧存在，制约着IT在业务响应力方面的进一步突破。
二、能力复用弱
对IT来说，导致能力复用弱的一个最为根本、结构性的问题，是“烟囱式”的系统建设模式。
这种模式下，开发团队按业务领域划分，不同团队各自负责所属领域的功能实现。各系统在自己的“领地”中独立开发、独立部署，缺乏横向的协同设计。举一个资管领域的例子，开发团队一般按照固收、权益、FOF等投资标的划分，每种投资都会涉及风控，原来都是各个团队自行负责。
其结果是，不同团队重复“造轮子”，导致资源浪费严重，难以形成统一、可复用的能力资产，最终制约了IT的业务响应力。
并且，“烟囱式”模式产生的接口，多是一种“页面驱动”型接口，缺乏泛化性。在未来智能体发展趋势下，这也将成为一个亟需解决的重要问题。
其实，大多数企业也并非没有意识到这一问题，中台概念提出之后，许多企业也尝试通过建设中台来打破系统壁垒。然而，现实情况是，许多中台只是“存在于PPT中”，真正落地效果并不理想。
三、变更影响大
这一问题源于系统自治性差。一旦某个功能需要新增或修改，往往需要多个相关系统同步调整，牵一发而动全身。变更难以在局部独立进行，更无法以“小步快跑”的方式进行持续迭代和快速响应。
从表面上来看，问题出在系统之间交互过多，而交互多又源于微服务划分不合理，进一步又导致了数据孤岛的产生，又需要更多交互。
这就形成了一种典型的恶性循环。那更深层次的原因呢？我认为在于在架构设计方法论层面上，应用与数据的设计未能深度协同。
具体来说，一是应用设计时往往忽视数据，体现在微服务划分上，只是一味地拆，缺乏整合。二是数据设计时只关注应用，体现在数据设计主要围绕微服务展开，这种“以应用为导向”的设计方式，很容易导致数据模型的碎片化。结果就是每开发一个系统，就需要依赖其他大量的系统，重新聚合起所需的数据进行功能构建。
关键解决思路
在深入剖析了IT在业务响应力方面所面临的三大困境之后，接下来，我们再探讨一下关键的解决思路。在后续的“设计篇”和“实现篇”中，我们也会进一步将这些思路具体展开阐述并形成可落地的技术方案。
不过，在探讨具体思路之前，我们先来整体看一下软件（即前面说的系统）的本质。
从表面来看，软件是由特定架构组织起来的计算机数据和指令集合。但从根本上来说，它是对现实世界中业务运行规律的代码化表达。
那么，这种代码化表达带来了哪些优势呢？
首先，一旦业务流程被软件实现，就具备了“确定性”的特征。这种确定性意味着流程可以被反复调用和稳定执行，从而大幅减少人为操作带来的错误。当然，软件本身并不负责将现实中的不确定性转化为确定性，这一过程需要依靠人对业务的抽象与建模来完成。
其次，软件极大地提升了流程的执行效率。在数字化环境中，计算机的运算与处理速度远远超过人类，使得业务流程得以快速运转。
现在，我们回过头来看前面提到的三个问题。可以发现，研发门槛高主要反映在软件的建设模式和形态上，能力复用弱主要与软件的分层结构有关，而变更影响大则主要是软件的模块化问题。
一、研发门槛高的解决思路
传统研发体系整体上是一种“封闭式”的开发模式：业务部门在“围墙”之外等待，IT团队在“墙”内完成系统建设，最终交付一个成品。
这种模式在过去长期主导着企业的数字化建设，IT团队从内部很难实现突破，我们亟需一场研发范式的根本性变革。而如今，随着大模型时代的到来，这一传统模式正迎来颠覆性的变革。
一是IT建设模式将由“保姆式”转变成“共建式”。大模型技术驱动的智能编程显著降低了开发门槛。编程知识的获取也变得更加便捷，越来越多的业务人员具备了基础的编程能力。
各类轻量化的智能工具不断涌现，将编程进一步封装为可视化、低门槛的操作。例如，Dify 可快速搭建智能体，RAGFlow 可快速构建知识库，这类“类低代码”工具大大提升了业务自建能力。
这意味着，业务人员参与IT共建，正在从“可能”变为“必然”，也成为企业提升响应力的重要突破口。
我们可以借用传媒行业做一个类比。传统的电视剧制作模式高度封闭：由专业编剧、导演、演员和制作团队在“围墙”内完成内容创作，观众只是被动接收者。
而如今的平台型企业，如抖音、小红书等，则采取了完全不同的策略。它们不直接生产内容，而是搭建开放平台，吸引用户和创作者共同参与，从而形成一个自生长、自演进的内容生态。
这种“平台+共建”的模式，正是未来企业IT建设的演进方向。未来的IT部门，不再应是唯一的建设者，而应转型为“能力输出者”和“平台运营者”。
但在这个过程中，架构必须回答一个关键问题：在业务与科技共建的模式下，两者的边界在哪里，以及如何能更好地支撑业务参与共建？
二是应用形态将从“重量级”向“轻量级”演进。传统系统建设通常是在业务需求积攒到一定程度后，按业务流程或领域整体构建，系统复杂而庞大。
而如今，业务可以借助便捷的工具，随时可以基于自身场景快速构建功能。系统将从面向流程的“重量级”逐步转向“轻量级”的应用形态。
这里，大部分人都认可各类智能体，或用Cursor等智能编程工具辅助开发的“轻应用”会是未来的主流演进形态。然而，事实并没有想象中那么简单。我们知道，大模型本质是概率性质的。举个简单的例子，如果业务人员使用DataAgent，发现每次返回的指标或报表都不一样，或是使用Cursor开发的程序总发现有几回执行结果是错的，那么，这种方式肯定是不可持续的。
因此，未来在前端的“轻应用”与大模型之间，肯定还需要中间的一层，用来约束大模型应该如何去做，或是用来降解大模型的不确定性。这就像一个小孩子，家长也不会让其直接去闯荡充满不确定性的社会，而是会先教给他一些应对的原则和方法。
那么，未来中间层应该如何建设？智能体与现有的微服务之间存在怎样的关系？在未来的发展中，它们又将如何共存与协同？这些问题，都需要架构层面进行深入思考与解答。
二、能力复用弱的解决思路
这一问题本质上与软件的分层相关。回顾计算机的发展历程，最早出现的是“软硬件分层”的思想：将稳定、不变的功能固化在硬件中，而将灵活、可变的功能交给软件来实现。这也是“软件”中“软”字的由来——它代表着一种柔性和灵活性。
后来，随着软件系统的日益复杂，分层的思想被进一步引入到软件内部。前台、中台、后台的划分，本质上与软硬件分层思想一脉相承。
前面我们提到了一种“烟囱式”的建设模式。这种模式的弱点就是，缺乏横向上统一的分层设计。每当有新需求出现，往往都是从头开始、纵向上重复建设大量相似功能。
与之相比，一种更好的系统建设方式是“模型驱动”的建设模式。通过统一建模，构建一个沉淀共性能力的中台或平台体系。
可见，分层是一种提升能力复用的普适性方法。因此，在智能原生时代，中台或平台仍将扮演重要角色。
不过我们也看到，在过去的实践中，许多企业的中台建设并未达到预期效果。为了解决这一问题，在后续的课程中，我们将借鉴大语言模型中“Token原子化”的思路，提出“实体Token”这一新概念，尝试为业务中台的建设提供一种新的方法路径。
同时，时代在变，中台或平台的内涵也将不断延伸。除了业务中台，在不同的发展阶段，企业所依赖的核心中台能力也有所不同：信息化时代以云平台为核心，数字化时代则聚焦于数据中台。那么，进入智能化时代，又将出现哪些重大的变化呢？我将在后续的实现篇中详细展开。
三、变更影响大的解决思路
“变更影响大”这一问题，本质上是软件模块化的问题。然而，尽管软件模块化看起来是一个软件功能划分的问题，但其实和数据分不开关系。
我们先从一个基础问题说起：软件（即功能）和数据之间是什么关系呢？
前面提到，软件的本质是对现实世界中业务运行规律的代码化表达。如果从数据角度看，所谓的“运行规律”，其实就是关于数据怎么转化、怎么流动的一套规则。
同样，如果从数据角度看企业运作，本质上就是数据在不同岗位、不同业务节点之间不断地流转、处理、加工、传递的过程。而传统软件在这个过程中扮演的角色，简单来说就是两个字：“固化”和“加速”。
其实，现在在企业里的不少岗位，少了软件系统，业务其实仍然可以运转起来，只不过效率低了而已。
所以，数据其实是比功能更本质的东西。
回到“变更影响大”这一问题，前面分析时提到的根本原因“应用与数据之间缺乏深度协同设计”，简单来说，主要就是在软件模块化拆分时，忽视了对数据的统一规划，让数据的处理、流转变得更加复杂了。
这个问题解决的关键，并不是从软件系统的功能维度去下手，这样“治标不治本”，而是先从数据入手。
首先，在架构设计层面，提出数据的“双层价值模型”，打破传统的“以应用为导向”的数据设计思路，对于跨领域、跨系统的重要数据，转向“以价值为导向”的设计，这部分具体的设计将在数据架构篇中展开介绍。
其次，重塑企业内数据交互结构，降低耦合度。传统企业内系统间的数据交互，以数据库直连、数据同步、集中式数据中心或API的接口调用为主。这些方式多是紧耦合的，对变更影响大。
相比之下，后面将要讲到的事件驱动架构（Event-Driven Architecture），是一种更具弹性和松耦合特性的数据交互方式，在某些场景中可以重塑系统之间的数据沟通结构，有效降低变更带来的连锁影响。
最后，在数据问题解决之后，在微服务划分方面，在原有的拆分原则基础上完善一些整合性的原则，降低服务拆分不合理带来的交互混乱。
总结
这节课我们分析了业务响应力面临的三大挑战，即研发门槛高、能力复用弱以及变更影响大。而这些挑战背后的原因，可以归纳为软件的建设模式与形态、软件的分层以及软件的模块化这三个方面。由此，解决思路也聚焦到这三类重要的架构问题上。
随后，我们进一步探讨了关键的解决思路，其中绝大部分思路或是直接来源于大模型，或是受到了大模型的启发。因此，大模型绝不仅仅是一项单纯的技术，其背后所蕴含的思想、理念更值得我们深入思考与探究。
另外这节课的重点我为你梳理了一张知识导图，方便你总结复习。
思考题
今天分析的业务响应力面临的三大挑战，未必精准契合你所在公司所遭遇的实际困境。那么，你认为你所在的公司，影响业务响应力的最主要挑战是什么，核心解决思路是什么？
期待你在留言区和我交流互动，如果这节课对你有启发，别忘了分享给身边更多朋友。
精选留言