《中台战略》- Chapter 3 - 3.4 中台的发展与进化

推荐购买《中台战略-中台建设与数字商业》正版纸质书籍阅读

  大中台立足于横向的、全局的长远考虑，而小前台则注重于解决纵向的业务应用的当前问题。

3.4.1 中台的演变

  中台的催生基石是能力共享。

  一个应用系统首先是为用户服务的，因此最先离不开的是系统的角色和用户。因此，建设中台的一个起步点就是先将角色和用户这些资源管理起来，形成用户共享中心。统一用户、统一权限、统一登录，可以看作是中台的雏形。
  在用户共享中心的基础上，再发展与人相关的会员系统，比如会员的积分、积分的变动、会员的等级等就形成了会员中心。
  用户是通过商品、订单与系统进行交互的，因此，商品的管理、订单的集中处理也是可以一起共享的。
  将用户共享中心、会员中心、商品的管理、订单的集中处理等统一集中管理后，相关的用户、会员、积分、订单等数据被存储在一起，方便全局管控。如此，进行集中管理的资源越多，建设中台所取得的成果就会越大，就越能体现中台对前台应用的支撑作用。

中台建设的三个步骤

  在资源集中管理的基础上，更重要的是抽象出系统能力。抽象是指在考虑目标事物时，去除表象的、次要的方面，而抽取相同的、主要的方面，从而做到从个别中把握一般规律。通俗一些的说法就是将目标事物模型化。只有通过抽象，设计出来的能力才能应用到类似的需求中。

  中台是为前台业务服务的，因此当前台业务有所更改时，中台要随需而变。这就要求中台具有很好的灵活性来支撑业务的开拓和发展：
  1）数据模型需要根据前台业务要求实现可扩展性。
  2）业务流程可根据场景和需求重新定义和编排，并可通过插件机制进行定制。
  3）中台环境需要支持多环境可部署。比如不同的基础设施环境，包括公有云、私有云及容器云等；再比如不同的微服务框架，如阿里云的EDAS、开源的SpringCloud、Dubbo等。

3.4.2 中台生态的形成

  1）技术中台：整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口。

技术中台

  业务中台的每个业务服务中心都需要关系型数据库。关系型数据库要提供一主一备和自动切换功能，以及读写分离和只读库创建的能力。为了快速访问大数据量的表，一般需要使用分布式数据库对其进行分库分表操作。分布式缓存是提高访问效率的一个必不可少的组件。通过消息队列实现异步解耦和大流量削峰填谷，这大大增强了前台应用应对大用户并发的能力。使用CDN加速的对象存储，可极大提高前端访问的性能。数字中台是在技术中台的基础上开发、运行的，但又不能与技术中台绑定。因为数字中台关心的是如何满足业务要求，而技术中台提供基础设施底层的能力，两者相互促进但又相互隔离。

  2）研发中台：是关注应用开发效率的管理平台，软件开发和系统建设是一项工程，涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。

研发中台

  研发中台为应用开发提供了流程和持续交付的能力，包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般由问题、迭代、实施等组成，并管理研发人员的日常工作和任务。开发流水线则涉及源代码的版本管理、分支的创建、合并和提交，半成品的构建、存储和使用以及产成品的构建。将产成品部署到指定环境并上线运行是部署流水线的职责。线上的应用需要监控，包括基础设施监控、应用监控、日志洞察、浏览器监控、链路分析和追踪等功能。研发中台为应用的开发提供了流程、质量管控和持续交付的能力

  3）移动中台：消费者接触得最多的企业前台触点在移动端，为快速开发移动APP、H5、小程序、快应用等以支撑前台业务发展所进行的最佳实践就逐渐沉淀为移动中台。

移动中台

  1）移动App与其他前端技术比较，有其特殊性。比如移动App作为一个C/S架构，其发版模式需要通用应用市场的审核，而其客户端的更新是使用者控制的，提供远程配置、动态更新有助于控制App端。
  2）移动业务是在线业务，对网络存在强依赖，而移动链路本身的稳定性和连通率等相比有线网络有一定的不足，因此消息推送的实现需要考虑网络因素。
  3）因移动端质量相关问题，需要提供热修复等功能。
  4）对移动App本身的安全扫描和加固也是一个需要着重考虑的因素。由于前端有不同的实现技术，如果完全使用不同的开发方式，对于企业来说是重复投入，且资源和技术不能共享。因此，使用Hybrid混合开发的方式，既可以支持移动App，又可以支持H5，甚至小程序，这也是移动中台需要研究的一部分。因此，尽可能将前端组件化，比如UI组件和图表组件，在此之上组装成业务组件，能大大提高移动端开发效率和质量。

  4）AI中台：AI中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题，通过AI能力平台化，降低对人员能力的要求。与数据中台利用CPU级别的资源不同，AI中台需要扩展对GPU资源管理和整合能力，为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务，并最终为业务人员提供智能化的服务。

3.4.3 中台与前台的博弈

中台对业务的参与度

  中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同，会产生不同的中台建设路径。
  一个极端理解是中台是工具，即将中台作为工具平台来建设，导致中台不能沉淀业务。
  另一极端是中台完全为业务服务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。

中台与前台应用的关系

  从历史发展来看，一开始企业建设了一个前台应用A。随着业务的发展，扩展到类似的业务，由于业务快速发展的需要，很有可能重新开发另一个前台应用B。但随着应用B的建设，发现应用A和应用B的很多功能和能力是重复或相似的，因此考虑是不是可以通过建设公共的部分，避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。但是中台建设是一个新的命题，需要更强有力的团队，需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化，那么中台就只能满足部分前台业务的需求。再者，如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。

  中台既需要满足业务的需求，但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性，便于业务方根据规范自主完成，减少沟通成本，提升效率。
  “大中台，小前台”，并不意味着前台不重要。相反，建设大中台就是为了更好地服务于小前台。大中台要想发挥作用，体现出自己的价值，必须通过小前台的引导。

3.4.4 中台的进化策略

中台的广度和深度两种进化策略

  广度是指中台所涉及的内容会越来越多，即可以认为各种中台的不断出现，也可以认为是一个中台内部的共享服务中心会不断横向扩展，从一开始所提的业务中台、数据中台，逐步演化到AI中台、技术中台、研发中台等。另一方面，一个中台范围内的共享能力也在扩展，从用户中心、交易中心、营销中心等扩展到内容中心、工单中心、成长中心等。

  中台所沉淀的共享服务能力并不要求支撑所有前台业务，只要有多于一个前台业务需要某一种能力，此能力即可沉淀为中台能力，因此我们不能大而全地建设中台。中台的建设是可以分阶段逐步实施的，无须将所有重构全部一起推动，而后者既会增加复杂性，又会提高风险，还不能及时得到反馈。

  1）中台的成长离不开前台业务的创新。
  2）中台还需要建设成为开放的体系。
  3）中台的开放也意味着中台需要支持个性化需求。
  4）中台作为平台，必然需要考虑拆分整体应用形成业务组件，通过业务抽象建模，解决共性的问题，从而更好地为业务服务。
  5）中台作为一个平台，其本身的运营也需要数据支撑。
  6）中台建设是一个综合性的系统工程，因此需要有效的方法论的指导。