• <tr id='Bkfobf'><strong id='Bkfobf'></strong><small id='Bkfobf'></small><button id='Bkfobf'></button><li id='Bkfobf'><noscript id='Bkfobf'><big id='Bkfobf'></big><dt id='Bkfobf'></dt></noscript></li></tr><ol id='Bkfobf'><option id='Bkfobf'><table id='Bkfobf'><blockquote id='Bkfobf'><tbody id='Bkfobf'></tbody></blockquote></table></option></ol><u id='Bkfobf'></u><kbd id='Bkfobf'><kbd id='Bkfobf'></kbd></kbd>

    <code id='Bkfobf'><strong id='Bkfobf'></strong></code>

    <fieldset id='Bkfobf'></fieldset>
          <span id='Bkfobf'></span>

              <ins id='Bkfobf'></ins>
              <acronym id='Bkfobf'><em id='Bkfobf'></em><td id='Bkfobf'><div id='Bkfobf'></div></td></acronym><address id='Bkfobf'><big id='Bkfobf'><big id='Bkfobf'></big><legend id='Bkfobf'></legend></big></address>

              <i id='Bkfobf'><div id='Bkfobf'><ins id='Bkfobf'></ins></div></i>
              <i id='Bkfobf'></i>
            1. <dl id='Bkfobf'></dl>
              1. <blockquote id='Bkfobf'><q id='Bkfobf'><noscript id='Bkfobf'></noscript><dt id='Bkfobf'></dt></q></blockquote><noframes id='Bkfobf'><i id='Bkfobf'></i>
                首頁 > EA > 正文

                中臺辨析:架構的演進【趨勢

                2020-04-27 10:49:35  來源:頭條sandag

                摘要:對企業△級軟件架構設計方法的研究需要所有人共同①關註,它是在持續進化ぷ的,也是未來企業走向數字化№過程中,實現⊙業務與技術深度融合的必經之路。
                關鍵詞: 架構
                  春節前應“技術瑣話”之約,試圖寫一篇討論架▅構方法論的文章,然而動筆之後,才發現,自己似乎∑ 陷入了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