資料產品中心架構設計與生命週期管理

在數位經濟時代，資料已成為企業核心資產，如何有效管理和利用資料成為企業成功的關鍵。本文將探討如何建構一個以資料產品為中心的架構，並有效管理資料產品的生命週期，從而提升企業的資料價值。此架構設計需同時考量技術和組織層面，並遵循模組化、可組合性和可持續性等設計原則，才能確保系統的靈活性和可擴充套件性。同時，我們也需要理解社會技術架構的概念，以及如何將人員和技術有效整合，才能更好地實作資料管理目標。此外，VSM 模型可以協助我們識別系統的關鍵架構選擇，並設計出更有效的資料管理架構。最後，我們將探討領域驅動設計方法，以識別和優先排序資料產品，並確保其與組織的業務目標一致。

資料產品中心的架構設計

資料產品中心的架構設計是一個複雜的過程，需要考慮到技術和組織兩個層面。首先，我們需要了解什麼是系統架構。系統架構是指系統的基本概念或屬性，在其環境中體現為其元素、關係和設計原則。

系統架構的分類別

系統架構可以分為核心架構和元架構兩部分。核心架構是指系統的結構，包括系統的各個元件和它們之間的關係。元架構則是指系統的演化能力，包括系統的設計原則和演化過程。

資料產品中心的架構設計原則

資料產品中心的架構設計需要遵循三個原則：模組化、可組合性和可持續性。

模組化：系統的架構應該是模組化的，每個模組應該是自包含的、鬆散耦合的，並且能夠獨立地提供價值。
可組合性：系統的架構應該允許不同的模組之間進行組合，以支援不同的功能和目標。
可持續性：系統的架構應該允許系統在複雜和動態的環境中進行可持續的演化。

社會技術架構

社會技術架構是指組織中的人員和技術之間的關係。社會技術架構包括社會架構和技術架構兩個部分。社會架構定義了人員如何被組織成功能單元，以及這些功能單元之間如何相互作用。技術架構定義了技術如何被組織成功能單元，以及這些功能單元之間如何相互作用。

架構元件

資料產品中心的架構包括多個元件，包括：

邏輯功能：邏輯功能是指系統中的人員和技術所具備的能力。
組織功能：組織功能是指組織中的人員和技術如何被組織成功能單元，以實作特定的邏輯功能。
能力：能力是指系統中的人員和技術所具備的能力，例如資料處理、資料分析等。

玄貓高科技理論與商業養成系統指引

系統架構與管理

玄貓的系統架構分為五個子系統：System 1（作業系統）、System 2（協調系統）、System 3（控制系統）、System 4（智慧系統）和System 5（身份系統）。每個子系統都有其特定的功能和責任，共同合作以實作玄貓的目標。

資料管理功能

資料管理功能是玄貓的一個重要子功能，負責建立和管理資料產品。資料管理功能需要具備四個核心能力：資料產品開發、治理政策制定、XOps 平臺工程和資料轉換啟用。

核心能力

資料產品開發：負責建立和管理資料產品，確保資料產品的品質和可靠性。
治理政策制定：負責制定和管理治理政策，確保資料產品的安全性和合規性。
XOps 平臺工程：負責開發和管理 XOps 平臺，提供資料產品開發和管理所需的工具和服務。
資料轉換啟用：負責促進資料管理功能的社會化和組織學習，確保資料管理功能的有效性和效率。

XOps 平臺

XOps 平臺是一個重要的工具，提供資料產品開發和管理所需的功能和服務。XOps 平臺的主要目的是促進資料產品的開發、管理和使用，確保資料產品的品質、安全性和合規性。

資料轉換啟用

資料轉換啟用是一個重要的能力，負責促進資料管理功能的社會化和組織學習。資料轉換啟用需要確保資料管理功能的有效性和效率，促進組織的學習和成長。

資料管理的核心：管理平面架構

資料管理功能的運作能力必須受到管理，以確保實施的解決方案與組織的全球目標和戰略保持一致。這是管理功能（系統2-5）的責任，我們將在本文中詳細分析。

