1、主數據管理(MDM)的成熟度根據主數據管理實施的復雜程度，參照Jill Dyche, Evan Levy 的觀點大體可以把主數據管理可以分為五個層次，從低到高反映了主 數據管理(MDM)的不同成熟度。下面我們簡單介紹一下這五個層次：Level 0 :沒有實施任何主數據管理(MDM)在Level 0的情況下，意味著企業(yè)的各個應用之間沒有任何的數 據共享，整個企業(yè)沒有數據定義元素存在。比如，一個公司銷售很多 產品，對這些產品的生產和銷售由多個獨立的系統來處理，各個系統 獨立處理產品數據并擁有自己獨立的產品列表，各個系統之間不共享 產品數據。在Level 0，每個獨立的應用負責管理和維護自己的關 鍵

2、數據(比如產品列表、客戶信息等)，各個系統間不共享這些信息， 這些數據是不連通的。Level 1 :提供列表不管公司大還是小，列表管理是我們常用的一種方式。在公司內 部，會通過手工的方式維護一個邏輯或物理的列表。當各個異構的系 統和用戶需要某些數據的時候，就可以索取該列表了。對于這個列表 的維護，包括數據添加、刪除、更新以及沖突處理，都是由各個部門 的工作人員通過一系列的討論和會議進行處理的。業(yè)務規(guī)則 (Business Rules)是用來反映價值的一致性，當業(yè)務規(guī)則發(fā)生改變或 者出現類似的情況時，這樣高度手工管理的流程容易發(fā)生錯誤。由于 列表管理是通過手工管理的，其列表維護的質量取決于誰參加

3、了變更 管理流程，一旦某人缺席，將會影響列表的維護。MDM Level 1比MDM Level 0的不同就是，各個部門雖然還是獨 立維護各自的關鍵數據，但會通過列表管理維護一個松散的主數據列 表，能夠向其他各個部門提供其需要的數據。在MDM Level 1中，數 據變更決定以及數據變更操作都是由人來決定的，因此，只有人完成 數據變更決定后才會變更數據。在實際情況中，雖然數據變更流程有 嚴格的規(guī)定，但是由于缺乏集中的、基于規(guī)則的數據管理，當數據量 比較大時，數據維護的成本會變的很高，效率也會很低。當主數據， 比如客戶信息、產品目錄信息等數量比較少時，列表管理的方式是可 行的，但是當產品目錄或客戶

4、列表出現爆炸式增長以后，列表管理的 變更流程將變得困難起來。MDM Level 1依賴于人的協作。如果產品 經理需要更新過后的產品價格列表，那需要聯系ERP系統所有者，讓 其發(fā)送郵件給她。在企業(yè)范圍內實現客戶或產品列表就如同維護不同 部門之間人們的關系一樣。如果客戶或產品存在層次或分組，列表將 很難提供，并且通常在Level 1因為過于復雜難以被管理。Level 2 :同等訪問(通過接口的方式，各個系統與主數據主機 之間直接互聯)MDM Level 2與MDM Level 1相比，引入了對主數據的(自動)管 理。通過建立數據標準，定義對存儲在中央知識庫(Central Repository)中

5、詳細數據的訪問和共享，為各個系統間共享使用數據 提供了嚴密的支持。中央知識庫(Central Repository)通常會被稱為“主數據主機(Master Data Host)”。這個知識庫可以是一個數據庫 或者一個應用系統，通過在線的方式支持數據的訪問和共享。創(chuàng)建、讀取、更新和刪除(CRUD)是處理基本功能的典型編程術 語。即便在MDM中，CRUD處理也是基本功能。你的數據庫如果僅僅 支持CRUD處理并不意味著你實現了 MDM。MDM Level 2引入了 “同 等訪問”(peer-based access)，也就是說一個應用可以調用另一個 應用來更新或刷新需要的數據。當CRUD處理規(guī)則定義

6、完成后，MDM Level 2需要客戶或“同等”應用格式化請求(和數據)，以便和MDM 知識庫保持一致。MDM知識庫提供集中的數據存儲和供應 (provisioning)。在這個階段，規(guī)則管理、數據質量和變更管理必須 在企業(yè)范圍內作為附加功能定制構建。比如，一個數據庫或一個打包應用(比如一個銷售自動化系統) 對外部應用提供數據訪問功能。當一個外部應用(比如呼叫中心應用) 需要增加一個客戶，這個外部應用將提交一個事務，請求數據所有者 增加一個客戶條目。主數據主機(Master Data Host)將增加數據并告 知外部應用。CRUD處理方式比紙上辦公有了很大提高，其是基于會 話的數據管理。在MD

