作者 | 付曉巖

現在很少有程序員沒有聽說過“中臺”，但很少有程序員了解企業架構，更少有程序員會把企業架構的作用聯系到數字化轉型上，但這是已經涌起的趨勢，是每個真正關心如何做好 B 端實現的程序員都需要具備的思維方式。想走好腳下的路，也需要多抬頭看看天，所以，是時候重新關注下企業架構了，也許關注了企業架構，你會逐漸獲得不一樣的設計視角，會越來越知道自己寫的軟件有什么樣的價值，而不只是有什么樣的功能，這些價值最終也會轉變成你自身的價值。

那什么是企業架構呢？今天有什么樣的企業架構實踐？未來需要什么樣的企業架構設計思路呢？本文就打算分三部分跟各位程序員讀者談談這個平時很少涉及到的話題。

1 企業架構是什么？

回答一個事物是什么，做好的方式莫過于“溯源”，知道它怎么產生的，也就知道該怎么去認識它。那么企業架構從哪里來的呢？答案是為了解決一個我們今天依然很常見的“毛病”：軟件開發中的“先寫了再說”。早期的軟件開發是不會有什么章法的，多數行業的誕生期都是活在一片“混沌”中，軟件行業也不例外，編程甚至是對硬件高度依賴的。但是到了上個世紀 60 年代，這種全憑能力與靈感的開發方式，無法有效地保證項目的順利實施，必須有工程手段去加強多過程控制，于是，今天被人們大肆詬病的“瀑布模型”很“驚艷”地誕生了，別看現在很多人一談“瀑布”一臉的不屑，但是當年“瀑布模型”也曾在美國軍方的開發指導文件中占有一席之地。

“瀑布模型”是過程模型，還不是架構設計方法論，借鑒它的思路，確實可以更好地控制單個軟件的生產，但是企業的需求是無法被單一軟件滿足的，哪怕搞到 ERP 那么大、那么復雜，也還有一堆其他系統一起上陣，才能搞定企業的需求。那這么多的軟件都是“高內聚，低耦合”，可以“老死不相往來”，“低調”地走完自己的一生嗎？答案是否定的，他們不僅不會“老死不相往來”，甚至可能“吵”得一塌糊涂，比如，數據的不一致、用戶體驗的不一致；企業希望他們能協同工作，但是他們有可能只具備很差的互操作性，甚至無法互操作，這當然給 RPA 留下了“美麗”的成長空間。

IT 是件很燒錢的事情，企業花了大把的 IT 投入，如果只是給自己建上一堆高聳林立的“煙囪”，那會讓人覺得很不開心，這只是給不得不持續追加 IT 投入留下了“借口”。當然，這種現狀 IT 人自己也是很不滿意的，這豈是“高智商”行業所為？于是，早在 1987 年，IBM 的 Zachman 先生在其論文《信息系統架構框架》中提出了應該從多個視角整體分析企業，從而合理進行軟件架構設計的思想，這篇論文就成為了“企業架構”思想的開山之作。

但是，Zachman 先生提出的只是設計思路，沒有講清楚具體的設計過程和方法，直到 1995 年，更為成熟的企業架構框架 TOGAF（the Open Group Architecture Framework，開放組架構框架）誕生了。TOGAF 今天經常被批評過程“笨重”，但是，回到 1995 年，這可是解決了一個大問題，就是 Zachman 先生提出的那么有道理的東西到底怎么做出來。對企業來講，最重要的是一件事情該怎么組織，畢竟企業不是只有一個程序員，可能有 100 個、1000 個、100000 個，那這么多人怎么才能有序地整個企業的軟件做好？無論是搞企業架構和瀑布，還是搞敏捷，你都得教給企業一個可以被大多數人理解和執行的過程，否則，想法無法轉化為實現。

