業務架構精簡元模型：說到企業架構(ea)，最權威的標準檔案就是togaf了。togaf中，把企業架構分為業務架構、資料架構、應用架構和技術架構。其中的業務架構，是指導後面3個架構的，是業務的高階模型。即使現在流行敏捷開發，但業務架構還是要先設計出來，作為敏捷的」框架「或」藍圖「。敏捷開發通過迭代形成的業務模型是業務架構的細節。
下圖是togaf中業務架構的」元模型「，即主要元件及其之間的關係。理解了」元模型「，業務架構就入門了：
togaf的元模型好在給出了比較全的元件，特別是元件之間的關係比較詳細。但是（重點來了：）），有些元件說得比較多，如上圖紅色的目標等；有些說得比較少，或者缺失，如計畫、狀態等；有的關聯不全面，如產品僅和流程關聯，未和職能關聯，那麼沒有中間產品嗎？另外還有有羅列之嫌，未對這些元件分出層次。
下圖是我在諮詢工作中總結出來的」業務架構精簡元模型「：
首先，把元件分成了2個層次：知識層和行為層。知識層是企業中的各種規章制度、標準、模板等。行為層是企業對制度的落實和執行。
其次，補充了計畫、狀態元件；把資料從資料架構提公升，作為業務架構的一部分。
第三，產品、服務、資源和目標等概念抽像為製品；把流程和職能抽象為流程；去除了不在同一抽象顆粒度的元件如度量、合約等。
通過這樣的重構，層內和層間元件之間的關係更清晰，做到了」高內聚、低耦合「。
行為層的計畫和事件在關於事件驅動和工業4.0cps體系結構的博文中有描述，這裡就不重複了。這裡重點說明一下知識層的元件。
流程：活動及其之間的關係。建模工具是流程圖，如bpmn, epc, uml活**等
資料：資料及其之間的關係。建模工具是實體關係圖（er圖）、uml的類圖等
狀態：活動和資料之間的關係。建模工具是資料流圖，數學模型是petrinet
這裡一般相對不太被重視的是狀態。狀態是資料實體在流程活動、步驟作用下發生變化的階段性結果。是業務表單和物件的狀態控制了活動和流程的執行，落實到執行層就實際上控制了計畫項執行的先後關係（前後置關係）。這樣把傳統計畫管理中計畫項之間前後置關係落實到實際的業務技術狀態層面，不再是脫離技術的人為規定。把技術的狀態能即時地反饋到計畫層面，更便於管理層進行決策和半自動化、自動化地推進。
執行層的事件的組合反映的是業務狀態，狀態決定了要匹配什麼樣的規則，規則定義了要採取的下一步活動。
知識層和行為層的元件還可以有更細的分解，並形成更完整的業務邏輯。下圖結合精簡元模型和戰略地圖，給出了企業業務中主要分解結構（bs-breakdown structure）：
簡單解釋一下。
上圖的核心是流程層面，是整個戰略地圖的黏合層。其中專案管理、日常執行和能力建設的工作分解結構（wbs）都是企業的工作計畫，而計畫是流程bpbs的例項化。
流程需要資源層提供輸入。資源層包括技術tbs，資源rbs, 組織obs等；
流程的輸出是產品，是客戶能看到的，是為客戶服務的。
流程的結果是要有良性財務成果，這樣企業才能持續經營。
業務模型 業務概念建模 系統模型 應用邏輯架構
從方法到思維 什麼是應用邏輯架構的正確姿勢？職責明確，某種粒度的模組 包括域 元件 系統 包 類 方法 上述模組之間的明確的關聯關係 若干約束和指導原則 軟體設計本身，模組，粒度，職責，復用，等等，在講解軟體設計的時候，使用的是這個架構圖，這個架構圖是通過系統模型和業務概念架構推導而來。所以系統模型...
模型 元模型
在兩個月的漫長假期裡，我花了一點時間看了 uml寶典 和xpdl規範，在兩分資料中都提到了元模型的概念，雖然以前不只一次的聽說過元模型，但是這次我才真正意識到它的重要性。元模型指的是描述模型的模型。在uml圖中，我們用類圖來描述系統的結構，這個時候，我們所繪製的類圖就是我們系統的模型，而 類圖 um...
再談企業架構 業務架構
再談企業架構 業務架構 人月神話 前面已經談到過企業架構的層次和維度方面的問題，在這裡簡單談下企業架構中的業務架構和業務價值鏈方面的內容。隨著企業不斷的發展和演進，各個業務功能單元會逐步成熟，也會形成多個端到端的流程，這些流程涉及到工程專案管理，鏈，財務，人力資源，產品研發等多個方面的內容。我們再進...