| 编辑推荐: |
本文全面讲解企业如何建设各类中台，并利用中台以数字营销为突破口，最终实现数字化转型和商业创新,希望对您的学习有所帮助。
来自于infoq,由火龙果软件Alice编辑、推荐。 |
|
中台的存在价值是为它的客户服务，比如业务中台和数据中台要快速响应前台应用的需求。但如果中台同时服务于多个前台应用，在资源有限的情况下，必然涉及对来自不同应用的需求的优先级排序和取舍。如果前台应用急需某一能力，但中台又不能及时提供，是否允许前台先实现，等中台有时间再来沉淀？由此可以看出，大中台立足于横向的、全局的长远考虑，而小前台则注重于解决纵向的业务应用的当前问题。大中台的发展必然涉及权衡，但如何做取舍没有标准答案，需要结合实际情况进行。
中台的演变
中台的催生基石是能力共享。如果中台所提供的能力无法被共享，那就不是中台能力。如果中台只服务于一个前端应用，那就不是中台。那么哪些能力比较通用且是多个前台系统的共性需求？要回答这个问题，可从系统的组成开始分析，如图
3-9 所示。一个应用系统首先是为用户服务的，因此最先离不开的是系统的角色和用户。因此，建设中台的一个起步点就是先将角色和用户这些资源管理起来，形成用户共享中心。统一用户、统一权限、统一登录，可以看作是中台的雏形，但如果仅仅停留在此阶段，就退化成了单点登录。在此基础上，再发展与人相关的会员系统，比如会员的积分、积分的变动、会员的等级等就形成了会员中心。再者，用户是通过商品、订单与系统进行交互的，因此，商品的管理、订单的集中处理也是可以一起共享的。这些资源的统一集中管理后，相关的用户、会员、积分、订单等数据被存储在一起，方便全局管控。进行集中管理的资源越多，建设中台所取得的成果就会越大，就越能体现中台对前台应用的支撑作用。
图 3-9 中台建设的三个步骤
在资源集中管理的基础上，更重要的是抽象出系统能力。抽象是指在考虑目标事物时，去除表象的、次要的方面，而抽取相同的、主要的方面，从而做到从个别中把握一般规律。通俗一些的说法就是将目标事物模型化。只有通过抽象，设计出来的能力才能应用到类似的需求中。
中台是为前台业务服务的，因此当前台业务有所更改时，中台要随需而变。这就要求中台具有很好的灵活性来支撑业务的开拓和发展：
1）数据模型需要根据前台业务要求实现可扩展性。
2）业务流程可根据场景和需求重新定义和编排，并可通过插件机制进行定制。
3）中台环境需要支持多环境可部署。比如不同的基础设施环境，包括公有云、私有云及容器云等；再比如不同的微服务框架，如阿里云的
EDAS、开源的 SpringCloud、Dubbo 等。
中台的建设不是从零起步，但是中台是为业务服务的，是需要根据企业业务演进逐渐积累而成的。因此中台的建设不是一蹴而就的。
中台生态的形成
中台是企业级共享能力平台，因此除了最开始提出的业务中台和数据中台，还会逐步发展出技术中台、研发中台、移动中台、AI
中台、算法中台、组织中台等其他中台。
技术中台整合和包装了云基础设施，以及在其上建设的各种技术中间件，比如微服务、分布式缓存、消息队列、搜索引擎、分布式数据库等，并在此基础上建设和封装了简单易用的能力接口，如图
3-10 所示。技术中台的建设标准是参考在一个只提供虚拟机或容器的私有云上，建设一个业务中台或数据中台所需但私有云没有提供的技术相关组件。技术中台作为工具和组件，为建设前台应用和业务中台提供了基础设施重用的能力，大大缩短了它们的建设周期。如果数字中台（即业务中台
+ 数据中台）是强大的中台炮火群，则技术中台提供的是如何根据需要快速搭建中台炮火阵地（即创建和部署不同环境下的中台）。
如何让阵地建设得更加可靠、简捷易用（通过技术中台提供资源的动态扩展能力等）？隔离数字中台对基础设施的依赖。比如业务中台的每个业务服务中心都需要关系型数据库。关系型数据库要提供一主一备和自动切换功能，以及读写分离和只读库创建的能力。为了快速访问大数据量的表，一般需要使用分布式数据库对其进行分库分表操作。分布式缓存是提高访问效率的一个必不可少的组件。通过消息队列实现异步解耦和大流量削峰填谷，这大大增强了前台应用应对大用户并发的能力。使用
CDN 加速的对象存储，可极大提高前端访问的性能。数字中台是在技术中台的基础上开发、运行的，但又不能与技术中台绑定。因为数字中台关心的是如何满足业务要求，而技术中台提供基础设施底层的能力，两者相互促进但又相互隔离。
图 3-10 技术中台
研发中台是关注应用开发效率的管理平台，如图 3-11 所示。软件开发和系统建设是一项工程，涉及项目管理、团队协作、流程、测试、部署、运营、监控等方面。如何将在企业应用开发过程中的最佳实践沉淀为可重用的能力，从而更好地快速迭代开发创新型的应用，也是很多企业目前的一个关注点。这个关注点也是企业能力的体现，即研发中台。研发中台为应用开发提供了流程和持续交付的能力，包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般由问题、迭代、实施等组成，并管理研发人员的日常工作和任务。开发流水线则涉及源代码的版本管理、分支的创建、合并和提交，半成品的构建、存储和使用以及产成品的构建。将产成品部署到指定环境并上线运行是部署流水线的职责。线上的应用需要监控，包括基础设施监控、应用监控、日志洞察、浏览器监控、链路分析和追踪等功能。研发中台为应用的开发提供了流程、质量管控和持续交付的能力。
图 3-11 研发中台
消费者接触得最多的企业前台触点在移动端。如何保障移动端的迭代效率和稳定性也是企业需要着重考虑的。一个电商业务一开始可能只是一个工具型的
App，完成对商品全生命周期的闭环支持。随着在业务中台基础上发展出相似业务，需要平台级的移动端开发支持。继续深化发展可能还需要支持多业态。因此为快速开发移动
App、H5 和小程序以支撑前台业务发展所进行的最佳实践就逐渐沉淀为移动中台，如图 3-12 所示。
移动 App 与其他前端技术比较，有其特殊性。比如移动 App 作为一个 C/S 架构，其发版模式需要通用应用市场的审核，而其客户端的更新是使用者控制的，提供远程配置、动态更新有助于控制
App 端。
移动业务是在线业务，对网络存在强依赖，而移动链路本身的稳定性和连通率等相比有线网络有一定的不足，因此消息推送的实现需要考虑网络因素。
因移动端质量相关问题，需要提供热修复等功能。
对移动 App 本身的安全扫描和加固也是一个需要着重考虑的因素。由于前端有不同的实现技术，如果完全使用不同的开发方式，对于企业来说是重复投入，且资源和技术不能共享。因此，使用
Hybrid 混合开发的方式，既可以支持移动 App，又可以支持 H5，甚至小程序，这也是移动中台需要研究的一部分。因此，尽可能将前端组件化，比如
UI 组件和图表组件，在此之上组装成业务组件，能大大提高移动端开发效率和质量。
图 3-12 移动中台
前面所提的业务中台、数据中台等都是从技术系统层面展开的中台演变。企业在进行中台建设时，容易着手的也是对技术体系的改进。但要发挥中台的能力，让中台战略实际落地到企业，并为企业的业务目标服务，需要有与中台技术架构相匹配的组织架构。从
Supercell 的“部落”，比如阿里巴巴的共享业务事业部、数据平台事业部，京东的前、中、后台，大家都可以看到建设中台需要两手抓，两条路线相匹配，齐头并进。如果将业务中台、数据中台等称为“战斗部队”，那么为企业提供的项目投资管理、风险管理、资源调度等的组织中台则是“战场指挥部”，指挥前线，调度后方。
“大中台，小前台”这种组织形式，并不是什么新鲜事物，实际上它是一种理想化的支撑模式。前台业务足够灵活，配套支撑足够快捷，资源还能够高效复用。不过要让中台模式在企业中发挥作用，对企业本身也是有一定要求的，比如企业有一定规模，业务比较丰富，值得去提炼共性元素形成共享能力。如果同时开展多种相类似的业务，那么从业务
A 提炼出来的能力可能提供给业务 B 使用；或者虽然业务单一，但同一业务在不同地域有不同的模式，也能沉淀出很多共享能力。
数据中台提供了数据分析报表来响应运营，并在此基础上提供数据能力直接服务于业务。那能不能更进一步，提供诸如个性化服务等与智能相关的能力？答案是肯定的，通过
AI 中台就可实现。AI 中台借助数据中台的能力，尝试解决模型的训练、发布，智能服务的构建自动化，统一的元数据管理体系，模型的全生命周期管理等问题，通过
AI 能力平台化，降低对人员能力的要求。与数据中台利用 CPU 级别的资源不同，AI 中台需要扩展对
GPU 资源管理和整合能力，为算法模型的开发者、训练者、标注管理者、数据管理者等构建智能服务的人员服务，并最终为业务人员提供智能化的服务。
中台与前台的博弈
中台通过提供基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力基线。根据中台对前台业务的支持与参与度不同（见图
3-13），会产生不同的中台建设路径。
图 3-13 中台对业务的参与度
一个极端理解是中台是工具，即将中台作为工具平台来建设。由于工具的通用能力强，抽象层度高，所以工具可适应各行各业的企业。如此，中台的研发人员可只专注技术相关的问题，而无须关注和了解企业本身的业务。但是正由于工具无法深入业务场景，也不内含业务能力，导致中台不能沉淀业务，从而使中台开发人员与业务方沟通不顺畅，中台方无法直接为业务赋能。为了解这个问题，需要一个长期的业务理解和系统建设过程。
另一极端是中台完全为业务服务。中台方能快速理解业务需求，参与业务方的数据模型讨论、流程设计等，并将其变成系统实现。中台研发人员参与业务建设，符合中台为业务服务的目的，而且中台的能力也是通过业务沉淀下来的。但是过分关注业务，过分与业务团队耦合，会受限于时间和团队的能力，不仅中台可能会没有考虑通用的业务能力，也会导致无法更专注于对中台技术的深入研究。中台如果不从抽象度、适配性等角度出发，投入建设机制性的工作，很有可能局限于某单一业务，导致中台无法很好地适应其他相关业务的要求，从而不能很好地应对业务的变化。
目前很多宣传中描述的数据中台走到了图 3-13 所示的最左侧：把数据建设的工具称为数据中台，或把数据治理、数据建模等工具宣称为数据中台（其实只是片面地在理解数据中台）。中台最主要的能力是提供业务方可重复使用的并与业务相关的能力。数据工具的能力太泛化，会导致与业务方的距离太远，从而不能很好地为业务方赋能。
从历史发展来看，一开始企业建设了一个前台应用 A（如图 3-14 所示）。随着业务的发展，扩展到类似的业务，由于业务快速发展的需要，很有可能重新开发另一个前台应用
B。但随着应用 B 的建设，发现应用 A 和应用 B 的很多功能和能力是重复或相似的，因此考虑是不是可以通过建设公共的部分，避免重复投入和建设。由不同前台应用抽取出来的公共部分即为中台。但是中台建设是一个新的命题，需要更强有力的团队，需要不断探索。如果中台研发团队的研发能力和时间进度无法跟上前台业务的需求变化，那么中台就只能满足部分前台业务的需求。再者，如果中台的抽象程度低、扩展性差，则会导致中台无法满足前台业务需求。这时前台应用又因为业务本身的发展目标和压力不得不自行组织团队完成这部分功能，由此可能发生本应由中台提供的能力却最终实现在业务应用中。中台越做越小，前台应用越做越大。这样一来，进一步压缩了中台的生存空间。
图 3-14 中台与前台应用的关系
因此，中台既需要满足业务的需求，但又不能过度参与业务。中台能力的建设首先要保证投入到中台的资源不能成为业务建设的瓶颈。中台提供的能力要具有灵活性和可定制性，便于业务方根据规范自主完成，减少沟通成本，提升效率。
“大中台，小前台”，并不意味着前台不重要。相反，建设大中台就是为了更好地服务于小前台。大中台要想发挥作用，体现出自己的价值，必须通过小前台的引导。因此，判断中台建设是否成功的指标应包括：前台有没有使用中台，前台从使用中台中获得了哪些好处，中台好不好用，愿不愿意继续使用中台。
中台的进化策略
虽然中台概念的提出到现在仅几年时间，但中台已经在这几年中走出了自己的路径。根据中台的进化和演变的历史及可能的方向，目前可以看到共有广度和深度两种途径，如图
3-15 所示。
图 3-15 中台的广度和深度两种进化策略
广度是指中台所涉及的内容会越来越多，即可以认为各种中台的不断出现，也可以认为是一个中台内部的共享服务中心会不断横向扩展，从一开始所提的业务中台、数据中台，逐步演化到
AI 中台、技术中台、研发中台等。另一方面，一个中台范围内的共享能力也在扩展，从用户中心、交易中心、营销中心等扩展到内容中心、工单中心、成长中心等。中台团队如发现某一前台业务模式很好，则将其沉淀为共享服务，从而提供更多的业务，这也是在建设和加强中台。由于中台作为中枢点同时支撑多个前台业务，因此中台成为打通前台业务的最好着力点，让不同的前台业务可以互相借力和引流，互相促进发展。
中台所沉淀的共享服务能力并不要求支撑所有前台业务，只要有多于一个前台业务需要某一种能力，此能力即可沉淀为中台能力，因此我们不能大而全地建设中台。如果企业认为现在企业各系统的用户管理能力需要统一，那就可以着手进行用户中心的建设。在此基础上，如果企业发现会员需要统一管理，订单需要全局视图，那么就构建会员中心和订单中心。因此，中台的建设是可以分阶段逐步实施的，无须将所有重构全部一起推动，而后者既会增加复杂性，又会提高风险，还不能及时得到反馈。
中台的成长离不开前台业务的创新。只有不断进行业务迭代和更新试错，对中台提出新的挑战和沉淀，才会让中台做得更好。另一方面，中台团队也需要有自己的产品化、平台化建设思考，并作为新业务的孵化器。
中台还需要建设成为开放的体系。开放不仅仅是对企业内部开放，也要对企业外部开放。通过中台建设，企业可以将自有的系统变为开放式平台，从而为其他企业充分提供第三方的数据和服务。再者，中台本身通过开放也可以充分利用其他第三方数据和服务。开放可以接口的方式，通过开放
API，开创新的商业机会和应用模式。
中台的开放也意味着中台需要支持个性化需求。通过抽象能沉淀共性的流程、数据模型等。但不同业务总有不同点，这些不同的需求就需要个性化的支撑。中台和前台一般是由不同团队负责的。因此为了提高效率，中台必须留出足够灵活的扩展点，以便不同前台业务根据其需求进行定制化扩展。
中台作为平台，必然需要考虑拆分整体应用形成业务组件，通过业务抽象建模，解决共性的问题，从而更好地为业务服务。对业务问题的抽象程度越高，中台对业务的适配度就越高，需要对具体业务参与度就越低，从而更能发挥中台及中台团队的价值。因为越好的抽象越能发挥业务应用开发的创造性。在考虑拆分的同时，必须设计整体框架和组装策略，即组件间的协作机制。通过协作机制，才能让各业务组件协同实现业务场景以达到业务目标。
中台作为一个平台，其本身的运营也需要数据支撑。比如需要统计和观察中台以 API 形式提供的共享能力，从而了解中台哪些能力被业务引用及引用的频率，所使用的参数模式等；哪些设计的接口能力没有用处等。有了实际的数据，可更好地迭代中台。
中台建设是一个综合性的系统工程，因此需要有效的方法论的指导。中台建设方法论会在后续章节专门讨论。 |
