本篇文章是《从数据仓库到大数据平台再到数据中台》（《关于数据中台建设之思考》）的姊妹篇，之前讲的更多的是关于从数据仓库到大数据平台再到数据中台的演进过程，一直想写一篇关于中台的文章，一来应人之约，但迟迟未动笔，实乃力有不逮；二来是圆自己的一个的总结。
关于中台的概念，以下是来自于百度百科的说法。
中台这个概念早期是由美军的作战体系演化而来的，技术上所说的“中台”主要是指学习这种高效、灵活和强大的指挥作战体系。电商经过十几年的发展，组织已经庞大而复杂，业务不断细化拆分，也导致野蛮发展的系统越来越不可维护，开发和改造效率极低，也有很多新业务不得不重复造轮子，所以中台的目标是为了解决效率问题，同时降低创新成本。
所谓的中台就是：通过制定标准和机制，把不确定的业务规则和流程通过工业化和市场化的手段确定下来，以减少人与人之间的沟通成本，同时还能最大程度地提升协作效率。
中台的本质还是在于重构，重构的目的是为了复用，复用的目的是为了解决效率，而要重构必然涉及到权力的再平衡和组织的调整，解决了组织的问题后，才是解放思想，解决思想必然要颠覆或重组现有的业务流程，且在原有的技术上进行微调整或引入新技术来解决当前所存在的问题。
话好说，但事儿很难做，中台方兴未艾，但关于中台已死或唱衰中台的文章已经层出不穷了，笔者只列举了一下自己收藏的几篇文章，权且一看。
《建设中台：难点是技术问题？不！其实是认知问题》其实讲的更多的是数据中台，文章讲的更多的是数据中台建设的方法论，包括数据治理体系和数据建模等等。
《没有中台的名，却得了中台的病》提出中台其实并不是个具体产品，更不是标准化的产品，它是一套“机制”，通过有形的产品和实施方法论来支撑，讲的更多的也是数据中台，认为数据中台，就是那个“中台中的中台”，只有把企业的数据打通了，让数据变成资产并服务于业务，其它的所谓“中台”才能依存，企业的数字转型才有底气。
《钟华讲 中台背了谁的锅》则提出了四个决定了中台落地成败的因素，第一、企业高层对中台的认知和理解。第二、是业务的顶层设计要想清楚。第三、人才的问题。第四、中台是解决整个业务链的贯穿，需要构建科学的协同机制。
《中台搞了2年，项目叫停，CIO被裁！本以为中台是道送分题，没想到是送命题！》提到了浙江某制造企业中台建设失败的三点原因。1、CIO太急功近利，低估了中台项目的风险。2、项目的短中长期目标，没有在集团层面达成共识。3、没有跟外部资源形成合力。并且强调了组织中台，就是要解决人员组织问题，因为牵涉到利益、权利，所以是最难的部分，需要项目负责人具备很强的组织能力。并且指出“什么是玄学？中台就是”。
《中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费》，分享了某企业十几个月，大几百号人，业务中台项目被裁撤的惨痛经历，认为失败有几方面原因：数据团队需要在几个业务团队中寻找一个平衡点；人的因素——想法太多，都想驱动这个中台；人员能力问题：流程的问题，太多太长；最后是资源的问题。
“夫以铜为镜，可以正衣冠；以史为镜，可以知兴替；以人为镜，可以明得失。”，以史为鉴，可以帮助我们了解各种企业在建设中台过程中的探索和经验教训，通过上述几篇文章的分享，大体上我们可以知道，中台的建设不是一蹴而就的，需要高层领导的强力支持，短中长期规划，要在当下的问题和将来的规划之间做出平衡和妥协，在不同干系人的期望之间寻找平衡点；其次中台的建设需要大量人力财力物力的投入，需要负责人有很强的组织能力和协调能力；再次中台引入的技术太多，必然涉及太多的研发资源，这点企业能否承受；最关键的应该是组织中台的建设，一般信息系统建设都避免和现有的组织机构相冲突，而中台的建设恰恰是要触动领导的、部门之间的、研发人员的利益，这其实才是中台建设成败的核心问题所在。
中台到底是什么？
简而言之中台通过打造集中化的业务中台、数据中台、AI中台、技术中台等平台能力，推动业务组件、技术组件的标准统一；并实现业务的快速交付与生产、管理的融合。
再回顾一下数据中台的定义，数据中台就是数据服务化，服务化的核心是数据模型化和服务组件化，服务化的基础是大数据平台和数据仓库。数据中台的目的当然是满足快速交付，快速交付的前提是数据的高度复用和组织。数据中台的目标其实为了更好的支撑业务应用的建设和决策分析支持，业务应用主要是为了支撑业务的实现，但是需要跨域快速获取数据怎么办，通过技术中台实现跨域数据访问啊，但要访问跨域融合数据或用户画像怎么办，只能访问数据中台数据了，当然访问也是通过技术中台的；其次因为数据中台本身具备了长周期的数据，构建了数据模型，足以支撑对内的决策分析需要；在确保网络安全和数据安全的前提下，还可以通过融合外部数据，满足对外应用需求。
业务中台是什么?通俗来说，业务中台把各个项目中共通的业务进行下沉，进而形成一个个通用的服务平台。业务中台旨在打破系统之间的数据壁垒，让业务联动成为可能，重要的是解决数据的服务能力；通过微服务架构，持续解耦优化，进行基础业务能力的汇聚，构建各业务领域能力。业务中台，需要梳理出整个业务系统所支撑的业务场景，并且根据场景梳理和业务中心的能力要求；然后业务中心根据业务场景梳理的能力要求做匹配，匹配不了的进行能力开发，以满足业务运营中心场景能力的需求。业务中台其实是个重构的工作，重构则需要进行提炼和抽象，提炼和抽象的目的是为复用；必然涉及对原有烟囱似系统和接口的重新改造，将原有的接口进行凝练，将原有不畅的环节打通，原有不顺的流程梳理成标准化流程，并形成标准化服务；业务中台也存在多个维度，最好以业务场景为核心，将流程、环节、能力编排成为一个场景。为了更好的服务于业务支撑，业务中台也需要数据中台的融合数据，引入实时推荐能力，数据中台全生命周期的数据也可以增强业务中台的拓展和服务效率。
关于AI中台，则是降低机器学习和深度学习技术的使用门槛，让所有人都能轻松实践机器学习和深度学习；降低人工智能应用的开发维护成本，构建企业在人工智能方面的基础研发能力；沉淀企业最佳实践，传承业内优秀的智能化转型经验；AI中台一般构建在大数据平台和数据中台之上，且向业务中台输出AI能力，在看似杂乱无章的用户及行为数据与不断发展的业务之间挖掘其复杂和深刻的逻辑关系，AI中台主要包括平台能力和服务能力，平台能力要求其具备全面的算法库，实现上下游数据的打通，提供良好的可视化界面，进行算法模型的选择和评估，并提供数据标注能力；服务能力则要求提供场景化的AI服务组件，实现内置的即插即用的AI服务能力。
关于技术中台，则包括技术中台门户、微服务注册开放组件、微服务开发&交付能力、技术中台运维能力、能力集成技术组件能力和基础的技术服务以及弹性伸缩和计算能力，以及虚拟化管理能力。技术中台有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。技术中台有点像工具大仓库，里面放满了各式各样的技术工具，无论是哪个团队，哪个人，快速找到自己的工具，拿来就用就行了。技术中台是连接业务中台和数据中台、AI中台的纽带，是服务于上层应用的桥梁。
所以，理想的中台是什么样呢？下面的架构图为笔者整合了各家方案后得到的架构图。因个人能力所限，不一定正确，权且仅供参考。
关于中台的高层架构，中台需要依托于组织中台的强有力支撑，并且服务于前台，业务中台、数据中台、AI中台需要通过技术中台释放其效能，数据中台构筑在大数据平台之上，提供数据服务能力。
关于中台的架构设计，前文已做了相关总结，在此不再赘述。
关于中台的实施是一个复杂的系统工程，如前文所述，中台通过打造集中化的业务中台、数据中台、AI中台、技术中台等平台能力，推动业务组件、技术组件的标准统一；并实现业务的快速交付与生产、管理的融合。中台不是一个单一的系统，也不是一件完整的产品，更像是个系统工程，需要不断迭代，持续运营。
关于中台实施，首先需要获得公司高层领导的强力支持，尤其是业务中台需要重构，必然牵动了各个部门的奶酪，因此需要从组织中台着手，在公司层面形成统一认知，才能减少后续实施工作的阻力，必要时可由公司领导进行决策和调整。
其次中台是一项长期艰巨的任务，需要组织和动员大量的技术人员参与到中台的建设过程中，还需要组织大量的业务人员进行业务中台的重构工作，重构不是技术人员拍脑袋的决策，而是需要业务流程的重新规划，很多是来自一线业务人员的使用操作和宝贵经验。
再次中台是个渐进的过程，需要做短中长期的规划，短期不妨从数据中台入手，数据中台一般是企业的共识，在一定时间的成效也是可以预见的，以数据中台支撑业务系统的实施，来推动企业实施中台的信心；再从技术中台入手，基于技术中台来实现业务系统对数据中台的述求；最后是业务中台，业务中台可以先从新上线的系统着手，有了一定的突破，再选择部分天怒人怨的存量系统作为重构对象，最后再到核心业务系统；然而核心业务系统的变更又会影响到原有的大数据平台和数据中台建模，但是没办法，活是一定要干，只是长期痛还是短期阵痛而已。
最后中台尽管不是一个系统和产品，但也涉及大量的技术引进，技术没有好坏，只有适用不适用，因此技术引进不一定求全求新，而是选择合适的或者比较成熟的。
至于说中台能给企业带来什么经济价值，这点很难从数据来支撑和证明，从之前的大数据平台实施经历大致可以看得出来，短期内企业的投入必然是会增加的，长期而言，数据中台提升了企业数据复用能力，业务中台进行了业务流程优化，AI中台让企业凝聚了智慧，技术中台则提供了快速交付能力。
言尽于此，笔者对中台的认知也就结束了，每个人的知识结构都是有限的，对我而言，首先是数据中台算是我比较擅长的，AI中台呢，自己也算一直长期在研究，至于业务中台和技术中台就不班门弄斧了，后续再写的话，可能会谈谈数据中台的数据建模吧。