中台建设，是近2-3年非常火的一个话题，从业务中台、数据中台，到技术中台，再到组织中台，各种概念、理念，以及方法论被国内越来越多的企业深度的研究、探讨。

当然，中国移动也不例外。移动智慧中台由4中台1中心组成，其中业务中台又包含B、O、M域系统，涉及范围非常广，是一个十分庞大且复杂的体系。那么，针对智慧中台这么庞大且复杂的体系，省分建设过程中到底有哪些挑战呢？

说到挑战，我们得从中国移动当前的IT现状谈起：

中国移动IT现状

基础能力不足

我们都知道，中国移动支撑系统经过三代演进，在B、O、M、D域分别建设了海量的服务，但由于缺乏统一的管控和运营手段，导致企业不能对这些海量服务进行有效沉淀，从而无法实现服务的共享和复用。其次，绝大部分省分B、O域系统都是分部门自治，很容易形成技术栈不统一；同时，由于异构的存在以及新的开源技术不断引入，域内系统甚至同一厂家的系统间也存在多条技术栈，从而使移动面临统一管控、协同和调度等难题。

架构不够灵活

业界普遍认识，系统架构不够灵活一定是多方面因素叠加导致的，既有架构本身设计方面的原因、也有业务复杂性所带来的影响。从IT规范的角度看，当前架构有没有缺陷或不足呢？回答是肯定的，毕竟IT规范只是一段时间内的产物，随着技术和业务的发展，规范也需要不断去更新和迭代。

但追求更深层次原因，我们分析发现规范中的架构并没有想象中那么LOW，而是由于省分在系统建设实际落地过程中与规范产生了较大偏差，最明显的例子是目前仍然有省分未按三代规范要求对CRM、BOSS等系统进行中心化的彻底解耦，从而导致了目前难以实现业务需求敏捷迭代。

另一方面，中移动从原来以移动业务为主，一步步发展到今天的全业务和生态业务运营，系统模型方面肯定需要优化和扩展，例如当前对多元素打包、售卖、计费模式就存在支撑灵活度不足等问题。

运营效率不高

当前，移动还处于B、O分域分部门自治，信息技术中心负责B、M、经分、B域大数据平台及应用建设；网管中心负责O域、网络数据平台及应用建设。两个部门分别面向市场前端、网络后端提供支撑服务，但在一些省份，由于系统、数据融合程度不够，导致跨部门面向企业的运营效率相对较低。

其次，基于AI与数据融合的智能化业务运营和管理能力不强，导致无法实现向企业级全要素的深入融合与渗透。

智慧中台建设思路及关键内容

面对这么多挑战以及移动“三融”价值经营体系对IT建设提出的新要求，省公司IT部门应该如何去应对呢？接下来我们提出一些思路和策略，以更有序去应对挑战。

技术中台

技术中台作为智慧中台底座，为业务中台、数据中台、业务能力运营中心以及前台应用提供了基础设施重用的能力，是共享服务体系建设的基础。

如果说业务中台+数据中台是强大的中台炮火群，技术中台提供的是如何根据需求快速搭建中台的炮火阵地。

如何让阵地建设得更加可靠、简捷易用？

技术中台要隔离业务中台、数据中台以及业务能力运营中心等对基础设施的依赖。业务中台、数据中台以及业务能力运营中心都是在技术中台的基础上开发、运行的，但又不能与技术中台绑定。因为业务中台、数据中台以及业务能力运营中心关心的是如何满足业务要求，而技术中台提供基础设施底层的能力，两者相互促进但又相互隔离。

有了以上原则，技术中台的建设思路就相对清晰了。

讲思路之前，我们有必要先了解移动中台的建设现状，少数省完成了业务中台、数据中台的建设，但大部分省都处于未建设的队列。

不出意外，第一类省的技术中台早已建设完成，在这里就不多谈，我们重点探讨第二类情况。