我們今天談論的企業架構其概念大多來自于給出了一個完整構建過程的 TOGAF。在這里，筆者簡要介紹下，在 TOGAF 中，企業指“有共同目標的組織集合體”，也就是，不是單純指領了工商牌照的企業，而是“組織”，可以是一個企業，也可以是一堆企業，甚至是非盈利組織，也可以是企業中的一個部門，這么看，是不是很有“可擴展性”？是的，你用它來套今天很火的“生態”也是毫不違和的。這里的關鍵就是“共同目標”，這也指出了“企業架構”的設計目的，為了更好地實現“共同目標”。“架構”則引用了 ISO 的概念，即，架構是指系統的基本組成部分，各組成部分之間及其與環境之間的關系，決定其設計與演進的治理原則，也即，架構主要包括結構、關系、原則。那么，組合一下，“企業架構”的概念應當是“具有共同目標的組織集合體的基本組成部分及其內外部關系與治理原則”，用普通話講，就是把企業分成一個一個的組成部分，確定好它們之間的關系和設計原則，再去分別實現，然后組合起來成為一個企業。按照 TOGAF 對企業的定義，那么企業架構大到可以對整個生態進行架構設計，也可以小到對部門內的業務進行設計，只要最終是跨兩個以上的系統進行設計，就能體現出設計思維上的優勢，范圍越大，優勢越明顯。

那么，企業架構都會設計哪些內容呢？TOGAF 給出的企業架構內容元模型如下：

圖一 TOGAF 企業架構內容元模型

可以看出，Zachman 先生多視角架構的理念得到了體現，表現為業務、數據、應用、技術四個架構，因為架構的一詞的英文字首為“A”，又稱“4A”架構，在這里可以看到，數據和應用又被合稱為“信息系統架構”。

整體看，企業架構的設計既包括對了對企業的愿景、戰略、業務、組織的分析，有包括基于業務分析而進行的應用系統設計分析，是業務與技術相連接的設計思維。但是，企業架構也有一個問題，就是大多數企業架構理論都沒有很好地給出從業務分析到應用設計的銜接方法。

既然提到了“大多數”這個詞，那就意味著企業架構理論還有別的方法論，是的，還有聯邦企業架構框架（Federal Enterprise Architecture Framework，FEAF）、國防部架構框架（Department of Defensive Architecture Framework，DoDAF）、CBM（Component Business Model）等一系列企業架構框架和方法論。總的來講，這些方法論之間的差異就是用什么樣的理念進行企業的整體設計，本文不在此展開了，筆者有關于企業架構理論的專著討論此事。

從上述介紹看，“中臺”無疑也是一種“企業架構”方法，因為它同樣需要基于整體視角進行設計。所以，我們可以看到面向整個企業的“中臺”設計；“中臺”也可以只對著一個事業部去做，只要它的業務夠復雜，需要橫向拉通業務和系統，這一點也跟企業架構一樣，小大由之。

2 企業架構做的怎么樣？

這么漂亮宏大包羅萬象的理論，實踐的怎么樣呢？

先說說 TOGAF 吧，TOGAF 不僅是個框架，其中的“TOG”，也就是 The Open Group，還是個論壇型組織，專門負責研究和推廣企業架構，目前有會員企業 800 多，當然，主要是歐美的大型企業居多，今年是該組織成立 25 周年，10 月份還組織了一系列的推廣活動。在 The Open Group 的努力下，TOGAF 的方法論一直有持續更新，如今是 9.2 版了。實踐案例集中在大型企業，能源、航空、制造、金融企業等，都有案例，與 SAP、IBM 等大型軟件供應商、咨詢服務商都有良好合作，有大量的資質認證培訓，也是唯一具有權威認證的企業架構師資質。

但是，不得不說，TOGAF 的很多實踐還是在借用其理念而不是完整、一板一眼地按照其方法論進行實施，所以，業界也常有一個說法，就是，判斷一個項目是否是 TOGAF 項目，不是看其交付物，而是看其過程。也就是說，不是對著 TOGAF 手冊去檢查設計文檔是不是種類齊全，而是看項目執行過程是不是接近 TOGAF 的 ADM 過程模型，也就是類似下圖這個過程模型：

圖二 TOGAF 過程示意圖

國內企業極少有設立專門的企業架構部門的，但是筆者確實接觸過一家頭部科技企業，設立有非常完整的企業架構管理組織，并設有企業架構委員會。

