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