作者：付曉岩

來源：華章科技

企業架構設計的服務對象是企業，所以，“企業”是企業架構理論需要首先明确的概念，對于這一概念，筆者比較贊同TOGAF理論中對“企業”的定義，也即，企業是具有共同目标的一系列組織集合體。

盡管概念略有抽象，但是這一旨在界定涉及範圍的概念有效地避免了關于企業性質的深入讨論可能會帶給企業架構理論的混亂，也很好地拓展了企業架構理論的适用性。

基于這一概念，企業架構理論适用于任何組織形态，也不需要區分組織規模，并且強調“共同目标”對企業架構設計的指導性意義，實現“共同目标”是企業架構的使命。

确定了“企業”的概念之後，接下來要确定的自然是什麼是“架構”。筆者比較認同ISO中對“架構”的定義：架構是指系統的基本組成部分，各組成部分之間及其與環境之間的關系，決定其設計與演進的治理原則。也即，架構主要包括結構、關系、原則（也可以理解為“規律”）。

這一概念同樣也沒有限制架構的适用範圍，所以筆者曾在自己的公衆号文章中提到，“萬物皆有架構”，不僅我們設計的系統如此，詩詞歌賦也一樣。不同的詞牌子有不同的字數、平仄、韻腳的要求，可以産生不同的節奏，每個詞牌子都是一種“架構風格”，不同的“架構風格”适合不同的主題、抒發不同的情感，頗像技術領域常說的設計模式。

那麼把這兩個概念結合起來，筆者認為，作為名詞的“企業架構”的概念應當是“具有共同目标的組織集合體的基本組成部分及其内外部關系與治理原則”。由此，企業架構設計就意味着：

• 根據共同目标分析、設計相關組織集合體的基本組成部分和内部關系；
• 企業架構治理的核心則是持續形成和完善用于指導設計和架構演進的原則；
• 企業架構方法論則是根據企業架構的概念，為企業架構設計和治理的實現提供指導性的框架；
• 企業架構實施則是根據企業架構方法論提供的框架，針對本企業的特點進行的企業架構實施活動，包括架構設計與工程管理兩部分，企業架構實施會帶來企業架構方法論的改變，這種變化最終也可能會導緻企業架構核心概念的變化，也即，企業架構理論是動态的、知行合一的理論。

按照Zachman框架的理念，企業架構是多視角架構的集合；TOGAF将其内部劃分為“4A”架構，即業務架構、應用架構、信息架構（數據架構）、技術架構。

筆者也認為企業架構不是一張包羅萬象的“大圖”，而是多視角的集合，筆者建議應當将TOGAF“4A”架構中的業務架構與信息架構整合為新的“業務架構”，理由是業務和數據應當在架構設計過程中整合考慮。

這并非要取消數據模型，而是數據模型不應再是單獨的設計過程，應該與業務模型一同設計，并形成更緊密的關系。一方面有利于提升業務架構的結構化、标準化程度，另一方面也便于業務架構與應用架構的銜接。

因此，筆者建議的企業架構在内部分類上包括業務架構、應用架構和技術架構，信息架構則分别融入這三個架構的設計過程中。

每種架構都有自己關注的部分，但是，作為整體而言，構成三者之間銜接關系的則是對相同内容的審視，這個相同的内容就是對架構組成部分和原則的認知。而這三種視角認知的背後，則是企業戰略、組織和企業文化的影響。

因為每種架構最終都要為實現戰略服務，而各個架構都會不同程度地受到企業組織結構的影響，在這方面，“康威定律”的作用已經被廣為接受了，盡管不太合理，但是，即便是離業務相對較遠的技術架構，其平台的規劃設計也難免會受到組織因素的影響。

企業文化作為一種不可見的“軟因素”，其對企業的影響更是滲透到企業的方方面面，圍繞企業架構開展的各種活動都是企業活動的一部分，也必然受其影響，因為一切活動最終都是人的活動，企業架構活動也不例外。當然，企業架構活動也會反作用于企業的戰略、組織和文化。