此外，筆者有幸參加過一個在全世界范圍看也少有的極為完整的大型銀行企業架構轉型工程，是一家國有銀行，工程歷時六年多，項目投入和深度都是無與倫比的。該項目采用的是 TOGAF 加 CBM 的融合型方法論，其工程情況如下圖所示：

圖三 工程情況示意圖

工程具有顯著的 TOGAF 特征，但是交付物則有明顯的 CBM 特征，是兩種理論的融合，可見，企業架構的實施并非“死板”的，而是根據需要靈活設計的。但是“靈活”的前提是要對方法論有深入的了解，對實施困難的克服有堅定的信心，辦法總比問題多。筆者總結，企業架構的設計與實施，就是“問題決定工具，毅力決定結果”。

在這段長達六年多的實踐中，該行采用標準化的流程模型、數據模型、產品模型建模方法，對二十幾個業務條線進行集中的企業級建模，建模的時間達到兩年左右。其實這并非一個很長的時間，因為其中包含了對方法論的打磨，對行內戰略的解讀，對 80 多個主要業務專題長達半年的深度研究，是基于較為完整且長期的業務能力規劃進行的業務模型設計，其中的數據模型更是對 3000 余個數據實體、20000 余個屬性進行了企業級統一定義，對歷史數據進行了完整的數據遷移，奠定了企業數據治理的堅實基礎。基于業務模型，還對主要業務系統進行了服務化重構，涉及眾多核心系統。部分核心系統的重構是難度極高的，比如金融市場領域相關的業務系統，其完全替換更是一直持續到了近期，這對相關系統的國產化設計也做出了有益的探索。完整的企業架構設計相當于梳理了相互對應的一套業務能力地圖和一套 IT 資產地圖，這兩者又共同構成了一套企業能力地圖。

業務的標準化是對業務行為的精準認識，這是一切合理化設計的基礎，如果沒有標準化約束，業務行為的認知可能是極為發散的，比如，該行最初的三級業務活動識別數量曾經達到接近 10000 個，而在進行結合了數據實體分析的標準化后，三級業務活動的數量驟降至 900 余個，這對 IT 設計而言，其需求的去偽存真程度可想而知，這種方法是不是也可以讓不合適的需求少很多？

筆者深度參加了該行企業轉型工程，在這一過程中完成了從一個業務人員到業務架構師的轉變，從 2012 年算起，筆者做業務架構已經 9 年了，可以算是這個小眾領域中的“資深”人員。筆者從接觸這個領域開始，就認定了企業架構、業務架構的價值，也因此而努力到今天。“不謀全局者不足謀一域”，這就是企業架構的思維邏輯。解決孤島問題、培養全局設計能力，這就是研究企業架構、業務架構的價值所在。業務架構也并非一個完全以業務能力為主的角色，當然，也非以技術為主，而是以“架構”為主，通過流程、數據、產品三種模型的結合分析，設計出業務的結構，為 IT 設計提供結構化的分析依據。提供豐富深入的業務信息是業務專家的職責，因為無論業務架構師如何努力，都不能保證在第一時間內感受到業務變化，這是“位置”決定的，所以，能力的關鍵在于對結構的分析和設計。一個合格的業務架構師要有快速切換領域的能力，而非一輩子專注一個領域，筆者自己也是客戶信息、客戶關系、養老金、同業、金融市場、資管、托管等多個領域切換過。當然，這不是單純依靠能力，還要依靠架構資產，也就是業務模型。筆者之前在從事同業領域業務架構設計時，也是在之前沒有接觸過同業業務，依靠業務人員的輸入和既有的企業級業務模型，完成對其全部業務涉及的二十多個業務組件的業務架構方案設計。

