数据中台这个概念在最近几年相当的火，传统的做MDM主数据，大数据，包括BI类厂商都转向做数据中台解决方案。不论是以上哪种思路，传统的类似MDM主数据平台建设都可以很好地解决上面的问题。按照新的中台思路，没有一个独立的MDM系统。
今天整理和分享下近期进行数据中台需求交流和售前解决方案制作过程中的一些思考总结，对于主数据平台，数据中台，大数据平台等在我头条前面的文章中都有专门的论述，因此这篇文章不会再去详细讲解这部分的内容。
数据中台这个概念在最近几年相当的火，传统的做MDM主数据，大数据，包括BI类厂商都转向做数据中台解决方案。特别是很多人将企业的数字化转型简单地理解为数据化，过分夸大数据驱动和数据的价值，这也间接导致了数据中台比业务中台得到更大的推广和建设。
这篇文章不去谈论数据中台本身的对或错，而是真正从最近一段时间和客户交流过程中，涉及到数据中台建设的需求沟通和方案建设的一些思考和总结。
主数据平台还是数据中台大家都清楚，传统的IT系统建设模式最大的问题就是导致了各个业务系统垂直隔离，数据无法共享和协同，包括同一个基础数据多个系统共同建设和管理引起的数据不一致等问题。
在和客户沟通中，客户刚开始的需求很简单，即要构建一个统一的基础数据，包括共享的动态数据的统一数据视图，解决当前的数据多点建设，多点录入，数据不一致等诸多问题。
举个简单的例子，比如一个房地产类企业，下面是餐饮，文旅，物业诸多的子公司，但是当客户面对这些子公司的时候都需要新注册会员和用户，导致客户重复注册，对于子公司之间同样这些新无法互联互通，物业公司的会员信息也无法共享给餐饮子公司使用。
当你面对这个问题的时候有两个思路。
第一个思路就是各个业务系统都不要再管理客户或会员信息，企业单独建设一个统一的CRM或会员管理系统来进行管理，然后再讲会员信息开放给各个业务系统使用。
第二个思路是将各个业务系统管理的会员信息进行采集和整合，在整合过程中进行数据质量检查，包括规范性检查和去重等，形成一个完整的客户统一视图再提供给上层业务系统或分析决策类系统使用。
不论是以上哪种思路，传统的类似MDM主数据平台建设都可以很好地解决上面的问题。第一种思路对应到集中化建设思路，第二种对应到共享化建设思路。
在和客户的沟通中，发现客户并不想去构建一个独立的MDM主数据平台，按传统IT架构进行集成，而是希望构建数据中台来解决上面这个问题。在和客户的需求和方案讨论中，逐步梳理清楚以下两个关键原因。
首先整个客户的IT系统都在规划考虑逐步数字化和微服化转型，因此不太希望还安装建设MDM系统，通过ESB传统集成方式来解决当前问题。
其次是客户期望的目标不仅仅是底层数据整合和统一数据视图提供业务使用，同时也希望整合后的数据，比如统一客户视图，能够提供给上层大数据分析使用，比如常说的客户行为分析，客户大数据画像等。
也就是说客户也不是盲目地上数据中台，而是有自己的考虑，前期也对数据中台做给相关的学习和研究。
没有业务中台能否先上数据中台？在阿里最早提起数据中台的概念的时候，整体中台架构里面包括了业务中台和数据中台，也就是常说的双中台架构。
业务中台一般来讲会采用微服务架构进行单体拆分，形成类似用户中心，订单中心，库存中心，支付中心等各个微服务能力中心。而数据中台则是一方面采集业务数据中台的数据进行整合，形成数据服务后又反哺业务系统使用。
也就是常说的业务能力数据化，数据能力业务化。
在前面很多中台的文章里面已经谈到，传统企业IT架构要进行微服务化转型，包括从传统架构转变为类似业务中台这种架构，整体改造和迁移的难度都相当大，用伤筋动骨来形容也不过分。
那么能否在没有形成业务中台的情况下，或者说在企业IT仍然是传统IT业务系统支撑的情况下来构建数据中台？
这个是在规划建设数据中台的时候必须要回答的问题。在这里先给出下结论就是：
企业完全可以在业务系统仍然是传统IT架构的情况下优先构建数据中台，而不是等业务中台建设完成后再构建数据中台。企业业务中台的建设可以逐步演进，但是数据中台的建设可以一开始就按目标架构规划，逐步实施。
最近几年可以看到，将传统IT架构完全推翻，一开始就去规划构建大而全的业务中台，去构建全业务能力中心的很多项目大部分都是失败的。这也导致很多企业认为中台就是一个忽悠人的概念并怨声载道。对于其它的一些一开始没有实施全面的中台化，反而是业务和问题驱动，先去规划建设数据中台的项目，反而是取得了不小的实施收益和效果。
所以企业在进行内部IT系统规划和建设的时候，一定要考虑到遗留系统的资产如何保留，如何逐步迁移，如何分步骤实施减少推动阻力等诸多问题。太理想化的东西带来的一定就是落地实施困难，这个道理大家要清楚。
客户为何不构建一个类似业务中台中的客户中心微服务？
在前面已经谈到为了对客户信息进行统一，在主数据中也存在集中化建设模式，即将原来业务系统中管理客户的功能全部封闭，而是将其移动到主数据平台统一管理，包括客户的申请，创建，变更，废弃，数据分发，对外能力开放等都集中化到MDM系统中进行管理。
按照新的中台思路，没有一个独立的MDM系统。
那么能否构建一个客户中心独立的微服务，来将各个业务系统中对客户管理的功能移出，全部放到客户中心进行管理，再对外提供服务能力？在和客户的沟通中，客户也想过这个方案，最终通过讨论后将这个方案彻底否决，其原因主要包括以下三个点。
第一是集中建设客户中心不是简单地构建一个系统，而是涉及到原有的组织架构的调整，这个组织架构，职责调整还涉及到子公司，可想而知难度多大。
第二是集中建设不同于简单地抽取数据共享，集中建设后一定涉及到已有的各个子公司业务系统已有功能的变更和改造，这个推广实施难度同样很大。
第三是原有子公司自己构建业务系统，数据都在自己掌控，现在集团想构建集中化系统将数据拿走，子公司仅只有数据的使用权，这个事情你认为有无难度？简单来说，你要多给些我需要的数据给我使用，那么我愿意。但是你要把我的数据拿走，没那么简单。
综合以上几点，可以看到任何新系统建设，都不是技术层面的问题，而是管理和业务层面的问题。单纯从技术驱动思维去考虑系统建设，一般都死得很惨。
从主数据，大数据平台到数据中台在建设和实施数据中台的时候，对于数据中台，主数据，大数据平台三者之间的关系必须要搞清楚。在前面已经解释了为何是实时数据中台而不是建设主数据平台。
数据中台承担传统主数据平台的功能
主数据平台的建设一般包括了集中化建设和共享化建设两种模式，对于共享化建设则是基础主数据原有的创建，申请，变更等流程还是在业务系统里面无变化，MDM系统仅仅是抽取数据进行清洗和整合，形成统一数据视图再提供服务。
当建设数据中台的时候，完全可以完全替代主数据平台中的共享化建设模式，即重点是实现数据的采集，集成，整合，清洗，数据服务能力开放。而对于数据创建变更等内容管理仍然放在各个业务系统里面。
那么数据中台在进行数据采集整合过程中如果发现了数据质量问题如何处理？
简单来说，这些数据不一致，数据不完整等问题，数据中台仅仅是发现问题，而对于问题本身的修复仍然要回到源头的业务系统进行。
大数据平台是数据中台演进的关键
大数据平台是一个技术平台。这个技术平台提供了对于大数据的分布式采集，存储，流处理和计算，实时分析等能力。在没有大数据平台前也有数据集成和管理的平台，这种平台可以实现对结构化数据本身的采集，集成和管理。
而对于数据中台，一般底层都需要一个提供数据存储和处理能力支撑的技术平台。这个技术平台如果你有大数据需求，构建出来的就是大数据平台。但是如果你没有大数据需求，那么用传统的数据集成和管理技术平台即可。
其次，数据中台的范畴包括了如下几个方面
- 一套底层的数据技术平台（可以是大数据平台，也可以是数据集成平台）
- 一套数据资产（业务层面的内容，实际数据，数据模型，算法都装进来了）
- 一套数据服务能力提供和共享
- 一套数据管控和治理标准规范体系
因此可以看到对于数据中台核心重要的反而是数据资产 数据服务能力共享这两点,而这两点在一般的大数据平台并不会包含。如果整个数据中台建设有大数据平台，那么大数据平台也仅仅是一个底层技术平台和技术实现手段。具体两者的差异点我们再通过图来对比下。
基于客户前面的需求，可以看到。
规划建设数据中台不是马上就需要进行大数据分析，客户画像等，而是优先解决统一客户数据视图，提供数据服务能力给业务系统使用，即数据反哺业务。
当数据中台建设采用了大数据平台这个技术底座后，那么这个技术选型具备了支撑后续大数据分析类应用场景的可能。即使当前不会用到大数据平台中的各种技术，但是平台建设需要考虑后续这些技术的引入没有侵入性，也不会影响到已有的功能。
为啥不是建设大数据平台？
前面也分析了，短期目标实际是数据服务能力开放，为业务系统提供实时数据服务能力接口。数据中台架构里面有一个重要的数据服务能力开放层，这个在传统的大数据平台里面是没有的，这也是构建数据中台的一个差异点。
从技术框架到内容建设的迭代演进不要以为数据中台就是几百万上千万的大工程，数据中台建设一样需要基于垂直场景逐步落地实施，要有逐步演进实施和持续迭代的规划建设思路。
对于客户来讲想的也是先做一个小预算投入，先进行试错，如果实施效果好再大面积建设和推广，因此在规划建设数据中台的时候需要这个点也考虑进去。
对于数据中台的建设一般包括了三方面内容。
- 底层大数据技术平台搭建
- 相关数据资产建设和内容服务提供
- 数据管控治理标准规范
对于技术平台搭建，管控治理规范建设两项内容一般在第一期项目建设和实施中就必须完成。技术平台建设需要考虑整个技术架构，各种开源工具和技术的选型，本身的高可用性和可扩展性，这个不能出现大的选择错误，否则后续可能导致整个底层技术支撑推倒重来。
对于数据治理同样的道理，里面涉及到元数据管理，数据质量管理，数据标准规范体系，数据安全管理，数据能力开放诸多的内容都需要指定相应的管理流程，标准规范体系。这个是实施各类数据主题域，数据资产管理的集成。
这两部分内容无法迭代，在第一期就需要规划建设好。而对于数据内容和数据资产管理则完成可以根据垂直业务场景，客户迫切需要解决的问题来规划建设。
比如这个客户，前期目标很明确，就是需要首先解决当前客户和用户信息不统一，构建客户统一视图的问题。那么第一期实施重点围绕客户主题域进行即可。
从中台技术或功能架构到实施方法在前面更多谈的都是数据中台整体的功能架构或技术架构，但是数据中台类项目不是你卖一个标准化的数据中台产品，更多的反而是你如何进行数据资产和数据内容管理。
或者讲搭建平台只是第一步，更加重要的是如何进行实施？
比如前面提到客户一个核心目标是构建客户统一视图，远期目标是构建大数据客户画像和标签体系，那么在准备售前方案的时候就需要去详细回答这个问题。
对这个问题的回答最终应该体现在整体的实施方法论上面。还是以上面这个问题出发，要构建客户统一视图，简单来讲至少应该包括如下关键阶段或步骤。
- 客户数据管理现状调研和梳理
- 数据采集和集成=>数据贴源层
- 数据清洗
- 数据模型建立，数据整合
- 数据资产和数据内容管理
- 数据服务能力开放
简单来说就是你需要详细地说明清楚如何构建客户统一视图，里面包括了哪些关键步骤，每个关键步骤涉及到哪些方法，哪些工具技术。不要讲太多技术层面的内容，但是整个方法流程必须要讲清楚。
要讲大数据用户画像和标签构建，那么就需要将整体标签构建方法涉及到的关键步骤说明清楚。比如上图，标签体系建设包括了标签定义，标签申请，标签建立，标签展示，标签维护等多个步骤和环节，这个关键方法需要讲清楚。
对于数据中台建设项目。
技术平台是骨，而具体构建的内容资产和服务体系才是血和肉，没有血和肉的数据中台是没有灵魂的，也无法解决客户真正的业务问题。
讲述整体实施方法和内容的核心就是要说明清楚数据中台建设不是单纯地给企业搭建一个大数据技术平台，而是真正基于业务问题和目标驱动，将数据资产和数据内容装进来，形成能够为业务系统服务的数据服务能力，这才是数据中台建设的价值。
业务目标->产品->实施->管控治理在我原来整理主数据平台建设方案的时候，给出了完整的方法论，如上图分为主数据现状分析，业务解决方案，信息系统建设，实施方案几个大的阶段。回到数据中台，基于客户的需求和目标如何准备方案。
简单来说可以分为四个大的章节来准备。
1.现状分析和目标提出
整个方案首先还是得对当前数据管理和使用现状进行分析，基于当前存在的一些问题给出最终的项目建设目标和范围，这个是标准套路。
基于前面的梳理，客户对于数据中台建设项目可以分为几个关键的子目标，即搭建一个技术平台，构建一套数据治理规范体系，同时基于客户域进行数据资产和内容管理，这个本身又可以展开为统一客户数据视图和服务提供，客户大数据分析和画像两个层面。
2.数据中台整个架构介绍
对于第二部分还是需要介绍清楚数据中台整体架构框架，注意这里不是单纯的技术架构，还需要介绍清楚技术架构上层的数据建模，数据资产和内容管理，数据服务能力开放等。
也就是说数据中台架构本身是分层的，需要说明清楚整体分层逻辑。
3.数据中台实施方法论和实施策略
注意这里不是简单的讲解标准的实施方法论，基于客户的需求和目标，最好是在这部分详细说明清楚基于数据中台当前产品的功能架构和组件，如何基于客户业务系统和数据现状，来完成统一的客户统一视图沟通，数据服务能力的开放，如何实现客户信息的大数据画像。
什么意思？
前面数据中台架构是一种静态架构，现在基于客户提出的需求和目标，你需要去回答如何基于你已有的功能架构组件，工具和技术，来一步步完成最终客户的业务目标。
即真正回答清楚数据中台中的内容和资产是如何一步步建设出来的。
4.数据管控治理体系
这部分是必须交待的内容，即不仅仅是帮客户构建一个平台，完成了一个数据资产或内容的建设，更加重要的是帮助客户建立一天覆盖数据全生命周期的管控治理规范体系，这才是真正的知识转移和资产沉淀。
数据管控治理刚好体现了自身多年经验积累，最佳实践的沉淀。
5.项目管理范畴
当然，还可以对项目管理范畴内容进一步细化。包括对整个项目工作量和费用的预估，项目执行周期的预估，是否需要分迭代版本的规划，具体项目参与人员，项目组织架构，项目交付物清单等的说明。