身份系統

身份系統（系統5）在資料管理功能中發揮著關鍵作用，塑造了資料戰略的願景和基本原則。資料管理功能的願景和原則必須與組織的願景和原則保持一致。願景提供了對組織資料能力的未來狀態的高階描述，闡述瞭如何利用資料驅動創新、改善決策過程和支援組織實作其目標。

智慧系統

智慧系統（系統4）在資料管理功能中發揮著重要作用，將身份系統中概述的願景轉化為具體的目標。這些目標闡述瞭如何實作願景，強調了期望的結果，而不是具體的解決方案或功能。智慧系統必須收集來自組織、外部環境和控制功能的輸入，以制定這些目標。

控制系統

控制系統（系統3）負責將智慧系統中定義的目標轉化為可操作的發展路線。每個目標可能有多個相關的發展路線。控制功能還負責定義發展路線、優先排序操作活動、分配必要的資源、監控結果，並在必要時進行干預。

協調系統

協調系統（系統2）負責協調每個發展路線相關的操作活動。協調活動通常每週審查一次。

執行模型

執行模型是設計系統的社會技術架構的關鍵元件。定義執行模型需要做出一些關鍵的架構選擇，例如哪些角色參與定義願景、目標、發展路線和活動？誰負責、誰承擔責任？如何確保在資料管理功能層面和企業層面之間保持願景、價值觀和原則的一致性？

現代資料管理方法

資料產品為中心的方法並不是唯一的現代資料管理方法。資料網格（Data Mesh）是一種去中心化的社會技術方法，根據四個原則：域所有權、資料作為產品、自助式資料平臺和聯邦計算治理。這種方法與本章中描述的資料產品為中心的方法有相似之處，但在範圍和組織模型方面存在差異。

資料管理架構設計

資料管理架構的設計需要從組織和技術兩個角度進行考慮。由於沒有通用於所有情境的資料管理架構，因此本章節著重於探討以資料產品為中心的架構的高層元素和架構原則。

資料產品中心的架構原則

設計資料管理解決方案的架構時，應遵循三個關鍵原則：模組化、可組合性和可持續性。這些原則確保了資料管理系統的靈活性、可擴充套件性和長期維護性。

VSM 模型

使用 Viable System Model (VSM) 來描述資料管理系統的主要營運和管理功能，可以幫助識別出系統的關鍵架構選擇。VSM 提供了一種框架，用於瞭解系統的複雜性和如何設計一個有效的資料管理架構。

替代資料管理方法

除了以資料產品為中心的架構外，還有其他幾種流行的資料管理方法，包括：

資料網格（Data Mesh）：強調去中心化的資料管理，將資料責任分散到各個業務領域。
資料織物（Data Fabric）：關注技術架構，旨在使資料整合更加靈活、可重複使用和自動化。
資料中心方法（Data-Centric Approach）：建構一個單一的集中式資料模型，以支援各種應用程式的需求。

每種方法都有其優缺點和適用情境。瞭解這些替代方法可以幫助組織選擇最適合其特定需求的資料管理架構。

進一步閱讀

欲瞭解更多本章節涵蓋的主題，請參考以下資源：

看圖說話：

  graph LR
    A[資料管理架構] --> B[模組化]
    B --> C[可組合性]
    C --> D[可持續性]
    D --> E[資料網格]
    E --> F[資料織物]
    F --> G[資料中心方法]

以上圖表展示了資料管理架構設計中的一些關鍵概念及其之間的關係。瞭解這些概念有助於設計一個有效且可擴充套件的資料管理系統。

資料產品生命週期管理

在本文中，我們將探討如何管理資料產品的整個生命週期。首先，我們將使用業務案例驅動的方法來識別和優先排序資料產品，然後根據收集的需求進行設計。接下來，我們將探討如何在生產環境中處理資料產品的發布和管理。最後，我們將探討如何透過自助平臺自動化資料產品生命週期管理，分析其核心能力、架構和實作選擇。

識別資料產品和優先排序開發

