中台生态建设:业务中台、数据中台、AI中台、研发中台、移动中台

“大中台,小前台”并不意味着前台不重要,恰恰相反,建设大中台就是为了更好地服务于小前台。大中台要发挥其作用,体现中台价值,还必须要通过小前台的引导。


中台的存在价值是为客户服务,比如业务中台和数据中台要快速响应前台应用的要求。但是有时候一个中台会服务于多个前台,在资源有限的情况下,中台会对不同应用需求的优先级排序和取舍。

由此可见,大中台立足于横向的、全局的长远考虑,而小前台则注重解决当前纵向业务问题。如此看来,大中台的发展必然会涉及权衡,但如何做取舍并没有标准答案,需要结合实际情况而定。

中台生态有哪些?

自从阿里提出中台的概念以后,近年来业务中台、数据中台、AI中台、研发中台、移动中台……等有关中台的名词层出不穷,许多相关概念如雨后春笋般应运而生。

中台:所谓中台,是与前台、后台相对应,系统中被共用的中间件的集合。中台存在的目的是更好地服务于前台,使数据信息不断地发展到业务、组织、商业模式等领域。为技术中台、业务中台、组织中台、数据中台等一系列数据平台带来共享和便捷性,中台的核心就是共享性。

业务中台:业务中台是具有业务属性并支持多业务的共性能力组织,有助于业务的复用,对业务具有快速响应能力。从广泛意义来讲,一切中台皆是业务中台,它们来源于业务并服务于业务。从狭义角度而言,业务中台一般是指以在线业务为典型特征的中台。比如,天猫、淘宝、京东等一些平台,它们有一些通用的业务中心,包括商品系统、订单中心、营销中心、用户评价系统等通用性的业务系统集合。

数据中台:简单而言,数据中台就是提取各业务的数据,统一标准和口径,通过数据计算和加工为用户提供数据支撑。对于企业来说,要构建数据中台就必须包含数据模型存储、数据资产管理、对外数据服务、数据挖掘与分析等各方面的过程。其核心就是构建一个共享数据服务体系。

AI中台:AI中台简单来讲就是提供一个通用化智能服务,是基于客户对数据需求服务的演变,比如客户可能需要一些动画实时数据展示,希望对当前服务提供“个性化”服务等等。AI中台需要数据存储、数据分析、数据管理等都能实现智能化、自动化。

研发中台:研发中台是关注应用开发效率的管理平台。软件开发和系统建设是一项IT工程,涉及项目管理、团队协作、流程、测试、部署、运营等方面。如何将企业在应用开发过程中的最佳实践沉淀为可复用的能力,从而能够快速迭代出创新型应用,也是诸多企业当前的关注点。

中台生态:业务中台、数据中台、AI中台、研发中台、移动中台

研发中台

研发中台为应用开发者提供了流程和持续交付能力,包括敏捷开发管理、开发流水线、部署流水线、持续交付。敏捷管理一般是由问题、迭代、实施等组成,并管理研发人员日程工作和任务。

开发流水线是指对源代码管理、分支组建、合并和提交等,是将成熟产品系统部署到指定环境并上线运行的流水线职责。线上应用需要监控,包括基础设施监控、日志洞察、浏览监控链路分析等功能。由此可见,研发中台为应用的开发提供了流程、质量管控和持续交付等能力。

移动中台:随着业务发展的不断创新,许多新业务也会产生,就需要平台级的移动端开发支持。长此以往,可能会有更多的业态需要支持,因此快速开发移动APP、H5和小程序一直呈前台业务发展,将最佳实践逐渐沉淀为移动中台。

中台生态:业务中台、数据中台、AI中台、研发中台、移动中台

移动中台

移动PP与其它前端技术相比,有其特殊性:

第一,移动APP采用C/S架构,其发行版本模式需要应用市场审核;另外,客户端程序的使用控制者是用户本身,系统需要提供远程配置、动态更新等,帮助用户合理控制移动APP。

第二,移动业务通常是在线业务,对网络具有很强的依赖性。而移动链路本身的稳定性和连通率等与有线网络相比还是有所不足,因此在消息推送的时效性方面需要考虑其网络因素。

第三,移动端需要不断地更新迭代,修补补丁、漏洞,因此需要提供热修复等功能。

第四,由于前端实现技术的不同,移动APP本身的安全性也是一个重中之考虑的因素。如果完全采用不同开发方式,无疑对于企业来说其重复投入和资源浪费是非常巨大的,而且数据不可共享。

因此,采用Hybrid混合开发模式,不仅能够支持移动APP,而且支持H5、小程序,也是移动中台需要的一部分。因此,在前端开发中尽可能使用组件化,大大提高移动端的开发效率和产品质量。

中台于前台的博弈

中台是通过基础服务和解决方案为前台业务应用提供服务。中台的职责是不断提升整体平台的服务能力。根据前台业务的发展中台会提供不同的支持和参与,其建设路径也就不同。

一方面,我们可以将中台理解为工具,也就是将中台当作工具平台来建设。由于中台的通用性特征,其抽象程度较高,应用范围较广,可以在各行各业适用。

但由于其作为工具无法深入业务场景,就导致中台不能够沉淀到业务中去,从而中台研发人员与业务方在沟通环节出现矛盾,导致中台方无法直接为业务赋能。要解决这类问题,还需要对业务和系统有充分的理解。

另一方面,中台完全为业务服务。中台方能够快速理解业务需求,参与业务方的数据建模、流程设计、系统模型设计等,并将其演变为系统实现。中台开发者参与业务建设,符合中台为业务服务的目的,且中台的能力也是通过业务沉淀下来的。

从业务角度考虑,过分与业务团队耦合,很可能会忽略中台通用性样的业务能力,也会导致无法更专注于对中台技术的深入研究。

但是随着企业业务不断发展,类似的业务随时间的推移会出现很多。然而,我们在不断的扩展,耦合中会发现原业务应用于新生业务应用的功能和能力极其相似,甚至可以复用,因此,考虑搭建中台系统,避免业务功能和能力的重复投入和建设,有助于业务系统的开发和成本的浪费。从不同前台应用中抽取出来的公共部分即可成为中台。

但是中台建设是一个新命题,需要强大的团队,不断探索和发现。如果中台研发团队的开发能力和时间进度无法跟上前台业务的变化需求,那么,中台就只能满足部分前台业务的需求。

所以,“大中台,小前台”并不意味着前台不重要,恰恰相反,建设大中台就是为了更好地服务于小前台。大中台要发挥其作用,体现中台价值,还必须要通过小前台的引导。

全网数商拥有15年、百余家大型企业数字化转型经验,可为您量身打造解决方案

索取量身打造解决方案

HI!欢迎来到 全网数商

扫码后您将获得以下福利

资深产品专家

  • 专属客服 一对一 指导
  • 社群大咖运营经验分享PPT
  • 超多福利免费领取

扫码添加企业微信

扫码添加企业微信
获取更多福利资讯