企業資料狀態混亂之原因與對策：引入DDD - Allamaraju

banq發表於2021-11-23

由於多種原因，企業中資料狀態混亂，四個方面很突出：
  1. 跨組織邊界的零散所有權和問責制：資訊孤島、筒倉。
  2. 資料庫管理和資料工程等特定功能的集中化，但在整個企業遊戲中沒有一塊完整的皮膚可用
  3. 技能不平衡——軟體開發團隊很少將資料視為他們服務的一部分，資料工程師很少接觸軟體開發生命週期；他們經常以不同的方式說話和處理問題，專業術語不同
  4. 需要將資料探勘和轉換為強大的分析用例（包括機器學習）所需的膠水技術。

通常，生成資料的團隊與下游分析和 ML 用例分離開來了，形成資訊孤島和筒倉；同樣，處理分析用例的人員通常不知道系統是如何產生資料；資料工程團隊被夾在中間，他們的任務卻是使用資料驅動企業發展。對於經歷過這種混亂的資料從業者來說，這些資料處理分析流程中的部門鴻溝非常常見。
最近一個例子，看到一個 ML機器學習團隊在等待資料工程團隊修復他們不熟悉的領域：由於源頭應用程式中的某些缺陷，資料子集停止流入特定目的地，但資料工程團隊最終將該錯誤保留在資料佇列中達數週之久，他們不知道去哪裡尋找這些錯誤，因為他們不擁有這些產生這些資料的資料來源頭的應用程式。
 

難怪資料科學家經常將資料收集、清理和資料質量等與資料相關的問題列為痛點列表的首位。
畢竟，機器學習是一個反饋迴圈問題。您需要反饋迴圈的所有部分協同工作才能快速學習併產生價值。但要使其正常執行，您必須找到使運營和分析領域無縫執行的方法。
 
雖然看到資料庫領域的創新和選擇令人興奮，但由此產生的靈活性加劇了特定的挑戰。

  • 首先，軟體開發團隊很難為資料模型和預期的訪問模式做出資料庫選擇。
  • 其次，一旦團隊做出選擇，他們必須在面對資料或訪問模式變化或吸取的教訓時處理該選擇的後果。更改會消耗時間，造成停機，並可能留下髒資料。
  • 第三，資料選擇會滋生蔓延，使得追蹤真相的來源、資料的純正血統和確定要消費的資料變得複雜。

這些挑戰也導致治理成本和時間增加。如果想知道在哪個資料儲存中存在哪個資料欄位就可能花費長達數週時間的流程。
 
分析方面的情況似乎更糟，分析工作經常被分解以保持事情的進展或“能繼續工作”。我的意思並不是說企業努力進行業務資料分析或機器學習。這些用例肯定有很棒的產品和技術，但總是會涉及到將多個資料來源拼接在一起、執行資料移動和轉換。然而，在目前的情況下，資料分析世界的成功取決於首先找到合適的膠水一樣粘合劑，然後將這種粘合劑將端到端地連線在一起。
 
最後一點，許多組織似乎在過去十年的微服務和開發運營轉型中遺漏了很多資料。這些變革透過基礎設施、人員和責任的大規模分散，從根本上改變了技術和文化。然而，我們仍然看到大型資料工程組織在資料的生產者和消費者之間掙扎，其中部分資料因為分山依賴帶來問題。
 

如何應對這些挑戰？
首先，我不相信業務資料分析世界會有顯著改善，除非我們在資料運營的世界中非常認真地採用領域驅動的資料方法。
任何變化都需要從資料生產開始，其中大部分通常發生在運營領域。我們可能需要新一代面向開發人員的資料運營系統的抽象，以更好地與資料分析系統連線。
 
其次，我們需要組織轉型以在有界上下文中實現“資料即產品”。它需要轉移責任。您可以讓集中團隊提供和運營共享技術，但您必須將資料所有權和責任交還給域團隊。您還必須適當地僱用並調整目標設定和計劃慣例以支援這種權力下放。
我不是第一個這麼說的人。Zhamak描述資料網格作為“分散的社會技術方法”。我想強調這個描述的社會方面，因為你必須在每個層面進行改變才能獲得資料作為產品概念的好處。但轉型是昂貴的，需要具有堅韌、耐力和遠見的領導。這些可能很難獲得。

第三，資料網格的核心原則，例如

  • （1）面向領域的去中心化資料所有權和架構，
  • （2）資料作為產品，
  • （3）自助資料基礎設施作為平臺，
  • （4）聯邦計算治理，


這些原則承諾為分析世界提供一個更好的狀態。我不相信由於我上面描述的所有原因，前方有一條直路。 這四項中的每一項都需要在技術、流程、角色和職責方面進行重大轉變。我會睜大眼睛前進，從首要原則開始，並在我們前進的過程中對不斷變化的想法持開放態度。
 

相關文章