抱歉，请不要把 “业务逻辑层” 理解为 “业务中台”

这是头哥侃码的第197篇原创

在IAS2019中台架构峰会上，我曾与一位年轻帅气的技术小伙来了一番有趣的对话。

因为和朋友有约，所以我在现场互动结束之后，就急匆匆地跟其他嘉宾打了声招呼，抱着笔记本冲出了会场。

但没想到刚到电梯口，却被一位帅小伙迎面拦住。

他朝我摆了摆手，开口说：“王老师，耽误你点时间，想请教一个技术性问题可以吗？”

我假装谦虚：“太客气了，请教不敢当，大家一起探讨探讨。”

随即他从背包中拿出手提电脑，打开一份PPT，并指着其中的几张图问我：“你看，这是我们公司的业务中台，麻烦你给评价评价。”

图1. 他们的 “业务前/中/后台” 是这样的

图2. 他们 “业务前/中/后台” 的功能定义

图3. 他们 “业务前/中/后台” 的组织结构

在听完他的叙述之后，我忍不住笑出声来，并对他说：“小伙子，你这哪是中台啊？！这分明是三层架构(3-Tier Architecture) 啊……”

从表情上看，我感觉他有点懵圈，小声问了一句：“三层架构？MVC吗？”

我摇了摇头，给他从头到底普及了下3-Tier Architecture，并且强调了界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）的分层目的是为了“高内聚，低耦合” 。

他听完摇了摇头，似乎不太理解，并追问：“那么 ‘业务逻辑层’ 与 ‘业务中台’ 的区别是什么呢？”

我把他拉到一旁的咖啡厅，找了个座，并在网上翻到一张3-Tier Architecture的结构图，然后对他说：“说实话，虽然单纯通过几张图和口述，我无法了解你们的业务背景与现状。”

图4. 3-Tier Architecture

“但你所描述的那个 ‘业务中台’ ，最多只能算是一个软件体系架构中的业务逻辑层，压根跟 ‘中台’ 没半毛钱关系。”

他听完，一边摇头，一边说：“不对啊，我们技术老大可不是这么说的……”

我很好奇，忙追问他。

按他的说法，在他们公司内，大家都认为中台是一种松耦合结构的架构模式，主要是用来解决层与层之间的依赖问题的。

也就是说，他们公司的 “业务中台” 价值主要体现在以下几点：

1、把标准化的服务下沉到 ”业务后台”，把非标准化的服务上浮到 “业务中台”。

2、有了 ”业务后台”，一旦上层的设计改变，对于其调用的底层而言没有任何影响。

3、大部分的业务需求只需要捣腾 ”业务中/前台”，似乎成本更低，效率更高了。

听完他的这番言论之后，我愣了近十秒钟，一时间不知道说些什么。大脑给我的第一反应是把一堆 “吐槽” 喷在他脸上，但最终理智还是战胜了冲动。

我朝他微微的笑了笑，说了一下我的看法。

就像我在 #请你们不要调侃中台，它是我们赖以生存的镰刀#中讲述的那样，业务中台也好，技术中台也罢，它并不是一种技术实现，而是一种技术战略。而业务逻辑层可不是战略，它只不过是专门用来处理软件业务需求的一层，是用来实现设计模式及组件技术的一种手段。

说到这里，我还特地跟了一句：“不要被热点名词所迷惑，即使它处在体系架构中的中间位置，也不应该把它称为 ‘中台’。”

“我个人觉得，你们把这个部门称为 ‘自定义服务事业部’ 更为贴切。”

说到这里，我特地停顿了下，喝了口咖啡，继续说。

“当然，刚才叙述的观点主要来源于我自己的实践经验，所以听上去会显得比较武断或片面，但中台战略的兴起在国内主要来自于阿里巴巴的中台战略思想。”

“在我们系统的演化过程中，我曾多次阅读 《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书，在谈到构建业务中台基础的部分，有过这样一些描述，我觉得说的挺到位。”

说完，我打开阅读笔记给他看。

……

构建业务中台的基础 —— 共享服务体系。

松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。

反观企业需要通过ESB组件打通不同系统间的交互，实则是因为相关业务领域的业务和数据被以“烟囱式”方式建设的系统分割到了不同的系统中。

当越来越多的系统都采用自建“轮子”的方式满足自身系统对这部分业务的需求时，之前的这个服务慢慢就少有人问津，当有更好的服务出现或该服务完全满足不了当前业务发展的要求时，也就是这个服务离开历史舞台的时刻。

1、传统组织结构：我们可以将整个技术团队看做成一个组合精密的流水生产线，源源不断的业务需求进入到这条流水线后，经过流水线上各专业人员的贡献，最终将业务需求以系统的方式输出这条流水线。

2、FeatureTeam：不同角色的人员（架构师、开发人员、UED工程师等）组建成了一个新的组织，每一个这样的组织都针对某一服务中心提供持续的服务能力开发及运维，更准确说是基于这一服务中心的业务能力进行“运营”。

……

看完这段文字，我问他：“你瞧，根据阿里中台战略的定义，再结合到刚才的叙述，你发现了什么？”

他摇了摇头，看着我。

在我看来，你们那个 “业务中台” 是 用来做服务编排的，作用是助力业务的快速响应和创新，而你们那个 “业务后台” 是 松耦合的服务带来业务的复用，杜绝重复造轮子的现象。

“当然，这样的说法不仅不科学，而且有点死拉硬拽的味道，但我觉得两者之间的道理是相通的。”

听完我的话，这小伙子突然站了起来，冲着我说：“王老师，是不是我们老大在忽悠我们啊？那么长时间，很多人之所以留在这破公司卖命，就因为一直觉得自己做的是行业先进技术啊！”

我也站了起来，并拍了拍他的肩头示意他冷静，并让他坐下。

随后，我用缓和了下语气对他说：“首先，我不仅没有资格来对你们公司指指点点，更没有底气在仅知道这点皮毛信息的前提下来对某某某说三道四，这跟耍流氓没什么区别。”

“我只想说，中台，的确是在现阶段来看当下最热的一个造势名词。既然是造势名词，这就意味着可以成为企业重要抓手和杠杆，可大干一番。”

“说白了，就是在很多时候，这些热点或是概念，它主要的作用是用来对齐思想，找到战友的一种方式。”

我常说，一切抛开业务、组织及历史债的架构设计都是耍流氓。

那么啥叫好架构？啥叫牛逼的技术老大？

在我看来，在国内的大部分企业中，如果有谁能用一种理念团结人心，再加上能用一套能落地的实战方式，最终满足公司在业务发展上的需要，那就可以了。

很显然，中台这个词，似乎是这几年里最适合的粘合剂。

至于你家的数据中台都有哪些标准？他家的业务中台对人才的需求标准都有哪些？还是交给学术界的朋友们去琢磨吧。

对我们来说，意义并不大。

聊到这，我的电话铃声响了，低头一看，糟糕，原是朋友打来的，应该是催我去吃饭的。

我一看表，要死……从坐下到现在，时间已经过去了一个小时。

在和他相互留了微信之后，我就一溜烟的跑出了会场。

什么？你想知道后来如何了？至此之后，我们俩就再也没联系过，但我好像记得在他的朋友看到他在这场大会结束的一个月后，就离职了。

原因可能是因为听了我这番言论的鼓动，回去就跟他老大干仗了吧……

现在回想起来，也不知道自己是干了一件好事，还是干了一件坏事。

算了，就这样吧，挺好的。