三個架構中，重點是業務架構，這是實現業務與技術深度融合的關鍵部分。

企業架構方法論并非隻關注理論的自洽，而是高度關注其實現能力，因此，企業架構方法論中，除理論邏輯外，應當包含實施建議或者指南、工具介紹。新理論可能在列舉實施指南時缺少可供參考的實例，但是不能因此而停止對理論發展的大膽讨論，因為對待方法論研究的正确态度是積極思考、勤于動手、博采衆長。

方法論實踐是需要結合企業自身特點而不能簡單照搬的，因此，實例對于理解方法論而言，雖然具有非常珍貴的參考價值，但不能完全按照實例去理解方法論，因為實例都是方法論的落地的“特例”。所以，理論上的研究也需要敢于大膽提出方向和設想，再去實踐中求證。

在企業架構方法論中，除對設計方法的介紹外，也應包含方法論對工程模式适配能力的分析，工程模式是企業落實企業架構的必經之路，所有設計最終要通過工程能力實現，工程管理對于架構落地效果具有至關重要的影響。方法論要做到的是努力兼容各種工程模式，這對方法論而言是一種很大的挑戰。

企業架構方法論不應當隻停留在“當下”，應當對自身的發展方向有所指向，這是架構方法論在時間上的擴展性、适應性的來源，也是為對該方法論感興趣的企業、讀者提供創新思路的指引，也即，所有的架構方法論理論上應當是自洽的、閉環的，但思想上應當是演進的、開放的，方法論研究永遠在路上。

因此，沒有停滞不前的方法論，隻有讓方法論停滞不前的選擇，也即，方法論的停滞通常是人的問題。

關于企業架構的認知，還有一點非常重要，企業架構是為企業服務的，但企業不是為企業架構而生的。做企業架構是為了更好地理解企業，提升管理能力，但不是為了用企業架構去“統治”企業。

企業架構是為了通過内部一體化、内外一體化的設計提升效率，但企業架構自身的述求不是企業必然會放在第一位去考慮的問題，當利益的需要與既有架構的工作方式、原則産生沖突時，企業很可能會把利益置于優先地位，這是可以理解的，盡管會對架構産生影響，甚至給今後遺留下問題，但是，企業架構和做企業架構的人都必須能夠接受和适應這種“例外”情況。

筆者希望企業更多地通過企業架構引導自己的決策，企業架構反映的正是遵循秩序帶來的自由，沒有秩序的自由終将導向全面的混亂。臨時的、局部的混亂也許可以為企業帶來産生一定優勢的“靈活”，但是，沒有企業可以靠“全面混亂”取得長期競争優勢。

筆者提出的新企業架構方法論的主要内容如圖3-1所示。

▲圖3-1 新企業架構方法論概念圖

如果讀者對企業架構方法論有一定了解的話，可以發現，筆身并未新增概念，而是對已有認知的加強和調整，這也是對“奧卡姆剃刀原理（簡單有效原理）”的應用，“如無必要，勿增實體”。

1. 企業架構要去解決的問題

數字化時代是以軟件為主要生産工具、以數據為關鍵生産要素、以協作為普遍生産組織方式，虛拟與現實深度融合的“超級體驗”時代，個體将享受到空前的獲得感、參與感，乃至幸福感。

這樣的一個時代，是被軟件“包圍”、“填滿”的時代，軟件開發量的增長已經先于時代的到來提供了未來的迹象。據某知名機構預測，未來5年的軟件開發量将超過過去40年開發的總量，那麼，未來10年、20年、30年呢？

随着軟件技術在基礎教育中普及，“全民編程”時代距離今天也未必很遠，對于企業端的軟件開發而言，這是好消息，也是壞消息。

企業的對外服務、對内管理大量都在依靠軟件實現，即便是街邊零售攤販，也在使用軟件收款結算。軟件服務範圍的擴大，直接導緻“軟件缺口”的擴大，且沒有因為軟件開發速度的加快而縮小。