7、M Level 1,數據變更是基于手工的方式。在MDM Level 2,數據變更是自動完成的一通過由具體技術實現的標準流 程，允許多應用系統修改數據。MDM Level 2可以支持不同的應用使 用和變更單一、共享的數據知識庫。MDM Level 2需要每個同等應用 理解基本的業(yè)務規(guī)則以便訪問主列表、與主列表進行交互。因此，每 個同等應用必須正確恰當地創(chuàng)建、增加、更新和刪除數據。授權應用 有責任堅持數據管理原則和約束。Level 3 :集中總線處理與MDM Level 2相比，MDM Level 3打破了各個獨立應用的組織 邊界，使用各個系統都能接受的數據標準統一建立和維護主數據(MDM Lev

8、el 2的主數據主機上存儲的數據還是按照各個系統分開存儲的， 沒有真正的整合在一起)。集中處理意味著為MDM構建了一個通用的、基于目標構建的平 臺。大多數公司發(fā)現MDM正在挑戰(zhàn)他們現有的IT架構：他們擁有太 多的獨立平臺處理主數據。MDM Level 3集中數據訪問、控制跨不 同應用和系統使用數據。這極大的降低了應用數據訪問的復雜性，大 大簡化了面向數據規(guī)則的管理，使MDM比一個分散環(huán)境具有更多的功 能和特點。企業(yè)主數據面臨一致性的挑戰(zhàn)。數據在不同的地方存在， 數據所代表的含義也是不同的，數據的規(guī)則各個系統之間也是不一樣 的。集中MDM處理-通過一個公共的平臺作為一個總線(HUB)-說明一 個

9、共識，從多個系統整合主題域數據，意味著使用集中、標準化的方 法轉換異構操作數據，不管其在源系統中是什么樣子，都會被整合起 來。在MDM Level 3,公司對主題域內容采用集中管理方式。這意味 著應用系統，作為消費者或使用主數據，擁有一個共識就是數據是主 題數據內容的映像，打破了各個獨立應用的組織邊界。MDM Level 3 支持分布主參考數據的存在。MDM的核心之一就是保證所有系統都能接受數據表示的唯一公認 方法。這有點類似于語言翻譯，通過其他語言的翻譯，英語已經稱為 一個全球性的語言。在MDM Level 3，個公司可以讓任意兩個系統 共享數據和說對方的語言。MDM Level 3還降低了

10、等同訪問的復雜性。 消費應用不再需要支持系統定位和操作邏輯。任何與源系統數據相 關的分布式細節(jié)都會被MDM總線集中處理。在MDM Level 3自動數據 標準意味著：建立目標數據值表示和通過必要的步驟提供精確的主數 據值捕獲。在所有的分類中從MDM Level 3開始第一次支持一致性的 企業(yè)數據視圖。數據質量規(guī)則在這里進行數據清洗和錯誤糾正。Level 4 :業(yè)務規(guī)則和政策支持一旦數據從多個數據源整合在一起，主題域視圖超越單獨的應用 并表現為一個企業(yè)視圖，你將獲得事實的單一版本。當事實的單一版 本已經能夠提供出來時，來自業(yè)務主管和執(zhí)行人員的必然反應經常 是：“證明它”。MDM Level 4可

11、以保證主數據反映一個公司業(yè)務規(guī) 則和流程，并證實其正確性。MDM Level 4通過引入主數據來支持規(guī) 則，并對MDM總線以及其它外部系統進行完整性檢查。由于多數公司 相對比較復雜，影響業(yè)務數據訪問和操作的規(guī)則以及策略(rules and policies )相對也比較復雜。假定任何一個單一系統可以包含并 管理與主參考數據相關的各種類型的規(guī)則是不切實際的。因此，如果 一個MDM總線真正打算提供企業(yè)范圍內數據的精確性，工作流和流程 整合的支持是必不可少的。舉例來說,在一個HMO內，需要多個應用來支持一個病人的護理。 一個單一的訪問（visit）可能包括入院、房間和床位分配、監(jiān)控設備、 化驗、身體

12、檢查以及其他程序等。一旦一個病人準備離開醫(yī)院，出院 流程需要確保和這個病人相關的所有活動、資源都被結清MDM技術 在召集多個應用系統一起保證病人辨識方面是十分有效的，處理是正 確的。雖然病人辨識很重要，業(yè)務規(guī)則整合同樣重要。臨床系統依靠 一系列的業(yè)務流程和數據規(guī)則來辨別所有顯著的病人詳細資料。這包 括返回所有基于房間的資源（監(jiān)護設備、床位等）以得到有用的詳細目 錄，當病人要出院時分解其所有的費用。MDM保證當John Smith出 院時，正確的房間和設備放入到該John Smith的詳細目錄中，而不 是其他的John Smith（正在另一個樓層做身體治療）。MDM系統必須不僅支持基于規(guī)則的整合

