企業架構培訓感悟

一、前言

很多企業希望能夠做數字化轉型，但是一到具體啟動做的時候又覺得兩眼一抹黑，不知道如何下手，這次培訓向我們闡述了如何可以通過TOGAF這種方法論把戰略進行落地，

二、為什么企業架構那么重要？

作為軟體開發工程師，我們總是習慣于努力盡責的把分配給我們的開發任務按時按質完成，再有業務導向一點的開發會在受理需求前會先向業務了解清楚具體的需求背景及想解決的業務問題，這已經很不容易了，

因此，為什么需要去解決這個業務問題？背后跟企業的業務戰略有什么關系？或者說企業的業務戰略是如何一層層的對應上我們日常的開發作業呢？作為一個合格的架構師，無論是業務架構、技術架構或應用架構，這都是必須得知道的基本事實，我的理解是TOGAF就是那個把企業的戰略有效略映射到IT系統層面的那個方法，它的內涵是強調IT與業務對齊，通過建立企業架構將戰略規劃落地，保證架構的規劃是以業務為驅動和主導，架構落地后能夠實作業務目標；這跟我們的目標管理是同一原理的，就是通過自頂而下的進行目標的分解，而只有從上到下的分解才能保證IT的動作能夠跟業務目標緊緊對應上的，

TOGAF9.2作為企業架構的標準，它包含了以下四種架構（具體如下圖），其中我這里想要稍微討論一下我對業務架構（BA）和應用架構（AA）的一些理解，

1、業務架構（Business Architect）

2、資料架構（Data Architect）

3、應用架構（Application Architect）

4、技術架構（Technology Architect）

三、業務架構（BA）

首先，業務架構在TOGAF方法論上是上承業務戰略下接技術的一個中間關鍵環節，它明確定義了企業的治理結構、業務能力、業務流程及業務資料，其中，業務能力定義了企業做什么，業務流程定義了企業怎么做，

在明確業務能力的這個范疇內，業務架構師需要通過政策研究、高層訪談及同業調研等手段確定我們要做推行這個業務戰略的驅動因素及業務目標，即是企業要做什么來達到這個業務戰略，接著，業務流程則明確了針對流程中每個部門的定位及職責、具體業務規則、業務資料流向等維度的資訊，既然企業架構是企業對市場資訊認知的體現，那么業務架構（BA）就是實作或者實施這個體現的一個具體方法論，

為什么我會這么說？舉個例子，在企業剛開始那幾年，企業首要做的是生存下來，然后會出現什么狀況？所有系統的建設都是基于急用先行而進行建設的，就妄論系統間的資料共享或功能復用之類的高階需求了，因此導致煙囪林立，這也是我們目前的現狀，但是隨著新煙囪的增加和舊煙囪的進一步鞏固，需求交付會隨著功能復雜度增加和跨團隊溝通成本提高而呈現下降趨勢，這個時候會出現慢慢跟不上業務節奏的現象，這個時候，可能業務功能（或者叫業務戰略）大體還是沒變的，但是隨著規模的擴大，可能原有的業務流程已經不適應了，這個時候就是業務架構（BA）要開始發揮能力的時候了，這個時候，它需要根據企業實際的情況（如組織架構的變動、流程變動）重新定義或調整新的業務流程以便更好的適應或者支持業務，

例如，本人所負責的幾個業務條線在這幾年陸陸續續在往導流方向發展，每個業務條線的業務流程都是基本差不多，更多不同點可能就是需要收集的資訊不一致，或者渠道展示風格不一致，研發側也會發現實際上大體流程是可以復用的，因此覺得可以共建，但是業務側也會有自己的想法（例如資源專屬、風格各異等），這本身沒錯的畢竟每個業務條線也背各自的KPI，那肯定按自己業務構想去做是最安全的，就算指標達不到也認命了（自己挖的坑自己哭著也認了），但是這個怎么解決資源復用和資源專屬的沖突呢？就沒有辦法嗎？按照業務架構（BA）的方法，應該是從業務流程層面定義清楚如何把這三個業務條線進行求同存異或者如何分段管理，并跟領導層溝通并得到充分理解與認同，一旦有了這個新調整的業務流程，研發側在系統開發時候才能更加有跡（原則）可循，從而研發效率才能得到提升，基于復用最大化為目標的中臺化才能更加順利的落地，

