数据中台最核心的就是data API，它提供一个一个的可以复用的标准，这种数据服务给到业务系统。构建数据中台和构建数据平台也有很大的区别，构建数据中台一定是业务价值出发，而且数据中台一定不是一个单体的产品，数据中台里面的组件是有的是可以产品化的，比如数据存储，比如说你的数据分析工具，比如说你的数据探索的工具，你是可以有产品去组合的。但是数据中台一定不是一个产品，每个企业的数据中台会依赖于他企业的业务模式，他企业的信息化水平，他企业的投资预算，依赖于很多他的个体化，个性化的因素，所以数据中台对于不同的企业来讲，它一定是一个定制化的系统，因为它跟业务息息相关。数据中台的架构一定不是一个固定的，它一定是眼镜式架构，比如我们现在在有一个客户那里，一个做全球润滑油的零售客户，我们跟他们合作已经两年多了，将近三年了，他们最早的时候还没有数据中台的概念，但是从他们最早的时候，由于在中国没有it，所以他们最早的预算非常低，非常小。但是在那样的情况下，可能也就很少的预算，我们也能构建一个数据中台的雏形，然后一点一点地快速地为他们的业务产生价值，并且持续的演进到现在他们已经有了自己真正的数据中台，做的是比较完善的了。
第三，数据中台的建设一定要有战略耐心，这里的战略耐心我们把它叫做两个耐心。一个是投资方要有战略耐性，不是说我给你钱，给你1000万，你赶紧给我买个数据平台回来，然后买完了以后赶紧要产生业务价值，往往这样的项目，我们认为数据中台的构建一定要是平台就是数据的部分，技术的部分和业务的部分要同时前进。但是它一定会有一定的过程，有一定的过程，你的
数据价值的探索，到你的数据价值变成一个数据产品的设计，然后变成一个可用的软件上线，这是一个需要时间的，所以我们认为投资方要有战略耐心。要认识到从数据到业务价值是有一个过程的。那么建设方也要有耐心，建设方不能好高骛远，一上来就做一个庞大的能力，然后在上面再生长，因为变化太快，技术更新太快，业务变化太快。所以我们所讲的数据中台的构建方式一定是敏捷的，然后是不断的迭代。
坦率来讲，这两年我们一直在思考
数据治理是不是个伪命题？是因为在五年以前，十年以前，我在做传统的数据，做了很多数据治理项目，那样的数据治理项目在他看来很多是不成功的。之前我们所讲的成功是项目系统验收了叫成功，但是现在我们理解成功指的是它对企业的业务带来价值。
我们回想起来，过去的数据治理的项目，会产生三大类的服务，第一类，一堆流程，一堆标准，这是第一类，就是一堆文档。第二类，产生一堆岗位，就是会有很多的人，原来做业务的，做技术的，现在专门出来给它个名词叫数据管理员，或者给它个名词叫数据管理委员会，或者是物料审批员，像这样的名词会产生一堆岗位。第三类，会产生一堆系统，
元数据管理系统，但是数据治理的项目都往往做起来都很庞大，因为我们希望就从根本上解决企业级
数据质量的问题。但是现在我们回过头来看，我们觉得这种方式不一定是最有效的，而且很多时候当你把这些标准做出来，把系统做出来，实际上当时认为你可以解决的这些问题的这些数据已经发生了变化。
刻舟求剑是一个很好的名词来形容这个数据类项目数据治理的特点，因为数据在企业里面它是流动的，像河水一样，永远是在流动的，而且我们企业追求的是什么？就是数据的流动速度。我的数据流动越快，我产生的数据越多，我对用户的维度越细分，我的企业的经营就越有活力，我在市场上就越具有竞争力。但是你流动的越快，你很难保证。因为它一定会有你想不到的东西，你的系统响应力一定没那么快。这种情况下，我们希望现在用做一个
数据标准做一个数据模型，然后做一个数据治理，然后就好像是说在河水上加标准化的检测站一样，这是做不到的，所以我们现在所讲的治理，把它叫精益数据治理，在业务层面跟业务一起去治理数据，而且我们追求的不是说一定要把数据质量设计到好多完美，做不到，这是不可行的，达不到的。
我们的目标是哪怕我的数据只有50%的准确性，那么在我提高数据质量同时，我也希望这50%准确的数据也能为我产生业务价值。这句话是我们现在正在尝试的，也是用来做的。
（部分内容来源网络，如有侵权请联系删除）
