摘要：爲了打破技術與業務的壁壘，搭建技術與業務的橋樑，所以基於以下流程實現應用業務模型管理 ROMA ABM。
在數字經濟時代，數據正在成爲企業極其重要的戰略性資產。在政府方面，數據第一次做爲新型生產要素，列爲比肩土地、勞動力、資本、技術的「第五要素」。隨着數據增多，愈來愈難弄清楚這些數據背後的具體含義，從而引起一些下列問題：數據庫
- 查找信息難 大數據時代，政企數據量呈爆發式增加，在海量信息中快速、精確查找數據顯得不盡如人意。
- 理解不一致 業務理解存在差別，讓IT與業務脫節成爲「兩張皮」，從而形成大量重複工做，甚至影響業務決策。
- 學習成本高 員工具備必定的流動性，如缺少業務的管理辦法，對於新員工須要花費大量時間和成本作培訓，形成嚴重的知識流失和金錢消耗。
對於上述的問題，構建以業務模型突破語義屏障、運營管理驅動高質量發展的思路，構建一套完善的資產管理方法。安全
爲了打破技術與業務的壁壘，搭建技術與業務的橋樑，所以基於以下流程實現應用業務模型管理 ROMA ABM（Application Business Model），框架
以下對關鍵的流程作了說明和解讀，方便你們更好的理解：微服務
1. 模型標準
先解釋下什麼模型，模型是描述數據的數據，也統稱爲元數據，好比書的目錄（做者、ISBN、價格等），簡單對應對物理表的表字段，API的輸入輸出等。工具
業界OMG規範組織對模型有專門的定義，在MOF 2.5規範中模型術語M1層。組件化
- M3是元元模型用於定義元模型，提供基礎模型快速組裝一個元模型包，例如定義元模型須要的領域、類、屬性、關係等等；
- M2是元模型，是M3的實例，是一種模型的規範，具體來講就是描述組成模型的元素和元素之間的關係，如關係數據庫元模型，從庫到表、實例、表、字段、索引之間的關係；
- M1是模型，是用於描述數據的數據，好比一本書的目錄信息（做者、ISBN、價格等），通常對應到物理表的表字段、API響應的字段等；
- M0是基於此模型的對象，也就是物理世界中的數據，通常對應到物理表中的數據。
2. 模型分類
ROMA ABM定義了業界比較承認分類方式，主要分爲：技術模型，業務模型兩種。學習
- 技術模型包括：字段名稱、字段長度、數據庫表結構、API描述、消息描述、文件描述等。技術模型一般經過自動化的任務完成對模型的採集，也能夠經過文件導入等其餘方式完成模型的獲取，以下是關係型數據庫、微服務模型包的樣例供參考；
- 業務模型包括：業務名稱、業務定義、業務描述、安全策略等給其餘使用者可以看懂的業務屬性，使用者可根據本身的業務線或者領域快速定位到本身想要獲取的數據模型，通以下是業務模型的樣例包供參考；
3. 模型設計
經過ROMA ABM的元模型可視化配置能力可以快速的完成元模型的設計，元模型的設計體現了設計者對整個業務系統的理解程度，從業務視角整理出的數據分類，這裏咱們能夠稱之爲業務模型，它使得整個組織統一數據語言，是業務流打通、消除信息孤島和提高業務流集成效率的關鍵要素。在設計業務模型以前，須要對組織的業務作端到端的梳理，例若有哪些業務範圍、業務過程、業務發生主體、業務事件等等，而後將以上整理內容作概括總結，設計出符合本身組織特有的業務模型（元模型），這裏以智慧城市的場景爲例，整理設計概括出數字政府的業務模型：大數據
經過ROMA ABM可視化元模型配置能力完成數字政府業務模型的M2元模型配置、屬性配置，爲了幫助你們更好的理解元模型的設計，經過數字政府業務模型對M二、M3層作詳細說明， M3層爲M2層建模提供通用的元模型設計元素，具體參考以下：url
M3層設計結構以下圖：spa
M2層設計結構以下圖：
M2層除了對業務條線作了抽象之外，還定義了業務屬性，幫助使用者獲取庫表、API等底層結構依賴的業務附加屬性，這些類內容經過底層的系統是沒法獲取的，具體須要附加哪些屬性，須要數據管理者結合業務場景作梳理，以下是數字政府業務模型包中提供的通用屬性，供參考；
經過上面的數字政府業務模型咱們其實不難發現，模型管理的核心能力就是從抽象逐步分解到實現，M0、M一、M二、M3對象在真實系統中的關係能夠總結以下：
- M1是M0層抽象，M0表明實際存儲的數據，M1表明存儲這組數據須要的結構，一般對應到業務系統中就是一組表結構、一組API、一組文件等等；
- M2是M1層的抽象，M2表明對M1這些表結構、API、文件等的存儲模型，M2層雖然是元模型，但同時M2也是數據，所以元模型也須要統一的存儲結構而且具有擴展性；
- M3是M2層的抽象，M3表明對M2的抽象，具備通用型，就和設計工具相似，能夠設計各式各樣的元模型；
4. 模型關聯
經過以上設計完成了業務模型與技術模型的設計以及配置，可是這個時候兩類模型之間並無發生任何關係，所以咱們須要將業務模型與技術模型關聯起來，讓技術語言走向業務語言，經過工具提供快速、穩定、多樣的關聯顯得很是的重要。
在整個MOF框架中，M3-元模型是整個模型管理的核心， 那麼如何構建「可配+多樣+穩定」模型採集框架就很關鍵，咱們能夠參考以下原則：
- M3元模型能力圖形組件化，經過拖拽方式完成對元模型包的構建；
- 同類型元模型下的多套採集適配器共用「一套程序」，實現各類介質中的模型與關係進行採集與解析，重點用於對技術模的多樣化採集，以下是關係型數據庫的適配樣例圖：
- 元模型包設計過程當中支持跨包關聯，即當前元模型能夠和其餘元模型發生依賴關係，模型採集完成後自動實現跨包關聯；
基於上述原則從而造成下列模型採集過程：
通過以上步驟處理之後，將自己不可讀的表、字段、API等信息所有轉化爲帶有業務語義的模型，讓各個部門、各個系統、各個開發者在用數的查找上更簡單、效率更高，完全實現技術模型到業務模型的扭轉。
5. 模型生態
應用業務模型管理（ROMA ABM）做爲元模型驅動開發的載體，與周邊系統或者夥伴造成良好的生態循環：
- 將存量系統中的庫表、API、文件等技術模型自動化抽取，經過可視化的元模型設計器，讓全部的技術模型可以按照業務領域統一存儲，讓開發者或者用戶不須要關心實際的細節，屏蔽底層系統的差別；
- 經過模型扭轉把技術模型與業務模型自動關聯，讓底層庫表、API等這些沒法理解的數據模型具備業務上的語義，同時讓全部的底層數據模型迴歸到屬於它本身的業務範圍，讓懂業務的開發者或用戶能夠在本身擅長的業務範圍內，使用本身熟悉的業務語言完成數據模型的查找；
- 第三方應用或者系統能夠經過統一的接口獲取技術模型、業務模型，更進一步完成模型的消費，第三方應用或者系統基於已有的存量模型經過組合、編排等方式生成新的模型後，在回饋給應用業務模型管理服務，讓全部模型像血液同樣不停在整個系統中流動，最終造成完整的模型生態。
本文分享自華爲雲社區《基於MOF的應用模型管理》，原文做者：中間件小哥。