作者 | Kelsey Beyer

自2019年 Thoughtworks 員工 Zhamak Dehghani 首次提出 Data Mesh 概念以來，Thoughtworks 便開始嘗試在全球范圍內與客戶共同實施 Data Mesh。

以下是根據我們的經驗總結的十項建議。對于每項建議，我們都指出了在實施過程中觀察到的反模式、我們推薦的替代方法及其原因。這些建議將按照組織中的層級順序從高到低列出。

1.僅靠自下而上是行不通的，應當盡早獲得自上而下的支持

一項新技術要獲得管理層的支持往往都存在一些挑戰。也正因為如此，一些 Data Mesh 的倡導者試圖通過“在特定領域實施 Data Mesh、進而構建數據產品”的方式來自下而上地實施 Data Mesh。

然而，我們已經看到，當這些領域和數據產品試圖將 Data Mesh 擴展到其他部門時，會遇到一個無法逾越的障礙——其他部門不明就里，對這個整體方法持懷疑態度。

想要以自下而上的方式跨越部門界限，試圖改變他們的優先級、資金、角色和責任會非常困難。當有人詢問“你是誰，為什么你要告訴我該怎么做？”時，倡導者也會略顯尷尬。

平臺團隊有時也會遇到同樣的問題。他們應該是最佳實踐的推動者和教練：沒有自上而下的支持，他們無法改變數據產品團隊的工作方式、團隊設置，甚至無法實施統一的數據治理策略。當數據產品團隊試圖說服非 Data Mesh 團隊向他們提供數據訪問權限或協助解釋數據時，也會遇到類似的障礙。擴展 Data Mesh 需要自上而下的授權，以便在擁有不同優先級和利益相關者之間創造共識和達成一致。

需要自上而下和自下而上的雙重支持：愿意從自下而上改變工作方式的團隊，以及支持這一變化的高層領導。

2.從運營模式開始

實施 Data Mesh 需要同時在運營模式和技術方面作出改變，但前者常常被擱置，因為它太難撼動了。因此，組織經常嘗試采用技術優先的方法來實施 Data Mesh。這種策略雖然能改善技術實踐，但通常在第一年內就會失敗。這是因為支持 Data Mesh 擴展所需的結構沒有得到充分的改變，以適應新的工作方式。

誠然，改變運營模式很難，但這卻是不可或缺的。甚至它應該在 Data Mesh 計劃的第一天就同步實施。

Data Mesh 不是一個項目，它是一個企業級計劃。影響著各團隊之間的協作方式，需要彼此配合和支持。因此，高層需要給予高度支持和幫助，以確保組織范圍內的一致性。與此同時，它還需要一定程度的變革管理，例如創建各種治理機構，重新定義角色和責任，以及提高組織的技術水平。轉型部門可以在此處提供幫助，通過將具有運營模式和技術知識的人聚集在一起，確保組織一致性。

總的來說，運營模式的改變可能令人望而生畏，但它是成功在組織內實施 Data Mesh 的基本要素，需要盡早做。

3.以“代表組織領域對象和優化效率及溝通”的方式定義領域

領域所有權是 Data Mesh 中的核心原則。這一點至關重要，因為它確保了 Data Mesh 中的每個數據產品都由組織內該特定領域的專家所擁有。其好處在于，它使得數據產品對于那些可能想要使用它的人來說更加有用——它消除了某些術語在特定數據字段中含義的潛在混淆，并有助于減少不一致性。

換句話說，如果某些內容不夠明確，領域所有者最適合進行修正或提供必要的上下文。

當然，這并非沒有挑戰。定義組織領域的界限以及誰擁有什么，是困難的。這通常是由預先設定的預算和報告線，或潛在的政治暗流所引起的。因此，在一開始，比較容易的方式是沿著現有功能的邊界定義領域。隨后，隨著項目的推進和新信息的浮現，可以進一步對過于復雜的領域界限進行分割，或重新分配領域界限。

更好的做法是，從定義一個領域開始，隨著時間的推移作為一個迭代過程向外探索。已經在其運營模式中采用領域驅動設計的組織，在進行這種操作性轉變時會更加輕松。

最終，定義領域有多種方式。重要的是這些領域在組織的背景下講得通，有文檔記錄，并使溝通和流程更快、更高效。下面是一些可能的例子：

• 沿現有的業務單位或功能劃分
• 根據業務成果（如增加利潤、提高客戶滿意度等目標）劃分
• 沿價值流（為客戶交付價值或成果的舉措）劃分
• 使用逆康威操作（即根據所需的架構來構建團隊，而不是讓現有的通信路徑和結構來塑造它）
• 采用領域驅動設計