我们认为技术中台在规划过程中可以参考以下三个原则：

一、我们需要关注现在及未来业务模式给架构带来的要求，而不用去关注现网系统的技术架构。

二、我们需要关注现网业务流程、业务规则、系统集成等要素给新架构带来的要求。

三、我们需要关注如何为应用开发提供流程和持续交付的能力，包括敏捷开发管理、开发流水线、部署流水线、持续交付等。

规划完成后，就可以进入技术选型阶段。

看业界，都是依托云原生技术，以开放式架构聚合生态业务。

业务模式决定了技术中台的架构特征，每个特征都对应不同的技术组件。

能力可扩展：弹性计算框架、分布式数据库、容器化保障能力的扩展性支撑敏捷性：云原生的分布式服务框架、微服务化与DevOps保障业务支撑的敏捷性运营持续性：组件化、能力开放提供合作开放的技术支撑基础

技术中台与业务中台、数据中台一样，可分阶段建设。

在实际建设过程中，技术中台都早于其他中台启动，同时技术中台也会根据业务要求，配合业务中台或其他中台同步做技术升级。

从技术验证、项目实践的角度来看，一般都会选择先难后易的业务场景，这样可以避免复杂业务正式上线后带来的各种冲击。

最后，技术中台建设。一方面可以很大程度上帮助移动解决基础能力不足以及架构不灵活方面的问题。例如技术栈统一既解决了开发、运维管控难等问题，也能帮助企业提升开发效率，实现降本增效。

业务中台

区别于传统按需求建设系统的模式，能力的梳理和建设优先级的重要程度更高。

建设业务中台的核心目的是对服务能力进行梳理、沉淀、以及共享复用，实现能力资产化。

业务中台的建设，除了方法论外，本身也有一些方法和策略的考究，对应到演进路线通常有：顾旧立新、平滑过渡和不破不立三种方式。

顾旧立新：保留原有系统，利用新建系统搭建中台架构，逐步沉淀能力，为旧系统改造重建，迁移到中台架构打好基础平滑过渡：保持现有系统运行正常的同时，逐步沉淀中台共享服务中心，最终完成中台架构建设以及系统的升级改造不破不立：原有系统难以满足业务要求，利用中台架构建设新的系统替换原有系统

长远来看，不管选择哪种路线，对于企业来说都将面临不小的挑战。

从投资、风险等角度考虑，我们建议第一种方案，前期先挑选耦合度低且少数几个能力中心、采用先易后难、通过分阶段新建的方式搭建中台架构。通俗的来讲，就是“老城区”不做变化，另建一个“新城区”，在“新城区”进行中台架构搭建并沉淀业务能力，为后续“老城区”相关业务搬迁打好基础，做好准备。

这样的路径选择，好处在于对原有系统不会造成任何影响，同时对新的系统建设有规划有节奏的去实现。

上述中台搭建方案是从系统/能力中心的视角出发，也可以从业务场景出发来搭建中台架构。比如云网、权益营销、政企支撑等重点业务场景。

相比系统/能力中心的中台搭建方案，基于业务场景中台搭建方案的复杂程度完全由场景本身决定。例如政企支撑比权益营销肯定复杂得多。因此，我们建议前期先挑选较简单的场景进行搭建。

两种方案各有优劣。不管省公司最终选用那种方案，最终推导下来都会落到能力中心建设上去。

能力中心建设的整体策略与我们以前在建设系统过程中所采用的方法差异不大，基本都是从业务抽象到领域建模，再到架构设计。

往深层次看，新的技术架构引入，还是会给我们在建设策略上带来较大的变化，这里主要指微服务架构设计以及服务分解。

微服务架构下的服务分解有两种方式：一种是基于业务能力的分解方式，一种是基于DDD领域驱动子域分解。

以客户中心为例，用业务能力的分解方式来说明。

首先，客户中心需要满足下列需求：开户、资料修改、销户等。

