一、背景

數據治理項目通常伴隨著監管壓力、高成本和不明確的投資回報。識別關鍵數據、管理元數據、控制數據質量和確定數據來源的程序通常耗時較長且成本高昂。比如銀行業的相關年度成本很容易超過每年 1000 萬元，有時甚至超過 1 億元。執行過程既痛苦又緩慢，因為需要在數百個系統和應用程序中手動識別數千個數據元素，而這些系統和應用程序通常是在過去幾十年創建的。

也許其中最難以捉摸的是數據沿襲。一些供應商已經設法創建可以掃描系統和收集元數據的工具，但它們通常無法連接到大多數現有系統環境。由于數據流通常沒有在整個企業中進行結構性和一致的記錄，因此主要依靠供應商知識和手動映射工作來編譯它們。當供應商紛紛離開時，這種知識就會離開企業，情況也會變得更加嚴重。

此外，即使業務和技術元數據已被記錄為協調補救計劃的一部分，但由于元數據捕獲和記錄不是自動化的，大多數元數據很快就會過時。保持其最新需要持續的手動工作。

最后，組織將這些元數據共享到企業的業務部門，以實現除數據治理本身之外的業務目的。許多大型組織都有數據戰略，以某種形式闡明數據管理基礎也應該為數據科學等業務目的提供支持，但很少有人在實踐中成功實現這一點。

基于云的技術的出現帶來了可擴展性、彈性、更低的成本、快速部署和增強的數據技術兼容性的承諾。在過去幾年中，我們與各種組織就其云遷移和數據現代化計劃進行了合作，從設計的那一刻起就出現了如何智能管理數據的模式。

例如，可以為 API 定義互操作標準，以便未來數據沿襲可視化中的日志記錄和治理實現自動化。數據質量控制可以基于一致的數據模型創建并直接嵌入到新的基礎設施中。轉換期間存在的知識不會丟失或降級，因為有關數據元素及其來源的關鍵信息會輕松記錄在數據目錄中。

接下來將進一步詳細闡述數據治理設計的概念，并解釋如何通過數據資產、數據管理中心和 API 驅動架構等功能（通過稱為 Data Fabric 的數據層）實現數據治理。

二、框架

在基于服務的架構中，微服務連接組織的業務流程。在這樣的架構中，四個基礎組件可以共同實現數據管理和數據治理的設計。下面提供了一個示例：描述了一個擁有 5 個部門（風險與合規、財務、營銷、客戶管理和產品開發）的組織。每個部門創建并維護多個數據產品，其中一部分被歸類為“數據資產”，因為其他部門的消費者也使用它們。不同部門之間，各種API交換數據和信息。所有這一切都是根據數據基礎結構精心策劃的，并由數據管理中心掃描并提供數據管理和服務。讓我們快速瀏覽一下這些組件。

數據資產——每個域或部門通常都會生成供其他域使用的數據或信息。例如，客戶管理域可以通過入職和客戶關系管理流程收集客戶數據，以生成和維護包含客戶信息的中央數據庫。營銷團隊可以使用該數據庫來執行銷售活動，風險部門可以使用該數據庫來確認是否遵守數據隱私法規。此類數據產品被賦予了不同的標簽，其中包括數據產品、數據資產、可信來源、權威數據源和記錄系統。

API 驅動的架構——不同的團隊通過 API 作為首選或唯一的數據集成方法進行連接。保持 API 優先的理念可確保組織內部和外部的消費者都可以使用任何關鍵數據。

數據管理中心——在單獨配置的空間或環境中提供一組數據管理功能。這些功能包括元數據管理、主數據和參考數據管理以及數據質量。不必在組織的每個區域內構建這些功能，而是可以從中央數據管理進行部署。

Data Fabric— 提供跨所有系統和應用程序連接的線程稱為 Data Fabric。它不是一個可以憑空實例化的魔法層；相反，它由一組支持功能和經過仔細考慮的治理協議組成，這些協議共同使整個企業的數據可發現、編目、分類、標記、質量控制，并可通過通用的互操作性標準和渠道進行訪問。

采用數據資產理念管理

什么是數據資產

