最近数据字典这个词经常跳出来，挑动着笔者的神经，搞了很多年的取数，报表、经分直至大数据，每每都会搞数据字典，但每每都难说成功，我们的数据字典都经历了三生三世啊，为什么还未成功？
第一代数据字典
首先，其往往零碎的散落在每个开发人员的设计文档中，或者长眠在文档服务器中，鲜有人去动它，找到一个简单的字段解释很艰难。
其次，很多系统的数据字典是缺失的，只能找开发人员咨询，因此，无论是报表或取数人员，得跟开发人员混熟，以下是当初为了找各类系统的数据表解释编制的对应开发人员列表。
最后，有时候找到的数据字典其实也没什么卵用，解释太单薄，就是个英文字段的翻译好吗，信息量不大。
但无论如何，还是解决了部分有无的问题，虽然质量堪忧。
第二代数据字典
首先，我们有了体系化的概念，梳理出了多级目录，给出了每个实体的更多解释，比如备注了枚举值。
其次，我们在线化了数据字典，让每个人都可以访问到它，建立了数据字典更新的流程，让里面的内容随着变化及时更新。
再次，我们规范了数据开发过程，实现了可视化，数据字典从传统的后向方式改成了前向，这算是巨大的进步。
最后，我们已经创造了活的数据字典，实现了数据字典的血缘分析、影响分析，还有很多其它辅助功能。
看似做了很多，但貌似又落后了，大数据时代到来，数据逐渐成为一种资产，这二代的数据字典在资产管理上显然是力不从心了，即离技术太近，离客户太远。
离技术太近，是笔者感觉企业的大多数数据字典其实都在为技术人员服务，而技术人员恰恰是最不需要的，当然你可以说传承知识的需要，但实践告诉我们，口口相传并不比这个效率低。
离客户太远，是我们的数据从来没有以资产的身份出现在我们的客户面向，告诉它这个资产有多大的价值，值不值得投资和买单，我们的数据字典太不业务化了，等到大数据变现的时候，有多少企业能拿给客户一份看得懂的数据资产清单？
这也是文章开头笔者烦恼的原因，突然发现努力了半天打造的大数据字典呈现给我们客户的却是一堆噪声，虽然我们也提供了查询的能力，但如果输入“客户”关键词，数据字典竟呈现上百个与”客户”相关的数据表，解释是如此生硬，让人望洋兴叹，太多的选择实际就是无法选择。
回归数据管理的本源，笔者曾经提出过四个核心问题，不能沉溺于数据管理术的追求，还应该抬起头，看看如何上道，解决最核心的问题。
客户对数据的理解和使用是否更容易了？
为我们的客户提供准确的价值信息和极高的使用体验。
开发人员效率是否真得高了？
开发时长（如表逻辑设计）降低了多少时长。
运维人员核查问题是否真的快了？
采用信息化手段降低了多少核查时长。
系统的数据冗余度是否下降了？
公司在数据相关扩容上降低了多少投入。
不能简单的将数据字典当成一个工具，我们不仅要建设它，而且要运营它，让其发挥出应有的业务价值。
第三代数据字典
笔者建议打造第三代数据字典，虽然不知道具体的第三代数据字典长啥样，但建设好它起码有以下三个要求：
首先，数据字典要为业务服务，要服务好最终客户，这个最终客户可能是分析师，建模师或合作伙伴，但不要总围着开发和维护人员转，反倒误入歧途，这条当然是有争议的，但笔者仅是为了说明，从实用主义的角度看，数据字典在技术层面的帮助并不那么明显。
其次，数据字典需要产品化思维，为其设立独立的产品经理并不为过，其需要的是内容、体验和迭代，而不是简单的功能，项目化方式打造的数据字典很难成功。
最后，评估数据字典好坏的始终是流量和客户的认可，让数据字典成为每个客户的案头书，就是目标，但很遗憾，大多数企业的数据字典做不到这一点，我们已经为数据字典付出了很多，但回报不多，值得反思。
因此，我们又启程了，以下是最近的思考，考虑到公司的数据资产成千上万，围绕大数据变现，我们挑选了100张最重要的表，从业务的角度尝试重新去诠释它。
我们希望未来客户翻看我们企业的数据字典，是如此的赏心悦目，明白这个资产到底于他有多大的价值，也许他看到的数据分类描述是这样的：
然后他翻到了这些数据的价值案例，既然数据是资产，讲清楚用途是必须的，以下只是形式上的示意。
在大数据时代，如果真的把数据当成资产，似乎要转换一些思维方式和管理模式了，元数据概念之初就有技术和业务之分，我们似乎更热衷于技术上的数据管理追求，对于诸如元数据产品的厂家来说的确变了现，功能也越来越丰富，但我们的前端真得要变现的时候，却发现业务元数据这个东西对于客户来说没有什么价值，而且，它还不能像技术元数据那样依赖外力，从内容到体验，哪个不需要自己搞定？
一入大数据深似海啊，数据字典的成长就是客户化的过程，我们从关注技术逐步回归到价值本身，就像经历了三生三世，希望有个叫好又叫座的结局。
最近数据字典这个词经常跳出来，挑动着笔者的神经，搞了很多年的取数，报表、经分直至大数据，每每都会搞数据字典，但每每都难说成功，我们的数据字典都经历了三生三世啊，为什么还未成功？
第一代数据字典
首先，其往往零碎的散落在每个开发人员的设计文档中，或者长眠在文档服务器中，鲜有人去动它，找到一个简单的字段解释很艰难。
其次，很多系统的数据字典是缺失的，只能找开发人员咨询，因此，无论是报表或取数人员，得跟开发人员混熟，以下是当初为了找各类系统的数据表解释编制的对应开发人员列表。
最后，有时候找到的数据字典其实也没什么卵用，解释太单薄，就是个英文字段的翻译好吗，信息量不大。
但无论如何，还是解决了部分有无的问题，虽然质量堪忧。
第二代数据字典
首先，我们有了体系化的概念，梳理出了多级目录，给出了每个实体的更多解释，比如备注了枚举值。
其次，我们在线化了数据字典，让每个人都可以访问到它，建立了数据字典更新的流程，让里面的内容随着变化及时更新。
再次，我们规范了数据开发过程，实现了可视化，数据字典从传统的后向方式改成了前向，这算是巨大的进步。
最后，我们已经创造了活的数据字典，实现了数据字典的血缘分析、影响分析，还有很多其它辅助功能。
看似做了很多，但貌似又落后了，大数据时代到来，数据逐渐成为一种资产，这二代的数据字典在资产管理上显然是力不从心了，即离技术太近，离客户太远。
离技术太近，是笔者感觉企业的大多数数据字典其实都在为技术人员服务，而技术人员恰恰是最不需要的，当然你可以说传承知识的需要，但实践告诉我们，口口相传并不比这个效率低。
离客户太远，是我们的数据从来没有以资产的身份出现在我们的客户面向，告诉它这个资产有多大的价值，值不值得投资和买单，我们的数据字典太不业务化了，等到大数据变现的时候，有多少企业能拿给客户一份看得懂的数据资产清单？
这也是文章开头笔者烦恼的原因，突然发现努力了半天打造的大数据字典呈现给我们客户的却是一堆噪声，虽然我们也提供了查询的能力，但如果输入“客户”关键词，数据字典竟呈现上百个与”客户”相关的数据表，解释是如此生硬，让人望洋兴叹，太多的选择实际就是无法选择。
回归数据管理的本源，笔者曾经提出过四个核心问题，不能沉溺于数据管理术的追求，还应该抬起头，看看如何上道，解决最核心的问题。
客户对数据的理解和使用是否更容易了？
为我们的客户提供准确的价值信息和极高的使用体验。
开发人员效率是否真得高了？
开发时长（如表逻辑设计）降低了多少时长。
运维人员核查问题是否真的快了？
采用信息化手段降低了多少核查时长。
系统的数据冗余度是否下降了？
公司在数据相关扩容上降低了多少投入。
不能简单的将数据字典当成一个工具，我们不仅要建设它，而且要运营它，让其发挥出应有的业务价值。
第三代数据字典
笔者建议打造第三代数据字典，虽然不知道具体的第三代数据字典长啥样，但建设好它起码有以下三个要求：
首先，数据字典要为业务服务，要服务好最终客户，这个最终客户可能是分析师，建模师或合作伙伴，但不要总围着开发和维护人员转，反倒误入歧途，这条当然是有争议的，但笔者仅是为了说明，从实用主义的角度看，数据字典在技术层面的帮助并不那么明显。
其次，数据字典需要产品化思维，为其设立独立的产品经理并不为过，其需要的是内容、体验和迭代，而不是简单的功能，项目化方式打造的数据字典很难成功。
最后，评估数据字典好坏的始终是流量和客户的认可，让数据字典成为每个客户的案头书，就是目标，但很遗憾，大多数企业的数据字典做不到这一点，我们已经为数据字典付出了很多，但回报不多，值得反思。
因此，我们又启程了，以下是最近的思考，考虑到公司的数据资产成千上万，围绕大数据变现，我们挑选了100张最重要的表，从业务的角度尝试重新去诠释它。
我们希望未来客户翻看我们企业的数据字典，是如此的赏心悦目，明白这个资产到底于他有多大的价值，也许他看到的数据分类描述是这样的：
然后他翻到了这些数据的价值案例，既然数据是资产，讲清楚用途是必须的，以下只是形式上的示意。
在大数据时代，如果真的把数据当成资产，似乎要转换一些思维方式和管理模式了，元数据概念之初就有技术和业务之分，我们似乎更热衷于技术上的数据管理追求，对于诸如元数据产品的厂家来说的确变了现，功能也越来越丰富，但我们的前端真得要变现的时候，却发现业务元数据这个东西对于客户来说没有什么价值，而且，它还不能像技术元数据那样依赖外力，从内容到体验，哪个不需要自己搞定？
一入大数据深似海啊，数据字典的成长就是客户化的过程，我们从关注技术逐步回归到价值本身，就像经历了三生三世，希望有个叫好又叫座的结局。
