在听完他的叙述之后,我忍不住笑出声来,并对他说:“小伙子,你这哪是中台啊?!这分明是三层架构(3-Tier Architecture) 啊……”从表情上看,我感觉他有点懵圈,小声问了一句:“三层架构?MVC吗?”我摇了摇头,给他从头到底普及了下3-Tier Architecture,并且强调了界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)的分层目的是为了“高内聚,低耦合” 。他听完摇了摇头,似乎不太理解,并追问:“那么 ‘业务逻辑层’ 与 ‘业务中台’ 的区别是什么呢?”我把他拉到一旁的咖啡厅,找了个座,并在网上翻到一张3-Tier Architecture的结构图,然后对他说:“说实话,虽然单纯通过几张图和口述,我无法了解你们的业务背景与现状。”
“但你所描述的那个 ‘业务中台’ ,最多只能算是一个软件体系架构中的业务逻辑层,压根跟 ‘中台’ 没半毛钱关系。”
他听完,一边摇头,一边说:“不对啊,我们技术老大可不是这么说的……”我很好奇,忙追问他。按他的说法,在他们公司内,大家都认为中台是一种松耦合结构的架构模式,主要是用来解决层与层之间的依赖问题的。也就是说,他们公司的 “业务中台” 价值主要体现在以下几点:
1、把标准化的服务下沉到 ”业务后台”,把非标准化的服务上浮到 “业务中台”。
2、有了 ”业务后台”,一旦上层的设计改变,对于其调用的底层而言没有任何影响。
3、大部分的业务需求只需要捣腾 ”业务中/前台”,似乎成本更低,效率更高了。
听完他的这番言论之后,我愣了近十秒钟,一时间不知道说些什么。大脑给我的第一反应是把一堆 “吐槽” 喷在他脸上,但最终理智还是战胜了冲动。我朝他微微的笑了笑,说了一下我的看法。就像我在 #请你们不要调侃中台,它是我们赖以生存的镰刀#中讲述的那样,业务中台也好,技术中台也罢,它并不是一种技术实现,而是一种技术战略。而业务逻辑层可不是战略,它只不过是专门用来处理软件业务需求的一层,是用来实现设计模式及组件技术的一种手段。
说到这里,我还特地跟了一句:“不要被热点名词所迷惑,即使它处在体系架构中的中间位置,也不应该把它称为 ‘中台’。”
“我个人觉得,你们把这个部门称为 ‘自定义服务事业部’ 更为贴切。”
说到这里,我特地停顿了下,喝了口咖啡,继续说。
“当然,刚才叙述的观点主要来源于我自己的实践经验,所以听上去会显得比较武断或片面,但中台战略的兴起在国内主要来自于阿里巴巴的中台战略思想。”
“在我们系统的演化过程中,我曾多次阅读 《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》这本书,在谈到构建业务中台基础的部分,有过这样一些描述,我觉得说的挺到位。”
说完,我打开阅读笔记给他看。
……
构建业务中台的基础 —— 共享服务体系。
松耦合的服务带来业务的复用,通过服务的编排助力业务的快速响应和创新。
反观企业需要通过ESB组件打通不同系统间的交互,实则是因为相关业务领域的业务和数据被以“烟囱式”方式建设的系统分割到了不同的系统中。
当越来越多的系统都采用自建“轮子”的方式满足自身系统对这部分业务的需求时,之前的这个服务慢慢就少有人问津,当有更好的服务出现或该服务完全满足不了当前业务发展的要求时,也就是这个服务离开历史舞台的时刻。
1、传统组织结构:我们可以将整个技术团队看做成一个组合精密的流水生产线,源源不断的业务需求进入到这条流水线后,经过流水线上各专业人员的贡献,最终将业务需求以系统的方式输出这条流水线。