數據資產是一組準備好的數據（一般不是原始數據），可供更廣泛的消費者使用。它受到管理、貼上標簽、質量受控且易于訪問。它是可發現和描述的，以便為整個企業的消費者啟用自助服務。數據資產通常在整個企業中重復使用，并在給定的數據或業務域內擁有。

為什么被高度關注

鑒于數據資產被大量消費者使用，因此這是實施數據質量和治理控制的非常合乎邏輯的位置。在該受管資產中，內容被標記，數據質量受到嚴格控制，因此不必在整個企業中識別和測量這些數據，這通常會導致不一致的“事實版本”，而是有一個可信的分發點給定的數據集。例如，美國十大銀行已經啟動了一些計劃來識別這些關鍵數據源并對其進行管理。通常，大約 20 到 100 個數據資產將使組織能夠控制其所有關鍵數據，這比嘗試在 1000 個單獨系統中定義數據質量要有效得多。

數據資產采用

創建和定義數據資產還不夠。一個必要且同樣重要的步驟是管理它們的使用，因為如果消費者不使用它們，他們就無法從集中控制的數據質量中受益。因此，許多組織已經啟動了各種版本的數據資產采用計劃。通常，一方面包括共享流通，加強培育對數據資產及其使用好處的認識，另一方面包括合規標準和機制，要求只能從數據資產而不是任何地方使用別的數據。

業務用戶和影響

對于數據組織來說，除了難以衡量的價值（例如避免監管罰款）之外，闡明它們為企業增加的價值一直是一場歷史性的斗爭。數據資產在這里改變了游戲規則。僅當存在下游關鍵消耗時，數據源才能成為數據資產，因此建議記錄這些消費者及其用例。

構建數據資產和依賴于它們的用例的簡單概述可以清楚地闡明這些資產產生的影響。通過收集數據的下游需求并評估如何在受信任的分發點內控制和增強數據，也可以更有效地執行影響評估。例如，一家領先的保險公司能夠相對精確地衡量一組增強的客戶數據如何使他們能夠更輕松地執行和提高銷售活動的有效性。

如果沒有數據資產的識別和主動管理，結果通常是難以理解的數據流“蜘蛛網”，存在數據重復和不一致的情況。戰略性地使用數據資產，可以識別使用獨特的可重復使用的精選的數據源用例組。

三、數據資產治理

需要一個治理模型來將數據資產嵌入到 Data Fabric 中，以確保它不會被“壞”數據淹沒，其中“數據網格”是如何將此治理嵌入到組織中的主要方法。

數據網格

一個相對較新的術語是“數據網格”，它是一種使業務領域能夠在捕獲和維護數據的點管理其關鍵數據的方法，并由中央自助服務數據支持基礎設施。這與過去的努力形成鮮明對比，過去的組織試圖將其關鍵數據集中在數據湖和數據倉庫中。這種集中化工作通常會受到對中央數據團隊的過度期望的困擾，這些團隊沒有特定于業務的上下文來理解數據，因此無法跟上消費者所需的步伐。“臟”數據湖是一種常見癥狀。

治理模式

某些業務或功能域可能已準備好立即管理其關鍵數據資產，但其他域可能還沒有。以銀行業為例，通常相對成熟的領域包括風險和金融，因為它們在遵守監管數據治理準則方面擁有多年的經驗。

允許域所有者生成數據資產供其他人使用有幾個要求。首先，支持領域必須在數據管理和工程方面具備最低水平的所需技能和經驗。其次，域所有者必須在團隊內部或外部擁有所需的資源，或委派部分職責的預算。維護數據資產通常不是一項全職工作，但同時它確實意味著重大責任。

基于這些考慮，企業可以選擇適合的治理模式，每種治理模式都有各自的優點和缺點。組織可以先選擇一種模式，但隨著時間的推移，可以發展到另一種模式。

治理建議

以下建議可以標準化任何模式的實施并降低其風險：

• 將數據資產的概念嵌入到企業變革方法中
• 制定并遵守一系列設計原則，其中包括數據資產的治理
• 堅持數據資產必須直接源自經確認的權威來源的設計原則
• 定義具有清晰描述的領域的權威企業數據模型
• 維護數據資產的中央目錄
• 堅持使用最少的所需元數據集，包括分類和其他與安全相關的元數據，以實現基于角色的訪問
• 定義并執行可發現性和互操作標準

