老板给的一本书，当然得要怀着敬畏之心认认真真看几遍了。
这本书是阿里巴巴首席架构师钟华所作，其实还有个副标题叫《阿里巴巴中台战略思想与架构实战》。全书主要是围绕阿里巴巴的中台战略思想，从引发中台设计的业务场景到技术框架设计最后再通过两个案例分析来结尾，从三个角度来论证企业IT架构转型之道。
本书的第二部分在详细介绍共享服务体系搭建的过程、技术选择和组织架构等内容的时候使用了许多在计算机领域比较专业的术语，会让许多人认为这是写给程序员的书，但抛开技术实现手段不谈，本书的第一部分和第三部分关于中台战略思想的发展与应用，还是很值得企业的所有IT从业人员，包括企业高管、集团IT项目经理、产品经理来阅读的。
是这本书我首次认识到了“中台”的概念。以前，大家对“前台”、“后台”的理解比较直观，所谓前台就是用户访问、操作、查询用的端口，是应用展现层的内容，而后台则往往指通过代码或者可视化的后台集中管理界面来处理的一些为前台提供支撑和服务的、放在服务器数据库上的内容。那么中台应该是什么呢？本书的第一部分给了我们答案。
中台的由来——从企业IT建设普遍面临的困境说起
最早我们每做一个软件产品，都是单独立项，交付给一个技术团队来负责，里面有项目经理和程序员，甚至项目经理本身也就是程序员，收集了业务部门的需求，划分周期和范围、按部就班进行需求确认、开发、测试和上线的项目周期。这是瀑布式的软件开发方式，也造成了所谓的“烟囱式”系统建设模式：根据业务模式的不同而分别矗立着几套单独的系统来支持，相互之间也许会有某些重复的功能和业务，但相互之间各自独立，想要打通这些烟囱的连接，代价特别大。同时，在产品运营阶段，如果针对相似或重复的功能及业务需要做对应的产品升级，运维成本很高，不同产品的升级迭代周期缓慢，越来越不利于业务的沉淀和持续发展。很多时候，会出现系统改造疲于奔命，功能更新严重滞后，或者是为了临时满足一些需求不得不放弃长远规划通过一些变通方式应付当前的需求结果后面更不利于维护和优化，以及导致很多业务仍然需要借助大量的手工来整合、处理。
综上所述，传统的烟囱式的系统建设模式会导致——
a)重复功能建设和维护带来重复的成本投入
b)打通烟囱式系统间交互的集成和协作成本高昂
c)不利于业务的沉淀和持续发展
为了解决上述问题，很多企业通过ESB系统来实现多个独立系统之间的打通，并通过SOA集成项目让标准封装的一些服务对外提供的功能进入稳定的状态，也就是说，很多服务在初次上线后，在接下来几年里几乎没有新的功能的增加或提升。
这样处理的结果使得后续有新的业务系统接入这些服务时，很可能出现现有服务不能很好的满足已经变化的业务要求。面对这样的情况，最容易出现下面两种结果：
a) 服务提供者拒绝新的服务需求，倒逼新业务系统需求方重新规划并一套与这个服务差不多但又有某些区别的功能模块，也就是在封装服务的层面上又树立了一个新烟囱。
b) 服务提供这愿意根据新的需求改造现有的封装服务，但发现由于这个服务之前的设计存在通用性和业务前瞻性上的不足，如果要满足新需求则需要对现有服务的数据模型和业务逻辑做较大改造，由于接入服务的系统较多，考虑到改造的风险和成本，更多的团队会选择保持现有服务的稳定，而放弃对新需求的支持，从而回到了与a）情况同样的结果。
更糟糕的是，由于IT部门的人疲于应对一幢幢高高竖起的烟囱，对企业业务发展的理解不够深刻，使得IT信息化部门一直处于企业的『业务支持』的职能位置，即只为了满足业务部门需求而进行IT系统建设的实施和运维部门。这种模式下， 很多企业的IT信息化部门的员工大多数的工作内容都是项目管理。当一个项目顺利上线验收后，这些员工开始投入到下一个项目的工作中。因此，其结果是，员工增长了项目经验，但并不能在某一专业领域得到了知识和经验的沉淀，其最终结果是IT信息中心的员工很多少能在一个业务领域做足够深入的了解和业务沉淀。
解决之道——共享式业务中台
（未完待续）
技术指导——中台构建要诀
（未完待续）
借鉴及展望——结合案例思考中台的推广与应用
（未完待续）
