轉:數據字典的三生三世

最近數據字典這個詞常常跳出來，挑動着筆者的神經，搞了不少年的取數，報表、經分直至大數據，往往都會搞數據字典，但往往都難說成功，咱們的數據字典都經歷了三生三世啊，爲何還未成功？

第一代數據字典

 

首先，其每每零碎的散落在每一個開發人員的設計文檔中，或者長眠在文檔服務器中，鮮有人去動它，找到一個簡單的字段解釋很艱難。

其次，不少系統的數據字典是缺失的，只能找開發人員諮詢，所以，不管是報表或取數人員，得跟開發人員混熟，如下是當初爲了找各種系統的數據表解釋編制的對應開發人員列表。

最後，有時候找到的數據字典其實也沒什麼卵用，解釋太單薄，就是個英文字段的翻譯好嗎，信息量不大。

但不管如何，仍是解決了部分有無的問題，雖然質量堪憂。

第二代數據字典

 

首先，咱們有了體系化的概念，梳理出了多級目錄，給出了每一個實體的更多解釋，好比備註了枚舉值。

其次，咱們在線化了數據字典，讓每一個人均可以訪問到它，創建了數據字典更新的流程，讓裏面的內容隨着變化及時更新。

再次，咱們規範了數據開發過程，實現了可視化，數據字典從傳統的後向方式改爲了前向，這算是巨大的進步。

最後，咱們已經創造了活的數據字典，實現了數據字典的血緣分析、影響分析，還有不少其它輔助功能。

看似作了不少，但貌似又落後了，大數據時代到來，數據逐漸成爲一種資產，這二代的數據字典在資產管理上顯然是力不從心了，即離技術太近，離客戶太遠。

離技術太近，是筆者感受企業的大多數數據字典其實都在爲技術人員服務，而技術人員偏偏是最不須要的，固然你能夠說傳承知識的須要，但實踐告訴咱們，口口相傳並不比這個效率低。

離客戶太遠，是咱們的數據歷來沒有以資產的身份出如今咱們的客戶面向，告訴它這個資產有多大的價值，值不值得投資和買單，咱們的數據字典太不業務化了，等到大數據變現的時候，有多少企業能拿給客戶一份看得懂的數據資產清單？

這也是文章開頭筆者煩惱的緣由，忽然發現努力了半天打造的大數據字典呈現給咱們客戶的倒是一堆噪聲，雖然咱們也提供了查詢的能力，但若是輸入「客戶」關鍵詞，數據字典竟呈現上百個與」客戶」相關的數據表，解釋是如今生硬，讓人望洋興嘆，太多的選擇實際就是沒法選擇。

迴歸數據管理的本源，筆者曾經提出過四個核心問題，不能沉溺於數據管理術的追求，還應該擡起頭，看看如何上道，解決最核心的問題。

客戶對數據的理解和使用是否更容易了？

爲咱們的客戶提供準確的價值信息和極高的使用體驗。

開發人員效率是否真得高了？

開發時長（如表邏輯設計）下降了多少時長。

運維人員覈查問題是否真的快了？

採用信息化手段下降了多少覈查時長。

系統的數據冗餘度是否降低了？

公司在數據相關擴容上下降了多少投入。

不能簡單的將數據字典當成一個工具，咱們不只要建設它，並且要運營它，讓其發揮出應有的業務價值。

第三代數據字典

 

筆者建議打造第三代數據字典，雖然不知道具體的第三代數據字典長啥樣，但建設好它起碼有如下三個要求：

首先，數據字典要爲業務服務，要服務好最終客戶，這個最終客戶多是分析師，建模師或合做夥伴，但不要總圍着開發和維護人員轉，反倒誤入歧途，這條固然是有爭議的，但筆者僅是爲了說明，從實用主義的角度看，數據字典在技術層面的幫助並不那麼明顯。

其次，數據字典須要產品化思惟，爲其設立獨立的產品經理並不爲過，其須要的是內容、體驗和迭代，而不是簡單的功能，項目化方式打造的數據字典很難成功。

最後，評估數據字典好壞的始終是流量和客戶的承認，讓數據字典成爲每一個客戶的案頭書，就是目標，但很遺憾，大多數企業的數據字典作不到這一點，咱們已經爲數據字典付出了不少，但回報很少，值得反思。

所以，咱們又啓程了，如下是最近的思考，考慮到公司的數據資產成千上萬，圍繞大數據變現，咱們挑選了100張最重要的表，從業務的角度嘗試從新去詮釋它。

咱們但願將來客戶翻看咱們企業的數據字典，是如此的賞心悅目，明白這個資產到底於他有多大的價值，也許他看到的數據分類描述是這樣的：

而後他翻到了這些數據的價值案例，既然數據是資產，講清楚用途是必須的，如下只是形式上的示意。

在大數據時代，若是真的把數據當成資產，彷佛要轉換一些思惟方式和管理模式了，元數據概念之初就有技術和業務之分，咱們彷佛更熱衷於技術上的數據管理追求，對於諸如元數據產品的廠家來講的確變了現，功能也愈來愈豐富，但咱們的前端真得要變現的時候，卻發現業務元數據這個東西對於客戶來講沒有什麼價值，並且，它還不能像技術元數據那樣依賴外力，從內容到體驗，哪一個不須要本身搞定？

一入大數據深似海啊，數據字典的成長就是客戶化的過程，咱們從關注技術逐步迴歸到價值自己，就像經歷了三生三世，但願有個叫好又叫座的結局。

 