四、應用架構（AA）

首先，正如溫老師所說的，這里的應用架構指的不是應用系統的架構，而是一組應用系統及其相互關系的描述，它是用于定義為了支持某類業務所需要使用到的系統，相對來說比我們平時的系統架構要宏觀一點，因為它不關注單個應用系統的內部實作，

還記得應用架構設計的流程嗎？

首先，應用架構需要從業務架構藍圖中的業務功能及流程圈定具體的業務需求，我這里稍微展開一下，作為應用架構，我覺得從業務本質出發是很有必要的，首先什么是架構？架構的目的就是解決利益相關者的關注點，以下左圖取自于《軟體系統架構：使用視點和視角與利益相關者合作》，我嘗試使用腦圖（即右圖）進行分解，每個系統實際上是為了滿足利益相關方的一系列需求，具體方式是通過系統架構里面的一系列元素，諸如那些-ability、業務功能點及其相互關系所呈現的一堆架構視野（viewpoint）去分別對應的滿足利益相關方的每一個關注點，再回到應用架構這個范疇，業務藍圖實際上就是企業的整體戰略，也即整體需求，因此從業務藍圖中圈定范圍也是必然的，因為從這里開始才能保證所有干系人的需求得到滿足，

接著，應用架構需要根據業務功能及流程進行分析所需要提供什么系統；實際上，這里告訴我們的是需要什么系統承載什么功能，但是尺寸在系統級別而非服務級別，

然后，根據某種方法論把所有的功能進行歸類并分配指定到相應系統中；這里要表達的是結合業務的領域驅動設計（DDD）的方法論，針對同一型別的業務要進行歸并處理，做成服務層高內聚低耦合，

最后，針對每個系統制定系統間的互動方式，劃分服務粒度等，這里的就是系統架構的范疇，因為它涉及到系統服務間的粒度劃分及對應的技術實作細節，

從上面可以 ，這儼然就是指導業務中臺建設的方法論，為什么我會這樣說？可以拿所負責的某些系統作為例子，以前做系統的時候我們采取的是急用先行的策略先開發了一堆系統，但是在發展到一定規模的時候，業務覺得要精細化和規范化管理了，因此我們要準備上統一客戶管理系統了；整個公司各個系統的功能有一定程度的重疊和交叉，內部協調成了大問題，整個程序我們就像在打區域資訊化戰爭一樣，頭痛醫頭腳痛醫腳，需要解決什么樣的問題，就上什么樣的系統，最終就形成了所謂煙囪式的系統架構，這又導致整個架構重復造輪子，跨系統管理也給運營人員造成了不必要的時間精力浪費，

我的理解是中臺嚴格意義上就是一種業務戰略，大家再細品一下是不是這樣的道理，首先，企業架構是企業對市場資訊認知的體現，那中臺就是企業在不斷發展的程序中，隨著對市場資訊的認知不斷加深，為了保證其企業在不斷變化的程序中具備這種快速回應的能力，唯有通過在其紛繁各異的業務流程中尋找共同點并作為最佳實踐的方式固化在所謂的業務系統中，這便是中臺的價值所在，也是中臺存在的第一性原理，

五、后話

經過這一天的企業架構培訓，確實掀開了我對企業架構的一個初步認識，但是如何進一步結合現在的業務和系統現狀，然后通過TOGAF方法論進一步細化業務架構（BA）和應用架構（AA）確實一個比較高階的作業，暫時確實只是略懂皮毛，后面可能更多的需要在日常作業中進行實踐，同步看看行業的一些最佳實踐，