很多企業希望能夠做數位化轉型，但是一到具體啟動做的時候又覺得兩眼一抹黑，不知道如何下手。這次培訓向我們闡述了如何可以通過togaf這種方**把戰略進行落地。
作為軟體開發工程師，我們總是習慣於努力盡責的把分配給我們的開發任務按時按質完成，再有業務導向一點的開發會在受理需求前會先向業務了解清楚具體的需求背景及想解決的業務問題，這已經很不容易了。
因此，為什麼需要去解決這個業務問題？背後跟企業的業務戰略有什麼關係？或者說企業的業務戰略是如何一層層的對應上我們日常的開發工作呢？作為乙個合格的架構師，無論是業務架構、技術架構或應用架構，這都是必須得知道的基本事實。我的理解是togaf就是那個把企業的戰略有效略對映到it系統層面的那個方法。它的內涵是強調it與業務對齊，通過建立企業架構將戰略規劃落地，保證架構的規劃是以業務為驅動和主導，架構落地後能夠實現業務目標；這跟我們的目標管理是同一原理的，就是通過自頂而下的進行目標的分解，而只有從上到下的分解才能保證it的動作能夠跟業務目標緊緊對應上的。
togaf9.2作為企業架構的標準，它包含了以下四種架構（具體如下圖），其中我這裡想要稍微討論一下我對業務架構（ba）和應用架構（aa）的一些理解。
1、業務架構（business architect）2、資料架構（data architect）
4、技術架構（technology architect）
首先，業務架構在togaf方**上是上承業務戰略下接技術的乙個中間關鍵環節，它明確定義了企業的治理結構、業務能力、業務流程及業務資料。其中，業務能力定義了企業做什麼，業務流程定義了企業怎麼做。
在明確業務能力的這個範疇內，業務架構師需要通過政策研究、高層訪談及同業調研等手段確定我們要做推行這個業務戰略的驅動因素及業務目標，即是企業要做什麼來達到這個業務戰略。接著，業務流程則明確了針對流程中每個部門的定位及職責、具體業務規則、業務資料流向等維度的資訊。既然企業架構是企業對市場資訊認知的體現，那麼業務架構（ba）就是實現或者實施這個體現的乙個具體方**。
為什麼我會這麼說？舉個例子，在企業剛開始那幾年，企業首要做的是生存下來，然後會出現什麼狀況？所有系統的建設都是基於急用先行而進行建設的，就妄論系統間的資料共享或功能復用之類的高階需求了，因此導致煙囪林立，這也是我們目前的現狀。但是隨著新煙囪的增加和舊煙囪的進一步鞏固，需求交付會隨著功能複雜度增加和跨團隊溝通成本提高而呈現下降趨勢，這個時候會出現慢慢跟不上業務節奏的現象。這個時候，可能業務功能（或者叫業務戰略）大體還是沒變的，但是隨著規模的擴大，可能原有的業務流程已經不適應了，這個時候就是業務架構（ba）要開始發揮能力的時候了。這個時候，它需要根據企業實際的情況（如組織架構的變動、流程變動）重新定義或調整新的業務流程以便更好的適應或者支援業務。
例如，本人所負責的幾個業務條線在這幾年陸陸續續在往導流方向發展，每個業務條線的業務流程都是基本差不多，更多不同點可能就是需要收集的資訊不一致，或者渠道展示風格不一致。研發側也會發現實際上大體流程是可以復用的，因此覺得可以共建，但是業務側也會有自己的想法（例如資源專屬、風格各異等），這本身沒錯的畢竟每個業務條線也背各自的kpi，那肯定按自己業務構想去做是最安全的，就算指標達不到也認命了（自己挖的坑自己哭著也認了）。但是這個怎麼解決資源復用和資源專屬的衝突呢？就沒有辦法嗎？按照業務架構（ba）的方法，應該是從業務流程層面定義清楚如何把這三個業務條線進行求同存異或者如何分段管理，並跟領導層溝通並得到充分理解與認同。一旦有了這個新調整的業務流程，研發側在系統開發時候才能更加有跡（原則）可循，從而研發效率才能得到提公升，基於復用最大化為目標的中台化才能更加順利的落地。
首先，正如溫老師所說的，這裡的應用架構指的不是應用系統的架構，而是一組應用系統及其相互關係的描述，它是用於定義為了支援某類業務所需要使用到的系統，相對來說比我們平時的系統架構要巨集觀一點，因為它不關注單個應用系統的內部實現。
還記得應用架構設計的流程嗎？
首先，應用架構需要從業務架構藍圖中的業務功能及流程圈定具體的業務需求。我這裡稍微展開一下。作為應用架構，我覺得從業務本質出發是很有必要的。首先什麼是架構？架構的目的就是解決利益相關者的關注點，以下左圖取自於《軟體系統架構：使用視點和視角與利益相關者合作》，我嘗試使用腦圖（即右圖）進行分解。每個系統實際上是為了滿足利益相關方的一系列需求，具體方式是通過系統架構裡面的一系列元素，諸如那些-ability、業務功能點及其相互關係所呈現的一堆架構視野（viewpoint）去分別對應的滿足利益相關方的每乙個關注點。再回到應用架構這個範疇，業務藍圖實際上就是企業的整體戰略，也即整體需求，因此從業務藍圖中圈定範圍也是必然的，因為從這裡開始才能保證所有干係人的需求得到滿足。
接著，應用架構需要根據業務功能及流程進行分析所需要提供什麼系統；實際上，這裡告訴我們的是需要什麼系統承載什麼功能，但是尺寸在系統級別而非服務級別。
然後，根據某種方**把所有的功能進行歸類並分配指定到相應系統中；這裡要表達的是結合業務的領域驅動設計（ddd）的方**，針對同一型別的業務要進行歸併處理，做成服務層高內聚低耦合。
最後，針對每個系統制定系統間的互動方式，劃分服務粒度等。這裡的就是系統架構的範疇，因為它涉及到系統服務間的粒度劃分及對應的技術實現細節。
從上面可以 ，這儼然就是指導業務中臺建設的方**。為什麼我會這樣說？可以拿所負責的某些系統作為例子，以前做系統的時候我們採取的是急用先行的策略先開發了一堆系統，但是在發展到一定規模的時候，業務覺得要精細化和規範化管理了，因此我們要準備上統一客戶管理系統了；整個公司各個系統的功能有一定程度的重疊和交叉，內部協調成了大問題。整個過程我們就像在打區域性資訊化戰爭一樣，頭痛醫頭腳痛醫腳，需要解決什麼樣的問題，就上什麼樣的系統，最終就形成了所謂煙囪式的系統架構，這又導致整個架構重複造輪子，跨系統管理也給運營人員造成了不必要的時間精力浪費。
我的理解是中颱嚴格意義上就是一種業務戰略，大家再細品一下是不是這樣的道理。首先，企業架構是企業對市場資訊認知的體現，那中台就是企業在不斷發展的過程中，隨著對市場資訊的認知不斷加深，為了保證其企業在不斷變化的過程中具備這種快速響應的能力，唯有通過在其紛繁各異的業務流程中尋找共同點並作為最佳實踐的方式固化在所謂的業務系統中，這便是中颱的價值所在，也是中颱存在的第一性原理。
經過這一天的企業架構培訓，確實掀開了我對企業架構的乙個初步認識，但是如何進一步結合現在的業務和系統現狀，然後通過togaf方**進一步細化業務架構（ba）和應用架構（aa）確實乙個比較高階的工作，暫時確實只是略懂皮毛，後面可能更多的需要在日常工作中進行實踐，同步看看行業的一些最佳實踐。
新人培訓感悟
近幾個月來，一直培訓新人。也頎喜，也很累。其實說是培訓新人，卻發現連我自己一併培訓起來。眾多知識以為自己已經懂了，卻發現其實不懂 一直避而不理的範疇以為可以避開一輩子，怎知道躲也躲不開。慚愧之感油然而起，故奮而直追。可是，軟體工程看了半天，不得要領 系統架構雲裡霧裡。看來是要把自己當成新人，好好地自...
職場培訓感悟
今天有幸參加公司組織的一場職場培訓，剛開始覺得我們工作這麼久了，應該職場怎麼樣比較清楚，但是參加了這個培訓，才發現職場上還是有很多東西，很多技巧，很多方法需要我們注意的。在這邊就分享幾個 積極方面考慮消極的。對待周圍一切都要懷著感恩的心。有了感恩心，再大的困境都可以以積極的心態去迎接，去應對解決。為...
培訓感悟（一）
兩天的 領袖的風彩 培訓終於結束了，原本想好好休息一下的，卻又搞得累累的回家。雖然很累，我想所有參加這次培訓的人與我一樣，都深深覺得很值。通過這次培訓讓我們更多的看到了自身的不足，自已所處的團隊，所帶領的團隊的不足。另外就是有一種深深的後怕感，如果再不深思，再不改進，很快我們這樣的企業，也許就不存在...