摘要
企業的内部需求和外部環境一直在變,軟體研發、傳遞和使用的方式也一直在變,相應地,企業架構的方法論也一直在演進。數字化時代如火如荼,傳統的企業架構方法需要引入新的思維模式,才能滿足企業發展需求。 作者結合自己在架構領域多年的實踐經驗和思考總結,針對數字化轉型大背景下企業的架構需求,對TOGAF等傳統企業架構方法論的不足進行了改進與創新,提出了一套面向數字化企業的企業架構方法論——聚合架構(ABAE),是管理數字化企業的新思維,在企業架構方法的發展史上或有劃時代的意義。
三大主流企業架構體系核心點
Zarchman核心
6橫6列,多視角設計架構
TOGAF的幾個核心
1 ADM 方法過程:葫蘆圖(麥圈圖)
2 4A架構,業務架構、應用架構、資料架構、技術架構
3 中繼資料和視圖
4 架構治理
CBM核心點
CBM是聽診器,是根據業務戰略作為輸入、分析IT戰略存在改進方向
DoDAF核心點
1 引入資料為中心
2 架構(體系結構)業務管控引入架構思維
3 八個視點
第一講 開篇
聚合架構第一講:開篇啦-2021-11-20 22:41:46_哔哩哔哩_bilibili
第二講 企業架構的認知曆程
聚合架構第二講:企業架構的認知曆程-2021-11-20 22:41:46_哔哩哔哩_bilibili
第三講:從包餃子看工程與架構
聚合架構第三講:從包餃子看工程與架構_哔哩哔哩_bilibili
第四講1-3:工程方法的進步也不容易
聚合架構第四講1-3:工程方法的進步也不容易_哔哩哔哩_bilibili
四個價值觀:見靈活宣言
工程方法論三次演進:1970年瀑布模型 1988年螺旋模型 2001年靈活開發
聚合架構第五講1-4:架構方法的進步也不容易
聚合架構第五講1-4:架構方法的進步也不容易_哔哩哔哩_bilibili
DoD 美國國防部 最先提出企業整體架構的
IBM:CBM(IT能力模型)=》BIAN(開放銀行服務标準化、接口、微服務化)
企業級業務架構(EBA)方法源自Zachman架構和TOGAF理論,是曉岩大神提供的唯一國内的企業架構
1-5聚合架構第六講:聊聊開山祖Zachman架構
1-5聚合架構第六講:聊聊開山祖Zachman架構_哔哩哔哩_bilibili
列是不同視角,行是利益相關者。同一視角下的行分層是松散的,沒有分層關系也沒有必要的關聯和限制
各個cell之間是松散的,上下層也沒有必然關系
企業架構是對企業的一種觀察,是一種觀察的結果。對企業的觀察結論,可以叫企業觀(套用世界觀)
架構不是Single of Archtechure,而是Set Of Archtechure (架構不是單一的架構,而是一套架構)
按Zachman理論結合不同利益相關者和視角次元,架構圖至少要有6*6=36張圖,所有很多講架構的隻是把業務和應用整合到一起展示的職能叫概念圖。
Zachman評價:
優點 1) 開創先驅 2)多視角架構的統一,解決了盲人摸象;
缺點:缺少過程講解,全是道理沒寫怎樣做;缺少傳遞,沒有介紹每一個格子裡面視圖内容
1-6聚合架構第七講:聊聊togaf的發展曆程
1-6聚合架構第七講:聊聊togaf的發展曆程_哔哩哔哩_bilibili
togaf 内容比較多9.0版本有中文版700+頁;9.2壓縮很多 500+頁,但是沒有中文版的文檔
togaf的模型設計工具ArchiMate
建議學習資料:Togaf 9.0 有中文版,或9.2英文版;金蝶軟體口袋書(80多頁,可以有個概覽)
學企業架構方法論,不要有批評思維去看,而是要先了解吸收。 起于思維止于思維,企業架構方法論是嘗試建立一個通用的方法。對一個方法論在整體深入認知之前急着拿着執行個體去看一個方法論的執行的話會産生很大偏差,因為執行個體都是個性化的。是以方法論和個性化執行個體之間有很多不對稱需要有很多折中。
1-7聚合架構第八講:ADM被罵的冤嗎?
1-7聚合架構第八講:ADM被罵的冤嗎?_哔哩哔哩_bilibili
麥田圈,葫蘆圖:是面向企業架構的過程的内容(Zachman架構方法缺失的)
架構變更管理:架構和計劃是可調的,根據落地執行情況修改。計劃的作用是用來修正的,幫你來評估修正計劃的代價,是否值得修正以及該不該修正。計劃不是毛病,架構也不是毛病,但是把計劃和架構做死了才是毛病。文檔裡面有描述思想是擁抱變化的,不是正常了解的固化的,各個步驟都是以需求為中心的。一個壞的執行結果不能歸咎于方法的好壞。
togal設計方法具有一緻性:如左圖,大的戰略計劃可以用這個圈過程,細化子層小的範圍也可以使用這個方法過程。從認知的角度逃不過這個圈:認識業務,認識應用架構,認識技術架構的實施方式,到評估方案是否可行,以及對舊系統的影響。這些思維過程都是繞不過的。
1-8聚合架構第九講:我們聊聊4個A?
1-8聚合架構第九講:我們聊聊4個A?_哔哩哔哩_bilibili
4A就是TOGAF的四個架構,業務架構、應用架構、資料架構、技術架構
4A 架構于Zarchman提出的架構應該是多視角多元度的思想一緻
左側框圖是ADM(麥圈圖方法過程)解釋下來的
架構原則、願景、需求包含兩個前置一個步驟:(預備階段、架構願景、架構需求)
設計階段:包括三個步驟,業務架構、資訊系統架構、技術架構
架構實作:包括三個步驟,機會與解決方案、遷移計劃;實施治理
企業架構就是4A架構的設計(元模型)和實施(架構資産管理平台)過程。
架構設計是軟體工程中的一環。
業務架構:定義了業務戰略、治理、組織和關鍵業務流程
資料架構:描述組織的邏輯和實體資料資産、以及資料管理資源的結構
主要是資料分布和模型定義;先把邏輯和實體資料資産定義出來,然後再看管理資源結構(分布)。
應用架構:為将要部署的單個應用程式、他們的互動及它們與組織的核心業務流程的關系提供藍圖。
業務流圖轉換到應用設計上之後形成服務流,服務分布和之間的調用順序。
技術架構:描述支援業務、資料、應用程式服務部署所需的邏輯軟硬體能力,即平時說的平台的分布。包括IT基礎設施、中間件、網絡、通信、處理、标準等
4A之間的關系:業務驅動模式推導應用=》資料=》技術的過程轉向以應用為紐帶連接配接業務與技術架構的模式(是以具體方案可能會多多考慮下技術資産中心位置)
按togaf和
下圖是本人自己簡單初步描述4A結構關系:
技術架構目前是很獨立了,尤其是很多開源的技術構件出來之後整個技術體系變得非常獨立,而且在資金到位的情況下可以買一整套的技術棧。不大需要從應用系統的架構去推技術架構應該什麼樣,比如:分布式技術棧已經都準備好了,直接考慮怎樣切除來功能在上面設計就行了,而不用從應用角度來推應該用什麼樣的技術平台,而是我有這樣技術平台應用功能是如何在上面進行設計。是以反而應用架構就退化成業務架構和技術架構的連接配接器。雖然現在都提倡技術驅動業務,現狀是業務架構和技術架構都很獨立,隻是應用存在諸多不确定性。
企業設計要從4A 視角這種全景視角來看企業内部系統設計比單一從某個某幾個技術視角看更合适
togaf使用場景:1) 全企業級别;2) 隻要超過兩個系統就可以使用不一定要到全企業時候才使用。
1-9聚合架構第十講:即使枯燥也得聊聊概念
1-9聚合架構第十講:即使枯燥也得聊聊概念_哔哩哔哩_bilibili
TOGAF中定義的企業,與工商系統的企業不是一回事,有共同目标的組織單元集合體就算企業。比如為實作某個目标的互相協作的兩個部門就可以合稱為一個企業。
基于TOGAF 對企業的定義,就應該有企業架構設計和頂層企業架構設計的說法了。頂層企業架構是機關最進階别的企業架構
架構:系統的基本組成部分、組成部分之間的關系、治理原則
架構這個定義是從ISO上引入過來的
企業架構曉岩大神的另一種說法: 披着數學外衣的國文課。表面上看着很有邏輯性,也希望能學建築行業長處能把結構和關系都做好,但實際真做到裡面的時候全是某一個語境下的語義問題,在某個語境下把某個語義考慮清楚了在拿某個文法去表達,幾乎全是這種我呢提。
1-10聚合架構第十一講:不服?那得治!架構治理
1-10聚合架構第十一講:不服?那得治!_哔哩哔哩_bilibili
架構治理在TOGAF中将近有7~8章的章節來介紹,從45章以後全都是,占篇幅不少
治理環境:
角色的分工、描述運作背景,怎麼讓架構運作起來
架構師隻管項目,不管實施。PMO來負責,這裡項目實施和Devops分開的(假設有Devops這情況)
企業連續統一體概念:
TOGAF 裡面沒有定義,教程裡面曉岩大師的解讀:
是個泛用的概念,架構有架構的連續統一體,解決方案有解決方案的統一連續體,連續統一體講的更像一個:一般性架構到一個特定架構的設計過程.,一個比較粗糙的提煉了一個共性的架構元素到一個細化的過程,然後兩者之間來回疊代互補。循環往複的過程:粗的一版基礎上做了一般具體的,這個具體的版本又作為下一個循環的起點,成為下一次架構的一般性架構。一般架構庫<=>解決架構庫
我本人的了解:這裡是從上到下箭頭是指導填充,從下往上的箭頭是指遵從的意思
治理機構:
管理角度來講,治理機構(架構委員會或高層的架構管理辦公室)指導整個架構運作環境的管理。
給架構專業人員通過教育訓練提供架構技能和知識(技能和知識的定義沒有明确的解釋,不知道這個知識和TOGAF裡面的技能成熟度中第三級知識是不是一回事),但TOGAF有一張架構師的技能架構(羅列内容很多,做一個合格架構師不太容易),其中把架構人員的技能成熟度分四級:背景、認知、知識、專家。
架構設計師要配合PMO進行項目管理和項目治理
架構師的角色和職責(一般的或項目特定的,後續課程曉岩大神會專門來講)
治理六大特點:企業項目管理的與之相去甚遠,是公司級别的了。紀律性、透明性、獨立性(不受公司經營的特殊的左右)、追責(相關人違反契約時要進行追責)、負責(對承擔的工作負起責任)、公平。是從公司治理角度套用特點了這樣的六個特點來描述架構治理的
IT和業務之間的關系:目前看是IT治理和業務營運是分野的,長期來看的趨勢講更深層次的融合的,在企業的管理層、業務側把架構師引進來,而不應該是内部的甲方乙方的關系。
企業架構應該成為新時代即數字時代的企業管理語言,成為企業管理思維。不僅僅是IT設計思維。如果僅停留在IT範圍内進行IT治理的話是不夠的,這也不符合公司對IT的期望。反過來說膽子也不應都在IT測,管理層要把企業架構引入到業務側。
1-11聚合架構第十二講:聊聊啥是企業架構師吧
1-11聚合架構第十二講:聊聊啥是企業架構師吧_哔哩哔哩_bilibili
企業架構師:
1)覆寫所有利益相關者的所有關注(多視角)
2)對利益相關者之間的沖突進行關注,做出權衡(權衡設計不是最優設計)
3)對架構視圖的權衡受實用性和适用性限制
4)與企業管理人員充分合作,保障架構設計可追溯到業務決策
5)架構師不是建造者,必須保持一定程度的抽象,以確定不妨礙實施
6)架構師關注重要細節,但不可以是以過載(細節失控和整體掌控的辯證關系)
職責:
1)了解并解釋需求
2)建立有用的模型,必須了解所有必要的業務元件
3)确認和細化擴充模型,評估源于現場的增強解決方案的價值
4)管理架構,促成改變
特點:
1)産生技能和經驗
2)具備一個或幾個技術領域的深度和廣度
3)設計方法論的能力;
4)項目全周期的經驗
5)具備一個或多個行業的工作經驗
1-12聚合架構第十三講:該總結下togaf的優缺點了
1-12聚合架構第十三講:該總結下togaf的優缺點了_哔哩哔哩_bilibili
TOGAF既不是教科書也不是論文。不是教科書因為沒有考慮缺乏工程經驗的人使用,不是論文是因為沒有在某些細節寫的很深。所有容易被人從各種角度去攻擊。是以在學習某個方法論的時候一定要分析優點和不足,以便總結自己的理論,從TOGAF中要學到作為一個方法論要考慮哪些方向。我們自己的經驗該怎樣去總結,讓我們的經驗成體系,而不隻是一些散的知識點。
不足:
1)ADM方法每個步驟怎麼設計,建構塊怎樣誕生沒有說明
2) 架構統一體怎樣來保證,難以實作行業級連續統一體
3)難以讓企業架構超越技術标簽,是以推行自己的企業架構方案一定要考慮業務友好性。業務友好性是決定某個方法使用的基礎。
1-13聚合架構第十四講:CBM的專業化
1-13聚合架構第十四講:CBM的專業化_哔哩哔哩_bilibili
1-14聚合架構第十五講:為啥咨詢公司就能從高往低打
1-14聚合架構第十五講:為啥咨詢公司就能從高往低打_哔哩哔哩_bilibili
1-15聚合架構第十六講:聊聊CBM能幹啥
1-15聚合架構第十六講:聊聊CBM能幹啥_哔哩哔哩_bilibili
1-16聚合架構第十七講:CBM的分析過程和結果是啥樣的
1-16聚合架構第十七講:CBM的分析過程和結果是啥樣的_哔哩哔哩_bilibili
右側矩陣圖很有價值,每個格子與資訊化系統關聯矩陣
可以描述資訊系統對對應關系(可以分析哪些系統是缺失的,哪些是支援過度的)
1-17聚合架構第十八講:聊聊CBM哪好哪差吧
1-17聚合架構第十八講:聊聊CBM哪好哪差吧_哔哩哔哩_bilibili
1-18聚合架構第十九講:道聽途說DoDAF之曆程篇
1-18聚合架構第十九講:道聽途說DoDAF之曆程篇_哔哩哔哩_bilibili
1-19聚合架構第二十講:今天聊聊DoDAF的主要概念
1-19聚合架構第二十講:今天聊聊DoDAF的主要概念_哔哩哔哩_bilibili
企業架構的概念:
架構思維進入管理思維
數字化轉型一個企業要同時管理包括IT行業和自身兩個行業,把業務架構視角和技術架構視角整合起來看整個企業的架構思維
業務融合
資料共享
DoD 資料為中心、企業管理引入架構思維(架構能反應基線、能夠反應變化和成長路徑和計劃[目标]、分布實施)
目标:适用(fit-to-purpose)