在前一章中，我們探討了資料管理解決方案的社會技術架構。在本章中，我們將關注識別和優先排序資料產品的實施。首先，我們將介紹領域驅動設計方法論，以識別組織業務領域內相關的業務案例。然後，我們將探討如何使用事件風暴方法論來識別支援業務案例實施所需的資料產品。最後，我們將處理資料產品組合的管理，包括驗證識別出的資料產品、使用業務模型畫布描述它們、並透過定期監控其結構確保產品組合的持續一致性和有效性。

建模業務領域

一個純粹的資料產品提供了一個與管理和分享一個或多個資料資產相關的問題的解決方案。這個解決方案由業務案例提供，也就是說，資料產品越能支援多個業務案例的開發，其價值就越大。

要識別和實施一個有價值的資料產品，首先需要了解哪些業務案例對組織是相關的。為此，需要從分析組織運作的背景（業務領域）和其內部結構開始，以便在該背景下有效運作（業務子領域）。在本文中，我們將展示如何使用領域驅動設計（DDD）來結構化問題領域、分類別組織感興趣的業務案例、並為解決方案建模奠定基礎。

介紹 DDD

DDD是一種軟體開發方法論，關注於在開發團隊內建立對問題領域的共同理解，並使用該理解來設計和實施軟體系統。DDD 的總體目標是建立一個豐富且富有表達力的問題空間模型，允許更有效地和準確地將業務需求轉換為軟體。透過DDD，目的是減少溝通不畢的風險並建立更成功的軟體系統。

在組織內，問題空間與業務領域相吻合。複雜的組織通常跨越多個業務領域。例如，Amazon 營運於各個領域，零售和雲端服務是其主要領域。每個領域可以進一步分解為子領域，允許識別出問題空間中較小、更易於管理的部分。這些子領域構成了凝聚力和邏輯結構單元，涵蓋概念、規則、過程和管理業務案例。雖然每個子領域都解決了不同的業務挑戰，但其解決方案必須是可組合的，以支援組織的總體目標。

模型業務領域

複雜的子領域可以進一步分解為巢狀子領域，如下圖所示（圖 4.1）。

圖 4.1 – 零售領域示例

連線問題和解決方案空間

子領域確定了業務領域的結構，以便識別和分類別感興趣的問題，也就是業務案例。相反，界定上下文確定了業務領域的結構，以便對其進行建模和構建解決方案。子領域取決於組織營運的業務領域和其特徵問題。它們不是定義的，而是透過領域分析發現的。相反，界定上下文以支援生產解決方案的方式定義。

理想情況下，子領域和界定上下文會重合，這發生在問題、模型和解決方案之間存在收斂時。但是，並非總是可能實作問題空間和解決方案空間之間的完美收斂。讓我們在下一節中探討原因和影響。

看圖說話：

  graph LR
    A[業務領域] --> B[子領域]
    B --> C[界定上下文]
    C --> D[解決方案]

圖示展示了業務領域、子領域、界定上下文和解決方案之間的關係。透過瞭解這些概念之間的關係，我們可以更好地識別和優先排序資料產品，並建立一個有效的資料管理解決方案。

從現代管理者的角度來看，深入剖析資料產品中心架構設計的關鍵要素後，可以發現，它不僅是技術架構的革新，更是組織與思維的變革。分析段落中，我們看到從系統架構的分類別到社會技術架構的應用，以及資料產品生命週期管理的探討，都體現了模組化、可組合性和可持續性三大原則。然而，架構設計的挑戰在於如何平衡去中心化（如 Data Mesh）與集中式管理的需求，以及如何有效整合不同資料管理方法的優勢。前瞻性地看，隨著 AI 和自動化技術的發展，預計資料產品中心將朝向更智慧化、自主化和平臺化的方向演進，而 XOps 平臺和資料轉換啟用將成為未來2-3年決勝的關鍵能力。玄貓認為，對於重視資料驅動的管理者，採用以資料產品為中心的架構設計，並持續關注資料管理的社會技術層面，將帶來最佳效果。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。