數字化轉型之頂層數據架構規劃
很多企業經過多年的數字化實踐,逐漸意識到數字化轉型是戰略、業務、技術、數據、環境、組織等高度相關聯的事情,全鏈條的響應是數字化的基本框架。但經過這么多年的信息化單體系統建設,數據獨立存在于各自系統的數據庫中,雖然通過數倉、大數據平臺甚至數據湖等方式使企業大部分數據匯聚到了一起,從而可以實現一定程度上的數據共享和數據深度分析能力,但這其中需要付出巨大的、繁重的數據治理代價。每增加一個系統,就可能需要重新做一遍數據的抽取、轉換、加載、處理等。各個系統之間數據不一致,格式、語義不統一,數據冗余或缺失等問題并沒有從根本上改變。初始的數據依舊散落于每個系統各自的數據庫中。
在企業架構上,大部分企業缺乏整體的架構規劃,也就缺乏頂層的數據架構設計。雖然很多公司成立了項目管理辦公室PMO,但卻沒有全局的架構師團隊,或者缺乏企業架構的意識。也因此無法實現企業架構下數據的全局架構定義、全局數據模型的設計等。一方面,從廠商角度來說,專注于某一方面技術和產品的研發,利益訴求不同,無法為企業提供全局的架構視角;另一方面,企業習慣了信息化的單體系統建設方式,各部門和團隊基于自身認知和利益習慣了一個一個項目的立項申請流程,改變太難;再者,PMO關注的是項目的管理,而不是項目的頂層規劃,更缺乏企業架構的頂層設計;而專業的咨詢團隊往往限于時間、費用、保密要求等難以融入企業細致的業務之中,水土不服,難以提供有針對性的解決方案。所以企業數字化轉型最終還是需要依靠自身的能力來進行規劃和推進。
數據作為數字化階段的基礎生產要素,需要在企業架構內規劃設計數據架構,使數據在產生的源頭上就標準化,盡可能消除數據治理環節,以主數據為骨架重構企業全局數據架構,實現數據的融合。從而徹底解決數據孤島和數據脫節的問題,支持企業業務應用系統的融合,在數字化階段實現最短鏈路最高效率的轉型賦能和轉型支撐。這對推進數字化轉型企業來說,可能需要設立企業架構團隊,根據數字化業務需求,去規劃、設計、實施、支持和適時調整企業數據架構、應用架構和技術架構。
設立具備企業架構思想和意識的企業架構團隊是企業推進數字化轉型很關鍵的一步。當前大部分企業習慣于一個項目一個項目去實施,缺乏頂層IT架構的設計。而絕大部分架構師是不具備相應的認知和能力的,特別在數字化階段,架構師不但需要理解和了解各種的架構模式和知識,還需要能夠自由的運用這些模式和知識,根據實際的情況選擇合適的架構模式。比如說,中臺就是一種架構模式,中臺的本質就是一種架構方式,其主要目的為了實現企業級的復用,所以中臺架構復用粒度的定義就非常重要。正是由于很多人沒有理解中臺而盲目的去上中臺,比貓畫虎不成反為所累。再比如微服務并不是要把服務拆分的多么微小,不是一個操作就定義一個服務。微服務架構提出的目的,其是為了解決單體系統敏捷變更的問題,所以微服務也不是越小越好。把微服務架構和中臺架構結合,去實現微服務粒度的復用,也就為單體系統重構改造提供了一種比較好的方案。
企業架構團隊可以對接企業戰略和業務、IT部門,指導和協調數據架構、應用架構和技術架構的規劃和設計。數字化不能只關注單一信息系統的能力,而是要協調系統之間的配合。信息化系統往往會盡可能去實現很多功能,所以也導致80%的功能幾乎不用,因為這些功能要么在別的系統是有的,要么沒什么價值,這就造成很大的浪費;數字化應用就需要消除這80%的功能,從頂層架構上規劃企業所需能力和功能,以微服務重構信息化單體系統,并盡可能復用已有的能力。
領域驅動設計將企業內數據劃分為若干個領域,這樣簡化了數據模型的設計,但同時也導致一些模型在設計過程中缺失一些相關性,也會導致一些重復的能力設計。基于領域驅動設計的不足,考慮到主數據是企業內各系統之間共享的高價值數據,以主數據實體來驅動數據架構的設計,通過主數據骨架圖,將更容易直觀的看到實體之間的關系,以及業務和數據實體之間的聯系。考慮主數據在企業內的共享性,也可以以主數據來驅動微服務設計,實現企業級數據服務的復用。
有了主數據實體模型,則參考數據和描述這些主數據和參考數據的元數據等也就有的放矢,也不用把元數據搞的那么復雜化,分什么業務元數據、操作元數據的,避免以元數據為中心的數據治理誤區。在數據治理過程中,如果以元數據為中心,就容易迷失在森林里,看不到數據的整體框架和范圍。主數據就像樹的主干,屬性等如枝葉,而元數據描述這些干支葉的數據,比如樹干高、截面積、圍長等等,它在粒度無法串起企業的數據整體框架的,所以數據治理要避免因小失大。
當前對于數字化轉型的理解還有很大差異,但比較重要的一點是要理解數字化轉型的本質和目的,才能更好地去規劃和推進數字化能力和生產力的建設,更好地去培養數字化團隊,更好地利用數據要素,更好地推進創新和轉型。
|