總結而言，領域定義使組織能夠識別數據的所有者和專家，并對溝通和協作渠道進行高效地優化。對于每個組織而言都是獨特的，盡管第一個領域的定義可能很困難，可以從組織最容易采用的方法開始，在熟悉工作方式和責任后進行持續演變。

4.同步構建運營模式、數據治理和平臺

平臺將運營模式定義的角色、責任和工作方式以及數據治理定義的策略變為現實。

我們經常看到的一個反模式是，運營模式和數據治理是分開的、孤立的項目，每個項目都定義了一堆文檔，這些文檔被扔過墻給IT部門去實施。在這里，將“Data Mesh”視為一個產品可能會有所幫助，在其中運營模式、數據治理和平臺具有相同的基本目標、假設、計劃和待辦事項列表。采用這種一體化方法，運營模式和數據治理理念可以通過數據產品進行反復測試和優化，而這些數據產品正是基于平臺能力得以實現的。

我們建議首先選擇的場景應該將運營模式和數據治理策略定義為需求的一部分。

一個示例需求：

“當數據產品團隊創建一個數據產品時，它會自動注冊到數據目錄中，并附上對其輸入端口、輸出端口、模式、服務級別協議（SLOs）、領域和領域所有者的描述，以增加組織內數據產品的透明度。”

然后，平臺可以實現這樣的需求，之后相關的運營模式和數據治理辦公室可以監控這種策略在 Data Mesh 生態系統中的影響和性能（以及其性能是否達到了定義的成功度量標準）。

5.盡早建立一個良好的平臺

自助式數據平臺是 Data Mesh 的四個原則之一，它是關于數據產品能力、領域定義和治理策略決策的技術實現基礎。平臺以自助服務的方式為數據產品團隊提供能力，使他們無需等待平臺團隊臨時創建資源和進行數據集成。

采用 Data Mesh 方法，平臺團隊不再負責維護和轉換數據以供分析師使用，而是負責提供構建數據產品（自包含的可部署包）的能力，數據產品團隊可以請求并使用這些能力來維護他們的數據。

這些構建數據產品的能力被稱為“架構量子”（如《演進式架構》中所定義）。它們包含了數據產品團隊構建其數據產品所需的一切，例如圍繞數據接入、存儲、分布式計算的數據轉換的基礎能力，與數據目錄工具的集成，數據質量工具中的監控和治理策略。有時，對于不同類型的數據產品會提供多種選擇。這些實踐和模板使團隊能夠盡可能輕松地交付數據產品。

由于自助式數據平臺是 Data Mesh 的主要推動者，它們需要盡早建立。一個常見的錯誤是組織在沒有基本平臺的情況下啟動數據產品團隊。這些最初的數據產品團隊會因為等待平臺開發基線能力而陷入僵局數月，這給正在進行中的計劃帶來了壓力。在另一個極端，一些組織花費數年時間試圖構建了完美的平臺，這需要耗費太長時間，而且維護和運營起來太困難。

正確的做法是介于兩者之間：一個“良好的平臺”是基于研究數據產品團隊實際需要什么而構建的。一個經過充分研究的自助式服務平臺在減少創建數據產品時可能發生的摩擦中起著重要作用。

為了避免花太多時間構建完美的平臺，我們建議從定義一組核心MVP（最小可行產品）能力開始，這些能力“足夠好”，以便讓數據產品團隊快速移動，為組織提供價值，并繼續根據新的數據產品團隊和領域的經驗進行迭代構建和擴展。

6.在新的 Data Mesh 平臺中復用現有技術

在 Data Mesh 的早期階段，許多客戶都會對所需的大量技術和工具感到壓力重重。實際上，盡管有些工具可能更適合 Data Mesh 的需求，但最理想的做法是在合理的情況下，利用起已有的技術棧、許可證和專業知識。隨后，可以添加自定義層以改善開發人員體驗，并使用新工具來填補任何剩余的能力差距。

請注意，“復用現有技術”并不意味著“復用現有的或舊的平臺”。現有的或舊的平臺可能與 Data Mes h方法不兼容，因為 Data Mesh 需要在構建平臺的方式上進行關鍵的范式轉變。此外，復用不符合 Data Mesh 方法的舊平臺可能會增加額外的復雜性，提高成本并減慢您的速度。

我們建議首先對現有的技術進行梳理，然后根據 Data Mesh 自助數據平臺的需求以及你的數據產品要求，對這些技術進行評估。對于那些符合要求且已足夠成熟，可以通過自助服務方式使用的工具（例如，提供了API接口，或者能夠為了實現基礎設施即代碼而聲明性地定義資源），應予以保留和再利用。

7.場景先行，小步慢行

如果使用 Data Mesh 的項目失敗，其首要原因很可能是它們試圖過快地擴展規模。正確的操作是給予組織時間去學習和適應變化。這種初步的耐心最終會帶來長期的回報。

