中台完成从 0 到 1 建设：从 1 到 100，需要运营

在不同的阶段，技术方案往往会表现出不同的特征，中台也是如此，从 0 到 1 和从 1 到 100，企业需要对中台有不同程度的建设。本文，InfoQ 有幸采访了云徙科技副总裁李楠，探索现阶段建设中台需要关注哪些事情。据了解，云徙科技已经完成 3.5 亿元 B 轮融资，并于近期发布了数字中台灯塔计划，自 2016 年成立起便持续在中台领域输出。

从 1 到 100，中台需要运营

自今年以来，中台成为了非常热门的解决方案，对于众多 To B 企业而言，既追求产品的个性化，又追求服务的定制化，在面对不确定的市场环境时，还要考虑最快速度和最小成本试错，如果企业原来沉淀了大量的 IT 能力，就可以在新的环境下进行重用。李楠在接受 InfoQ 采访时说道：“这波数字化转型本质上还是技术驱动，但不代表会发生翻天覆地的变化，更多的是多种新技术的融合，帮助用户在产业互联网下探索未知领域的事情，而中台就是可行的解决方案”。

过去，传统企业大都是烟囱式的单体应用，彼此之间没有任何关系，建设中台之后就可以完美解决所有问题吗？在技术圈，其实没有大一统的解决方案。中台也是需要运营的。

采访中，李楠表示，企业进行数字化转型的本质是为了创造新的业绩增长，而业绩增长离不开运营，中台不应该只是一套简单的技术产品，应该直面数字化的本质，应该让业务部门运营起来。过去，企业迫切的希望中台建设从 0 到 1 的问题，但未来一定会从 1 走到 100，建设中台也是分阶段的，只是在此之前的企业大部分停留在从 0 到 1 的过程，但企业拼到最后一定需要考虑成本的，一定需要考虑通过建设中台如何降低产品的研发成本。

其次，对企业 IT 部门而言，中台的建设和维护也需要投入不少精力，一旦出现新的业务模式而企业自己搞不定时，可能还需要寻找厂商的帮助，这也是需要成本的。企业不是想不到这些问题，只是在初始建设阶段还没有考虑到这些问题，而现在需要考虑了。

对企业而言，这种运营能力包括人、商品、场地等众多信息，如果不经过对应场景的打磨，中台解决方案很难以可量化的指标运营，比如销售数据的增长。如果在某个建设周期做了市场营销，可以配合中台的营销中心和运营平台的精准营销和内容营销等场景，不同插件之间又需要是解耦的，这会大大降低企业的实施成本和建设成本。

李楠表示，中台不仅仅是 IT 能力的沉淀，也不仅仅是越来越多的 API 和应用，中台应该具备更多的商业能力，应该是围绕着商业场景的闭环的商业能力，这样才可以支撑探索新的业务模式，如果不是围绕业务场景形成的闭环，就是一个个散乱的 IT 能力，价值不大，这并没有回归到建设中台的本质。

这些就是云徙科技推出中台解决方案 3.0 的原因。对开发人员而言，合格的中台应该可以满足如下三种情况：当新的业务诉求出现时，开发人员可以较低的代码量完成研发，一旦发现无论如何组合都无法满足新功能时，开发人员就需要考虑能否基于业务规则进行修改，如果改不了，最终再考虑通过修改代码逻辑扩展整个数据模型。

云徙数字中台经过了早期版本、2.0 和 3.0 的迭代。其中，早期版本偏向于底层技术版本，2.0 版本则在总结企业数字化转型的变与不变并试图沉淀相应的模块，3.0 则极大丰富了可沉淀的模块，面向企业用户，以可插拔模块选取和组合模块，而对经常变化的模块采用可变引擎以及研发底座予以承接，3.0 版本还相应推出汽车、零售和地产三大行业版本。

数字中台 3.0 的核心组件依然是 2.0 的双中台：业务中台+数据中台。不同的是，3.0 版本的业务中台总结 11 大业务域、105 项商业能力以及 6 大通用能力支撑中心，是对 2.0 版本业务中台 13 个共享服务中心及 10 个基础组件的进一步丰富、规整和完善。11 大业务域包括：用户域、会员域、营销域、结算域、商品域、店铺域、交易域、内容域、履约域、服务域和评价域；105 项商业能力就十分细化了，例如有账号体系、会员成长、门店库存、盘点、三方物流、预售、秒杀、分佣等；6 大能用能力支撑中心则包括：业务网关、调度中心、工单中心、通信中心、支付中心和流程中心。

3.0 版本数据中台提供了 7 大主题数据服务、10 大数据模型和 3 大数据服务工具，相比 2.0 的 10 大模型和 8 大数据服务则进一步细分和扩展了相应的模块。全新 7 大主题数据服务包括：商业企划助手、营销助手、智能配补货、运营雷达、老板看板、店铺健康助手、团队健康雷达；3 大数据服务工具则包括智能标签平台、自助分析平台和智能开发平台；10 大数据模型则有属于分析模型的用户主题、商品主题、交易主题、物流主题、营销主题、渠道主题、评价主题，以及属于算法模型的推荐模型、补货模型和预测模型。

