推薦語
：這是一本從實操角度探討企業架構落地的書籍，對於高階的軟件產品設計人員，即使沒有技術背景，也能夠經過閱讀本書，對企業級軟件架構的模塊化拆解設計有進一步的啓發和認識。
我在《決勝B端》最後一章提到過企業架構（EA，Enterprise Architecture）的概念。
EA是經典的IT建設方法論，給出了從業務戰略到IT架構推演的指導方針。
遺憾的是，EA相關的資料，彷佛除了Zachman、TOGAF等幾套方法論，就不多有文章、書籍，可以深入地探討其具體的落地過程，這也讓EA的理論框架略顯尷尬，總給人高高在上，術高莫用之感。
這一方面是由於，企業架構自己是一個高階軟件研發課題，可以真正有機會參與到企業架構設計的人並很少；另外一方面是由於，企業架構某些方面來說偏形而上，從幾套業界的方法論，到具體實踐層面，存在着一個鴻溝，不少人能夠泛泛的談論這套鴻溝上的橋樑的模糊形狀，但具體如何搭建這座橋樑，其實並不清楚。
直到本書的出現，做者付曉巖老師，多年來在銀行領域從事企業級業務架構設計，親自將EA方法論應用於實際工做，對架構設計有着很是豐富的理論經驗與實戰經歷。所以，付老師勇於突破，大膽嘗試了無數人都不敢碰觸的「燙手山芋」——企業應用架構話題，給出了一套通過實踐得出的企業架構搭建方法論。
因此，這本書去年8月剛上市時，我就第一時間買到，並一口氣讀完。總體閱讀下來，感受很是有收穫，但理解書中的內容，確實須要必定的經驗儲備。
整本書的核心，是經過邁克波特的價值鏈模型做爲理論基礎，基於價值鏈塑造的業務流程爲出發點，分析多場景下的業務對象本質，並通過超越了業務場景的實體抽象過程，獲得了企業級視角下的數據模型。
以上描述，估計過於抽象。接下來，我把書中印象比較深入的一些關鍵內容整理分享，儘可能嘗試可以把書中的核心觀點呈現給你們。
首先，遵循EA的理念，書中也一樣從企業戰略分析、業務分析入手，做爲整個架構設計的起點，以下圖。
業務架構可從企業戰略出發，按照企業戰略設計業務及業務過程，業務過程是須要業務能力支撐的，從戰略到業務再到對業務能力的須要，就造成了支持企業戰略實現的能力佈局，能夠將這個佈局理解爲業務架構，它是企業爲客戶創造價值的設計過程。業務架構設計會盡量地追求以更爲集約的能力實現更爲多變的業務或服務，這其實也是中臺戰略追求的目標，於是，中臺戰略實際上也能夠歸結爲一種業務架構設計。
業務架構設計完成後，「靈魂」就誕生了，IT架構則是根據「靈魂」的須要來設計「容器」。IT架構的分類方式並無統一的說法，一般會分爲應用架構和技術架構，而近些年隨着大數據的發展，數據架構的地位直線上升。此外，隨着數據安全問題日益受到重視，許多企業的IT架構也將安全架構置於重要的位置上。
所謂企業架構，必須以企業全局的視角思考、設計，可是實踐中，每每受到組織治理、組織結構的約束，難以按照企業級的方法論去執行。這其實也正是中臺建設中每每遇到的問題。針對這個問題，做者談到：
作業務模型，有兩個原則須要注意，其中之一就是總體性。設計業務架構，咱們固然但願可以通盤考慮整個企業，而不要由於部門利益影響組件邊界的劃分，影響功能設計。作出來的模型，凡是公用的部分，應該照顧到全部利益相關方的需求；凡是已實現的功能都應該對新的需求方開放並支持必要的擴展，這是企業級設計應該追求的目標，可是，實現起來經常困難重重。
企業不管大小，一旦系統的設計邊界跨越了單個部門的職能範圍時，都會出現部門利益問題，無非是企業規模、文化差別形成的協調難度的差異。在企業內部，部門利益是部門需求的自然邊界，即使要作企業級，各方確定也是要先說清楚本身的需求，再去考慮別人的需求，「種了別人家的田，荒了自家的地」是絕對不行的。因此，各部門在參與到企業級談判中時，都是首先要知足本身所在部門的業務訴求。
尤爲是下邊這段論述，我以爲很是精闢，不能爲了衆人皆大歡喜而退而求其次的產生折中方案，若是不符合企業級的建設訴求，還不如不作，這是實踐中的道德真知灼見。
這就要求，做爲業務架構的設計者，拿出來的方案最好是以一種更有效的方式來知足全部相關方的需求，而不是單純作抽象、歸併，要各部門「你讓一隴地，他少一棵樹」的方式搞折中，這樣作實際上就失去了作企業級的核心價值，由於這樣的折中既沒法保證系統的先進性，也沒法保證用戶體驗，甚至還可能發生退步。部門利益是作企業級的最大障礙，跨越這個障礙是對業務架構師設計能力的最高挑戰。固然，客觀地說，沒有更好的解決方案時，不動也是一種選擇，由於，一樣接受這個挑戰的還有企業文化。
在探討企業級不單純是架構設計問題，也是業務管理問題與利益分配問題時，做者給出了一個銀行體系積分平臺的例子，很是有表明性的說明了工做中面臨的各類複雜狀況。
舉個例子，銀行都有積分系統，近年來各行也都作了綜合積分，其實其中的實現難度很大，主要問題不在技術而在業務。理想的綜合積分是企業只有一個積分系統，支持全部產品的不一樣積分規則。對不一樣的客戶羣、不一樣的營銷方案能夠進行參數化配置，最重要的是，支持以單一積分形式統一用於獎勵兌換，而不是想要換個包，還得分別花去信用卡積分、黃金交易積分、基金業務積分，這樣客戶體驗會很是糟糕。
可是若都使用一個積分，那麼又會出現這樣的內部問題，信用卡部門爲了促銷，提升了積分發放，這樣信用卡用戶就在積分的獲取上佔了便宜，而客戶的資金終歸是有限的，所以黃金交易的業務量就有可能會掉下去。黃金交易的管理部門有樣學樣，也開始提升積分，結果就會形成積分的營銷費用提早花光，反應稍慢的部門便已經沒有機會進行促銷了。
說到這裏，讀者可能已經明白了，綜合積分背後的博弈多是營銷費用的分配。在開展綜合積分活動之前，這筆營銷費用有多是提早劃分到各部門的，各部門自行支配，蛋糕先分好，以後就不會再「打架」。若是綜合積分設計不考慮清楚這個問題，就會動了多數人的蛋糕。
因此，若是能解決這個問題，那麼綜合積分的活動就能真正作到在一個組件裏展開，若是解決不了，仍是各自爲政，那麼是否放在一個組件中就沒有實際意義了，只是解決積分綜合查詢問題的話，有不少方法都好過功能遷移。
本書的核心部分，是推演了從業務戰略到技術實現落地的企業級架構建設過程。對於企業級的業務戰略分析，做者重點介紹了知名的邁克波特價值鏈模型，做爲後續架構設計分析的起點和理論基礎，以下圖。
在波特的價值鏈模型中，認爲企業在創造價值的過程當中，全部生產經營涉及的活動能夠分爲兩類，即支持性活動和基本活動，前者支撐價值創造過程，後者完整價值創造和增值過程。
做者以價值鏈基本活動爲出發點，推導了從價值鏈向業務組件的演化過程，做者寫道：
價值鏈表明瞭構建企業能力統一視圖的「橫向」結構，每一個價值鏈環節中均包含了若干個業務流程；業務領域表明了構建企業能力統一視圖的「縱向」結構，描述了各種業務流程應如何經過組合實現領域級的業務目標。
業務流程即業務活動，業務活動是由不一樣角色分別完成的若干任務組成的，任務執行過程當中其必然與業務數據發生聯繫。數據主題域能夠將關係緊密的數據進行聚類，再將與數據關係緊密的行爲（也就是任務聚類），造成包含行爲和數據的業務組件，組件表明了企業的某一類業務能力。
做者認爲，基於價值鏈環節完成的業務組件的提煉，將完成企業級的能力服用提煉和抽象，做者寫道：
若是能在設計及後續迭代過程當中多注意對任務的企業級分析和對組件能力的開放共享，避免因組件能力與主要應用部門間的關係產生對其餘應用的天然壁壘，則如上圖所呈現的業務架構邏輯，能夠支持不一樣領域的不一樣活動對同一任務的自由複用，也就是常說的企業級能力複用。儘管本書以前的分析其實一直在儘可能避免出現活動層面跨價值鏈環節的複用，可是這並非表明排斥這種狀況的出現，一切還應視實際須要而定。
接下來，做者經過一個完整的銀行案例，闡述了以上理論是如何落地實操的，也是我認爲本書中最精彩的部分。
做者描述了銀行存款和貸款兩個業務的產品設計、獲客、營銷過程，經過分別研究這兩個不一樣業務主題各自的業務環節，最終提煉、抽象、合併背後的主題設計，來實現超越了業務線的企業級的領域架構抽象。
首先來看下存款業務的產品設計、上架、獲客和轉化過程，注意下圖中上邊是價值鏈環節（或核心業務過程），下圖是基於不一樣角色，針對價值鏈環節抽象出的業務組件（其實有點相似於咱們總說的實體）。
咱們能夠看出從上圖中抽象提煉了若干組件（或叫實體），包括客戶信息、帳戶信息、合約、產品等。
接下來再分析貸款業務的價值鏈環節，也涉及到貸款產品開發、獲客、轉化等環節。
接下來，很重要的一部，是從企業級的角度，考慮兩個業務線中，哪些組件是能夠合併並進一步抽象的，從而能夠爲其餘業務線提供複用。
通過一系列的分析，最終合併獲得產品、客戶、合約、帳戶四個組件，關於合併的思考過程，請你們閱讀原書。
上圖的架構，體現了一種超越業務線的架構設計，其中最重要的就是超越了業務屬性的組件的提煉，所謂組件，是技術底層最核心的數據對象，表明了對業務本質的理解和高度抽象。準確的提煉出企業級組件，表明着將來對於其餘相似的新業務均可以提供企業級的能力複用。
讀到這裏，可能不少朋友認爲這些都是技術話題，但其實對於高階的B端產品設計，對業務的支撐、賦能是一方面，對產品、技術本質的理解、提煉是另外一方面，二者都須要有很是深入地認知，缺了某一塊，都不能作出優秀的企業級軟件產品。
圍繞着以上企業級組件的構建過程，在書中做者還談到了團隊管理、組織架構、項目推動挑戰等各方面話題，對於我我的來說，印象最深入的是以上部分。
實際上以上提到的抽象的方法論，也是目前行業內中臺建設一個很重要的落地實踐過程。企業級架構設計中，經過技術能力的抽象和沉澱，封裝並強化了業務能力，能夠從技術角度快速支持新業務開展，不正是中臺的思路麼？
而書中提到的組件抽象，不正是《決勝B端》中提到的在產品設計中須要作的業務建模麼？
其實軟件設計的本質都是相同的，你理解他的本質，並不必定須要會編程，可是這種抽象思惟和建模思惟，是必須具有的。
今年9月，有幸和付老師相聚，暢談甚歡，被付老師的博學所折服。
↑ 掃碼關注付曉巖老師公號編程
本文分享自微信公衆號 - 曉談巖說（gh_18519a945f4e）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。安全