從長期對業務架構設計的實踐和對相關理論的研究，筆者也發現，其實做好業務架構設計進而做好應用設計的關鍵，并不是哪個“神奇”的方法決定的，無論是 DDD 還是敏捷，一樣都離不開對業務深入的理解，或者極端點兒說，什么方法都比不上你跟業務人員多交流幾天、幫助業務人員理清設計目標的效果。也正因為如此，筆者認為企業架構中的業務分析方法，更貼近于如何讓業務人員結構化地分析業務，并且更快速地跟技術人員對設計目標達成一致，因為這種方法相對而言是業務人員學習成本比較小的。業務和技術的融合，需要方法論支持，但是更重要的是提供一個充分融合的操作過程，這也是企業架構這種相對“慢”的方法“快”的地方，筆者也將這種思路代入了對企業架構方法論的改良中。

不過從筆者的實踐和與其他企業的交流看，筆者還是認為在企業內部采用一致的架構設計方法還是有很大價值的，尤其是對準備進行轉型工作的傳統企業而言，這些企業本來就是體系化的，內部有很多密切的聯系存在，如果在方法上不一致，相當于疊加了額外的溝通成本，對企業而言，這可能是消耗而非提效，企業不是這些方法“百花齊放”的試驗場。方法論在企業內不統一的另一個弊端就是影響企業的知識沉淀，無論是業務知識還是技術知識都一樣，沒有體系化的歸納能力，對人員能力的培養也會成問題，體系化知識訓練出來的人員，其對執行力和對本企業的理解能力都會顯著高于“野生”選手。該行最終通過業務模型沉淀了大量的知識，這些業務模型后來也成為了可以對外輸出的商品。

該行的工程中，特別值得其他企業借鑒的一點是對該行對工程的強大組織執行力，正是通過領導層的高度支持才能將眾多的業務部門、業務人員長時間集中到一起進行企業級業務架構設計，而這種設計是企業級業務系統之間能夠橫向聯通的關鍵，畢竟，只有業務部門自己才能打破相互之間的壁壘，這也是一些嘗試從技術側發起企業級業務系統設計在很多傳統企業最終難以實現目標的原因，離開了業務的深度參與就不會有真正的企業級業務系統。很多企業覺得學不了該行的“大手筆”，其實這是個認知上的誤區，“手筆”的大小取決于企業的“目標”，這是個價值判斷題，而且是未來價值判斷題。今天國內外看起來非常強大的那些科技企業，都曾經弱小過，都曾經不被看好過，他們幾乎都是在自己掙扎的路上時刻拼盡全力才有了現在的樣子，也許它們的今天很多企業確實學不了了，比如 Google 小團隊里那么高的博士密度，但是它們過去一路對極致的追求，則是很多企業現在能學的，這一點對于做企業架構來講也是一樣的。企業架構也不是一朝建成的，只要企業有足夠的韌勁就行。

目前國內銀行業，尤其是頭部大型銀行，幾乎都已經開展或者正在開展不同形式、深度的企業架構工作，企業架構的應用范圍也正在逐漸向股份制銀行擴散。那未來會不會有更多的中小銀行開展企業架構工作呢？筆者相信會的，只要沒有把數字化轉型的全部支出都“誤算”給企業架構，那企業架構的實際花銷并不是非常大，尤其是當對企業架構設計服務的需求逐漸增多，導致服務商的供給能力提升后，設計費用一定會朝向下降的方向，因為說到底，企業架構是一種整體設計的思維方式，企業經歷過一定的實踐后，逐步就會掌握這種設計理念，而越來越多的人掌握這種設計理念，就會帶動供給量放大和價格的下降。

作為一種設計思維而言，有些企業尤其是 SaaS 類軟件服務商，其實正在運用這類設計理念但是并沒有意識到這實際上也是企架設計，比如一些為中小企業信息化服務的廠商，他們在為客戶提供服務前，也要努力把客戶的主要業務流程梳理清楚并盡可能進行全程拉通或者橫向拉通，以尋找業務斷點、業務改進機會點。筆者曾與這類企業交流過，也為一些很有上升力的互聯網企業培訓過企業架構方法論。

不過，一些做過或者接觸過企業架構的企業和人員也產生了一些“誤區”，比如總是想從實例上學習企架，而忽略了它的思維方式，結果，要么是看不出模型的作用，要么是把力氣都用在死磕企業架構中那些“模糊”的定義上了。

