这段时间有幸读了《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》这本书，受益匪浅，本书是从阿里巴巴启动中台战略说起，详细阐述了共享服务体系如何给企业的业务发展提供支持，介绍了阿里巴巴在建设共享服务体系时如何进行技术框架选择，构建了哪些重要的技术平台等。
记得刚刚拿到这本书时，自我感觉此书食之无味，但当我将第一章内容读完时，激起了我读下去的欲望，本书主要内容分为三大部分，第一部分介绍的是阿里巴巴集团中台战略引起的思考，以及构建服务中台的基础即共享服务体系。
首先，大家应该都知道前台跟后台，所谓的中台，并不是阿里巴巴首先提出的词语，从字面理解来看中台是居于前台和后台之间，其实在阿里巴巴集团启动中台战略之前，就有另一个被外界所熟知的“厚平台，薄应用”架构，阿里巴巴是在2015年启动的中台战略，我佩服的是阿里巴巴的战略眼光，阿里早在2009年就开始建设共享事物事业部，几年的经验沉淀积累为启动中台战略的转型打下了坚实的业务基础，说了这么多，那么什么是中台呢，中台系统作为支撑和链接的作用，链接了前台与后台，支撑后台技术提升，为生产、商品营销指明方向有着重要作用。
我们知道。2008年淘宝技术团队同时支持着淘宝和天猫两大电商平台，1999年成立的B2B电商平台1688也一直拥有自己的技术支持团队，总体来讲也就是三套电商体系架构完全独立各自应用独立开发和运维，在电商平台上有购物经历的人都知道，一个标准的电商平台至少提供了会员服务、商品的信息、交易支付，不管是B2B、C2C、或者B2C的电商平台都需要提供，为什么阿里的三大电商平台会独立建设和维护，而这就是所谓的“烟囱式”系统建设模式，不仅仅是阿里，或许很多企业IT系统的建设模式都是如此，当一线业务部门提出需求，到需求分析开发测试上线的过程中，每次的需求变更修改都预示着一座新的烟囱矗立而成，作为后台开发人员，我对此深有体会，当我们收到一个新的服务需求变更时，我们内心是拒绝的，但是客户的需求是第一位，最终我们还是要改的，因为受限于之前服务设计的通用性和业务前瞻性不足，要满足新的业务需求就要在原有的数据模型和业务逻辑上作较大的改动，这是后台开发最不想做的，实际情况中可能更多的人会在改动带来的风险和满足新业务需求的选择中，选择放弃对新业务需求的支持，保持现有服务提供的稳定，重新开发一套跟这个服务差不多的功能模块，最终的结果就导致又一个新的烟囱形成。最终这样建立起来的系统就能发现大量的功能和业务在多个系统中同时存在，在日新月异的互联网时代，如何更好的整合内部资源、更好的提升用户体验，实现各个系统间的交互成为必然发生的事情。
想到我们PMS-T系统，我们也一直在避免这种烟囱式的建设模式，避免代码的重复，但是我想系统中还是会存在一些这种烟囱式的结构吧，毕竟系统的每个模块的开发都十分仓促，从开始到现在，有多少人接手了这个系统的开发和设计，每个人的代码风格以及设计思路开发都不会相同，因为最初对系统的不熟悉，只能按照设计来实现功能，功能实现起来或许简单，但是如果考虑到全局这个功能是否还是会这样设计呢？是否能跟现有的东西进行融合呢？鉴于这个系统一直在不停地修改，前人不断的挖坑，现职的人只能埋坑，其实也不能怪前人的代码有问题，因为当时的需求可能就是如此，也不用考虑太多东西，也可能只是在当时的系统全局的需求下就是如此，后来随着工程不断地增加、业务的复杂程度也不断的增强，然后就暴露出之前存在的很多问题，以及表设计和业务逻辑都要有较大的改动，正如书中所言，一个系统上线运行5~8年后，企业的信息中心会像企业更高领导人提出随着业务的快速发展，现有的系统不管是技术架构还是业务模型都不能满足现在业务发展的需求，需要整体系统的升级，而这样的升级往往意味着对原有的系统推倒重建。
如图1-1所示。到了一个时间点，量变产生质变，就会出现企业核心业务系统运行多年后被推倒重来的现象。