越來越多的企業端軟件，在提升單項工作效率的同時，也在加大總體管理的成本，增加數據處理的難度，這可稱之為“軟件混亂”。“軟件混亂”導緻通過軟件提升企業洞察力的難度加大，而這本應是數字化發展的關鍵方向。

如果軟件開發由于從業者人數、工作量的持續上升卻未能填補“軟件缺口”，反而加劇“軟件混亂”，那将與開發軟件的目标背道而馳。軟件本身要能夠很好地解決問題，這之後才有商業利益可言。

凡是軟件必有架構，這是由軟件的生産方式決定的，無論采用面向過程、面向對象還是面向函數的編程語言，軟件都隻能按照某個特定的結構去實現，因為需求本身也有其内在結構。

企業端軟件面對的問題是在其開發過程中導入了企業因素而産生的特殊複雜性，企業因素包括企業戰略、組織結構、業務模式、外部協作、客戶變化等等，企業是一個特定的“問題域”。

軟件架構的清晰會降低複雜度的不可見性，會讓問題的解決能夠因為結構的分解而從“大”變“小”，架構是解決“軟件混亂”的正确方式，企業端軟件也不例外。

為此而需要針對企業複雜性這個特定“問題域”導入的解決方式就是“企業架構”，目前各類應對企業端軟件開發存在的“軟件混亂”而采取的措施，最終都會導向某種在整個企業範圍内思考問題、尋求策略的傾向，其實質都是對“企業架構”的探求，僅是方法上的區别而已。

2. 企業架構還需要發展

“企業架構”是解決企業端“軟件混亂”的工具，但并不是意識到這一點就可以了，工具本身也會帶來複雜性的增加，也可能導緻混亂，因此，讓工具本身清晰也是非常重要的。

架構究其實質就是在澄清結構和關系，因此，必須聚焦于關鍵設計元素及其關系的獲取上，架構開發中采用的方法、工具都要服務于這一目的，而不要過度拓展架構解決問題的方式方法，導緻架構方法論的混亂。

企業不應當被“企業架構”龐大的“身影”迷惑，甚至産生畏懼，清晰的企業架構方法是在解釋企業的複雜性，企業的複雜性不會因此而放大，反過來，企業的複雜性也不會因為不采用企業架構方法而減少。

企業架構會關注企業的戰略、組織、業務、技術等方面，但是，架構在每個方面關注的都是其設計元素及相互關系的識别與表達，架構本身不等于架構設計對象，隻是對架構設計對象的良好表達，籍此澄清架構設計對象。

為了達到這一目的，企業架構方法論必須闡明自己關注的設計元素，并且可以動态調整這些設計元素及識别方法，這就是企業架構方法論的演進。

澄清架構設計對象雖然有助于解決“軟件混亂”問題，但仍然不能保證對軟件開發速度的提升，無法解決“軟件缺口”問題。

“軟件缺口”問題的成因之一可以歸結為“軟件混亂”問題，是更大的行業級别的“軟件混亂”，這一問題導緻行業通用功能即無法很好地由商業套件提供，也無法通過開源手段簡單解決，因為這是語境、語義上的“混亂”，是跨企業的定義、标準、理解不一緻産生的“混亂”。

由于架構方法的内在邏輯，企業架構有助于解決這一問題，但這不再是單一企業的架構設計方式可以解決的，需要跨越單一企業邊界進行标準化提煉，是行業級的标準化。但是即便在同一行業内，不同規模的企業，其架構依然可以是不同的，所以，這是按照企業行業、規模等維度“分層”的企業架構。

基于對标準化分層企業架構的提煉，可以孕育“量産”型的架構設計生産能力，當然，這并非絕對的“量産”，而是與當前長周期、人力型企業架構生産方式相對應的“量産”。

在企業架構工具的支持下，少量企業架構師應當可以有效指導一個企業的、快速的架構設計工作，這裡需要明确的是“指導”而非“生産”，因為企業架構設計不是架構師自己的事情，是整個企業的工作。

