注：看到这篇关于中台的文章，和我的思路比较接近，但是比我写的要好，分享之。（新浪微博：人月神华）
首先我再整理下我原来提到过的一些关于企业中台的观点：
1. 企业中台是企业共性业务能力的下沉，体现的是业务能力可复用和灵活组合
2. 企业中台区别传统的IaaS和PaaS平台，更多是一个业务平台，包括了业务中台和数据中台
3. 中台构建本身参考了微服务架构思想，并基于业务高内聚进行了微服务化并提供能力
对于一个专业细分的业务领域而言，软件企业要做的就是将对业务领域的多年经验和理解沉淀到业务中台，形成可复用的各个业务中台能力中心，然后为上层灵活多变的各类应用提供服务能力。由于沉淀了业务理解形成通用化，可复用的业务模型，那么这个能力被不会轻易被模仿。
而今天当我重新再谈企业中台的时候，可以理解为：
业务平台+能力开放平台 构成了企业中台，即业务平台各微服务模块化后的业务中心首先提供可复用的业务能力API接口，然后这些接口能力再通过能力开放平台开放出去并统一管理。
今天我再谈这个概念，主要是想从如果一个企业邀请我们去将中台建设，那么从售前方案PPT的角度我们应该如何来准备材料来说明企业中台的建设思路和解决方案？
其一，中台思路的产生
首先还是要先讲清楚为什么会产生中台的概念，中台的提出和中台的产生背景。这些还是得介绍清楚。同时在介绍这些的时候还是要谈到SOA，可以看到前台和后台分离，中台提供能力，前台可以基于中台能力快速的构建应用本质还是SOA的核心思想，即原来讲过的可重复服务识别，服务能力的组装和组合。
那么中台思路和原来的SOA的思路差别点在哪里？
从我原来对SOA架构思想的描述，到中台的核心构建可以看到，SOA更多的是遗留系统本身的可复用接口服务识别，形成共享服务能力层，对遗留系统本身是一个简单的适配过程；而对于中台思想下可以看到完全是一次重新构建过程，这种重新构建的体现在。
传统模式更多的是垂直化的业务系统构建模式，而中台思路下不再有明确的单垂直化业务系统的概念，而本身就是为了打破原来垂直化竖井的边界，因此采用的是一种分层构建的新IT应用构建模式。
其二，从SOA到微服务，中台演进的必然之路
前面已经讲到了中台本身就是一个能力提供中心，而这个能力中心本身不再是简单的遗留系统暴露接口的适配和发布，而是微服务能力+能力开放API接口，这个是和传统SOA架构和业务系统集成下一个很大的区别点。正是这个原因我们讲从SOA到微服务，是中台演进的必然之路。
那么又得讲清楚什么是微服务？SOA和微服务架构的区别点在哪里？在采用了微服务架构后真正带来了哪些复杂度，同时在采用微服务架构后又面对哪些挑战。
从SOA到微服务，本周管理的粒度更加细，管理复杂度实际是增加了，为了更好的进行模块开发和持续集成，配套开始介绍下DevOps和容器化技术。
其三，构建核心中台层能力(中台微服务模块+API接口服务）
要将企业中台的构建本身又需要分为好几个方面来讲。其中包括了业务中台的构建和数据中台的构建。而对于业务中台的构建本身又包括了由已有的遗留系统和IT资源来构建中台，还是全新构建中台。
构建中台核心要做哪些事情？可以看到重点就是要搞清楚重点就是识别中台应该包括哪些微服务模块，同时每个微服务模块究竟应提供哪些API能力接口？其次才是单独的一个中台模块如何进行开发建设，API接口如何进行开发并能力开放。
即中台的构建部分一定包括两个方面的内容，业务咨询和规划，技术实现两个层面。业务咨询规划解决的是中台模块如何划分，接口服务如何识别？而技术实现解决的是采用微服务开发框架如何开发，API接口如何开发和接入等技术层面的问题。
其四，构建能力开放平台(API接入+能力运营+管控运维）
这块感觉可以单独拿出来讲，即传统业务系统集成我们更多讲的是ESB服务总线，共享服务平台。而在企业中台构建思想下，我们讲的是API服务网关和能力开放平台，即是一种轻量的SOA服务总线。
结论：业务平台+能力开放平台 构成了企业中台
中台构建完成后必须要将能力以API接口服务的方式暴露出去给前台用，因此有必要单独介绍下能力开放平台，刚开始可以是简单的API网关，但是要实现更好的接口服务运营和管理运维，则需要进一步将API网关引擎升级为完整的能力开放平台。