我們建議從包含兩到三個數據產品的場景開始，這些產品在六個月的時間內涵蓋運營模式、產品和技術三個維度。

可以理解的是，一些組織認為這種方法“太保守”了。他們可能想要采取更激進的方法，在開始時同時啟動幾個場景。我們發現，涉及上述三個維度下的第一個數據產品通常需要六個月的時間來引導。一旦度過這一時期，就需要對數據產品所有者進行培訓，并組建一個平臺團隊，以便開始為平臺構建新的能力。還需要新的模板和工作方式，以將組織從集中式轉變為分散式模式。還需要建立一個 Data Mesh 治理委員會，并制定一個路線圖，以增加額外的領域。

簡而言之：不要在學會走路之前開始跑。在旅途中會有很多學習的機會。不要錯過它們。

8.審慎選擇您的首個場景

確定最初的場景可能會讓人感到挑戰重重，但重要的是要記住，并沒有唯一正確的答案。每個組織都有其獨特之處，您所做的決策將取決于您想要優化的內容以及您所在組織的風險承受能力。

例如，一些客戶選擇了非常緊急且復雜的場景。他們通常渴望解決組織中因效率低下和內部政治斗爭而造成的阻礙。其他客戶則選擇了更為保守的路線，通過選擇一個簡單、孤立的場景來測試組織對 Data Mesh 的接受度。

與此同時，其他客戶選擇優化構建多樣化的平臺能力。一個成熟的 Data Mesh 數據平臺提供了批量數據處理、近乎實時數據處理、數據分析、人工智能/機器學習（AI/ML）和數據治理的能力。選擇需要這些能力的場景，為并行構建所有平臺能力的基礎工作設定了優先級。

這種方法的另一個好處是，需要多種能力（例如機器學習和批量處理能力，這是常見的依賴關系）的場景成為首批場景的候選。然而，這種方法需要一個龐大且強大的平臺團隊，能夠處理產品思維和以兼容且可互操作的方式集成能力的復雜性。

在眾多方法和優化途徑中，我們的建議是，從以下情況中選擇最初場景：

• 在組織現有能力范圍內可管理
• 與業務目標緊密相關，并有明確的成功度量標準
• 可實現

由于內部政治和過度優化，選擇場景很容易讓人陷入困境，但通常沒有一個完美的場景。需要避免的一個常見錯誤是“分析癱瘓”：即過度分析導致無法行動。因此，應該為這項工作設定一個時間限制，并從那些“足夠好”的用例開始。

9.將數據產品納入平臺和運營模式的治理結構

我們觀察到在IT驅動的組織中存在一個反模式，即數據產品團隊的加入僅限于在平臺上的加入。實際上，將他們納入運營模式設立的組織流程同樣至關重要。

適當地加入運營模式流程中，可以讓數據產品團隊在各種討論中擁有代表權，從而影響諸如特性優先級等重要活動。加入過程還包括將他們添加到正確的交流渠道，以確保他們不會錯過關于新特性、發布和學習機會的重要信息。

從長遠來看，沒有加入運營模式的團隊可能與更廣泛的 Data Mesh 生態系統的原則不一致。這可能導致各方的不滿和挫敗感。

10.要堅定

在組織內部實施 Data Mesh 時，往往需要隨著時間的推移進行重大變革，這些變革會影響到許多人、現有部門以及決策流程。當組織的一部分抵制變化時，這可能會變得困難。

可能會有人認為，快速變化的組織——比如重視實驗、對數據訪問策略持更寬松態度的初創公司——與更加成熟、集中化、遺留問題更頑固的大型企業組織所面臨的問題不同，因此應該區別對待。盡管這種說法有一定道理，但實際情況是，無論組織類型如何，如果想要成功，就必須在實施和資源投入上做出變革的承諾。

我們最成功的 Data Mesh 采納者已經做到了以下幾點：

• 及早獲得了相關高層的支持
• 將 Data Mesh 作為組織的一部分，每個人都愿意通過全公司范圍的、以數據為先的理念參與 Data Mesh 的實踐和思維方式
• 人們愿意投入時間學習新方法并改變他們的流程
• 合適的人迅速被安排到合適的位置，一旦發現缺口就迅速投入資源
• 組織愿意接受并實施一個去中心化的模式
• 組織準備好與領域保持一致（如果他們還沒有）

已經下定決心全力以赴的組織，能夠更快（且成本更低）地通過 Data Mesh 實現價值。這就是為什么為了變革的效率和成功，需要對 Data Mesh 做出全面承諾的原因。

總結

Data Mesh 可能為您的組織帶來創新和積極影響，但前提是組織對正確實施它有堅定的決心和承諾。變革固然充滿挑戰，但只要采取了恰當的方法和流程，就有可能克服成長的陣痛，最終實現 Data Mesh 的成功。