读了了几本阿里系出版的书，由衷的感慨“阿里出品，必属精品”。
本人按以下思路进行展开，里面的专业术语及技术细节，就不阐述，如有兴趣，推荐看原书。
中台概念，中台出现前的现状，解决了什么问题，带来了什么价值，怎么落地的，中间遇到了什么思考，系统怎么评价，人员怎么考核，推广？结合自己的经验的感悟抒发。
中台概念
当下企业信息化建设中台概念被频频提起，有企业的在观望、有的企业跃跃欲试、部分企业早已开始吃螃蟹。中台概念在国内可能是阿里巴巴最先实践后并被行业知晓和关注。最初阿里巴巴从芬兰的一家软件公司supercell的游戏公司交流碰撞出来的，这家公司的一款IPAND游戏本人也玩过《部落战争》，的确不错，有段时间持续痴迷的在玩，该公司现在已被腾讯收购。解开中台神秘的面纱，就从supercell公司开始说起吧，从起源开始，减少失真。这家公司的特点概括起来就是人少产出高，量化数据是人均3.5亿美元的产出，高得不是一丁点吓人。多少企业会羡慕嫉妒恨。他们怎么做到的呢，小组背靠背作战，快速试错，探索客户喜爱产品。投入后如客户喜爱，则深耕细作，如反馈不好，迅速果断放弃。这里有两点深思，技术上怎么能支持快速试错？开放一个产品周期得按月计算吧？管理上怎么允许激励这种试错行为？首先技术上采用的就是前台、中台架构，组织管理架构也配套一致的组织架构。一般2-3周可以推出一个游戏产品。前台2-3人一组，有想法付诸实施，中台提供火力支援，中台的火力支援体现在沉淀、积累开发素材、服务组件。前台关注实现创意展示，业务逻辑可以通过服务编排方式快速实现。以达到快速响应业务需求和创新。
现状
现在企业信息化的系统建设可谓是“烟囱林立”，一个业务领域会被拆分多个系统建设，如果前期缺少长远规划，系统直接的数据无法交互，企业的数据资产是一个个信息孤岛，不能形成合力，为企业提供高效的价值，实现收益。为了解决系统数据共享交互问题，引入了"中心化"服务概念，通过企业总线，SOA服务调用，打系统交互壁垒。但这种方式存在不少弊端，企业总线成为企业庞大复杂系统链的中心点，演变为新的瓶颈点。烟囱式系统现状并有没有解决，系统的边界缺乏清晰明确的定义，原本在A系统实现合理，但因各种原因，在B系统实现了。对客户来讲要到达目的地，是做飞机还是做高铁，可能并不是太关注。基于这些存在的现实现状，企业实现SOA战略，最终会回到源点，在这种混沌状态，已服务化的得不到业务的滋养，缺少完善和创新，久而久之被人选择遗忘。
中台解决的问题
中台到底解决了什么问题？中台战略是"去中心化"的SOA,相比“中心化”SOA,避免成为瓶颈可能。中台战略要求把企业所有系统通用、公共的业务抽出形成共享的服务，由一个服务团队负责维护，前端团队业务需要时候进行服务调用，业务发展或使用过程产生新的需求，如果有通用和共用性，由服务进行完善，这样推动服务不断的完善和优化，服务能力持续提升，达到快速响应业务需求和创新需求。以往一个开发人员需要涉及系统多个功能模块的开发，还要考虑对其他功能模块及系统的影响，因为业务拆分服务化，分工更专业，团队成员包括架构师、开发、测验等只需关注服务领域的服务能力实现，关注点少了，各系统的重复工作减少了，节约企业成本，提升了企业生产效率。
中台落地可能面临困难和阻碍
人员技能
中台的落地需要业务的驱动，所以技术人员对需要深刻理解业务，对业务的发展有自己的见解，这种既懂技术由懂业务复合型人才在任何公司都是稀缺的，所以为了培养这种人才，需要采取轮岗的方式。
服务维护
服务化后，服务数量多，调用链路关系复杂，日常运营中怎么实时监控服务能力状态？出现问题后怎么快速定位问题服务？哪些服务性能需要优化？避免成为瓶颈。因此需要配套数字化运营监控产品，这个产品建设和维护对很多公司来讲也是一个高成本，第三方公司产品解决这些问题不会深入和透彻，浅尝辄止的效果。
绩效考核
对服务开发团队及个人怎样激励既能保持服务的稳定，同时要对服务创新。这个需要良好的绩效平衡设计，因为有什么样的绩效考核，就会产生与之相应的行为。稳定可以通过服务出问题的等级和频率来评估，创新可以通过新业务的数量来支持，为了支持创新可以对稳定的指标做一些赦免。等等。
高层支持
即要保持现有系统稳定运行，又要引入服务化改革，在系统层面风险很大，重则影响企业业务正常业务运行，影响企业品牌、企业收入等。高层需要有推行服务化改革的决心，管控风险。另一个方面会涉及企业内部相当多干系人的利益，怎么让他们接收？因此是一个自上而下的改革，高层必须的背书。
感概
业务发展，推动技术发展，企业的发展需要管理保驾护航。一个企业只追求技术，没有业务做支柱，就是空中阁楼。以业务为根基，技术匹配，管理手段支撑。才是一匹飞奔的野马。