3 企業架構的未來會是什么樣？

討論企業架構的未來，得先明確企業架構的未來是由什么決定的。答案是企業，企業架構是為了實現企業的“共同目標”，是為企業服務的，那企業架構自身的演進，無論是方法論還是設計結果，都是要隨著企業的演進發展的。

未來的企業是什么樣的呢？當然是按照實際業務需要，盡可能數字化的。數字化如今是國家級的轉型方向，在“十四五規劃”中，數字化有單獨的一篇，并且這一篇的首段，就點明了數字化的關鍵問題，“迎接數字時代，激活數據要素潛能，推進網絡強國建設，加快建設數字經濟、數字社會、數字政府，以數字化轉型整體驅動生產方式、生活方式和治理方式變革”，這段話說明了數字化是一個新時代，主要抓手是數據、網絡、軟件，目標是建設數字經濟、社會、政府，方式是整體轉型，所以，每個企業的數字化發展也離不開這些關鍵點，這是“數字中國”的方向，自然每個企業都會深受影響。

我們還可以進一步分析下，這樣的企業必然是要建立在更大的社會級、行業級數字化平臺上，也就是基于數字生態構建的云上虛實結合企業。這樣構建企業軟件，需要更為靈活的 SaaS 服務方式，也就是說，不是基于重量級套件，而是由可以更加靈活選搭的、更小、功能更單一的“構件”組成的，相當于基于一個大型標準化開源構件庫進行選搭。為什么要這樣？因為這樣可以降本增效，數字化需要太多的軟件，目前的開發模式無論如何也滿足不了這么龐大的需求。數字化最重要的生產要素是數據，最重要的工具是軟件，因為只有軟件才能處理數據。那么，這些要素、工具如果要滿足這么多企業進行轉型，那得需要什么樣的效率才可以。如今，即便是大型科技企業，其開發模式也不過是“大規模小團隊手工作坊”，完全無法與工業化生產的效率相比擬，如果繼續這樣，軟件行業是擔不起全社會數字化轉型大任的。

不僅僅是生產效率問題，傳統的豎井式開發在高效推動企業信息化的過程中，也留下了大量的混亂的設計，這與企業架構始終沒能充分發揮作用，尤其是在思維影響上發揮作用有著很直接的關系，一個內部連接都有問題的企業，更無法做好生態連接。

這些方向決定我們一定要能力探索與“數字中國”建設方向相一致的企業架構方法論，并努力通過方法論提升整體設計能力和標準化程度，使軟件真正具備成為基礎產業的能力。為此，筆者拋磚引玉，提出了“聚合架構”，也就是基于底層標準化架構元素聚合上層架構元素的企業架構設計思路，使軟件設計逐步走向形成行業級標準化構件庫，非競爭性的通用能力基于標準化構件進行微量改造，競爭性能力重點開發的設計模式，通過企業架構方法論最終為基于云的數字生態打造思路更容易跨企業對接的設計思維、設計語言。

云上的數字化生態會不會最終成為“巴別塔”，也許取決于我們的程序員是否能夠更好地犧牲一部分“自由”換取更大的“效能”。

“聚合架構”的設計方法和“構件化企業”的概念如下圖所示：

圖四 聚合架構和構件化企業示意圖

程序員們，是時候重新關注企業架構了！隨著數字化的發展，企業的商業環境、我們的開發環境、我們面臨競爭模式都將改變，國外已經有人提出將大規模軟件開發能力列為國家競爭力了，這絕不是依賴“996”的小部隊混戰，一定是產業級的大兵團作戰，我們需要“道路自信、理論自信”。

作者簡介：

付曉巖，互聯網大廠資深行業解決方案總監。《企業級業務架構設計：方法論與實踐》、《銀行數字化轉型》和《聚合架構：面向數字生態的構件化企業架構》三書作者，原國有大行資深業務架構師，多年負責業務架構設計、項目管理，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗。原 IBM 副合伙人，總監，金融行業企業架構師。

本文來自微信公眾號 “InfoQ”（ID：infoqchina），作者：付曉巖，36氪經授權發布。