MEAF框架概念檢索工具

  • 架構(ISO/IEC/IEEE-42010:2011 標準) :架構是系統在其所處環境中的基本概念或屬性,體現爲它的元素、關係,以及系統設計和演進的原則。
  • 企業架構規劃 (enterprise architecture planning, EAP):通過對於企業架構的規劃和設計,可以幫助企業構建整體的數字化策略,規劃數字化項目,通過數字化的手段幫助其實現期望的戰略目標和業務結果,形成企業的數字化頂層規劃與設計,指導企業的數字化轉型過程。這個企業架構規劃的過程也被稱爲企業架構規劃。
  • 系統架構(System Architecture)
  • 企業架構(Enterprise Architecture):始於 20 世紀60 年代,截至目前已有接近六十年的發展歷程,作爲一門關鍵的 IT 學科領域,經過多年的發展也催生了各類廣泛應用於各行業和應用場景的框架與方法論工具,例如 Zachman、TOGAF、DoDAF 等,這些企業架構框架也一直作爲重要的指導方法和工具,被應用於各類企業和組織的頂層 IT 規劃與設計。
  • 視角(viewpoint):企業架構設計因爲是在對於企業本身的進行架構設計,因其抽象程度較高,同時涉及各類不同的干係人和組織,不同的干係人和組織基於自身所處崗位角色和職責的不同,對於架構的關注點和視角也存在比較大的差異。因此,通過不同的視角(Viewpoint)的抽象,就可以充分體現我們在審視和進行企業架構設計時,處於什麼樣的觀察位置和角度,兼顧不同干係人的架構設計訴求。
  • 視圖(view):一個視圖描述了一個或一組相關的視角(Viewpoint)出發,通過組合這類視角所關注的元模型(Metamodel)要素及其關係,通過設計與建模之後,形成的切面視圖。一個視圖(View)體現了在一類視角(Viewpoint)下對其關注的架構元模型要素及其關係的描述和可視化。
  • 企業架構框架(Enterprise Architecture Framework):
  • 現代企業架構框架(Modern Enterprise Architecture Framework):在充分吸收經典企業架構框架的優秀思想和最佳實踐的前提下,融合最新的企業數字化發展的需求和新技術新趨勢,勇於跳出 TOGAF 的限制,從問題出發,迴歸第一性,重新思考和構建一個新的輕量級企業架構框架,切實可以解決企業在向現代企業架構演進過程中面臨的問題和挑戰,就成爲我們重點關注和研究的領域。通過幾年的研究實踐,也逐漸形成了一套輕量化、敏捷可落地的企業架構框架方法。
  • 元模型(Metamodel):元模型是對於架構核心概念要素的精確定義和描述,元模型構成了架構設計的“基本語言要素”,通過元模型及其關係的表達,就可以通過結構化的方式對於架構進行描述和展現,框架元模型體現了框架設計者對於企業級架構本身的理解和抽象,是企業級架構框架的核心,是對於架構描述的“統一語言”。
  • 業務架構 (Business Architecture) :業務架構是企業架構的核心內容,直接決定了企業戰略的實現能力,是其他架構領域工作的前提條件和架構設計的主要依據。定義了企業各類業務的運作模式及業務之間的關係結構。它以承接企業戰略爲出發點,以支撐實現企業戰略爲目標,通過對於業務能力的識別與構建,並將業務能力以業務服務的方式透出,實現對於業務流程的支撐,並最終通過組織給予保障。業務架構整體上包括“業務”、“流程”、“組織”、“服務”、“領域”和“模式”六大部分。
  • 能力:企業爲了應對業務的快速迭代、多場景和不確定性,需要在平臺上構建可複用的“能力”以及爲能力提供必要的擴展與可變機制,以此爲不同前臺提供靈活多變的業務服務,滿足不同前臺差異化個性化的的需求。“能力”根據粒度的不同,可再度細分爲“基礎能力”、“能力組件”和“解決方案”三個層級。不同業務的差異性,則可通過能力的“擴展點”設計和不同“業務身份”在擴展點上的“擴展實現”進行區分。
  • 業務身份:“業務身份”的概念最早由阿里巴巴提出,業務平臺在對各業務同時提供服務時,需要能區分每一次業務服務請求的業務身份要素,以便提供差異化個性化的服務;因此需要對企業各業務的身份和特徵進行建模和區分,其產出即爲“業務身份”。業務身份是業務在平臺中的代名詞,是在業務運營中唯一區分某個具體業務的 ID。平臺基於業務身份匹配該特定業務的流程和業務規則,並基於業務身份實現服務路由、需求溯源、業務監控和業務隔離。
  • 基礎能力:是對領域對象的原子操作,完成一個領域對象上單一且完整的職責。比如:創建售後單、修改商品庫存量等,是能力組合和複用的最小單元。
  • 能力組件: 能力組件是對基礎能力的進一步封裝,目的是方便業務的使用。按封裝粒度不同分爲兩類:第一類能力組件是根據業務服務的需要編排封裝的一組關聯的基礎能力,從而提供完整的服務。比如:訂單創建能力組件。第二類能力組件是平臺針對一系列緊密關聯的業務活動,設計的能力模板,可基於該模板快速定製某個具體業務的特定流程和能力,從而達到複用全部關聯能力的目的。比如:“組合支付”、“快速建站”等能力組件。能力組件加快了業務接入平臺的速度,讓業務側專注業務本身,不再需要耗費精力在理解平臺大量的基礎能力上。
  • 擴展點與擴展實現:“擴展點”是對基礎能力的可變性設計,在技術側體現爲基礎能力實現中的某一個步驟的接口定義,而接口的一個實現即爲一個“擴展實現”。比如:訂單渲染基礎能力中有一個步驟是訂單總價試算,而正常時期的總價試算規則與秒殺時期的總價試算規則是不同的,因此需要對訂單渲染基礎能力設計“訂單總價試算規則”的擴展點,並分別定義在正常時期和秒殺時期的擴展實現。
  • 解決方案:是平臺針對一類共性業務的端到端過程設計的能力模板;可基於該模板快速定製某個具體業務的特定能力和流程,從而達到業務模式級別複用的目的。比如:虛擬物品交易解決方案。
  • 流程建模: 負責識別共性業務,並抽取通用流程,設計可變點,作爲可複用性分析的基礎。
  • 領域建模: 負責基於流程建模結果,識別領域事件和領域對象,並劃分子域的邊界;領域對象構成了提供可複用能力的基本單元,對領域對象的操作即是基礎能力。
  • 業務身份建模:負責定義業務身份識別的要素和業務身份解析規則,用於給可複用的能力區分不同的業務身份要素。業務身份由“業務身份 ID”、“業務身份名稱”、“業務身份要素定義”、“業務身份識別解析規則”四個部分組成。
  • 能力建模:負責最終完成平臺三類可複用能力的設計,即“基礎能力”設計、“能力組件”設計和“解決方案”設計。
  • 領域事件(Domain Event):是領域專家關心的,在業務上真實發生的事件,這些事件對系統會產生重要的影響,如果沒有這些事件的發生,整個業務邏輯和系統實現就不能成立。我們可以通過領域事件對過去發生的事情進行溯源,因爲過去所發生的對業務有意義的信息都會通過某種形式保存下來。比如:“用戶地址已更新”、“訂單已發貨” 等領域事件。
  • 事件風暴(Event Storming):
  • 領域對象(Domain Object):是對業務的高度抽象,作爲業務和系統實現的核心聯繫,領域對象封裝和承載了業務邏輯,是系統設計的基礎。
  • 聚合根:是領域對象的根節點,具有全局標識,對象其它的實體只能通過聚合根來導航;如訂單可以分爲訂單頭和訂單行,訂單頭是聚合根,它包含了訂單基本信息;訂單行是實體,它包含訂單的明細信息,聚合跟所代表的聚合實現了對於業務一致性的保障,是業務一致性的邊界。
  • 實體:是領域對象的主幹,具有唯一標識和生命週期,可以通過標識判斷相等性,並且是可變的,如常見的用戶實體、訂單實體;
  • 值對象:實體的附加業務概念,用來描述實體所包含的業務信息,無唯一標識,可枚舉且不可變,如收貨地址、合同種類等等。
  • 子域(Subdomain):是對問題域的澄清和劃分,同時也是對於資源投入優先級的重要參考。比如:“訂單子域”、“物流子域”等,子域的劃分仍屬於業務架構關注範疇。
  • 核心域(Core Domain):是當前產品的核心差異化競爭力,是整個業務的盈利來源和基石,如果核心域不存在那麼整個業務就不能運作。對於核心域,需要投入最優勢的資源(包括能力高的人),和做嚴謹良好的設計。
  • 支撐域(Supporting Subdomain):解決的是支撐核心域運作的問題,其重要程度不如核心域,但具備強烈的個性化需求,難以在業內找到現成的解決方案,需要專門的團隊定製開發。
  • 通用域(Generic Subdomain):該類問題在業內非常常見,所以很可能有現成的解決方案,通過購買或簡單修改的方式就可以使用。
  • 基礎能力:是對領域對象的原子操作,完成一個領域上單一且完整的職責。比如:創建售後單、修改商品庫存量等。
  • 擴展點與擴展實現:“擴展點”是對基礎能力的可變性設計,在技術側體現爲基礎能力實現中的某一個步驟的接口定義,而接口的一個實現爲一個“擴展實現”。比如:訂單渲染基礎能力中有一個步驟是訂單總價試算,而正常時期的總價試算規則與秒殺時期的總價試算規則是不同的,因此需要對訂單渲染基礎能力設計“訂單總價試算規則”的擴展點,並分別定義在正常時期和秒殺時期的擴展實現。
  • 能力組件:是對基礎能力的進一步封裝,目的是方便業務的使用。能力組件加快了業務接入平臺的速度,讓業務側專注業務本身,不再需要耗費精力在理解平臺大量的基礎能力上。
  • 業務維度:此維度主要對企業的業務組合管理進行建模,分析企業各主營業務和輔助業務的關係結構及運作模式。
  • 業務羣:是企業基於業務戰略拆解,確定開展的特定經營活動。比如:開展 ToC 的電商平臺經營活動,其下又進一步細分爲快消品業務羣和消費電子業務羣等。
  • 業務:是業務羣下具有業務價值的業務單元。比如:實體商品業務、生活服務業務等;內部支撐類的業務比如人力資源管理等。
  • 場景:是面向用戶提供價值的端到端業務場景。通常從 4W1H(What、Who、Where、When、How)的維度識別和定義業務場景要素,然後從業務場景要素的排列組合中篩選出有實際意義的業務場景。
  • 流程維度:主要對企業的業務流程進行分層建模,分析企業如何通過一系列業務活動,按照相關的業務規則將輸入轉換成爲有價值的輸出,從而實現用戶價值。
  • 階段:即業務流程階段,包含一組用戶的及與用戶交互的業務活動,用以實現階段性價值交付的目的。比如:售前、售中和售後等。
  • 活動:即業務活動,是某個業務角色辦理的業務事項,包含一個或一組任務,有明確的業務成果和業務輸出。比如:商品發佈、活動發佈等。
  • 任務:是完成活動的工作程序,是流程的基本組成單元。比如:查詢商品詳情、更新商品庫存、創建訂單等。
  • 步驟:是完成任務的具體步驟,是流程的最原子操作。比如:校驗用戶狀態、校驗商戶狀態、訂單總價試算等。
  • 業務規則:是定義或約束業務某些方面的陳述,旨在維護業務結構或控制或影響業務行爲,它描述業務過程與決策過程。比如:if訂單.提貨方式=“郵寄”且 訂單 . 支付狀態 =“已支付” then “創建物流單”。
  • 組織維度:主要對企業的組織體系進行分析。公司組織體系指爲了保障戰略和業務規劃落地,以及有效實施業務流程體系,公司採取的組織架構和管控模式。
  • 組織單元:是公司組織體系的組成單元。
  • 崗位:是隨組織結構設定的,要求個體完成的一項或多項責任以及爲此賦予個體的權力的總和。
  • 角色:是業務流程中活動參與者的原型,參與者在流程中的位置通過擔任合適的角色確定。組織爲完成某一目標,往往會把此目標分解,以便能交給不同能力和責任的角色合作完成。
  • 服務維度:主要對企業對內和對外提供的業務服務進行建模分析。
  • 業務服務:是企業和企業的每個業務單元爲其客戶提供的內部和外部服務。服務是能力對外呈現價值的方式,是具備明確的業務特徵,獨立完整、由一個或多個關聯緊密的功能組合的集合。比如:開戶、提交訂單等。
  • 限界上下文(Boundary Context):是業務上下文的邊界,在該邊界內,當我們去交流某個業務概念時,不會產生理解和認知上的歧義(二義性),限界上下文是統一語言的重要保證。
  • 統一語言(Ubiquitous Language):是 Eric Evans在《域驅動設計 - 處理軟件核心中的複雜性》中使用的術語,用於構建由團隊,開發人員,領域專家和其他參與者共享的語言,也稱爲無處不在的語言、通用語言、泛在語言。統一語言是在限界上下文中建模的,在其中標識表達了業務領域的術語和概念,並且不應該有歧義。
  • 應用組:是一種大比例結構的邏輯邊界劃分結構
  • 應用組件:是一種細粒度的應用邏輯邊界劃分結構,是對功能、數據的封裝。按職責類型分解,流轉類、規格類、視圖類、配置類。
  • 應用層建模:除了應用組之外,常見的一種大比例結構是分層,因此我們也將應用層作爲一種元素加入進來。我們認爲分層代表了企業對變化速率的認知,併爲不同的變化速率匹配架構設計目標和管理方法。
  • 應用服務:元模型中的應用服務最主要的作用是顯式地向對外定義一個契約。這在做應用組件升級 / 替換、定義IT 服務級別等架構治理場景中會有幫助。應用服務可用來對一組相關的應用組件功能集合建模。
  • 數據分析三大工序:攝取(Ingest)- 加工(Process)- 能力包裝(Serve)
  • 數據對象:是數據架構的核心模型,是從數據視角對現實世界特徵的模擬和抽象。
  • 貼源層:貼源代表緊靠數據源,某個業務場景自身的業務運營分析需求,其需要的絕大部分數據原料就在支撐這個業務場景的應用中,需求和實現相對穩定。例如,銷售線索響應的前置時間趨勢,其依賴的主要數據原料是銷售線索的跟進事件,它們就在銷售線索管理系統這個數據源裏。
  • 衍生層:在貼源層之上的是衍生層,這裏的分析類場景需要整合多個數據源的數據原料,往往需要經過多次中間處理,實現難度較高,並且需求和實現相對容易變化。例如,整合多個數據源的客戶行爲數據,爲客戶打上標籤。
  • 架構模式元模型:模式分析是快速認識問題本質以及經驗複用的有效實踐,我們在元模型內容中增加了架構模式模型,引入模式分析視角,對上層架構設計意圖、問題進行分析建模,目的是快速、準確定位設計和複用技術方案。
  • 架構方案元模型:架構方案模型是描述技術架構設計的核心元模型,包含三個主要核心元素。基於平臺型企業架構技術設計的特徵,我們使用了平臺、服務、組件這三個層次遞進的元素對技術架構進行建模。
  • 架構策略元模型:架構策略模型是爲了約束和規範架構設計過程,保證架構設計遵循企業整體的架構設計願景與需求,符合企業整體的架構設計原則與規範,是對於架構設計過程本身的約束和指導。
  • 問題 Problem:問題和上下文是對上層架構設計輸入的分析和解讀。問題描述了架構需求背後要解決的實際問題是什麼,例如業務中臺中如何保證前臺獲得一致的服務等級承諾(SLA)。
  • 上下文 Context:問題和上下文是對上層架構設計輸入的分析和解讀。上下文描述了與問題相關的背景信息,例如問題產生的背景是什麼,需要考慮什麼樣約束條件,期望達到什麼樣的效果等等。
  • 模式 Pattern:模式是通過對問題和上下文的分析,快速映射到的業界或企業內的最佳實踐。模式是解決某一類問題的方案原理的總結,通過模式技術人員可以快速構成對問題及方案背後原理的理解,在問題不變時,模式具有相對的穩定性,是沉澱技術知識的最佳形式。
  • 決策 Decision:決策描述了在模式的基礎上,引入與具體架構方案設計相關的影響因素後,形成的符合滿足架構建設需求的技術類決策,決策的描述方式可以是決策樹或決策表。
  • 技術組件 Component:技術組件用於描述技術服務的實現,是可部署的物理組件,例如可運行的軟件系統或構建打包後的應用組件,技術組件通過架構模式的決策元素,與技術選型進行關聯。
  • 技術服務 Service:技術服務用於描述實現上層架構設計意圖所需的技術能力(或功能),例如網關、防火牆、數據存儲、緩存等。技術服務屬於邏輯模型,作爲一種對服務能力的描述,與之相關的 SLA 等跨功能性需求會同時作爲其參考描述信息。
  • 技術平臺 Platform:技術平臺是用於描述由一組技術服務構成,提供解決特定技術領域能力的邏輯模型,它主要用於從更高的層次對技術服務進行管理,簡化架構參與者對複雜架構的理解和使用,統一對用戶提供一致的SLA 服務承諾。
  • 經驗:經驗是特定場景中對模式的實例化應用的過程記錄,經驗可以加快對模式的理解,學習如何結合實際場景應用模式解決問題,經驗的內容由架構模式元模型中的問題、上下文、決策三個元素組成,每個元素可以通過定義對應的參考模型展開描述。
    發表評論
    所有評論
    還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
    相關文章