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

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

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

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

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

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

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

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

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

……

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

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

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

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

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

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

……

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

他摇了摇头，看着我。

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

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

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

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

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

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

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

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

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

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

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

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

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

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