摘要:爲了打破技術與業務的壁壘,搭建技術與業務的橋樑,所以基於以下流程實現應用業務模型管理 ROMA ABM。
在數字經濟時代,數據正在成爲企業極其重要的戰略性資產。在政府方面,數據第一次做爲新型生產要素,列爲比肩土地、勞動力、資本、技術的「第五要素」。隨着數據增多,愈來愈難弄清楚這些數據背後的具體含義,從而引起一些下列問題:數據庫
對於上述的問題,構建以業務模型突破語義屏障、運營管理驅動高質量發展的思路,構建一套完善的資產管理方法。安全
爲了打破技術與業務的壁壘,搭建技術與業務的橋樑,所以基於以下流程實現應用業務模型管理 ROMA ABM(Application Business Model),框架
以下對關鍵的流程作了說明和解讀,方便你們更好的理解:微服務
先解釋下什麼模型,模型是描述數據的數據,也統稱爲元數據,好比書的目錄(做者、ISBN、價格等),簡單對應對物理表的表字段,API的輸入輸出等。工具
業界OMG規範組織對模型有專門的定義,在MOF 2.5規範中模型術語M1層。組件化
ROMA ABM定義了業界比較承認分類方式,主要分爲:技術模型,業務模型兩種。學習
經過ROMA ABM的元模型可視化配置能力可以快速的完成元模型的設計,元模型的設計體現了設計者對整個業務系統的理解程度,從業務視角整理出的數據分類,這裏咱們能夠稱之爲業務模型,它使得整個組織統一數據語言,是業務流打通、消除信息孤島和提高業務流集成效率的關鍵要素。在設計業務模型以前,須要對組織的業務作端到端的梳理,例若有哪些業務範圍、業務過程、業務發生主體、業務事件等等,而後將以上整理內容作概括總結,設計出符合本身組織特有的業務模型(元模型),這裏以智慧城市的場景爲例,整理設計概括出數字政府的業務模型:大數據
經過ROMA ABM可視化元模型配置能力完成數字政府業務模型的M2元模型配置、屬性配置,爲了幫助你們更好的理解元模型的設計,經過數字政府業務模型對M二、M3層作詳細說明, M3層爲M2層建模提供通用的元模型設計元素,具體參考以下:設計
M3層設計結構以下圖:3d
M2層設計結構以下圖:
M2層除了對業務條線作了抽象之外,還定義了業務屬性,幫助使用者獲取庫表、API等底層結構依賴的業務附加屬性,這些類內容經過底層的系統是沒法獲取的,具體須要附加哪些屬性,須要數據管理者結合業務場景作梳理,以下是數字政府業務模型包中提供的通用屬性,供參考;
經過上面的數字政府業務模型咱們其實不難發現,模型管理的核心能力就是從抽象逐步分解到實現,M0、M一、M二、M3對象在真實系統中的關係能夠總結以下:
經過以上設計完成了業務模型與技術模型的設計以及配置,可是這個時候兩類模型之間並無發生任何關係,所以咱們須要將業務模型與技術模型關聯起來,讓技術語言走向業務語言,經過工具提供快速、穩定、多樣的關聯顯得很是的重要。
在整個MOF框架中,M3-元模型是整個模型管理的核心, 那麼如何構建「可配+多樣+穩定」模型採集框架就很關鍵,咱們能夠參考以下原則:
基於上述原則從而造成下列模型採集過程:
通過以上步驟處理之後,將自己不可讀的表、字段、API等信息所有轉化爲帶有業務語義的模型,讓各個部門、各個系統、各個開發者在用數的查找上更簡單、效率更高,完全實現技術模型到業務模型的扭轉。
應用業務模型管理(ROMA ABM)做爲元模型驅動開發的載體,與周邊系統或者夥伴造成良好的生態循環:
本文分享自華爲雲社區《基於MOF的應用模型管理》,原文做者:中間件小哥。