最近數據字典這個詞常常跳出來，挑動着筆者的神經，搞了不少年的取數，報表、經分直至大數據，往往都會搞數據字典，但往往都難說成功，咱們的數據字典都經歷了三生三世啊，爲何還未成功？

第一代數據字典

 

首先，其每每零碎的散落在每一個開發人員的設計文檔中，或者長眠在文檔服務器中，鮮有人去動它，找到一個簡單的字段解釋很艱難。

其次，不少系統的數據字典是缺失的，只能找開發人員諮詢，所以，不管是報表或取數人員，得跟開發人員混熟，如下是當初爲了找各種系統的數據表解釋編制的對應開發人員列表。

最後，有時候找到的數據字典其實也沒什麼卵用，解釋太單薄，就是個英文字段的翻譯好嗎，信息量不大。

但不管如何，仍是解決了部分有無的問題，雖然質量堪憂。

第二代數據字典

 

首先，咱們有了體系化的概念，梳理出了多級目錄，給出了每一個實體的更多解釋，好比備註了枚舉值。

其次，咱們在線化了數據字典，讓每一個人均可以訪問到它，創建了數據字典更新的流程，讓裏面的內容隨着變化及時更新。

再次，咱們規範了數據開發過程，實現了可視化，數據字典從傳統的後向方式改爲了前向，這算是巨大的進步。

最後，咱們已經創造了活的數據字典，實現了數據字典的血緣分析、影響分析，還有不少其它輔助功能。

看似作了不少，但貌似又落後了，大數據時代到來，數據逐漸成爲一種資產，這二代的數據字典在資產管理上顯然是力不從心了，即離技術太近，離客戶太遠。

離技術太近，是筆者感受企業的大多數數據字典其實都在爲技術人員服務，而技術人員偏偏是最不須要的，固然你能夠說傳承知識的須要，但實踐告訴咱們，口口相傳並不比這個效率低。

離客戶太遠，是咱們的數據歷來沒有以資產的身份出如今咱們的客戶面向，告訴它這個資產有多大的價值，值不值得投資和買單，咱們的數據字典太不業務化了，等到大數據變現的時候，有多少企業能拿給客戶一份看得懂的數據資產清單？

這也是文章開頭筆者煩惱的緣由，忽然發現努力了半天打造的大數據字典呈現給咱們客戶的倒是一堆噪聲，雖然咱們也提供了查詢的能力，但若是輸入「客戶」關鍵詞，數據字典竟呈現上百個與」客戶」相關的數據表，解釋是如今生硬，讓人望洋興嘆，太多的選擇實際就是沒法選擇。

迴歸數據管理的本源，筆者曾經提出過四個核心問題，不能沉溺於數據管理術的追求，還應該擡起頭，看看如何上道，解決最核心的問題。

客戶對數據的理解和使用是否更容易了？

爲咱們的客戶提供準確的價值信息和極高的使用體驗。

開發人員效率是否真得高了？

開發時長（如表邏輯設計）下降了多少時長。

運維人員覈查問題是否真的快了？

採用信息化手段下降了多少覈查時長。

系統的數據冗餘度是否降低了？

公司在數據相關擴容上下降了多少投入。

不能簡單的將數據字典當成一個工具，咱們不只要建設它，並且要運營它，讓其發揮出應有的業務價值。

第三代數據字典

 

筆者建議打造第三代數據字典，雖然不知道具體的第三代數據字典長啥樣，但建設好它起碼有如下三個要求：

首先，數據字典要爲業務服務，要服務好最終客戶，這個最終客戶多是分析師，建模師或合做夥伴，但不要總圍着開發和維護人員轉，反倒誤入歧途，這條固然是有爭議的，但筆者僅是爲了說明，從實用主義的角度看，數據字典在技術層面的幫助並不那麼明顯。

其次，數據字典須要產品化思惟，爲其設立獨立的產品經理並不爲過，其須要的是內容、體驗和迭代，而不是簡單的功能，項目化方式打造的數據字典很難成功。

最後，評估數據字典好壞的始終是流量和客戶的承認，讓數據字典成爲每一個客戶的案頭書，就是目標，但很遺憾，大多數企業的數據字典作不到這一點，咱們已經爲數據字典付出了不少，但回報很少，值得反思。

所以，咱們又啓程了，如下是最近的思考，考慮到公司的數據資產成千上萬，圍繞大數據變現，咱們挑選了100張最重要的表，從業務的角度嘗試從新去詮釋它。

咱們但願將來客戶翻看咱們企業的數據字典，是如此的賞心悅目，明白這個資產到底於他有多大的價值，也許他看到的數據分類描述是這樣的：

而後他翻到了這些數據的價值案例，既然數據是資產，講清楚用途是必須的，如下只是形式上的示意。

在大數據時代，若是真的把數據當成資產，彷佛要轉換一些思惟方式和管理模式了，元數據概念之初就有技術和業務之分，咱們彷佛更熱衷於技術上的數據管理追求，對於諸如元數據產品的廠家來講的確變了現，功能也愈來愈豐富，但咱們的前端真得要變現的時候，卻發現業務元數據這個東西對於客戶來講沒有什麼價值，並且，它還不能像技術元數據那樣依賴外力，從內容到體驗，哪一個不須要本身搞定？

一入大數據深似海啊，數據字典的成長就是客戶化的過程，咱們從關注技術逐步迴歸到價值自己，就像經歷了三生三世，但願有個叫好又叫座的結局。