13、，還要能夠整合外部的工 作流。這些規(guī)則可能包括通過總線與臨床系統交互或等待另一個系統 或者人（有權限做出改變的人）審批。通過一個MDM總線，規(guī)則定義可 以不僅局限在邏輯上，還可以依賴于其他系統的輸入。當然，協調和 審計數據意味著可以回退其他系統（或業(yè)務流程）來保證數據變化經 過嚴格的審批，這樣錯誤可以被發(fā)現并且事務在需要的時候可以被回 滾。MDM Level 4提出對規(guī)則和策略擴展性的支持。通過總線以一 個靈活可持續(xù)的方式支持任何面向業(yè)務的規(guī)則集合這很重要。比如，如果一個商店經理更新一個產品的價格，總線系統需要能 夠和一個可信系統（比如，商品管理系統）進行協商以便使規(guī)則生效。 詳細規(guī)則將支持另

14、一個系統中存在產品價格的變更一總線需要能夠 理解能夠處理和批準變更的權限系統或方法。這些規(guī)則可能涉及到復 雜性或隱私限制，禁止它們直接在總線上存在。在MDM Level 4，一 個企業(yè)可以支持一套步驟或任務，在一個特殊的創(chuàng)建、讀取、更新和 刪除任務被允許之前這些步驟或任務必須遵守。工作流自動化經常用 來支持發(fā)生在總線上的事件或活動的授權。但是變更管理遠遠不僅僅 是工作流：它可以包括基于邏輯的流程和基于人的決策。變更管理的 存在可以支持動態(tài)業(yè)務，允許變更。舉例說明，在911之前，任何 人都可以在美國國內的航空公司運載貨物。沒有規(guī)定以外的其他某種 形式的鑒定和付款方式。911之后，美國聯邦航空協會

15、（FAA）指導建 立了一個更加全面的規(guī)定，指示一個人是否被允許運載貨物。在這個 特殊的例子中，要求各個系統都部署FAA對托運人的要求是不現實 的。部署一個規(guī)則管理系統，為所有的系統（包括MDM總線）集中托運 人批準規(guī)則，更加容易實現（也更現實）。集中數據定義和標準化在 MDM Level 2就已經引入，與MDM Level 4的集中規(guī)則管理相比，相 對簡單。業(yè)務流程越復雜、業(yè)務流程越多，對總線的需求就越多，以 便對針對共同數據的跨職能、異構規(guī)則進行更好的支持。重要的是 MDM Level 4支持集中規(guī)則管理，但是規(guī)則本身和相關的處理是可以 分開的。換句話說，MDM總線需要保證規(guī)則是集中應用的，

16、即便這個 規(guī)則是在總線外居住的。Level 5 :企業(yè)數據集中在MDM Level 5，總線和相關的主數據被集成到獨立的應用中。主數據和應用數據之間沒有明顯的分隔。他們是一體的。當主數據記 錄詳細資料被修改后，所有應用的相關數據元素都將被更新。這意味 著所有的消費應用和源系統訪問的是相同的數據實例。這本質上是一 個閉環(huán)的MDM：所有的應用系統通過統一管理的主數據集成在一起。 在這個級別，所有在系統看起來都是事實的同一個版本。操作應用系 統和MDM內容是同步的，所以當變更發(fā)生時，操作應用系統都將更新。 在那些熟悉的MDM架構風格中，持久總線架構，當一個總線更新所有 的操作應用系統將體現這種變更，

17、形成改變的直接操作視圖。在注冊 環(huán)境中，當數據數據更新時，總線將通過Web服務連接相關系統應用 事務更新。因此，MDM Level 5提供一個集成的，同步的架構，當一 個有權限的系統更新一個數據值時，公司內所有的系統將反映這個變 更。系統更新完數據值后不要單選其他系統中相應值的更新：MDM將 使這種更新變的透明。從MDM Level 4到MDM Level 5意味著MDM功能性不是在一個應 用內被特殊設計或編碼的。這還意味著主數據傳播和供應不需要源系 統專門的開發(fā)或支持。所有的應用清楚的知道他們并不擁有或控制主 數據。他們僅僅使用數據來支持他們自己的功能和流程。由于MDM總 線和支持的IT基礎架構，所有的應