在业务中台和数据中台之上，云徙数字中台 3.0 推出了面向前台运营的 BOC 和面向中台运营的 MPC。BOC 是面向平台/商家插件化的商业运营工具，在之前云徙前端应用的基础上按领域模型形成了 i-CDP 会员运营域、i-Marketing 市场运营域、i-Commerce 商业运营域和 i-Service 服务运营域，每个运营域里都有详细的开箱即用的工具，以辅助前端业务人员直接运营业务进行创收。

而 MPC 是中台的“控制台”，面向企业用户进一步提供对业务中台和数据中台的可变化的配置和管理，总体目标就是让中台也能“动”起来。中台对于企业来说是如此的重要，而一个标准化的中台显然不能满足所有企业的差异化需求，同样的一个流程有的公司可能包含 5 个步骤、有的公司可能是 7 步，而同一家企业的中台二期三期建设过程中也需要对中台的能力进行翻新，因此就有必要对中台进行可视化编排与管理。xConfig 让商业能力可编排，业务规则可配置，而 MPC 的中台能力管理、业务应用管理和 API 管理则分别提供不同程度扩展、管理和调整中台的方法，此外还有 xOpen 中台能力开放生态让开发者和第三方参与中台能力的生态建设与运营。

相较于一些较为坎坷的中台建设过程，李楠对 InfoQ 表示，云徙科技的大部分项目实施周期不会太久，基本可以按照要求上线，这期间也会分批次迭代上线，最后一个迭代会把所有能力全部推进完毕，交由企业的 IT 部门进行运维。

数据中台与大数据平台

在中台还没有被广泛关注的时候，大数据平台帮企业解决了不少问题，比如数据统一、数据分析等，从一些日常的简单数据用例来看，大数据平台可以解决很多问题，甚至一些企业现在做数据中台的团队就是原来的大数据团队。如果大数据平台可以达到想要的效果，数据中台是否需要？

在采访中，李楠表示，试想一家传统企业内部有几十个，甚至上百个遗留系统，不同的系统中可能存在重复，但画像并不一致的数据，比如，同一个人在 A 系统中的画像是家在东莞的王先生，在 B 系统中是李女士的配偶，在 C 系统中的画像是开着劳斯莱斯的人士，在 D 系统中的画像是在深圳被限购。如果这几个系统中的数据可以打通，那销售人员就会尝试推荐东莞的房子给该用户，而不是推荐深圳的房子，这可以理解为数据中台方法论中的 One Data，另外还有两个方法论是 One  Model 和 One  Service，就是数据中台的数据会有统一的建模方式，不需要每次都从头开始利用数仓的方法论进行建模，这个建模过程也可以工具化、产品化，开发人员不需要每次都重新写代码，可以直接选择数据源和数据指标，并对数据进行自动加工，只有这样才会对业务产生价值。

在李楠看来，大数据平台和数据中台本来就是两种不同的技术手段，大数据平台没有这些方法论，只是一个大数据算力平台和基础设施平台。至于上面的管理工具，如何建立数据仓库等与大数据平台关系不大，大数据平台只是思考如何调度可以尽快运行并处理如此庞大的数据量，这与数据中台存在本质不同。

数据中台强调的是数据复用的能力，使用数据中台最明显的效果就是提升开发效率，使用封装好的工具平台，降低开发难度，数据分析的速度会大大提高。

中台的探索边界

从 PC 时代，到移动互联网时代，再到云计算时代，每一个时代都催生了大量的新的应用场景，开发者的开发方式也在逐渐发生改变。如今，云原生正在逐渐改变开发者的开发方式，而中台也开始探索与云原生的结合。

在中台之下，李楠表示，云徙科技全新发布了 i-DP 云原生研发管理平台。此前，2.0 版本的数字中台之下就是纯技术的 PaaS 和 IaaS，对于企业的 IT 团队和业务开发团队来说不够友好。一个企业往往有几十个、上百个项目在并行开发、发布、上线和下线，企业的开发团队要与业务部门进行紧密配合完成一次又一次的秒杀、限促、拼购等业务活动，因此 i-DP 的目标就是减少 80%非业务开发时间，提高业务交付速度，提升系统的可靠性，降低 90%以上人工失误操作，实现规模化作业、智能化监控、主动响应异常事件等。

i-DP 云原生研发管理平台为企业开发团队提供了开发门户，在管理方面提供团队管理、平台管理和效率工具，可以定义团队成员权限、提供报表管理和代码生成工具等；通过规划与设计、业务管理、计划与跟踪、迭代开发、知识管理、持续交付等全流程满足企业开发团队的开发需求；而在运营管理和运维监控等方面，i-DP 也提供了丰富的工具以提高企业开发团队的生产力。i-DP 还提供了 xMaker 企业开发者工具，包括可视化的业务模板工具、基于元数据的实体模型管理、代码生产线可视化、零代码/低代码开发等，以提升企业开发者个体生产力；xConnector 则通过配置化，可实现零代码与外部系统的对接；xRuntime 是面向微服务、大数据平台和应用支撑的经验证的系统运行时工具，保障系统质量。