换个视角，以资料修改来说。面对不同的场景，所修改的信息都应该有所不同。场景的分类既有业务的，也有空间的。

业务视角：直接修改客户信息与办理业务过程中同时修改客户信息应该有所不同；空间视角：用户上营业厅与通过线上渠道自助修改的信息肯定也有所不同。

从功能角度来看有：客户信息管理、联系人信息管理、关键人信息管理、纳税人信息管理等。

对应到具体的服务：

（1）客户类服务：客户信息新增服务、修改服务、删除服务（逻辑上的）

（2）联系人类服务：联系人信息新增服务、修改服务、删除服务

（3）关键人类服务：联系人信息新增服务、修改服务、删除服务

（4）纳税人服务：纳税人信息新增服务、修改服务、删除服务。

以上的这些微服务其实就会对应到我们资源模型中的一个个实体。那是不是所有的微服务都对应只操作一个实体呢？答案肯定不是。因为业务的复杂性往往需要我们通过一个微服务去操作多个实体。

当然我们也可以把这样的微服务再向下拆小，直到一个微服务对应去操作一个实体。但这样的做法真的合适吗？

肯定不合适，按上述方法去拆分将会给技术实现上带来很大的挑战，如事务的一致性如何去保障？

这时有人会跳出来说，可以引入一些开源组件，采用补偿的机制去实现。

确实，技术的问题，最终都能通过技术手段去解决问题，但同时也需要关注所花的代价有多大，给业务带来的影响有多深。

举个例子：订单修正。假如通过2个微服务来实现，那么就会出现前一个微服务的出参是后一个微服务的入参。以前的做法是通过一个服务直接搞定所有的读和写；而拆分成2个微服务后，则首先需要通过前一个微服务把旧的订单数据读取出来组装成后一个微服务所能理解的数据结构，再通过服务调用方式将数据传送给后一个微服务；后一个微服务接收到对应数据后，需要先做对应解析，最后做数据写入操作。

如果上述场景使用的频率非常高，势必系统的开销会成倍的增加。

因此，微服务拆分不一定是拆分得越小越好，而是需要根据业务场景来拆分才会更合适。上述微服务拆分原则，恰好也能与智慧中台规范中以场景驱动出发相对应起来。

这些拆分后的微服务最终能否都以资产的形式沉淀下来，还得结合业务场景要求以及业务能力运营中心的运营情况来判断和确定。总之，服务资产化也是一个持续不断优化迭代的过程。

业务中台的建设从场景出发，最终体现的是能力、流程、架构的提升，从而满足业务发展要求，实现内、外客户感知提升。

数据中台&AI中台

AI中台由集团统建，在这里不做讨论。

在本章节，我们和大家探讨数据中台的关键建设内容。

关于数据中台建设思路请大家阅读吴名朝专家所写的《揭开智能数据视图的技术面纱》一文，这里不做展开。

数据中台除了打通信息壁垒和数据孤岛，实现全网B/M/O三域、外部数据的融合、汇聚及存储外，数据治理也是值得重点关注的方向。

对移动而言，业务发展加快了数据膨胀的速度，也带来了数据不一致等问题，企业经营管理的不断变革同样会对数据治理提出挑战。这些日益复杂的内外因决定了中国移动对数据治理的超高标准要求。

数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如我们的数据该怎么进行规范，元数据又该怎么管理？这些问题都是数据治理过程中最实际的问题，也是最复杂的问题。

通常情况下数据治理工作主要有数据标准管理、元数据管理、数据质量管理、数据生命周期管理、数据安全、数据开发等。

以上各主题之间需要有机结合，如数据标准管理、元数据管理、数据质量管理等几个领域相互协同和依赖。通过数据标准管理，可以提升数据合法性、合规性，进一步提升数据质量，减少数据生产问题；在元数据管理的基础上，可进行数据生命周期管理，有效控制在线数据规模，提高生产数据访问效率，减少系统资源浪费。