企業架構是數字化企業的思維模式，把一切事物結構化，進而數字化，把所有局部有機整體化，這是需要全企業共同努力的事情，每個人、每個物品都是企業的一部分，也都是企業架構可以描述的一部分。

這種支持跨企業甚至跨行業标準化、“量産”的企業架構，也可以是采用生态方式構建的企業架構。專業咨詢公司依然可以靠設計更高質量的企業架構赢取收入，但是企業架構也可以是“開源社區”一樣的“開源企業架構社區”，可以是民主化、分布式的架構設計能力，而非中心化的架構産品。

以構件為單位的架構設計，其架構構件、關系說明應當可以開源，或者有償提供構件級的産品，從而為架構設計提供可以快速生長的“生态”，如果構件本身已經包含實現，這就是更好的、不以單一系統為生長邊界的“開源企業架構社區”，當然，這裡也需要國家的支持力量和專利管理的發展，才有可能平衡社區的運營，《中華人民共和國國民經濟和社會發展第十四個五年規劃和2035年遠景目标綱要》中已經對“開源”的價值有所肯定和期待。

企業架構有助于解決企業端軟件生産存在的“軟件缺口”和“軟件混亂”問題，但這并不是當前的企業架構理論可以馬上解決的，需要理論自身的發展和所有支持者、需求者共同而長期的努力，尤其重要的是，這不是在技術内部可以解決的問題，企業架構尤其是其中的業務架構部分，必須走出技術側，能夠被業務側掌握且廣泛應用，才能激發其全部價值。

3. 企業架構應滿足的基本要求

企業架構自身需要發展，而發展中應注意對自身最基礎的五項要求：

1. 架構資産的明确性。企業架構對其設計元素的表達、對架構資産的界定，應當盡可能清晰，不增加額外的複雜度。
2. 架構連接的清晰性。元素間的關系應當明确，元素間連接在連接存在的瞬間就是靜态的，必須清晰。
3. 架構組合的靈活性。架構從底層元素開始就要支持對其進行靈活組合，這是架構彈性的基礎，靈活的組合會導緻架構資産定義的困難，這需要在架構資産定義時做權衡。
4. 架構溝通的高效性。基于架構進行的溝通必須是高效的，否則，說明以上三項的要求未能滿足，架構溝通的高效性可以說是對架構設計質量的檢驗。
5. 架構方法的友好性。架構是具有一定抽象性，又是用來解決複雜問題的，方法難免會有走向過度複雜化的傾向。但企業架構是為企業戰略服務的，是遵循由戰略到業務到技術的路線傳導的，如果方法缺乏友好性，會讓業務和技術兩端“嫌棄”，尤其是業務端，業務端的“嫌棄”會讓通過企業架構促成業技融合的想法落空。

而對達成這五項要求非常重要的是對元模型和業務視角（也即業務架構）的重視，這也是構建企業架構方法論與架構框架的核心要點。

關于作者：付曉岩，IBM 副合夥人，全球企業咨詢服務部大中華區金融核心銳變團隊業務發展和交付總監。資深企業級業務架構師和數字化轉型專家，具有12年銀行業務條線工作經驗和8年IT條線工作經驗，是一位能将技術和業務深度融合的複合型人才。是國有大型銀行企業級轉型工程的親曆者，也曾在央行數字貨币項目組中從事業務架構工作。

本文摘編自《聚合架構：面向數字生态的構件化企業架構》，經出版方授權發布。

《聚合架構：面向數字生态的構件化企業架構》

推薦語：本書旨在為數字化時代的企業架構提供與時具進的方法論指引，或将成為軟件架構領域的裡程碑作品。本書全面且系統地講解了聚合架構方法論的演進背景、基礎理論、設計指南、工程管理和生态化構建。既包含方法論，又有對構建方法論的建議；既可以指導企業的架構實踐，又可以為企業在數字化過程中構建自身的方法論提供可參照的樣本。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!