四、API 驅動的架構和互操作性標準

采用 API 優先的理念以及明確定義的互操作性標準是確保未來數據流的治理和控制以及驅動自動數據沿襲捕獲、避免未來大量手動映射工作的關鍵。

API驅動架構

在 API 優先的基礎架構中，不同的團隊通過 API 作為首選或唯一的數據集成方法進行連接。保持 API 優先的理念可確保組織內部和外部的消費者都可以使用任何關鍵數據。如果做得正確，還應該推動對開放銀行標準等全球標準的遵守，從而為與戰略合作伙伴合作提供機會。

互操作標準

互操作標準由一組規則和協議組成，用于驅動不同系統和應用程序之間的交互和數據交換。如果我們用電來類比，您可以購買任何類型的電器，從冰箱到電燈或手機充電器，并且通常期望您可以將其連接到家中的插座。數據也類似——希望確保數據通過標準插座以商定的質量和數量提供，這些插座可供任何有權訪問房屋內不同房間的人使用。對于企業來說，就需要就接口類型以及向其提供數據的渠道達成一致。

沒有一套互操作標準適合每個組織，但有幾個維度或組件至關重要：

• 遵守數據模型以確保數據的使用和解釋的一致性，至少對于最小的一組關鍵數據而言如此
• 標準消息傳遞和有效負載格式
• 與系統和應用程序一起以標準化格式識別、維護和提供的最低業務和技術元數據
• 一組已確定的兼容技術

互操作工具集

擁有一套一致的互操作標準應該推動任何類型的兼容技術能夠與基礎設施交換數據。出于采用目的，建議確定至少 1 種也可能是幾種數據工程師可用于各自目的的 API 技術。

選擇哪種技術取決于組織、目標業務成果以及現有的技術堆棧和相應的專業知識。比如，一家區域零售組織決定采用 MuleSoft 作為其數字組織構建的首選 API 平臺，而一家大型領先制造商則選擇創建自己的內部構建的 API 功能。

通過 API 實現數據沿襲工業化

對于組織而言，存在巨大的機會來確保通過采用 API 優先的思維方式將數據管理納入未來基礎設施的設計中：

1. 可以定義 API 模式來滿足未來對數據和信息流的需求。示例模式包括異步、同步、編排和數據處理以及事件驅動模式。
2. 在各種模式中，對齊與 API 一起提供的元數據腳本或文件。這些腳本應該標準化，并包含最少的業務和技術元數據集，例如源、目的地、提要頻率、包含的關鍵數據元素以及一系列指標（例如分類、PII 指標）。最佳實踐是，每次更新 API 時，這些元數據文件都會更新（如果可能，自動更新），并在 API 目錄中維護。
3. 確保將 API 元數據文件推送或拉入元數據管理中。工具到位特別是數據目錄，以便可以創建譜系圖。

將驅動 API 作為系統間數據交換的主要手段與堅持最低標準相結合，推動“數據沿襲設計”。

注意：不要使元數據文件過于復雜。較小的關鍵元數據集優于業務價值不明確的詳盡集。除了例外之外，默認情況下不需要包含詳細的數據元素級采購和轉換邏輯。

五、數據管理中心

與實施后手動執行的治理活動相比，集中配置但本地采用的數據管理功能以更低的成本增強了數據的一致定義、治理和保護。

數據管理中心的重要性

為了通過設計推動數據管理，創建并提供一個單獨配置的管理中心并使其包含最低限度所需的數據功能至關重要。管理中心包含數據管理，應作為未來任何云原生業務或功能流程構建的一部分來引用和嵌入的功能。他們應該能夠從數據中自助服務這些功能，而不是讓每個轉換計劃或業務功能區域在如何確保正確使用主數據、管理元數據和監控數據質量方面重新構建功能和標準。

數據管理需要設計

歷史上，絕大多數傳統數據管理投資都是在“事后”（即實施后）花費的。發現業務流程，識別數據元素，推斷業務需求，并根據現有基礎設施實施來衡量數據質量，這需要大量的人工工作和持續的紀律。

在這里的方法中，這些數據管理注意事項嵌入在設計和實施階段之前和期間。此外，稍后手動執行的治理步驟將作為功能、非功能和技術需求集成為設計的一部分。隨著解決方案的實施，數據管理是“按設計”構建的。