数据治理不是一项临时性运动，需要从自身业务发展、数据治理意识形成、数据治理体系运行的角度，建立长效机制来进行保证。在大数据时代，经过数据治理的数据可以发挥更大的作用。

除了数据治理、数据融合外，数据智能化也是未来的一个趋势。

说到数据智能化，就不得不谈数智（大数据与AI）融合方面的话题。

大数据和AI的关注点虽然不尽相同，但却有密切的联系。一方面，AI需要大量的数据作为“思考”和“决策”的基础，另一方面，大数据也需要AI技术进行数据价值化操作。两者相辅相成，相互促进，共同推动技术应用落地，从而真正促进社会生产力的发展。

数据中台本身还是围绕数据服务来进行的，而非围绕智能服务。而AI中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。因此，只有将二者完美融合，才能加快推动数据智能化。

那么，如何将数据中台和AI中台进行有效融合呢？

常规的数据中台依赖于大量的CPU和内存，相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据。所以如何通过一个接口、一个调度器、一个管道来集成整个工作流，就成了数智融合需要考量的事情了。

通常做法，可以在数据中台的基础上，扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务、服务、智能CI/CD等服务，来实现AI中台。这样一来，就可以达到：

和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值

拆分服务构建环节，智能服务开发流程化，快速响应业务需求

利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发

基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化

统一的元数据管理系统，模型的全生命周期可管理

通用AI能力平台化，降低人员要求，提升协作效率

也即，利用算力、模型、框架，动态、快速地组装服务，创造出新的个性化体验和新的业务新的业务模式，解决“好用”的问题。

数据中台基于存储和计算的能力，结合不同的业务场景，构建出了用来支撑不同业务的数据服务，依托于强大的计算力，可以快速缩短获得结果的周期。而AI中台则是将算法模型融入进来构建为服务，让构建算法模型服务，更加快速高效，以更加面向业务。但无论是数据中台还是AI中台，都是一层基础设施，做好基础设施只是第一步，如何让它的价值最大化，还要依托于AI中台不断结合业务来持续优化，做到“持续智能”。

业务能力运营中心

业务能力运营中心承载四个中台之上的业务场景，拉通全域的能力，提供跨中心业务场景的编排能力。另一方面，通过业务场景的收敛为前台应用的开发提供场景模板和能力支持，从而提升应用开发的效能。关键建设内容在《为什么需要业务能力运营中心》基础之上，再补充2点：

第一点是推动需求梳理从传统线下向在线协作、智能协同模式转型。

之前通常是业务部门编写需求，然后与IT支撑部门讨论和确认，中间过程可能需要多次线上线下交互以及线下对各类文档的修改。文档传递基本以副本为主，当人员变动或临时调整，接手人很难快速了解前期的工作过程，效率非常低下。经过流程手段的变革，将需求整理，评审和修改全部线上化；通过协同创作，将PRD 文档和设计稿关联到需求，沉淀和分享更方便；让产品、设计、交付团队紧密协作，流转可以无缝衔接，从而提升工作效率。

以上内容都是省分在方案规划和系统建设过程中需要重点考虑和关注的。

对于集团而言，除了上述内容外，更需要关注有何手段能够帮助其管控所有省分的智慧中台都能够高标准落地，这也是我们接下来要讲的第二点内容。

因为有了第三代解耦实际落地与规范偏差大的前车之鉴，所以本次智慧中台建设，集团也相应采取了一些措施进行管控，比如总部统一组织建设方案的评审和核准、省公司设计批复完成后需将相关文件报备总部等。

以上措施都是事前管控，在一定程度上能够帮助省公司在方案规划阶段不会出现大的偏差，但在事中建设阶段和事后效果评估阶段仍然无法管控。

结合以上情况，我们建议制定一套智慧中台成熟度评估指标体系，并通过业务能力运营中心辅之运营，达到以评促建、以评促改、以评促管、评建结合来推动智慧中台建设。

