从去年开始，好像就有一只无形的手一直将我与“微服务”、“平台化”、“中台化”撮合在一起，给我带来了很多的困扰和思考与收获。
故事的开始源于去年的技术雷达峰会，我在会上做了一场关于平台崛起的主题分享（《The Rise of Platform》），这场分享主要是从技术的层面从Global的视角介绍了平台化的兴起，以及分享从基础设施到人工智能等各个领域不断涌现的各类平台，以及平台化对于软件开发人员及企业的影响。
记得当时在做演讲彩排的时候，有同事就提到过，在中国提“数字化平台战略”可能大家会觉得比较抽象比较远大空，如果你提“中台”大家会更熟悉一些。
而这也是我第一次听到“中台”这个词，原来除了我们熟悉的“前台”和“后台”外，居然还有个“中台”这样一个神奇的存在。
那…… 中台到底是什么？会不会又是另一个Buzzword呢？这个从名字上看像是从前台与后台中间硬挤出来的新断层，它与前台和后台的区别和界限到底在哪儿？什么应该放到中台，什么又应该放到前台或是后台？它的出现到底是为了解决什么问题呢？
从那时开始，一个接一个的问题就不断的涌出并萦绕在我的脑子里。直到一年多后的今天，随着参与的几个平台化、企业中台相关的项目已经顺利地步上了正轨，终于可以坐下来回顾一下这一年的实践与思考，再次试图回答这些问题，并梳理成文，与大家交流探讨。
##中台迷思
到处都在喊中台，到处都是中台，中台这个词在我看来已经被滥用了。
* 在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
* 在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
* 在有些人眼里：中台应该是组织的事情，在释放潜能：平台型组织的进化路线图 (豆瓣)中就提出了平台型组织和组织中台的概念，这类组织中台在企业中主要起到投资评估与投后管理的作用，类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
看完本篇你就会理解，上边的这几类“中台”划分还是靠谱的，更多我看到的情况是大家为了响应企业的“中台战略”，干脆直接将自己系统的“后端”或是“后台”改个名，就叫“中台”。
中台到底是什么？它对于企业的意义到底是什么？当我们谈中台时我们到底在谈些什么？
想要寻找到答案，仅仅沉寂在各自“中台”之中，如同管中窥豹，身入迷阵，是很难想清楚的。不如换个 ⾓度，从各类的“中台迷阵”中跳脱出来，尝试以更高的视角，从企业均衡可持续发展的角度，来思考中台的价值，来试图反推它存在的价值。
所以，为了搞明白中台存在的价值，我们需要回答以下两个问题：
1. 企业为什么要平台化？
2. 企业为什么要建中台？
###第一个问题：企业为什么要平台化？
先给答案，其实很简单：
因为在当今互联网时代，⽤户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
不断快速响应、探索、挖掘、引领⽤户的需求，才是企业得以⽣存和持续发展的关键因素。
那些真正尊重用户，甚⾄不惜调整⾃己颠覆⾃己来响应⽤户的企业将在这场以⽤户为中心的商业战争中得以⽣存和发展；⽽反之，那些在过去的成就上故步⾃封，存在侥幸⼼理希望⽤户会像之前一样继续追随⾃己的企业则会被用户淘汰。
很残酷，但这就是这个时代最基本的的企业⽣存法则。
⽽平台化之所以重要，就是因为它赋予或加强了企业在以用户为中心的现代商业战争中最最最核心的能力：用户响应力。这种能力可以帮助企业在商战上先发制人，始终抢得先机。
可以说，在互联网时代，商业的斗争就是对于用户响应力的比拼。
又有点远大空是不是，我们来看个经典的例子:
说起中台，最先想到的应该就属是阿里的“大中台，小前台”战略。阿里通过多年不懈的努力，在业务的不断催化滋养下，将自己的技术和业务能力沉淀出一套综合能力平台，具备了对于前台业务变化及创新的快速响应能力。
海尔也早在多年前就已经开始推进平台化组织的转型，提出了“平台自营体支撑一线自营体”的战略规划和转型目标。构建了“订单合一”、“用户付薪” 的创客文化，真正将平台化提高到了组织的高度。
华为在几年前就提出了“大平台炮火支撑精兵作战”的企业战略，“让听得到炮声的人能呼唤到炮火” 这句话形象的诠释了大平台支撑下小前台的作战策略。这种极度灵活又威力巨大的战法，使之可以迅速响应瞬息万变的战场，一旦锁定目标，通过大平台的炮火群，迅速精准对于战场进行强大的火力支援。
可见，在互联网热火朝天，第四次工业革命的曙光即将到来的今日，企业能否真正做到“以用户为中心”，并不断提升自己的用户响应力来追随甚至引领用户的脚步，持续规模化创新，终将决定企业能否在这样充满挑战和机遇的市场上笑到最后，在商业上长久保持创新活力与竞争力。
而平台化恰好可以助力企业更快更好的做到这些，所以这回答了第一个问题，企业需要平台化。
###第二个问题：企业为什么要建中台？
好，想明白了第一个问题，为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台+后台”的平台化架构又为什么不能满足企业的要求呢?
好，这就引出了我们的第二个问题：企业为什么要建中台？
###来，先定义一下前台与后台
因为平台这个词过于宽泛了，为了能让大家理解我在说什么，我先定义一下本篇文章上下文下我所说的前台和后台各指什么：
* 前台：由各类前台系统组成的前端平台。每个前台系统就是一个用户触点，即企业的最终用户直接使用或交互的系统，是企业与最终用户的交点。例如用户直接使用的网站，手机App，微信公众号等都属于前台范畴。
* 后台：由后台系统组成的后端平台。每个后台系统一般管理了企业的一类核心资源（数据+计算），例如财务系统，产品系统，客户管理系统，仓库物流管理系统等，这类系统构成了企业的后台。基础设施和计算平台作为企业的核心计算资源，也属于后台的一部分。
###后台并不为前台而生
定义了前台和后台，对于第二个问题（企业为什么要建中台），同样先给出我的答案：
因为企业后台往往并不能很好的支撑前台快速创新响应用户的需求，后台更多解决的是企业管理效率问题，而中台要解决的才是前台的创新问题。
大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度跟不上前台的节奏。
我们看到的很多企业的后台系统，在创建之初的目标，并不是主要服务于前台系统创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱外购，需要每年支付大量的服务费，并且版本老旧，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，也是企业所谓的“遗留系统”的重灾区。
总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。
有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个2.0问题不就解决了。
但就算是新建的后台系统，因为其管理的是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制。导致其同样往往无法被前台系统直接使用，或是受到各类限制无法快速变化，以支持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速创新迭代，所以要求转速越快越好；⽽后台由于面对的是相对稳定的后端资源，而且往系统陈旧复杂，甚至还受到法律法规审计等相关合规约束，所以往往是稳定至上，越稳定越好， 转速也自然是越慢越好。
所以，随着企业务的不断发展，这种“前台+后台”的齿轮速率“匹配失衡”的问题就逐步显现出来。
随着企业业务的发展壮大，因为后台修改的成本和风险较高，所以驱使我们会尽量选择保持后台系统的稳定性，但还要响应用户持续不断的需求，自然就会将大量的业务逻辑(业务能力)直接塞到了前台系统中，引入重复的同时还会致使前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。渐渐拖垮了前台系统的“用户响应力”，用户满意度降低，企业竞争力也随之不断下降。
对于这样的问题，Gatner在2016年提出的一份《Pace-Layered Application Strategy》报告中，给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。
而Pace-Layered Application Strategy也为“中台”产生的必然性，提供了理论上的支撑。
###Pace-Layered Application Strategy
在这份报告中Gatner提出，企业构建的系统从Pace-Layered的⾓度来看可以划分为三类: SOR(Systems of record )，SOD(Systems of differentiation)和SOI(Systems of innovation)。
处于不同Pace-Layered的系统因为目的不同，关注点不同，要求不同，变化的“速率”自然也不同，匹配的也需要采用不同的技术架构，管理流程，治理架构甚至投资策略。
而前面章节我们提到的后台系统，例如CRM、ERP、财务系统等，它们大多都处于SOR的Pace-Layered。这些系统的建设之初往往是以规范处理企业底层资源和企业的核心可追溯单据(例如财务单据，订单单据)为主要目的。它们的变更周期往往比较长，并且由于法律律审计等其他限制，导致对于它们的变更需要严谨的申报审批流程和更高级别的测试部署要求，这就导致了它们往往变化频率低，变化成本高，变化风险高，变化周期长。无法满足由用户驱动的快速变化的前台系统要求。
我们又要尽力保持后台(SOR)系统的稳定可靠，⼜要前台系统(SOI)能够小而美，快速迭代。就出现了上文提到的”齿轮匹配失衡“的问题，感觉鱼与熊掌不可兼得。
正当陷入僵局的时候，天空中飘来一声IT谚语：
软件开发中遇到的所有问题，都可以通过增加一层抽象而得以解决!
至此，一声惊雷滚过，“中台”脚踏七彩祥云，承载着SOD(Systems of differentiation)的前世寄托，横空出世。
我们先试着给中台下个定义：
中台是真正为前台而生的平台（可以是技术平台，业务能力甚至是组织机构），它存在的唯一目的就是更好的服务前台规模化创新，进而更好的响应服务引领用户，使企业真正做到自身能力与用户需求的持续对接。
中台就像是在前台与后台之间添加的一组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁。它为前台而生，易于前台使用，将后台资源顺滑流向用户，响应用户。
中台很像Pace-Layered中的SOD，提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了一种美妙的平衡。
有了“中台”这一新的Pace-Layered断层，我们即可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本，从而为前台提供更强大的“能力炮火”支援。
所以，企业在平台化的过程中，需要建设自己的中台层（同时包括技术中台，业务中台和组织中台）。
##总结
思考并回答了文初提出的两个关于中台价值的核心问题，解决了我对于中台产生的一些困惑，不知道对你有没有启发，让我最后再来总结一下：
1. 以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能力和规模化创新能力，是互联网时代企业综合竞争力的核心体现。平台化包括中台化只是帮助企业达到这个目标的阶段，并不是目标本身。
2. 中台(无论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应力困境， 弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的矛盾，提供一个中间层来适配前台与后台的配速问题，沉淀能力，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应。
3. 所以，中台到底是什么根本不重要，如何想方设法持续提高企业对于用户的响应力才是最重要的。而平台化或是中台化，只是恰巧走在了了这条正确的道路上。
##从数据中台到AI中台
企业对数据的利用有三个阶段：响应运营，响应业务，创造业务。数据中台解决的是响应业务的问题，第三阶段“创造业务”，则需要AI中台。
###数据中台的意义
数据中台对一个企业，起着至关重要的作用。在数据中台这个称谓成型之前，各个企业也都在用不同的方式来尽可能地利用数据产生价值。只是在这个过程中，也不得不处理着数据带来的各种问题，比如各个业务系统经年累月以烟囱架构形式存在而导致的数据孤岛、数据隔离、数据不一致等等。因为这些问题实在是过于繁杂，企业开始建立数据团队，或者数据部分开始继续数据整顿工作，因此数据仓库、数据湖、主数据治理等一系列的工作职能应运而生。
本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。有点像“头痛医头、脚痛医脚”：各个业务系统规范不一致了，于是开展了元数据治理；数据分析的时候数据关联不上了，于是不得不进行主数据治理。
这样的数据治理工作在进行了很多年后，数据中台这个概念逐渐有人提出了，阿里的《企业IT转型直到：阿里巴巴中台战略思想与架构实践》这本书更是把用中台战略把这个概念推向了一个极致。中台战略中，人们常说：大中台，小前台。在这种模式下，频繁出现的字眼是：共享。那么，到底共享的是什么？答案便是数据的服务。中台战略，并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。
过去，数据依赖于手工进行，没有软件；有了数据中台，以功能驱动，固定的数据输入，得到固定的数据输出，构建出能用的服务变得更快速、更加的标准化，解决了业务侧的“能用”问题。但是，如何以固定的输入，以产生更灵活多变的输出，提供比如个性化的服务，做到“好用”，数据中台并没有给出答案。
在建立了数据中台架构之后，我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个初始的参照方向。当我们发现，深度学习、机器学习等等一系列技术开始在这个平台下施展拳脚的时候，我们可能已经清晰地认识到：中台并不是数据分析利用的终点。
##企业利用数据的三个发展阶段
如果回顾数据分析的历程，可以归纳发现数据利用大概有如下三个阶段：
响应运营
响应业务
创造业务
###第一阶段：响应运营
响应运营是数据分析最直接也是最原始的诉求。没有谁不不会关心自己的用户留存率，没有谁不关心自己的营收额；出现了故障、如何分析定位，如何预测预防，运用数据分析自然不过。但是在运营分析过程中，也发现了另外一系列的问题，比如各个业务系统的数据存储格式、存储介质都不相同，在进行基本的运营分析的时候，无法流畅的进行。此时，不得不进行一系列的数据治理。常见的主数据、元数据治理就是发生在这个阶段，只是数据仓库将主数据和元数据治理进行了规范化。
###第二阶段：响应业务
数据分析停留在运营阶段的时候，对企业来讲最大的感受就是投入产出比不对称。这个问题在大数据爆发的时间点上，更为凸显。例如在今天的业务场景下，传统的数据仓库已经解决不了海量数据、异构数据等一系列问题，而大行其道的大数据分析技术，硬件要求高、学习门槛高。要实施一个大数据平台，成立一个大数据团队，这是一个不小的成本开销，更何况现在有不少数据分析团队要借助机器学习等手段，来对数据做分析来响应运营，这导致基础设施成本、整体门槛进一步提高。
于是像数据中台这样的思想就被提了出来：既然数据是从业务系统产生的，那么是否业务系统也需要数据分析结果呢？对于数据平台来说，数据平台本身提供两大能力：数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台，仅仅让业务系统很轻量的维护自己的业务流程操作？所以利用中台剥离了复杂的业务环境，再配合微服务等技术，一下子让人感受到了“数据服务的共享”。
而对业务场景来说，很多时候是需要数据服务的，例如用户的基本信息管理、用户的行为数据分析，这些数据不但可以暴露给业务系统使用，甚至可以直接丢给终端用户自行使用。类似这种契合点，让数据平台变成了一个服务，提供给业务系统。而对数据服务的使用者来说，在消费数据的同时也在继续产生数据，这样在数据平台和业务系统之间就构成了一个良性的闭环。
##第三阶段：创造业务
业务不会总停滞不前，因为人的生活会改变，想要的体验会改变。过去，大家到视频平台看视频，利用通用的数据服务，不同的用户看到的视频推荐都是一样的；很快，我们就会发现根据用户的偏好，推荐个性化的视频几乎是必不可少的体验要求。然后，我们就开始思考：数据是否可以变成个性化服务提供给终端用户？这是一个非常简单、常见的例子。当这样的个性化数据服务越来越多之后，各种服务不断组合，就会创造出很多可能性，进而提供创新的个性化体验和新的业务模式，这就是数据服务用于创造业务的阶段。
虽然有了数据中台，但是当有大规模的、基于智能算法的数据服务需要落地实现时，依然会碰到以下挑战。
如何对规模化的智能服务进行管理：当只是零星三两个智能服务的时候，通过手动人工管理等方式，不会有太大的问题；然则，当智能服务成千上万的时候，如何管理、如何构建、如何高效维护，就会成为很大的麻烦。
没有良好的工程实践来保证质量和流畅性：对于常规的应用软件开发我们有TDD、自动化测试、CI/CD等成熟的工程实践做保障；但是在智能服务这一块，无论是编程开发、还是服务构建，都没有成熟的工程实践，也没有良好的基础设施支撑，非常依赖于构建这个服务的数据工程师的个人能力，导致在实施过程中，问题难以复现，难于定位。
数据安全、治理和数据量不充分：数据中台的价值点，在于提供了数据的计算和存储的能力，但是在智能服务构建下，光有计算和存储还不够。治理到什么程度的数据，才能较好的支撑服务的构建？个性化的服务与数据安全冲突的时候，如何抉择？数据量不足导致算法模型泛化能力太差，怎么办？
###从数据中台到AI中台
什么是AI中台？数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。未来的操作系统，一定会越来越个性化，甚至每一个人看到的登录界面都不一样，系统可以根据对应的终端用户自行呈现符合该用户习惯的系统界面。那么对于这样的场景和服务，我们需要怎样的平台？整个软件开发架构和流程是否也都会相应重造？
回到创造业务的需求。以简单的销售业务为例，数据中台提供的服务本质如下图所示：
这是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务。这种方式，好比是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。
能不能这样：将整个软件组装出来的服务，包装成个性化的产品一样去售卖，提供量身定做的服务？那么整个运营模式就变成：平台提供了一种快速构建智能服务的过程，服务售卖者利用这个平台，自己动手构建出服务，拿出去售卖，类似一个提供“智能业务服务的PaaS”。
如果尝试给AI中台下个定义：
AI中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。
借助一个平台，将软件的服务个性化的创造，这将是未来的发展趋势。在麦肯锡的分析报告中，我们可以看到，各个企业或者行业，都在第三个阶段做了不同的探索和努力。
##从数据中台演进到AI中台
从AI中台落地实施的方式来看，AI中台可以是数据中台的进一步延伸，从数据中台一步一步演进过去。
###首先，从基础设施角度，可以将数据中台智能化
所谓的智能化，是指将在数据中台进行的一系列的数据服务构建操作进行智能化实现，让数据的接入、存储、分析展现、训练、到构建管道（pipeline）都更加自动化。例如，对于通用的CI/CD来说，测试不过则会构建失败，那对于AI中台下，就要考虑一个推荐模型构建失败的条件是什么？答案可能是“本次模型的准确率低于上一次构建的准确率”的时候，CI应该被构建失败。在实践中，这可能是CI构建过程的维度之一，还会有很多其他指标和维度。我们就需要在现有的数据平台的CI中，实现并自动化这些指标和维度，使之更加智能化。
###其次，对于中台使用者来说，将烟囱式模型构建过程改造为可复用的模型构建过程
目前基于数据中台的一个智能服务模型开发来说，流程如下：
这基本类似于一个横向的烟囱架构，导致目前对一个基于算法模型产生的服务进行拆分的时候，都不是特别地顺畅。如果大部分业务场景依旧以流程为主还好，如果新业务需要引入多的智能服务，那么一系列的问题就会暴露出来：
借助于现有数据平台手工进行数据操作
烟囱架构开发，对人员能力要求高
环节无法有效拆分，响应周期慢
智能场景规模化，管理复杂
训练，部署，发布依赖于手工部署缺乏有效的流水线
和数据平台孤立，缺乏统一的数据服务接口
基础设施隔离，无法动态进行资源的分配和管理
AI中台需要具备构建智能服务的能力，就要求我们对服务构建的过程进行如下拆分：
首先需要从基础设施层面进行集成。常规的数据中台依赖于大量的CPU和内存，相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据。所以如何通过一个接口、一个调度器、一个管道pipeline来集成整个工作流，就成了需要考量的事情了。
AI中台至少应该分为以下几个层级：
基础设施：对CPU做虚拟化的技术已经相对成熟，但是智能服务依赖的更多的是GPU，那么GPU如何做虚拟化，算法模型训练和数据是否需要共同使用相同的机器，还是集群相互隔离，都是需要在一开始设计好的。
资源管理：一切都是资源，无论是网络、内存，还是数据、服务，都是资源。对于模型构建者，关注的只是算法本身，如果该构建者需要数据，那这样的数据就是一个资源而已，无论资源是以环境变量的方式提供、还是以服务的方式提供，构建者本身并不需要关心。此时，必须一个资源管理系统，对数据服务进行统一管理。
中台和模型：中台有数据的计算和存储能力外，还应该具备算模型的能力，这里的模型指的是一些业界通用的、或者企业级通用算法模型。它可能是一个算法、可能是一个别人已训练好的模型，可以使用迁移学习的方式去使用。对于中台来说，它都是一个数据集的体现，不应该和一个表，一个文件有特别的区分。
流水线：流水是构建规模化智能服务非常重要的一个环节，工作如其名，让我们构建智能服务的时候，可以像流水线工作一样，达到这样的效果，则需要对整个任务进行非常详细的分解。
智能应用层：智能应用层直接面向终端，怎么利用元数据等功能，组合各自不同模型提供的服务，构建出组合效应的创新服务。
在数据中台的基础上，扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务、服务、智能CI/CD等服务，来实现AI中台。这样以来，就可以达到：
和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值
拆分服务构建环节，智能服务开发流程化，快速响应业务需求
利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发
基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化
统一的元数据管理系统，模型的全生命周期可管理
通用AI能力平台化，降低人员要求，提升协作效率
也即，利用算、模型、框架，动态、快速地组装服务，创造出新的个性化体验和新的业务新的业务模式，解决“好用”的问题。
##结语
数据中台提供的是存储和计算的能力，基于不同的业务场景，构建出了用来支撑不同业务的数据服务，依托于强大的计算力，可以快速缩短获得结果的周期。而AI中台则是将算法模型融入进来构建为服务，让构建算法模型服务，更加快速高效，以更加面向业务。但无论是数据中台还是AI中台，都是一层基础设施，做好基础设施只是第一步，如何让它的价值最大化，还要依托于AI中台不断结合业务来持续优化，做到“持续智能”。