“設計”功能示例

數據目錄 -正如上面針對 API 所概述的，但應用更廣泛，就應用程序及其之間的數據流而言的系統全面的發現、文檔和可視化可以自動化。

數據質量——監控和確保數據質量和完整性的控制可以通過兩種主要方式嵌入。首先，可以在數據創建、捕獲和傳輸時應用特定的控制和限制。比如對接受或有效值的限制以及數據流中的協調檢查。其次，在數據資產等戰略位置，可以對靜態數據實施質量控制，以衡量完整性、準確性和及時性。

主數據和參考數據——數據資產的非常具體的示例，主數據和參考數據是非常強大的杠桿，可以推動在事務級別重復使用的數據的一致使用。比如MDM以確保在整個企業中，在入職、交易、客戶聯系、營銷和關系管理等流程中使用正確的客戶數據元素。同樣，提供易于訪問的參考數據（例如郵政地址標準）將推動其采用。

六、Data Fabric 作為系統之間的云原生粘合劑

提供跨所有系統和應用程序連接的線程稱為數據結構。它不是一個可以憑空實例化的魔法層；相反，它由一組支持功能和經過仔細考慮的治理協議組成，這些協議共同使整個企業的信息可發現、編目、分類、標記、質量控制，并可通過通用的互操作性標準和渠道進行訪問。

在很大程度上，該結構是由前面描述的數據資產、API 和數據管理中心組件啟用的。如果正確并充分地使用，它們應該形成數據結構的主要架構。但是，即使不是最低要求，也有一些互補的數據功能：

數據管道、攝取、準備、傳輸、供應和存儲——在 API 無法完成工作的情況下，替代或補充的數據交付和集成選項可以確保根據業務或業務來收集、攝取、轉換、管理和提供數據。功能要求。需要配置存儲來保存數據。

數據編排——根據目標用例和業務流程，可以應用數據編排來從各種來源獲取數據，組合和集成數據，并將其提供給數據分析工具。數據編排可以在 IaaS 或 PaaS 級別執行，也可以使用抽象基礎設施級別活動的技術（例如 Apache Airflow、Prefect 和 Snowflake）來執行。

數據安全和保護——監控和確保敏感數據不丟失、不被濫用或被未經授權的用戶訪問的過程，并啟用主動保護數據資產的功能。政策和標準應規定如何保護數據以及如何共享數據。身份和訪問管理 (IAM) 可以促進基于角色的訪問，各種網絡和身份驗證保護措施可以保護數據免遭未經授權的訪問和操縱。

報告、分析和數據科學——可以創建一個或多個數據平臺來滿足報告或分析用例。具有數據資產、API 和數據管理。數據管理中心到位后，這將成為一項簡單的工作，因為數據可用、易于理解且易于獲取，并且在云原生環境中，可以按需激活相應的報告或數據科學工具，而無需大量的前期投資。

七、成功因素

讓我們以一些關于成功因素的想法來結束本文。取得成功的組織通常首先關注幾個選定的領域，從一開始就吸引業務利益相關者，確保將遵守法規和政策方面的好處與業務成果一起考慮，并堅持云優先的設計原則。

1. 從小規模開始——從組織相對良好的領域中的 1 或 2 個數據資產開始，其中物料、客戶和產品數據通常是強有力的候選者。在較小的規模上取得成功并利用聚集的動力來推動其他領域吸取的經驗教訓的實施會更容易。
2. 業務參與——從一開始就包括業務代表。價值創造取決于它們的采用和消費，這就是為什么確保將相關要求納入數據資產和數據結構中至關重要，包括需要什么數據以及如何訪問數據。
3. 效益整合——擁有強大成功案例的組織通常能夠將歷史數據治理職責與更具前瞻性的數據科學相關用例結合起來，清楚地闡明強大的數據基礎將如何為整個企業的利益相關者服務。如果數據管理，投資回報更有說服力。通過設計推動法規遵從性以及以業務為導向、洞察力驅動的用例。
4. 云優先——堅持云原生設計可以防止供應商壁壘，并允許進行無風險、無缺失的實驗，避免高額前期投資，并能夠“快速修復”，在出現問題時進行擴展成功。