注：微信公衆號不按照時間排序，請關注“亨利筆記”，並加星標以置頂，以免錯過更新。
新書消息：
我們雲原生實驗室從事着聯邦學習的 FATE / KubeFATE 等開源項目的研發，聯邦學習解決的是機器學習中企業數據聯合使用的問題，因此我們也很關注各類數據管理框架和技術。
《華爲數據之道》對企業管理和使用數據做了系統的總結，其中有不少的原理值得借鑑。在徵得出版社許可後，摘錄部分章節分享給大家，本文爲摘錄的第3篇，感興趣的讀者可以點擊圖片購買圖書作參考。
華爲的數字化轉型已經成爲行業公認的標杆，最近的暢銷書《華爲數據之道》對華爲的數字化轉型方法和經驗進行了系統性地披露。企業的數字化轉型，最重要的是數據治理，其次是信息架構的建設，本文將通過《華爲數據之道》這本書的內容來詳細看一看華爲的信息架構的組件、原則和核心要素，相信對其他企業搭建信息架構時會有幫助。
華爲過去的信息架構建設主要是爲了實現“信息化”或“業務上 ERP ”，信息架構往往隱藏在系統中、隱藏在 IT 功能下。對 於大部分業務作業人員和管理者而言，他們的關注點更多聚焦在 “功能是否完善”或“業務是在系統中完成還是手工完成”上。此時，對信息架構的要求僅限於支撐好各類 IT 系統的落地，或在一定範圍內對 IT 建設提供指導。
隨着企業數字化轉型的推進，華爲公司越來越認識到信息架構的價值並不應侷限於“支撐 IT 建設落地”，而是更好地管理企業數據資產，更好地提升整個業務交易鏈條的效率，甚至基於信息架構重新審視業務邊界的劃分和整合。（本文來自公衆號：亨利筆記 ）
信息架構的4個組件
企業在運作過程中，首先需要管理好人和物等“資源”，然後管理好各類資源之間的聯繫，即各類業務交易“事件”，再對各類事件的執行效果進行“整體描述和評估”，最終實現組織目標和價值。（本文來自公衆號：亨利筆記 ）
華爲在實踐中構建了一套對業務運作數據進行有效管理的信息架構方法論，用於指導企業內部各部門的信息架構建設工作， 讓管理者、專家和員工之間有共同語言。
華爲的企業級信息架構（Information Architecture）是指以結構化的方式描述在業務運作和管理決策中所需要的各類信息及其關係的一套整體組件規範，包括數據資產目錄、數據標準、企業級數據模型和數據分佈四個組件，如圖1 所示。
圖1 華爲企業級信息架構的四個組件
信息架構的5個原則
信息架構承載了企業如何管理數據資產的方法，需要從整個企業層面制訂統一的原則，這些原則不僅是對數據專業人員的要求，也是對業務的要求，因爲業務纔是真正的數據 Owner。所以，公司所有業務部門都應該共同遵從信息架構原則。
華爲首先確定了“數據同源一致”的治理目標，圍繞目標的實現，制定了五條架構原則。各業務領域和變革項目應按照架構原則設計其信息架構，並由 EAC（企業架構委員會）、IA-SAG（信息架構專家組）指導和監督各領域落實企業架構原則，在一套規則的約束下，共同建設一個企業級的信息架構。
原則一：數據按對象管理，明確數據 Owner
數據要發揮作用，必然會在多個 IT 系統和流程中流轉，並且越是重要的數據資產，所流經的業務環節就越多。例如，產品、人員、客戶的數據幾乎在所有流程中都會涉及，客戶合同數據也會在整個業務交易鏈條中流轉，因此不應該以 IT 系統、業務流程邊界來管理數據，而應該從數據本身出發，按對象進行數據全生命週期管理。（本文來自公衆號：亨利筆記 ）
幾乎所有的企業數據都是由業務產生的，IT 人員無法對數據的定義、質量負責，因此需要在公司層面確定數據 Owner。華爲公司按照業務對象任命數據 Owner，並且每個數據都只能有唯一的數據 Owner。數據 Owner 要負責所轄領域的信息架構建設和維護，負責保障所轄領域的數據質量，承接公司各個部門對本領域數據的需求，並有責任建立數據問題回溯和獎懲機制，對所轄領域的數據問題及爭議進行裁決，公司有權對不遵從信息架構或存在嚴重數據質量問題的責任人進行問責。
原則二：從企業視角定義信息架構
任何一個數據 Owner 都不只代表自己所轄業務範圍的數據管理訴求，而是代表公司對數據進行管理。華爲在數據治理實踐中，爲了拉通各部門所產生的數據結構和流轉路徑，實現數據在企業內共享和流通的目標，明確要求各業務領域都需站在企業的視角定義信息架構，充分考慮數據的應用場景、範圍和用戶羣體，參考業界實踐和主流軟件包，平衡和兼顧 AS-IS（現狀）和TO-BE（未來）訴求，在流程設計和 IT 實現中得到落實。（本文來自公衆號：亨利筆記 ）
以前面的合同編號爲例，銷售部門作爲數據 Owner 有責任定義合同信息架構，但不應只考慮銷售環節對合同編號的管理訴求，而是應該綜合考慮供應、交付、財經等各個環節對合同的訴求，合同在整個交易鏈條中延伸的範圍就是相應數據 Owner 所綜合覆蓋的範圍。在這個鏈條中，任何業務部門對合同編號的訴求，都可以提交給數據 Owner ；同時，合同數據 Owner 對所轄數據在整個企業範圍內的架構的合理性和一致性負責，如果某個業務環節私自定義了合同信息架構，那麼數據 Owner 有責任對該架構進行統一和整改。
原則三：遵從公司的數據分類管理框架
爲了協同企業內各業務領域的數據治理，華爲在實踐中總結了各類數據的內在特性，制定了統一的數據分類管理框架，公司所有業務領域按照統一的分類框架進行數據治理。
原則四：業務對象結構化、數字化
華爲在長期的數據治理過程中，制定了業務對象結構化、數字化的架構設計原則，實現數據處理效率的提升，構建數據的處理和應用能力，支撐業務管理。
業務對象內容包括業務結果、業務規則、業務過程，並應打造相應的數字化能力。（本文來自公衆號：亨利筆記 ）
原則五：數據服務化，同源共享
隨着企業業務規模的不斷擴大，往往會隨之產生大量的 IT 系統，這樣很容易出現數據多源頭的情況，導致數據不可信、不可管。爲了有效地避免這些問題，華爲制定了數據同源共享的架構原則，每一個數據有且只有單一數據源，數據使用方應從數據源獲取數據，數據更改應在數據源進行。爲了克服企業業務和 IT 的複雜性這一客觀現實，華爲公司持續推進數據服務建設，要求各數據 Owner 通過數據服務向各業務環節提供數據，各業務環節也有責任通過服務來合理獲取數據，從而在整個企業層面實現數據的“一點定義、全局共享”。
信息架構建設核心要素：基於業務對象進行設計和落地
1.按業務對象進行架構設計
業務對象是指業務領域中重要的人、事、物對象。業務對象承載了業務運作和管理涉及的重要信息，是信息架構中最重要的管理要素。（本文來自公衆號：亨利筆記 ）
業務對象同時還是業務和 IT 的關鍵連接點，也是實現 IA（信息架構）、BA（業務架構）、AA（應用架構）、TA（技術架構） 集成的關鍵要素。
以一個簡化的交易場景爲例（如圖2所示），要完成一個交易，實現商業價值的兌現，企業內的某個子公司，需要與法人客戶簽訂客戶合同，在客戶合同中，要明確交易的產品。在這個場景中，子公司、法人客戶、客戶合同、產品是企業需要管理和控制的核心對象，要作爲業務對象進行管理。
݄
圖2 業務對象和屬性示例
在進行信息架構設計時，架構師、業務代表、數據 Owner 通常會對業務對象的判定存在理解上的偏差，從而產生爭議。數據治理部門需要制定一套確定性的規則，通過確定性的規則促進形成穩定的架構。華爲通過以下四條原則來判定業務對象。
原則一：業務對象是指企業運作和管理中不可缺少的重要人、事、物
企業在設計業務對象時，圍繞支持企業運作和管理的重要的人、事、物去識別。通常，一個業務對象會有相應的管理流程、管理組織，以及支持運作的 IT 系統。比如“客戶”這個對象，企業通常會建立類似客戶管理部這樣的組織，會採購或者開發 CRM 客戶管理系統來支撐客戶管理，會建立客戶信息管理的一系列流程和規範來確保客戶信息的準確、合理、合規。爲了避免管理上的衝突，業務對象通常在企業內只能有一個唯一的數據Owner，由數據 Owner 制定相關的架構、標準和管理規則，用於監控和提升數據質量。
原則二：業務對象有唯一身份標識信息
企業要對業務對象進行管理，需要對所有業務對象的實例進行編碼，確保每個對象的實例在企業範圍內都有唯一的標識。比如員工，企業需要爲每個員工分配一個唯一的工號，如果工號出現重複，則可能引起管理上的混亂，比如工資錯發，任務指令接收不到等。又比如產品，企業需要給每一種產品分配精確的分類編號，確保在研發組織內部、製造工廠、物流運輸、銷售回款各個部門和階段，相同的產品使用唯一相同的編號，不同的產品絕不出現相同編號。企業的研發、生產、銷售、覈算各環節均採用產品的唯一編碼進行標識和處理。
原則三：業務對象相對獨立並有屬性描述
業務對象需要通過大量屬性來描述其各個方面的性質和特徵， 因此屬性必定依附於某個業務對象而不可獨立存在。比如“名稱” 是個屬性，單純地記錄“名稱”這個屬性，無任何業務含義，因爲“客戶”有“名稱”屬性，“供應商”也有“名稱”屬性，“員工”也有“名稱”屬性。業務對象可以獨立地存儲、傳輸、使用， 業務對象之間可以有關聯、依賴關係，但不應有包含或從屬關係。（本文來自公衆號：亨利筆記 ）
以“銷售訂單”爲例，“銷售訂單”通常包含兩個方面的信息。一方面是銷售訂單中所銷售產品的公共信息，比如歸屬的訂單編號、訂單名稱、訂單總價等，這類信息集中起來形成一個叫“訂單頭”的邏輯數據實體。另一方面是銷售訂單中某個產品的個性化信息，一個銷售訂單通常會銷售多種產品，每種產品的價格和數量可能不一樣，這些信息需要用另一個邏輯數據實體來記錄，並用一個“訂單編碼”屬性來表示這些明細的銷售產品歸屬於該銷售訂單裏，同時不同產品按不同“訂單行號”展示。而“訂單行號”是無法獨立存在的，企業能夠確保所有“訂單編碼”不會重複，但無法確保所有“訂單行號”不會重複，並且這也沒有必要，因爲任何訂單行都是隸屬於某個訂單的。因此從這個例子可以看出，訂單行是無法作爲一個獨立的業務對象而存在的，必須歸屬於“銷售訂單”這個業務對象。（本文來自公衆號：亨利筆記 ）
原則四：業務對象可實例化
在現實世界中，業務對象有大量的實例存在，並可感知、可獲取。以員工爲例，就算是規模很小的企業，通常至少會有經理、業務員、會計等不同崗位的人員，每個員工的信息都可以視爲一個實例；而“員工入職類型”是對員工入職信息的一種分類，其本身是無法實例化的，因此“員工入職類型”這一基礎數據應從屬於員工業務對象下，而不能獨立存在，員工業務對象Owner 也應該同時負責“員工入職類型”數據的生命週期管理。
圖3 業務對象示例：銷售訂單
2.按業務對象進行架構落地
信息架構向 IT 側落地的主要交付件是數據模型。數據模型本身有相對比較成熟的方法體系支撐，不同企業之間可能名稱存在差異，但本質差別不大。華爲公司將數據模型分爲三層：概念數據模型、邏輯數據模型、物理數據模型，如圖4所示。
圖4 數據模型分層框架
概念數據模型是通過業務對象及業務對象之間的關係，從宏觀角度分析和設計的企業核心數據結構。邏輯數據模型是利用邏輯數據實體及實體之間的關係，準確描述業務規則的邏輯實體關係。物理數據模型是按照一定規則和方法，將邏輯數據模型中定義的邏輯數據實體、屬性、屬性約束、關係等內容，如實轉換爲數據庫軟件能識別的物理數據實體關係。
爲了確保架構在落地過程中“不走形”，要控制好兩個關鍵點：一個是概念模型與邏輯模型的一致性，主要通過邏輯數據實體的設計管理來實現；另一個是邏輯模型與物理模型的一致性， 主要通過一體化建模管理來實現。
（1）邏輯數據實體設計
邏輯數據實體本質上是對描述業務對象的衆多屬性的歸類， 業務對象無法直接指導 IT 系統的物理實現，也無法基於業務對象來審視物理設計是否滿足業務需求，因此需要通過邏輯數據實體及相應的邏輯數據模型來指導 IT 系統層面的數據設計。在設計邏輯數據實體時，可參考如下幾條主要規則。
1）邏輯數據實體不能脫離業務對象獨立存在，因此某個邏輯數據實體一定是用來描述一個特定的業務對象的，業務對象與邏輯數據實體的關係是一對一或一對多，不允許多對一的情況出現。
2）描述業務對象不同業務特徵的密切相關的一組屬性集合， 可以設計爲一個邏輯數據實體。（本文來自公衆號：亨利筆記 ）
3）邏輯數據實體設計要遵循第三範式。在設計一個業務對象的邏輯數據實體時，每個邏輯數據實體的屬性不要重複定義， 不應包含其他邏輯數據實體中的非關鍵字類型的屬性。
4）提供數據服務或跨業務領域使用的基礎數據，要單獨設計邏輯數據實體。描述業務對象的若干屬性，如果能夠組合起來形成獨特價值的數據服務，滿足下游的數據消費需求，可以設計成一個邏輯數據實體。
5）兩個業務對象間的關係也可以設計成關係型邏輯數據實體，在數據資產目錄中，可按業務發生的時間先後順序，歸屬於後出現的業務對象。
（2）一體化建模管理
華爲公司過去長期存在信息架構與 IT 開發實施“兩張皮” 的現象，數據人員和 IT 開發實施人員缺乏統一和協同，數據架構遵從無法進行實質、有效管理，信息架構資產和產品實現的物理表割裂、不匹配，同時各種數據模型資產缺失。
●針對應用系統設計應遵從信息架構設計的政策要求，在相關項目、產品的流程中，缺乏顯性化的且有實操指導的角色和活動。（本文來自公衆號：亨利筆記 ）
●信息架構設計大多集中在變革項目層的設計輸出和領域層的例行刷新，未與系統落地有效拉通。
●IT 產品聚焦在版本交付，產品級的數據模型與數據字典缺少有效看護和及時維護。
爲了解決這個問題，華爲推行了一體化模型設計（如圖 4-7 所示），不僅在工具上實現了一體化設計和開發，而且在機制上形成了信息架構設計與 IT 開發實施的有效協同。通過一體化設計不僅確保了元數據驗證、發佈和註冊的一致性，而且實現了產品數據模型管理和資產可視。同時，由於促成了產品元數據的持續運營，進而能夠持續對物理模型進行規範，如整改、清理各類作廢表等。
●產品邏輯模型和物理模型一體化設計，元數據管理和數據模型管理融合；
●構建數據標準池，實體屬性只能從數據標準池選擇；
●產品元數據和數據庫自動比對和驗證；
●產品元數據發佈認證和信息資產打通；
●基於交易側產品元數據自助入湖。
在企業數字化轉型過程中，企業信息架構的定位、內涵和管理方式都在不斷地演進。信息架構的定位發生了根本性的變化，不再是對準 IT 功能或實現，而是對準整個企業的業務管理目標；信息架構的內涵也進行了極大的擴展，不再只是聚焦於進入類似 ERP 系統的結構化數據，而是對準整個企業在業務中產生的各種結構化數據、非結構化數據、內外部數據、過程類數據、規則類數據、IoT 數據等；信息架構的管理方式也發生了顛覆性的改變，不再是抽象化的、預先定義好的、一次定義覆蓋所有場景的標準，而是全量的、實時產生的、滿足差異化要求的，甚至是隨需定義的標準。
在這樣的背景下，需要對原有信息架構框架和方法論不斷進行審視和優化，可能兩年前剛剛確定的框架已經不能滿足要求， 甚至一年前發佈的架構規則就要重新修訂。在企業實現數字化轉型的過程中，信息架構管理的結構、技術、組件、標準可能永遠不會穩定，永遠在進化。
感興趣的讀者可以點擊圖片購買圖書作參考。
要想了解雲原生、區塊鏈和人工智能等技術原理，請立即長按以下二維碼，關注本公衆號亨利筆記 （ henglibiji )，以免錯過更新。