如何通过集团级业务能力运营中心辅助两级运营呢？

与智慧中台建设一样，我们认为智慧中台运营也可以从场景出发，让建设和运营紧密结合起来，实现建设带来运营、运营促进建设。

从集团运营视角看，未来场景加载方式有两种：一种情况是场景加载在集团业务能力运营中心，可直接通过配置数据分析；另外一种是场景加载在省分业务能力运营中心。这时需要将省分配置数据同步到集团业务能力运营中心，待集团平台发起测试通过后，再对省分上传的配置数据做分析，或者通过年度巡检进行评估打分。

我们以融合业务受理场景举例说明：

A省受理步骤8次，操作30次，对应微服务35个；配置到加载上线小于1天……B省受理步骤13次，操作45次，对应微服务有50个；配置到加载上线大于3天……

通过上述数据分析，我们就可以快速找出A、B两省间场景支撑上的差异。针对差异我们可以进行深入分析，找出落后省份在业务、技术和管理上的不足，来反推落后省份向先进省份靠齐，从而实现所有省分的智慧中台都能高标准落地。

最后，有了评估指标体系及相应的运营工具，还应与之配套制定考核管理办法，让三者进行有机结合，才能保证智慧中台建设效果。

浩鲸在中台的实践探索

基于阿里巴巴中台建设理念，浩鲸科技在运营商及其他行业落地了丰富的案例，既有企业级中台的搭建，服务于整体架构提升，也有分业务领域的成熟实践。

业务中台方面，浩鲸科技深度参与了电信BSS 3.0的规范制定、建设、咨询，和中国电信共同探索了全新的基于全云化架构、智能加持、能力开放的运营商IT支撑系统。BSS3.0“平台+应用”的中台架构带来的不仅仅是技术上的变革，更重要的是大幅提升市场运营效率，突破业务发展瓶颈。

分业务领域方面，浩鲸科技根据多年来在政企支撑领域的经验积累，先后在10多个移动省份落地了政企智慧中台。政企智慧中台实现了客户、商机、营销、受理、服务、风控的一站式支撑，进行业务和数据整合，发挥数据效能，支撑政企业务快速发展。以面向对象、面向任务、面向业务、面向过程为抓手，以IT支撑的“自动化管理”为目标，建立以效率提升为核心的互联网化业务服务能力，带动生产能力的提升，实现政企业务“流程优、开通快、风险低”。

数据中台方面，基于阿里巴巴数据中台建设理念和产品体系成功帮助20多个电信、零售、能源、交通、政务、地产等行业客户构建了数据中台，有效推进了客户的数字化转型进程，帮助客户最终实现全域数据资产、全局业务运营、全景客户洞察和全链价值创新。

技术中台方面，通过国内外众多项目经验积累，加上阿里对浩鲸科技的DevOps、PaaS的赋能，形成了浩鲸科技的技术中台产品，浩鲸的技术中台提供了规范化、标准化的技术服务，同时提供了场景化、自动化和数据注智的研发运维一体化的DevOps工具链平台。

对于业务能力运营中心，实现起来挑战难度大，区别于其它方还在犹疑琢磨或者停留在概念方案层面的探索，浩鲸已经基于阿里在星环平台（阿里中台之上的真正实现业务能力运营的平台）的实践，吸纳其设计理念，借鉴其实现框架，包括一些实现方法，再结合运营商领域特性，而特别打磨出来的产品。

今天，智慧中台已经成为中国移动信息化发展道路上必须要构建的体系，而且刻不容缓。跟任何一种技术架构的演进一样，中台也需要不断迭代、进化，中台思想深度融合到企业日常经营当中，形成强大的后台炮火群，从而更好的支持前端业务快速反应。

最后，希望本文的一些观点能够帮助集团、省分在构建智慧中台的过程中起到抛砖引玉的作用。