春節前應「技術瑣話」之約，試圖寫一篇討論架構方法論的文章，然而動筆之後，才發現，自己似乎陷入了Frederick P. Brooks先生在《設計原本》一書中指出的問題：「設計中最困難的部分在於決定要設計什麼」。
2020年1月18日，有人戲稱是「中臺」歷史上最「困難」的一天，一篇炸圈的文章將對「中臺」的討論又一次推向高點，雖然「潑冷水」的意味十足。其實筆者之前也談到過，「中臺」自誕生伊始就非一個嚴謹的定義，而是一種比喻，比喻當然也就容易導致爭論不休，「中臺」現在面臨的問題其實也和筆者動手寫這篇文章面對的問題差不多。但是，將「中臺」理論不斷明晰化的嘗試仍是個好事情，畢竟，這是國內企業掀起的一次對架構設計方法的有益探索。
筆者在2019年11月南京中臺大會上也曾講到，如今很多領域都在談國產化、自主可控，架構領域難道不需要嗎？架構領域方法論的持續完善、國產理論的持續創新，是駕馭技術組合的關鍵，底層技術的不斷自主化並不會必然帶來頂層設計能力的自主化，而數位化轉型，除了需要底層技術的支撐外，卓越的上層設計更是重中之重。走出有中國特色的數位化道路，底層技術能力與上層設計能力缺一不可。
對企業級軟體架構設計方法的研究需要所有人共同關注，它是在持續進化的，也是未來企業走向數位化過程中，實現業務與技術深度融合的必經之路。Brooks先生在同一本書還提到：「好的設計者應該投入大量精力來學習判例……但現代設計匆忙的節奏卻對這種實現非常不利」，他寫下此語是在10年前，今天，這種情況只能說是有過之而無不及吧。
討論架構問題永遠是困難的，雖然筆者能力有限，但是出於對架構理論的愛好，還是嘗試通過本文與各位讀者共同探討架構方法的演進與改良。
一、軟體工程與企業架構
（一）懵懂的早期：沒有工程、沒有架構
架構設計是隨著軟體複雜度的上升而真正受到人們重視的。1946年，巨大的電子管計算機ENIAC誕生，軟體行業的帷幕拉開，但是此後十幾年的時間裡，軟體設計都只是少數人的事情，這個行業大部分時間都在實驗室中發展。雖然高級語言出現，但是大多數程序設計人員的主要武器是彙編語言。模塊化的思路逐漸出現，但是軟體過程管理是很原始的，也沒有所謂的架構設計方法，流行的就是「先寫了再說」。
（二）方法的開始：瀑布模型和 Zachman 模型
混亂的管理方式引發了60-70年代的軟體危機，於是，1968年NATO會議上，「軟體工程」的概念首次被提出，其核心思想就是建立並使用完善的工程化原則，通過一系列方法，以較經濟的手段獲得能在實際機器上有效運行的可靠軟體。這個「樸素」的目標，反映了軟體行業早期存在的時間不可控、質量不可控、預算不可控等諸多問題造成的困擾。
1970年，Winston Royce在《大型軟體系統開發的管理》一文中，提出了「瀑布模型」，將開發分成如圖1所示的7個明確的階段：
中臺辨析：架構的演進趨勢
圖1瀑布模型
Royce其實認為這是一個有風險的開發過程，並提出了5個修改建議，包括在分析階段之前增加一個在信息不足條件下的預設計、開發過程中增加客戶參與等，但是大家卻把這個被他列為批評對象的「瀑布模型」作為開發的標準過程，包括美國國防部，他的建議卻鮮為人知了。其中的分析階段也就包括了架構設計工作，逐漸又被細分為概要設計和詳細設計。但是這個時期的架構設計主要還是針對軟體設計，還沒有發展出成形的企業架構理論。
隨著人們對軟體設計工作認識的不斷深入，大型軟體設計與企業管理的關係越來越緊密，這也體現了人們對軟體設計的本質性目標——為企業服務的認知。基於此，1987年Zachman提出了首個較為完整的企業架構模型，該模型按照「5W1H」，即What（數據）、How（功能）、Where（網絡）、Who（角色）、When（時間）、Why（動機）6個維度，結合目標範圍、業務模型、信息系統模型、技術模型、詳細展現、功能系統6個層次，將企業架構分成36個組成部分，描述了一個完整的企業架構要考慮的內容，如表1-1所示。
中臺辨析：架構的演進趨勢
表1 Zachman模型簡介
這個架構設計方法論已經將系統設計應支持企業經營管理目標的要求表達出來，但是該模型的一個不足是Zachman並沒有給出一個詳細的構建方法。
（三）成熟的進步：螺旋模型和 TOGAF
1988年，軟體工程上又一個裡程碑式的方法誕生了，Barry Boehm提出了「螺旋模型」，該模型如圖2所示：
中臺辨析：架構的演進趨勢
圖2螺旋模型
螺旋模型通過持續對原型進行驗證式、增量交付的方式，彌補「瀑布模型」在需求管理方面不足，是一種對需求的漸進式探索，也加強了對項目風險的管理。Brooks在2010年著書時仍對該模型讚賞有加。
隨著信息化程度的加深，企業越發認識到將IT融入企業管理的重要性，IT人員也意識到與業務結合的重要性，於是，1995年TOGAF（The Open Group Architecture Framework ，開放組體系結構框架）應運而生，業務架構的概念也被明確提出來。TOGAF認為企業架構分為業務架構和IT架構兩大部分，業務架構是把企業的業務戰略轉化為日常運作的渠道，業務戰略決定業務架構，它包括業務的運營模式、流程體系、組織結構、地域分布等內容，業務架構再作用於IT實現。TOGAF的設計交付物如表2所示：
中臺辨析：架構的演進趨勢
表2 TOGAF交付物示意
可以看出，到TOGAF時代，在內容上，企業架構和業務架構發展的已經較為完善了；在工藝上，TOGAF也有明確的操作要求，也正是因為有詳細的要求，TOGAF被公認的缺點之一就是太「重」，有點像是架構領域的「瀑布模型」。
從Zachman到TOGAF，儘管理論日臻成熟，但是企業架構設計與實際開發過程之間的結合一直不是很好，更像是在兩條線上發展，表面看起來，Zachman模型似乎還能跟「瀑布模型」走得到一起，畢竟二者都被認為是「漫長」的，但大部分開發實際上在這個時期都是沿著「豎井式」的道路在走，仍舊缺乏對企業級設計的關心。至於TOGAF，它跟螺旋模型、迭代模型之間在實操上有不易結合之嫌，恐怕不少企業接受了應用TOGAF思路的諮詢方案，卻在實施過程中將其束之高閣了。儘管如此，TOGAF對推動企業架構發展的作用仍是非常大的。
（四）對更快的探索：敏捷開發、 DDD 和微服務
對效率的探索湧現出了更多的軟體工程方法、設計方法，不同方法間逐漸形成組合，從單一方法到「組合拳」也是一個很有意思的過程。
不滿足於軟體工程的進步，90年代，敏捷開發的思路開始出現。2001年，在美國猶他州雪鳥滑雪勝地，敏捷方法發起者組織敏捷聚會並起草大名鼎鼎的《敏捷宣言》，「敏捷」開發也在這次聚會上正式定名。雖然目前對敏捷開發的認識還不是很一致，但大體上的開發流程，可以在網上找到很多類似圖3的介紹：
中臺辨析：架構的演進趨勢
圖3敏捷開發流程（來自網際網路）
敏捷開發的矛頭可謂直指「瀑布模型」，大多數講敏捷開發的書幾乎都以此開頭。筆者並非一個敏捷實踐者，因此也無法深入討論這一方法的優缺點，但是從對其實現過程的介紹來看，企業架構的設計顯然沒有包含在敏捷過程中，敏捷強調的是產品和用戶維度，而且敏捷的「輕文檔」理念與企業架構已有的「重文檔」方法之間也是有矛盾的。
由於研究的人很多，敏捷開發在軟體過程管理和軟體設計方面都有較快發展。儘管有人質疑其效果，但是據稱全球排名第11的資產管理公司——荷蘭國際集團（ING）是在全公司推行敏捷開發的，該公司擁有員工113,000人，在全球50個國家為6千多萬客戶提供金融服務。
除了對過程的加速，架構設計方法本身也有創新。2003年，Eric Evans提出了DDD，也即領域驅動設計方法，該方法的特點是在需求分析、軟體設計方面的一體化實現，通過領域模型直接形成可以指導到「類」設計的軟體架構模型。但是DDD明顯只是一個軟體架構設計方法，而非企業架構設計，並且，DDD領域的大師級人物Vaughn Vernon認為企業級是無法從頂層直接設計的，只能在領域建模完成後，逐個領域地進行嘗試性融合。Eric Evans也在其書的結尾對「總體規劃」方法表示了一種委婉的不信任。DDD最經典的架構圖如圖4和圖5所示：
中臺辨析：架構的演進趨勢
圖4六邊形架構（來自網際網路）
中臺辨析：架構的演進趨勢
圖5領域模型示例（來自網際網路）
Eric Evans曾提出該方法主要面向敏捷過程，二者其實在方法層面有相似之處，都強調快速由需求進入開發過程，也都注重對模式的運用。但是因為DDD方法掌握起來有一定難度，因此並沒有真的隨著敏捷開發「火」起來，倒是借了另一種架構風格的「東風」，微服務。
微服務最早由Martin Fowler與James Lewis於2014年共同提出，微服務架構風格注重用具備獨立資料庫的微服務來替代原有的單體應用設計方式，每個微服務運行在自己的進程中，並使用輕量級機制通信，通常是Restful API。這些服務基於業務能力構建，並能夠通過自動化部署機制來獨立部署，服務可以使用不同的程式語言實現，以及不同數據存儲技術，並保持最低限度的集中式管理。從理念上看，極具靈活性、快速響應能力、可復用性和擴展性，案例上更是有傳奇公司Netflix做標杆。
但是這種架構風格並沒有很好地處理它的前身SOA遺留的問題，就是如何確定服務的顆粒度，於是，不溫不火快10年的DDD派上用場了。DDD這種可以直接按照限界上下文導出數據和行為相結合的設計結果的方法，很適合推微服務一把。Chris Richardson在其著作《微服務架構設計模式》一書中就專門花了兩章來介紹DDD與微服務的結合。
在對更快的探索中，敏捷開發、DDD和微服務提供了一種包括軟體過程、架構設計和工程實現在內的「組合拳」，當然，這並不意味著所有企業都要這麼用，只是一種參考而已。此外，求快的同時，這些方法也都欠缺對企業架構的關注，它們都是可以提升IT開發效能的有力工具，但是，在To B端，仍需要一種可以面向企業級能力建設的方法作為總體導引。
（五）小結：行路難
架構設計的思路到上個世紀70年代才逐漸開始發展出來，軟體行業希望也能像工業、建築業一樣具有行業級的設計原則、標準，從而使高質量軟體的產出得到保證。但是，到目前為止，架構之路殊為不易，還沒有哪種方法升華為舉世公認的原則或者榜樣。
軟體工程到今天才算年過半百，還是個比較年輕的領域。從「瀑布模型」進化到「螺旋模型」大約用了20年；敏捷開發快20歲了，DDD也有17歲；微服務雖然很年輕，才5歲，但是它的前身SOA是1996年誕生的。企業架構從Zachman模型誕生到現在是33歲，而TOGAF到現在也就25歲，只相當於軟體工程的一半年紀。如此說來，這些方法以其要服務的目標領域而言，都還是只是剛剛進入「青年」這個水平。
然而上述方法我們至今仍在對其某一方面大加撻伐，沒有一個是「銀彈」，沒有一個不曾被人罵做「坑」。但是貴在探索和堅持，這些方法經歷時間的洗禮，仍未褪去「稚嫩」，仍需要「呵護」與反覆實踐才能健康成長。
現代社會的快節奏對架構的積累確實是一個挑戰，「快」原本應該是目標，而今成了方法。我們對很多架構方法的理解尚不深入，對其應用也需要對方法創立者的初衷深加體會，比如，敏捷方法的創始人、「敏捷宣言」起草者之一的Jeff Sutherland在《敏捷革命》一書中提到其靈感來源的「OODA」方法，建議在每個衝刺中都要完整使用，但在各類敏捷書籍中卻鮮有提及；Vernon也提到，無論是對敏捷方法還是對DDD而言，「知識獲取」都至關重要，但是「知識獲取」顯然需要積累；即便是對口誅筆伐的「瀑布模型」，也一樣存在眾多誤解。
拋去這些爭議不談，我們至少可以從軟體工程與企業架構的發展歷程中看到這樣兩個個趨勢：一是關注點從軟體架構向企業架構的進化，也就是對軟體設計核心目標的認識，軟體設計絕不是「先寫了再說」，也不一定是越快越好；二是不同方法之間更明顯的結合趨勢，面向企業的軟體設計是一個很複雜的事情，既然很難由某一個方法自己搞定，那就「抱團取暖」吧。
二、企業級業務架構（EBA）與「組合拳」
（一）關於 EBA
上文談到了架構演進的一個趨勢，就是關注點從軟體架構向企業架構的進化，這反映了技術在面對不斷上升的業務複雜度時，對自身局限的認知。不深入了解業務和企業，就很難建立面向整個企業的系統規劃，企業內部也就很難有效打通，事實上，比爾 ·蓋茨先生1999年在《未來時速》中提出的為企業打造「數字神經」的想法，至今也還沒能完全實現。
「數字神經」的打造跟理清企業架構是分不開的，如同給一個城市設計管道系統一樣，它與城市的結構是要匹配和共同演進的。而企業架構中非常重要、技術人員又很難處理的，正是業務架構。業務架構在Zachman手中萌生，到TOGAF時明確，儘管那個定義還是挺難理解的。TOGAF將企業架構（EA）和業務架構（BA）都推向了一個新高度，並且給出了包含業務架構在內的著名的「4A」結構，但是其實施難度一直飽受爭議，由於周期通常較長，分析業務架構能夠投入的業務人員就是有限甚至很難保證的，當然，這與企業自身的實施決心也有關。
國外有些基於BA的成功案例，比如US Patent and Trademark Office（USPTO）於2013年啟動了TMNG（TrademarkNext Generation）項目，按照BA方法梳理了企業層面的20多條價值鏈、19個1級能力、100餘個2級能力，並按照能力復用等條件確定實施優先級，能力復用越多的，計劃排期越靠前。TMNG項目持續5年，從第一年只能釋放1組價值鏈環節，到第四年可以6組價值鏈環節同時實施，這一方面顯示了對方法應用的熟練，另一方面也是來自於可復用能力的增加。
國內，建設銀行是貫徹業務架構方法的典範。由於長期受到「豎井式」開發的影響，該行於2011年痛下決心啟動了「新一代核心業務系統」轉型工程，以企業級業務架構方法驅動IT開發轉型，進而推動企業轉型。工程實施時間長達6年，通過業務模型方法構建了全行統一的業務架構，梳理了20餘個業務領域、80餘個業務應用、100餘個業務組件、900餘個活動、4500餘個任務、20000餘個數據實體，規劃了全行100餘個新老系統的SOA風格改造，將整個企業連接起來。此後，工行、中行也都在近兩年構建了自己的企業級業務架構模型。
綜上，EBA其實對開發最大的指導作用在於它對業務的深刻理解、對企業整體性的解讀與規劃、對業務能力的聚類與組件的劃分，從而使IT對業務的支持上升到合作、融合的高度而非原有的實現，它的作用其實更多還是在過程中，而非文字裡。
筆者基於原有的工作經驗，將EBA設計方法進一步改造為通用方法論，以期能夠為更多領域的設計人員提供借鑑。EBA方法這兩年有復興之勢，一方面是有建行這樣的大型實施案例，另一方面也有來自阿里巴巴這樣的網際網路頭部企業對業務架構的重視。如果再說更深層次的原因，也許是現在又到了一個「轉型」的時期，網際網路企業這類跨界競爭者對原有行業的巨大衝擊，使大家認識到，未來企業都將會帶有較強的科技屬性，信息化將進入它自身的高級階段，並逐漸走向數位化階段。這樣的「轉型」時期需要已經不僅是「一招鮮吃遍天」的爆款產品，更重要是大多數傳統企業需要首先完成自身的「科技化」改造，需要首先實現企業內部技術基因的增強，實現業務與技術的深度融合，這種轉型非常需要EBA的支撐。提高企業的整體性正是EBA方法的強項，正如筆者在《企業級業務架構設計：方法論與實踐》一書中對EBA的定義：「以實現企業戰略為目標，對企業能力進行整體規劃並將其傳導到IT實現端的結構化分析方法」。
企業無分大小都有戰略，都有架構，就算沒有顯性地表現出來，所以，各種規模的企業都可以嘗試用EBA方法為自己診脈，就算你沒有最終將它應用於IT實現。筆者介紹的方法沒有那麼複雜，充分地認識自己不是壞事，正所謂「知己知彼，百戰不殆」，畢竟，無論做不做系統開發，企業每發展到一定時間，總會積累些「管理債務」要去償還，EBA本身也可以應用於「管理」上的重構。
EBA的一般設計過程如圖6所示：
中臺辨析：架構的演進趨勢
圖6EBA設計的一般過程
EBA的整體邏輯如圖7所示：
中臺辨析：架構的演進趨勢
圖7EBA的整體邏輯
如圖8所示，EBA強調的是「知行合一」，強調企業自己對方法論的駕馭和對架構師的培養，未來的企業管理必然包含架構管理，企業管理追求的「韌性」很可能將來自於架構的「彈性」和演化能力。
中臺辨析：架構的演進趨勢
圖8業務架構的知行合一
EBA方法也是一個業務架構設計與IT實現之間不斷迭代的過程，如圖9所示：
中臺辨析：架構的演進趨勢
圖9 業務架構設計與IT實現的持續迭代過程
（二） EBA 與 DDD
方法之間的結合也是一個趨勢，當然，結合是一件難度很高的事情，它的基本要求之一就是嘗試結合者自己要對各個方法都有充分的了解和實踐經驗，並且能夠讓學習者可以掌握，因為對學習者而言，這意味著「1+1>2」的學習量。
EBA方法在形成業務架構解決方案之後，本身對IT實現端採用的方法沒有特殊的限制性要求，這也意味著進入IT實現端的需求分析階段後，可以嘗試採用DDD方法進行細化設計，因為二者都注重數據與行為的結合，EBA方法是通過流程模型與數據模型的結合進行表達的，DDD的實體表達方式則更為直接；二者都強調通用語言，只是範圍上， EBA是跨領域的通用語言，而DDD是限界上下文內部的通用語言；二者也都希望實現業務和技術兩端都能理解的解決方案，也都非常關注業務含義對模型設計的影響。
但是二者也有區別，結合也有一些的困難要克服。一個比較直接的問題來自於數據模型，EBA方法注重對企業級數據模型的設計，企業級數據模型對數據治理有非常重要的作用，對大數據應用也有很直接的影響。數據模型通常的設計方式與DDD中對數據的處理有一些區別，二者在數據建模方面，對實體的定義有共同之處，比如應關注實體的業務含義，但是具體定義、實體大小的考量上，都會在實操層面有區別，而且，EBA方法比較提倡在企業層面的數據概念的抽象和統一，但是DDD是從領域出發考慮問題的，而且這個領域也不同於EBA中範圍較大的領域概念，其限界上下文涵蓋的範圍可能很小，從而產生多個領域都有同名不同義的實體。
比如，Vaughn Vernon在《領域驅動設計精粹》一書第二章介紹的「保單」的例子，就是在承保、審核、理賠三個限界上下文中分別定義了「保單」實體，每個實體都有重複的部分和差異的部分，這樣做的原因則是認為整合會造成一個過於臃腫的「超負荷」的「保單」實體。這樣的實體也許大家在設計過程中也曾經遇到過，就是一個數據實體包含了過多的屬性，導致數據層面沒有很好地分離「關注點」。
Chris Richardson在《微服務架構設計模式》一書的第二章中也給出了一個通過DDD處理類似問題的例子，就是對「上帝類」的拆分，「上帝類」作為全局類，可以為多個不同領域的應用調用，因而也就設計了包含不同領域的狀態和行為的複雜結構，比如書中提到的「Order（訂單）」，下單、送餐、付款等多個領域都會觸發訂單狀態的轉換，如果將豐富的行為打包成一個中央Order資料庫，會導致微服務設計方面出現「緊耦合」，微服務之間不夠獨立；如果只保留一個純數據服務的Order Service，又會成為「貧血模型」。其解決之道同樣也是在不同領域定義同名不同義的Order。
這兩個例子其實體現了與EBA很不同的處理方式，EBA希望實現企業級的數據模型定義，也即，在企業級範圍內儘可能消除同名不同義的數據實體，所以，「保單」、「訂單」在EBA中通常會處理為一個而非多個實體，那麼解決實體過於龐大的問題，還是要依靠對數據實體的業務含義、業務能力的識別，因為按照領域的拆分本身也會存在弊端，就是企業級數據查詢與應用的困難。
對於Vernon舉的例子，由於沒有更多的信息，因此無法進行詳細的比較，但是EBA的數據建模中，子實體的概念也可以滿足不同領域的需要；Richardson舉的Order的例子，在EBA方法中，很可能不會僅設計成一個龐大的Order實體，而是會拆分出客戶、地址、付款單等多個數據實體，至於最後Order實體會剩多少個屬性，就要看實際情況了。
但是Order這個例子中，更重要的一點是，EBA方法確實有可能會朝著設計一個中央Order資料庫的方向前進，因為很可能將其定義為一個Order業務能力組件，供各類業務應用進行調用，這是企業級業務能力復用的一種體現。至於這個例子中，Richardson提到的「緊耦合」問題，其實並非是Order服務變動會引起其他服務變動，而是其他服務需要修改Order模式時，會引起Order服務變動，這在EBA中，也是會出現的問題，這個問題是要辯證的看，也即，在集中設計Order業務能力組件獲得的好處和引起的耦合之間進行取捨。
綜上，我們可以看到，EBA可以與DDD方法進行適當的結合，但是也有在數據模型、企業級抽象目標方面的矛盾，設計方法結合的實踐者必須思考操作上需要注意的問題。
如果能夠有效地實現EBA與DDD結合，那對於DDD而言，找到了從企業戰略分解到DDD設計的整體引導方法；對於EBA而言， DDD則對提升組件或者構件的設計效率有一定幫助。這方面的結合已經有了不錯的探索者，華為的朱如夢老師寫過一篇專門探討結合方式的文章《業務架構——跨領域的統一語言》，有興趣的讀者可以參閱。
（三） EBA 與微服務
其實EBA與微服務之間，筆者覺得交集主要就是在軟體架構設計上，說的更直接點兒就是服務拆分上。微服務在技術實現方面自有一套落地方法，而且有Netflix成功的大規模實踐。儘管通訊機制導致的複雜性也讓很多人頭痛不已，但是相比服務拆分這種很難找到標準的事情，還是要相對好些，所以，微服務才出現了與DDD的結合，二者都是想在一個限界上下文中，找到能夠適合為之設計獨立資料庫的一組行為。
EBA在落地層面也需要微服務這類可以提供較大靈活性、復用性、伸縮性的實施方式，如果結合的好，二者都能夠相得益彰，EBA同樣也可以解決服務劃分問題，而且還附贈戰略落地服務。EBA方法筆者在書中曾有個改良設計方法的建議，就是吸收2003年提出的構件理論在EBA解決方案中引入構件的概念，以「樂高」積木為目標設計功能模塊，這些功能模塊可以成為微服務設計中需要定義的服務。
微服務的局限性之一就是該方法比較適合重構，很難在一個系統的初期設計中找到合適的設計思路，因為，微服務事實上代表著對業務更深刻的理解和精煉，實際上，筆者提出的構件設計方式也很難用在系統的首次設計上，這一點二者倒是很相似。
說到二者的矛盾之處，主要也是操作層面，類似消除「上帝類」這種對企業級抽象的不同處理思路，微服務以追求服務儘可能高的「獨立性」為目標，但是實踐中，耦合通常都很難完全消除；EBA更看重的是對業務能力的聚類，儘管「高內聚、低耦合」也是其設計目標，但是聚類過程中，其實比微服務設計方式更容易出現耦合問題。對於真實開發工作而言，如何處理耦合問題還是要從實際出發，不能「一刀切」地論其好壞。
（四） EBA 與敏捷開發
EBA與敏捷的關係，筆者在書中曾經論述過，主要是針對「敏捷宣言」的內容。按照多數讀者的第一印象來講，恐怕都會認為EBA這種「漫長」的實施過程與敏捷主張的開發過程「格格不入」，這一點在EBA首次設計時更為明顯，坦白地講，筆者並不認為這一階段適合敏捷，因為認識和改變一個企業的整體架構，註定是一個需要深思熟慮的過程。
敏捷開發針對的是「瀑布模型」，但是EBA並非「瀑布模型」，它是一個對企業當前狀態的刻畫過程，是尋找企業戰略落地措施的方法，應該說，二者是不同問題空間的解域，直接比較二者並不一定合適。
此外，敏捷開發崇尚的是「輕文檔」而非「無文檔」，Martin Fowler認為敏捷注重的是演進式設計，而不是輕視設計；Vernon也批評一些敏捷開發實踐是用「任務板挪卡」代替了設計；Sutherland在「OODA」循環中也強調掌握全景信息而非只從自身視角看問題的重要性，每次Scrum結束提出MVP，都要重走一遍循環，因為MVP就是為了獲得更多、更全的反饋信息，有了這些信息才能快速決策，快速決策絕非快拍腦袋，是因為有模式加速了對信息的處理速度，這才是敏捷的原動力，也是要總結方法論的原因，「全景信息+思維模式=快速決策」。
「OODA」循環如圖10所示：
中臺辨析：架構的演進趨勢
圖10「OODA」循環（來自網際網路）
與敏捷比，EBA確實是個「慢悠悠」的工作，思考的深度決定EBA的價值，因此，不給予充分的時間開展的EBA工作，無異於是在浪費時間。沒必要試圖用敏捷的思路去加速EBA過程，當今社會更缺乏的反倒是對企業級問題的「慢」思考。
EBA解決方案誕生後，敏捷方法可以用來促進EBA的落地過程嗎？答案是肯定的，但是要讓業務架構師參加到敏捷團隊中，解釋、修改EBA解決方案，這樣才能確保實施團隊充分理解作為實施前提的EBA解決方案。USPTO的例子也說明了EBA在確定任務優先級方面的作用，這點對敏捷而言也很重要。敏捷的周期很快，這也意味著，如果結合不好，那實施效果偏離原定解決方案的速度也會很快。
（五）小結：多歧路
EBA與「組合拳」的關係暫且論述到這裡，總結一下：EBA最大的優勢在於為「組合拳」提供企業層面的總體設計指引，這不是為了整體而整體，是為了實現整體性而整體，有了這個指引，才能更好地發揮「組合拳」的功效。但是，方法之間並非沒有衝突，結合之路需要慎之又慎，如果我們當前無法像物理學家那樣追逐「大一統理論」，那就讓我們像Sutherland創立敏捷方法的初衷那樣去實踐，「當我著手開始建立Scrum時，並沒有打算創造一套新的流程。我只是想匯總一下之前幾十年裡關於最佳工作方式的研究成果，看看都有哪些最佳做法，然後借鑑過來，效仿一下」，這其實是個很輕鬆的說法，知易行難。
三、聊聊中臺
（一）「水深火熱」的中臺
「中臺」概念的緣起大家都清楚，來自馬雲先生對一家歐洲遊戲公司考察後的感悟，一個比喻。實踐層面，鍾華老師寫的《企業IT架構轉型之道：阿里巴巴中臺戰略思想與架構實戰》是第一本比較完整地闡述阿里巴巴中臺實踐過程的著作，可以說是中臺布道的開始吧，鍾華老師如今仍在實踐其理念。 2019年中臺可謂火的一塌糊塗，既有從原產地阿里巴巴出來的創業團隊，也有將其原有實踐簡單包裝冠以中臺名號的「貼牌」者。
去年在的一次交流中，筆者曾經用Gartner曲線的形式，串起了與中臺相關的書和文章，與參會者開了一個小小的玩笑，如圖11所示：
中臺辨析：架構的演進趨勢
圖11中臺曲線
彼時還沒有那篇炸了圈兒的文章，筆者也無意將其補進去，畢竟這張圖也只是個玩笑。任何技術形態都會經歷這個歷程，架構理念也不例外。有價值的自然會重新走回上升態勢，哪怕是10年以後，或者像AI一樣幾起幾落；沒價值的也就壽終正寢了。Richardson 也說過：「人們往往容易被情緒因素所驅動，這也是為什麼會有這麼多關於技術的兩極分化和過度粉飾的爭論」。
中臺就其設計理念而言，仍是為了有效降低系統設計複雜度、提升復用能力的企業架構方法。去年南京中臺大會的閉門討論中，主持人曾要求每位演講嘉賓用一句話概括自己對中臺的認知，筆者當時說的也是「跟我實踐過的EBA相似，也只是一種架構方式」，確實，就目的而言，二者殊途同歸，都是在考慮識別、沉澱企業的業務能力，將其模塊化、服務化之後，更好地支持業務變化。
EBA與中臺的差別，在實操層面也許主要是EBA並未考慮要將沉澱的業務能力剝離為中臺層，因為EBA主張企業級復用，從這個角度講，也不需要單獨進行一個特殊的表達。EBA形成的業務組件之間按照調用的頻率也可以適當進行分層，但這種分層結果並非現在中臺的含義。除此之外，中臺目前對企業戰略如何分解落地也沒有很詳細的解釋方法。
阿里巴巴也是業務架構理念的實踐者，業務架構根據其設計範圍可以區分為領域級和企業級，阿里巴巴對業務架構的應用，從其自身披露信息來看比較側重於領域級，業務架構師按領域配置和開展工作。當然，設計發展到一定程度，總是會自然關注到企業級。
對中臺的探索，筆者認為仍然值得開展下去，無論它以後還叫不叫中臺，這是對架構設計理念的探索。從阿里巴巴的角度看，也是他們在技術底層實踐越來越成熟之後，對上層設計的必然追求。筆者也不太贊同按照企業規模去給中臺劃個準入門檻，畢竟企業無分大小，只要系統建到一定規模或者數量，時間累積到一定程度，總有「技術債務」要還，總有重構的十足理由，那麼作為一種架構設計理念去應用中臺方法，未嘗不可。如果說到成本，規模小的企業當然不必仿照阿里巴巴的方式構建昂貴的基礎設施，設備成本是由系統的非功能性需求決定的，與企業的規模、財務能力也是匹配的，所謂中臺燒錢，可能主要是想照搬阿里的技術方案造成的吧。拋開這個，它與一般的重構相比，是否真的會大幅度提高重構成本，筆者還是懷疑的。至於進行業務梳理的成本，只要企業想改革，這個成本無論用任何方法都是要付出的。
玄難和毗盧離職前，阿里的中臺計劃取名為「星環」，據說名稱創意來自於劉慈欣老師的《三體》，是那艘超光速飛船的名字，對於快的追求不言而喻。但是從筆者的角度來看，倒是更喜歡美劇《無垠太空》中的「星環」，每個「星環」都是通向一個世界入口。企業自建中臺需要自身的沉澱，中臺產品提供商則需要行業沉澱，現實中，還需要對行業中處於不同位置或者細分領域的客戶進行不同分類的沉澱，如此看，中臺就像「星環」一樣，是通向不同世界的入口。如果願意再揶揄一下，走進入口，遇見的可能是「天堂」，也可能是「地獄」。
EBA也可以成為「星環」，道理是一樣的。通過EBA也可以不斷積累對行業或者細分領域的模型，這些模型不僅對架構設計者有所幫助，而且可能是未來走向自動化設計、AI設計的必經之路，因為AI也需要架構數據的供給才能產生設計能力，而目前架構領域連案例都經常是語焉不詳、光怪陸離，更不說積累數據了。
（二）中臺與「組合拳」
其實中臺與「組合拳」的關係，阿里巴巴的人自己出來多講講會更好。從筆者的了解來看，阿里巴巴的中臺實踐中，「組合拳」的應用是不少的，他們的特點是一般不會強制團隊使用某種方法。微服務顯然是廣泛使用的，敏捷開發、DDD在不同的團隊中也都有應用，但是，應該不是每個團隊在每次開發中都採用這些方法。
阿里巴巴的中臺，據說在大規模構建之前面對的問題之一就是企業已經有上萬個微服務，每次承接新需求都可能有數百個微服務受到波及，而服務數量如此之多，以至於沒有人能搞清楚業務能力到底有哪些、是如何分布的，所以，搞起了業務架構，分離業務領域，理清不同領域的業務模式，再沉澱業務能力，形成中臺。微服務是中臺在技術層面落地的方式之一，但是中臺設計要有效地為微服務的劃分提供指導，並從架構層面提供業務能力的可視化，進而支持業務能力的持續優化，通過架構演進指導微服務的設計與變化。微服務則在技術落地上提升對業務能力的運維支持，提供良好的升級維護和可擴展性。
在分離業務領域方面，DDD方法也有一定範圍的使用，畢竟這種方法與微服務的結合被廣泛傳說，而且DDD的思維方式就是側重對限界上下文的分離，以達到在同一個限界上下文內對同一業務概念理解上的一致。每年Thoughtworks的大會上，也都有阿里人來分享應用DDD的經驗。至于敏捷開發，更是常被當作網際網路企業的標配。
中臺跟「組合拳」的關係，其實也應該類似於本文第二部分中討論的EBA跟「組合拳」的關係，只是現有的信息中，中臺並沒有像EBA那樣給出一個明確的設計過程和方法，所以，分析也很難做的更深入，這並不是對著幾張漂亮的架構圖就可以做的比較。
（三）特化與泛化
筆者從各種交流，包括對筆者文章的留言中，也能感受到，中臺面臨的一個問題就是領域的積累達到一定程度之後，必須從企業層面去思考問題。所謂的做中臺以支持業務的靈活變化，那到底業務是什麼？到底是支持需求還是支持業務？技術人員到底理不理解業務？需要理解到什麼程度？需求到底是來自業務人員的還是來自真實客戶的？說到底，就是技術到底怎麼支持業務，其實這樣說還是有些「見外」，應該說，技術到底怎麼跟業務融合。
這波對中臺的爭論，也反映了對阿里中臺的一個認知問題，它到底是個特化的方法還是泛化的方法。
從阿里自身看，這首先是一個特化的方法，理由不難理解，他們要梳理自身過於複雜的微服務實現狀況，要支持業務端給數千萬商戶提供的千變萬化的營銷、管理手段，要面對複雜的商業生態和大量的不確定性，應對每年「雙十一」獨步全球的高並發環境，應對網際網路領域「唯快不破」的殘酷競爭，還要應對大量的技術「無人區」，這樣可謂「極端」生存環境下產生的方法，一定是個「特化」的方法。其實每個方法誕生之初都是「特化」的，面對的環境越極端，方法的特化性相應也越強，阿里的中臺也理應屬於這種情況。
但是大家需要的是一個泛化的方法，這就需要首先解釋清楚方法的特化之處，考慮清楚對特化的處理，才能實現泛化的目標。作為一個局外人來看，筆者建議，把阿里中臺方法中的各種武器首先拆分清楚來看，先不要抱著「要要要」、「買買買」的想法，而是搞清楚武器之間的關係和成本，應用的前提條件和最適宜解決的問題，再對號入座，實現「客戶化」過程。比如，業務能力梳理方法、組織結構是不是直接對標阿里（阿里可是經常變的）、微服務要不要搞、阿里技術棧選用哪些、需要全鏈路壓測嗎等等之類的問題。一個泛化的方法在應用過程中還是會再經歷一次本地的特化，尤其是中臺、EBA之類的企業級方法，這也代表需要足夠的時間和成本。「九尺之臺，起於壘土」，中臺的構建，也少不了「搬磚」的過程。
對於做中臺產品的服務提供商而言，應當把中臺認真當成一個軟體工程方法看待，把其中的組成要素、軟體過程、可選方案都研究明白，「工欲善其事必先利其器」，這是對工匠的基本要求。對於這些廠商而言，幫助客戶搞清楚自己要的到底是特化的阿里中臺還是泛化的中臺，是很重要的。泛化的中臺意味著要根據客戶的實際情況決定中臺的實施目標，而非靠「對標」的方式預先誘導實施目標，後者銷售的意味太過強烈。當然，這種情況不只中臺有，但凡商業化的東西，都有這個問題，說「酒香不怕巷子深」的越來越少了。
中臺說到底也是一個技術怎樣與業務融合的問題，看到了一個有成功實踐做背書的技術理念，但是套用到自家業務實踐上，卻發現「知行合一」遠非易事。
四、開放式架構
架構的演進隨著信息化程度的加深和越來越多的優秀從業者的加入而逐漸變得更加有趣、更加複雜，從「先寫了再說」到工程化的引入，從關注軟體自身到關注企業，問題空間越來越大，越來越複雜，對解域空間的要求也不斷上升。筆者通過前文，在回顧軟體工程和企業架構發展過程的基礎上，總結了兩個架構演進趨勢：從軟體架構到企業架構、從單一方法到「組合拳」，並通過對EBA和中臺的分析，對方法之間的差異比較與結合進行了論述。本處打算再簡單討論下第三個趨勢：從內部架構到開放式架構。
銀行是信息化起步較早的行業，而且大型銀行組織結構複雜、技術開發投入高、應用範圍大，在架構發展歷程上，很具有代表性，國內銀行在架構方面的發展歷程如圖11所示：
中臺辨析：架構的演進趨勢
圖11架構演進趨勢
上世紀80年代後半期銀行剛開始引入主機系統，此時構建的業務系統是「高度」分散的，每個地級市都有自己的業務系統，不同城市之間業務也是無法聯通的，一筆匯款業務，現在是實時轉帳，零級清算、秒級到帳，但是在那個時候是多級清算，跨地區匯款是從一個城市的網點到自己的市分行，市分行到省分行，省分行到總行，總行到目標地的省分行，省分行到市分行，市分行到網點，在地區割裂的情況下會是個什麼效率，大家可想而知。到了90年代末，隨著計算機性能的提升和網絡的發展，數據集中的需求越來越強烈，有數據集中才能有業務集中，大集中架構拉開帷幕，大集中可以構建全行統一的業務系統，業務效率的提升是不言而喻的，但是由此帶來的問題也逐漸顯露，就是「豎井式」開發的問題。2011年，建行首先開始企業級轉型，設計全行統一的企業級架構，包括企業級業務架構和7層12P的企業級系統架構，工程於2017年結束，內部一體化初步完成。
但是架構的演進不會就此打住，內部統一之後，更重要的就是適應面向數位化時代的開放與融合要求，深度參與到生態建設中，架構發展的下一階段自然就是開放式架構，真正從社會分工、生態分工的角度，結合生態夥伴、客戶的情況，綜合分析架構解決方案。其設想如圖12所示：
中臺辨析：架構的演進趨勢
圖12開放式架構理念演示圖
數字社會必定是一個與今日大不相同的「新時代」，所有參與者都將迎來一個轉型過程，無論是企業還是個人。雖然轉型是漸進式的，但是準備自然要從現在開始做起，對於企業而言，架構「新時代」的到來是註定的，而這個「新時代」一定是業務架構與技術架構、業務與技術深度融合的時代，無論是EBA還是中臺，都有機會在這個進程中扮演重要的角色，道路是漫長、曲折甚至孤獨的，敢於在這條路上探索的都是勇士。
作者簡介
付曉巖，《企業級業務架構設計：方法論與實踐》圖書作者，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計，現就職於建信金融科技有限責任公司。即將發行新書《銀行數位化轉型》，公眾號：曉談巖說。
第三十屆CIO班招生 法國布雷斯特商學院碩士班招生 北達軟EXIN網絡空間與IT安全基礎認證培訓 北達軟EXIN DevOps Professional認證培訓責編：yangjun