《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》算是我2020年读完的第二本书，简单记录下收货。

很有内味儿

我是抱着"到底什么是中台？这玩意和服务化有啥区别?"的疑惑找来了这本书看，但是书里并没有给出"中台"这个词的定义、解释，也没有讲清楚中台和服务化到底啥区别，就开始一顿吹（这真的很有内味儿，造出一些新词，没有明确定义就开始吹……）
书大概分3部分，前面两章讲中台战略的背景和“共享服务体系”，中间突然开始介绍技术基础设施(其实就是微服务那套全家桶），最后介绍商业案例。中间那部分我看不下去简单翻一下就跳过了，特别像内网邀功文章，一顿猛吹没营养。

不合格的技术书籍，很棒的管理书籍

看下来感觉这书作为技术书籍不太合格，与其看中间的技术部分不如看市面上其他讲的更好的书，但是开头两章、结尾两章以及后面第九章后半部分讲解的管理、商业上的思考还是让我感到很有收获的。

那么到底什么是中台？和服务化有啥区别？

个人理解，服务化偏向于技术上的概念，关注的是系统边界如何划分，而中台是管理上的“服务化”，关注的是组织结构上把共享业务给“服务化”成业务“中台”（或者叫部门、事业部之类的)，以及搭建配套的业务划分、绩效考核等管理制度。

举个例子？

这么讲还是太虚了，举个例子：比如假设淘宝有独立的系统专门做商品相关的业务，叫“商品service"，这就很服务化；但是淘宝、天猫、1688可能都有商品service，假如某天新成立个业务叫聚划算，他也想要商品service，按我之前呆过的某个电商公司的做法，会找其他业务部门做电商系统的工程师借调来帮忙复制粘贴搭一套商品service来。这么搞很不错，但是有一个问题：初期复制粘贴来的都是很基础的系统，以后怎么扩展？比如我加个定制的需求，找原来的那个工程师来做？对不起人家KPI不是这个，你猜你的事情优先级高不高。你找自己部门接手的人来搞？哎哟历史遗留那么多东西不太敢扩展。再比如，我想要些高级的业务创新型的功能，比如我聚划算迭代了一年后，看淘宝有商品巡检，也想搞个，这个时候再找淘宝的人来复制粘贴可能已经不好使了，因为自己一年下来魔改了太多东西了，没办法得自己的人重新造，慢。

于是，在这种情况下，你搞出个部门专门做商品相关的业务，并且强势要求淘宝、天猫、1688不准自己造、就得找这个部门提供商品service(这样这个部门就有了业务"抓手’），并给这个部门设计配套的KPI考核，这就叫中台了。假如某天新起了个聚划算的业务，拉上商品部门、交易部门、xxx部门的人，每个部门各自出一个积木，聚划算的人开发个皮，这乐高就搭起来了。更具体一点，可能商品部门的人说：“想新起一个商品中心呀，我们这有平台，你来新增个租户、做做配置就能用商品中心了。后面有新的定制需求你再找我们提”；这么一来，聚划算的人快速搭起了系统，而商品部门的同学也因为又接入了一个新租户，美滋滋的写进了年底KPI考核里。

迭代了一年后，聚划算的人说我也想要商品巡检，于是商品部门的人说“嘿嘿这个功能我们已经产品化了，你到我们的平台申请下资源、改改配置就行了”。于是商品部门的年终KPI里又加了一个新租户。
过了一阵子后，聚划算的人找到商品部门的人说，我有个新idea，想要个牛逼的商品XXX系统，商品部门的人一听，哟这个我们没有，来来来我们共创一下，我们给你开发个这个，然后沉淀到我们的平台上，于是年底的时候KPI里多了一项“业务创新：从0到1开发了商品XXX系统，并沉淀到平台能力，为将来服务多家租户打下坚实基础”。
又过了一阵子，淘宝的人看到这个商品XXX系统，觉得好牛逼我也想要，于是找商品部门的人聊了聊也接入了，于是商品部门的KPI……

(注：以上案例都是我按照书上写的加上自己的yy编的，我没呆过淘宝聚划算，如有雷同说明书写的好）

为什么搞这么一出？

因为阿里高管们参观了某游戏公司，发现人家几个人短时间内就能搞一个新游戏出来，快速试错，背后原因是该公司有很多现成的积木，造个新游戏搭积木很快；高管们觉得羡慕，回去后也想改改公司架构，让新业务能快速搭积木搭出来。

看到这个背景，技术同学肯定想到了服务化，毕竟服务化概念就是拿来解决系统复用性问题的。但从作者的描述来看，只关注技术、关注系统是不够的，还要关注人，关注流程、制度

为什么只关注技术、关注系统不够？

服务化的初衷是打通已有的烟囱，治标不治本

作者对SOA的理解是：企业信息中心是项目制，招一次标盖一个烟囱，烟囱多了后就要通过SOA把这些烟囱连起来，实现通信。但是按作者描述，这种改革不彻底，项目制仅仅把烟囱打通就完事了，干一炮收工，后续缺少对系统迭代的"激励"，且造好的烟囱不好扩展。

image.png

服务化+可扩展：既然SOA治标不治本，从一开始就别造烟囱

作者的意思是想救烟囱，光把他们打通是不够的，得一开始就划分好、一开始就不造烟囱。这也是为啥后面两章的案例分享都是跑到别人企业里从0到1搞一套新架构新系统出来，而不是去人家企业里帮人家把老系统做改造。
当然不是每次实战都允许你新搭一套系统出来的，公司内部的改革需要渐变，不可能一下子推倒重来，于是怎么把新成立的共享业务一点一点扶起来，就是管理的艺术，人的艺术了：