此文是关于《企业IT架构转型之道》的第二篇文章，虽然有很多地方由于实际经验的缺乏而难以理解，我也来谈谈对“中台”的看法。
我把企业IT架构分成三个阶段，第二阶段以平台命名，实际上中台也是平台，不过这样称呼。
烟囱式到平台
前文书说过烟囱式的架构，企业一项一项工程如烟囱林立互不相干。
烟囱多了，难免就有大量的业务逻辑是重复的，在业务线越来越多的情况下，企业一般会开始考虑平台化的架构。比如下图所示：
在改造过程中，比如两台烟囱A和B都有会员系统，即把两个会员系统修改成为一个会员系统。
这样做，问题就出来了：
举个例子，A系统有抽奖活动，特价活动这两种营销活动；B系统有抽奖活动，签到活动这两种营销活动。现在要做一个统一的会员营销平台，就是让管理者可以统一配置这两个系统的三种活动。但虽说都是抽奖活动，实则由于渠道、规则、限制、奖品等的不同，两种活动其实只是活动名称相同而已，具体的实现完全不同。最终造成的结果就是虽然是平台化了，但是实际上内部的实现还是根据具体的适用系统而走了不同的逻辑。虽然前端看起来是一个统一平台，但实际后端很大程度只是把原来两个系统的代码合并在了一起而已。对于原来两个系统独有的活动，也还是独立的去实现，并没有节省什么开发工作量，反而因为需要针对那些两个系统都存的在同类活动的合并而绞尽脑汁去抽象数据结构和逻辑流程，且一旦合并后，如果其中一个系统的活动逻辑需要调整，还可能影响到另一个系统的同类活动。
从平台到中台
我思考了一天中台到底是什么，中台本质是什么？从平台到中台改变的是什么？
最终，我觉得我发现了答案：
平台到中台的改变就是从业务抽象到服务的改变，中台的本质就是从抽象的服务中实现业务，从而满足快速多变的前台。
如何理解呢？
我们发现，从烟囱到平台，改变的只是：业务。我们只是把每个烟囱的业务抽离出来，组合成为了平台。
从平台到中台要做的就是，把业务提炼出服务来，业务是基于服务的概念。服务可以理解为类，业务是类具体的细致化的实现。
为什么花费大量精力实现中台呢？
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
对于中台，还是将A、B系统的通用会员营销逻辑沉淀下去，如会员资产：积分、等级、优惠券、订单等。但对于特有的营销活动，还是保留在业务前台系统中分别实现。这样既保留了系统独立的业务自由度，也能将集团范围内的公共数据资产和服务通过中台思想进行沉淀。且当未来出现某个组织来统筹“平台”时，也可以在中台的基础上很快的构建。
中台与微服务
微服务体现去中心化、天然分布式,与阿里的中台战略思想类似,是战略的具体实现方式的一种。
在不了解中台的时候，我在想，中台不就是把服务集成在一起吗？和企业服务总线差不太多吧？
这样的思考方向，实在弱智，导致网上无一人解答这样的问题。经过思考，我总结了以下的差异：ESB是业务层级而不是服务层级， ESB的服务总线提供的是服务的包装而不是服务本身。并且ESB往往是中心化的，这其实与去中心化的中台理念不一致。
至此，从平台到中台差不多讲完了。
不过仍然有大量的疑问等我去探索，比如如此多的服务中心化到中台上，如何快速的调用，如何检查问题，这又是另一个故事了。
