下载掌阅APP，畅读海量书库
立即打开
业务中台更偏向于业务流程管控，将业务流程中共性的服务抽象出来，形成通用的服务能力。比如，电商平台有C2C、B2C、C2B、B2B四种模式，其中订单、交易、商品管理、购物车等组件都是有共性的。将这些组件沉淀下来，形成电商行业的业务中台，再基于这些业务中台组件的服务能力，可以快速搭建前台应用，譬如C2C模式的淘宝、B2C模式的天猫、B2B模式的1688、C2B模式的聚划算，用户通过这些前台业务触点使用业务服务。业务中台不直接面向终端用户，但可以极大地提升构建面向终端用户的前台的速度和效率。
业务中台抽象业务流程的共性形成通用业务服务能力，而数据中台则抽象数据能力的共性形成通用数据服务能力。比如，原始业务数据通过资产化、服务化，形成客户微观画像服务，这个服务既可用于电商平台的商品推荐，也可用于地产购房意愿，还可用于金融领域的信用评级。同一个服务，在应用层面展现的内容可能不一致，但是底层的数据体系是一致的。数据中台也将极大提升数据开发的效率，降低开发成本，同时可以让整个数据场景更为智能化。
如果同时拥有业务中台和数据中台，则数据中台与业务中台是相辅相成的。业务中台中沉淀的业务数据进入数据中台进行体系化的加工，再以服务化的方式支撑业务中台上的应用，而这些应用产生的新数据又流转到数据中台，形成循环不息的数据闭环，如图1-3所示。
图1-3 业务中台与数据中台的数据应用闭环
业务中台与数据中台相互促进，为企业业务的发展、管理者更好的决策提供支持。其中，业务中台的存在是为了围绕公司业务流程运作进行服务，将获取的多维度数据传递给数据中台，由数据中台挖掘新的价值反馈给业务中台，以优化业务运营。
有人可能会有疑惑：数据中台和业务中台的建设是否有先后顺序？
笔者以为，这两者的建设没有先后之分，主要依据企业的实际情况进行规划。
从数据层面看，业务中台只是数据中台的数据源之一，除此之外，企业还有很多其他的数据来源，如App、小程序、IoT等多源数据，可以将这些数据的价值直接赋能于现有业务或某个创新业务。
从服务层面看，数据中台的数据服务也不一定经过业务中台作用于业务，它还可能直接被上层应用系统进行调用和封装，如电商领域的“千人千面”系统。
而从业务中台的角度来看，如果没有数据中台，也可以做一些简单的数据处理，如简单的分析和统计等，但是涉及较复杂的分析、数据的挖掘等则难以实现。而通过数据中台对业务中台的赋能，则可以使业务中台拥有全维度、智能化的数据应用能力。譬如业务的推荐、圈人、风控、预警等能力。有了这些能力，业务系统将从信息化业务系统升级成智能化的业务系统。
不止有业务中台，目前各种中台层出不穷，但笔者认为中台不是平台，平台可以有很多，包括营销平台、风控平台、管理平台等，但是一个企业只需要一个中台。现在还有业务中台、数据中台之分，我们预测未来数据与业务会更紧密地结合，完全融为一体，会统一成“企业中台”。
建设中台是为了资源的共享利用，建设数据中台是为了数据资源更充分的共享利用，建设业务中台是为了业务资源更充分的共享利用。所以不管建立哪种中台，都要考虑是否有需要共享的资源，如果没有可共享的资源或者资源的共享度不高，建设中台就很难达到预期的效果。
企业要建立业务中台，要考虑是不是多业务单元经营模式，并且这些业务单元是否有比较高的相似度，这样才有业务资源共享的可能。如果是单一的简单业务模式，则谈不上共享业务资源；如果多个业务间差异比较大，也无法共享业务资源。不需要共享或者无法共享，建立业务中台就没有意义。拿中台的提出者阿里巴巴举例子，阿里巴巴电商系有淘宝、天猫、聚划算、闲鱼、饿了么、飞猪等业务，这些业务各有特色，但是相似度很高，都需要管理卖家、买家、商品、订单、物流等，通过建立业务中台提供统一共享的卖家、买家、商品、订单、物流等服务，各业务单元利用业务中台提供的公共服务再结合自己业务单元的个性需求做一些定制，可以快速支撑业务所需，适应市场的快速变化。比如阿里巴巴可以利用这些共享的业务服务能力，快速组装出淘宝特卖这样的新的业务应用。但是绝大部分企业并不像阿里巴巴这样有多个相似度很高的业务单元，它们要么业务单一，要么多个业务板块之间差异巨大，这样就很难找到可共享的业务单元，很难发挥中台的价值。笔者见过一家企业想建业务中台，但因为多个业务单元之间的业务差异太大，业务共享程度不高，就把一个业务中心拆成多个业务中心去满足不同的业务需要，越拆越多，后来拆成数百个业务中心，管理起来非常复杂，已经失去建立业务中台的意义。
经过多年信息化的发展，很多企业积累了足够多的数据，利用好这些数据，让数据在多个业务环节共享，对于这些企业来说都是必要的。所以笔者认为，数据中台是每家有信息化基础的企业都要考虑建设的，而业务中台的建设则要根据企业的业务情况慎重决策。
数据仓库的主要应用场景是支持管理决策和业务分析，而数据中台则是将数据服务化之后提供给业务系统，目标是将数据能力渗透到各个业务环节，包含但不限于决策分析类场景。数据中台持续不断地将数据资产化、价值化并应用到业务，而且关注数据价值的运营。
数据中台建设包含数据体系建设，也就是说数据中台包含数据仓库的完整内容。数据中台将企业数据仓库建设的投入进行价值最大化，以加快数据赋能业务的速度，为业务提供更快速、更多样的数据服务。数据中台也可以将已建好的数据仓库当成数据源，对接已有数据建设成果，避免重复建设。当然也可以基于数据中台提供的能力，通过汇聚、加工、治理各类数据源，构建全新的离线或实时数据仓库。
另外，数据中台一般采用全新的数据技术架构，可以更方便地进行数据价值的挖掘。随着企业的数据量越来越大，智能化场景越来越多，传统架构的存储计算能力无法满足这类数据业务的需求。而机器学习、深度学习等技术不断发展，从看似无用的数据中挖掘出新价值的能力越来越强，新的技术架构为这些场景的建设提供了很好的能力支撑。
BI（Business Intelligence，商业智能）是将企业现有的数据进行有效整合，面向业务经营提供快速、准确的决策依据。BI通常依赖处理好的结构化数据，以报表或者大屏等可视化方式提供给决策者。BI一般在数据仓库的技术层，面向不同的业务分析决策提供支持以及可视展现。当企业业务相对简单，涉及的系统相对较少时，可以在建设数据仓库或者数据中台之前，利用BI做业务的决策支持。但当企业的业务复杂度提升，系统繁多，BI难以对接多种复杂系统、复杂的异构数据时，就要考虑用数据中台或者数据仓库配合BI系统。有了数据中台，BI可以作为数据中台应用的一种出口，数据中台的数据体系中的应用数据层可以对接BI系统，面向不同的业务需要提供决策支持和展示。这样BI可以作为数据中台体系的一部分，用于决策分析可视的应用。
数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。它按原样存储数据，而无须事先对数据进行结构化处理。数据湖可以存储结构化数据（如关系型数据库中的表）、半结构化数据（如CSV、日志、XML、JSON）、非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）等。
数据湖最初的目的是存储多种格式的数据。因为数据的价值难以在短期内挖掘，但是数据所包含的信息又可能在未来的某一时刻极其重要，所以为了把当前阶段难以挖掘的数据保存下来，以便在未来随时使用，人们提出了数据湖的概念。也就是说，利用相对廉价的存储方式，把企业尽可能多的数据存入数据湖，再在适当的时间点根据需要从数据湖中提取出需要处理的数据进行加工。
但是随着数据湖概念和技术的发展，数据湖已经不只是个数据存储池，而逐步融入了数据集成、数据处理、数据管理、数据挖掘、数据分析等一系列技术架构，与数据中台的定义越来越接近。总体上看，国外更多人提数据湖，而国内提数据中台的比较多。笔者认为，数据湖可以与数据中台结合，数据中台是个更大范围的体系，数据中台的目标是管控好整个企业或者组织的数据，让数据尽可能服务于业务，提供价值。而数据湖可以作为数据中台的全量数据汇集存储的环境，数据湖的数据最终还是要通过治理和挖掘服务于业务，采集、存储、管理、挖掘、使用这些功能组件可以与数据中台融为一体。数据湖就是企业的全量数据资源池，通过数据中台这套体系来管理，通过数据中台的数据服务能力让数据更充分地利用起来。
数据编织（Data Fabric）是最近数据技术领域一个比较火热的词，业界对于数据编织有多种理解，并没有统一、标准的定义。综合业界的多个定义来看，数据编织是一种设计理念，通过一套数据架构思想，统一管理并链接所有数据源，利用知识图谱和AI能力面向不同的数据使用场景提供准确、方便的数据访问，从而更高效、更大限度地发挥数据价值。
数据编织旨在解决大数据时代海量数据以及多云的复杂架构导致的数据孤岛加剧、数据集成成本高、数据使用难的问题。有了数据编织这套设计理念，企业可以在不迁移数据的情况下，方便地了解自有的数据资源，并根据业务需要快速访问所需数据。数据编织融入了知识图谱和AI能力，能够将合适的数据在合适的时间传送给合适的使用者。基于以上分析，数据编织应包含以下几方面的能力。
❑异构数据源连接能力：能够连接多个系统多种异构数据源的数据，包括各种业务系统、数据仓库、数据湖、文档系统等。
❑智能数据编目能力：对连接的数据源进行自动识别并获取元数据，获取元数据的同时识别数据的消费行为，对数据和数据消费行为自动编目，形成企业数据知识网。
❑数据连接能力：能够在不同的数据之间建立连接，简化数据访问模式。
❑语义理解能力：理解数据的业务含义，面向不同的使用者有针对性地进行语义表达。
❑智能建模能力：面向不同的使用场景，具备自动的智能建模能力，帮助用户获取场景化的数据服务能力。
可以看出，数据编织是一种数据技术的设计思想，强调智能化的能力。而数据中台是一套让数据用起来的机制，不仅包含数据技术，还包含企业战略、组织文化、运营机制等多个方面，目的是通过一整套机制的配合让数据在企业业务中被持续用起来。数据中台和数据编织不是非此即彼的关系，两者可以相互配合。数据中台可以借鉴数据编织的设计理念，数据编织可以借鉴数据中台的运转机制。
如何唤醒沉睡的数据资产，把数据真正用起来，以支持自身业务的智能化升级，是摆在所有传统企业面前的数字化转型难题。因此，对于是否有必要建设数据中台这件事情，似乎并无太多质疑之声，但真要建设数据中台，尤其是落实到具体建设的实操阶段，企业又开始担心，它们最担心的莫过于建设数据中台是不是要将企业的现有信息架构推倒重来。
在整个信息化的过程中，随着企业的业务发展和战略调整，为了更好地适应和支撑业务发展，企业的信息化系统常有推倒重建的情况。伴随着一批又一批数据人员的成长和离开、行业专家和业务人员的晋升或转型以及技术的演进等，数据仓库也有推倒重来的案例。有了这些经历，新的技术方案的提出会不会推倒原有的系统，是不是又要适应新系统，成为大家的顾虑。
数据中台作为解决企业级数据应用难题的新方案，不是一套软件系统，也不是一个标准化产品。站在企业的角度，数据中台更多地指向企业的业务场景，即帮助企业沉淀能力，提升业务效率，最终完成数字化转型。因此，数据中台与企业的现有信息架构不存在竞争关系，不会导致企业现有系统、功能和应用的重复建设。
举个简单的例子，笔者此前与一家做轮胎制造的上市企业进行过交流，它当时用了很多个业务系统，比如OA系统、ERP系统、工艺设计与管理系统、物流系统、生产系统等。该企业的一个核心痛点是：无法准确地知道当前的轮胎能否准时或者提前交付。制造型企业一般处于产业链的中间位置，非终端或者源头端，比如这家轮胎制造企业，它的上游是橡胶提供方，下游是汽车组装商或者汽车零部件厂商。轮胎的及时交付就意味着企业的生命线——稳定的现金流有了保障。而影响轮胎及时交付的数据变量，比如物流的及时性、对生产过程的控制力、是否有重大的经济压力、甲方工艺设计需求的变化等，散落在所有系统中。
在有数据中台之前，该企业是怎么做的呢？它需要首先拉出所有系统数据库中的表，然后用Excel做对应关系，整个过程是非常琐碎且耗时的。如果有数据中台体系，可以通过中台机制汇聚相关系统中的原始数据，并且面向轮胎这一企业经营的实体构建一系列场景化的标签特征。同时，通过离线或者实时的数据交互模式，不断更新特征值，将业务场景所关注的数据的价值直接展现出来。
从上面的例子可以看出，数据中台在定位上与业务IT系统并不冲突。企业原有的IT系统依旧会根据业务和IT技术的迭代不断升级，依旧会为企业的生产运营或者经营管理提供支撑。数据中台的定位则是在数据领域帮助企业不断沉淀数据能力。两者之间是相互依托、相互赋能、相互促进的关系。数据中台需要IT系统不断提供数据，而IT系统未来更加需要横向、综合的数据特征来支撑。只有形成了数据中台和IT系统良好的配合关系，才能更好地构建企业整体的IT支撑能力。
在后续的章节中，读者会看到一个完整的数据运营闭环。在这个运营闭环中，既有IT系统需要承载的职能，也有数据中台的使命。两者如何在技术上进行集成，后续也会具体讲解。