在過去一段時間，我碰到好幾個企業的IT領導要做“數字化規劃”，跟我說他的要求是：“一定要把企業架構（或者有時說成“4A架構”）做細，細到模型的第五級，程序員拿著五級架構的設計文檔，就能直接寫代碼了”。

聽到這樣的要求，我有些哭笑不得，不知道他們聽說有哪家企業是這樣做的？

“企業架構” 這個概念主要是從歐美大公司傳出來的，近年來不少歐美的全球化大公司紛紛建立了企業架構管理體系，國內也有不少金融機構、制造業等大型企業開始探索這個做法。由于某些先行企業的示范效應以及部分廠商和咨詢公司的推動，“企業架構”這個詞開始在國內流行，然而對這個名詞所代表的真正含義并不清楚的某些供應商或專業人士在咨詢市場上制造輿論，給企業管理者帶來不小的誤導。

下圖是我在2009年參加企業架構方法培訓時學習的一張圖，這張圖很明確地顯示了：企業架構的定位是上承公司業務戰略，下接各個具體IT系統建設的設計和交付，所以，企業架構本身并不涉及到每個IT系統具體的詳細方案設計，它是通過“架構治理”的機制，來協調各個IT項目（以及各IT項目之中會涉及到IT系統的建設）的功能范圍、建設優先級、技術標準等。

以這個例子為比方，“企業架構規劃能細化到開發說明書，拿著就能寫代碼”，就相當于要城市規劃設計院的規劃設計師，去給建筑工地的鋼筋工、泥瓦工畫施工圖。

今天下午我和三位前同事就企業架構在組織內定位及實踐做了次交流，他們一位服務于國內某大型金融機構，另外兩位則分別就職于兩家歐洲大型跨國公司IT部門，這些企業具有一定的企業架構管理成熟度——都在公司總部設置了專門的企業架構管理部門，甚至采用了諸如SAG ARIS這樣的專業架構管理工具。

他們的企業內實踐支持了我的想法：企業架構管理是業務部門和技術開發部門之間的統籌規劃職能，它并不能替代業務部門和技術開發部門之間直接合作的、IT系統開發相關的業務分析、設計、測試、實施管理等工作：

從我了解到的信息，至少在目前的現實應用中，企業架構管理工具和軟件工程工具是兩回事，架構建模（包括流程建模和數據建模）和實際的系統也幾乎沒有集成關系，是兩張皮——雖然所有架構管理的理論上都說要這么做。架構管理部門用工具畫出來的那些業務流程圖、數據模型圖，和在用系統的實際情況也是兩張皮，經常是業務部門不認，負責系統開發的IT部門也不認。

但是，這并不是說企業架構方法和架構管理軟件工具沒用，這些企業認為仍然有必要用結構化的方法、可視化的工具，來定義業務能力組件、識別部門邊界、規劃應用系統架構和實施路線，他們認為在目前的管理中，企業架構管理的這個作用達到了。

以ARIS工具為例，我觀察到國內某領先大型企業在市場上宣傳其采用了ARIS企業架構元模型來進行企業架構建模，但是據我所知，他們的企業架構模型和該企業實際的系統開發軟件工程平臺基本上沒有關系。一位在歐洲跨國公司的朋友也證實了，他們應用ARIS的流程建模和企業架構元模型，希望用TOGAF方法來指導整個公司的業務劃分和應用系統規劃，但是在實際操作過程中，對于定義應用系統的邊界以及處理不同業務單元的業務建模標準化問題，遇到很多挑戰，即使是指導應用也困難重重。

就我對ARIS的觀察，最近這十多年隨著企業架構理論的發展，建模方法論越來越細，從“業務流程建模”發展到了“企業架構建模”（如下圖），從工程學意義上來說，越來越邏輯完善、結構精密，固然很好，然而，這又形成了“方法論陷阱”，即當做一件事的方法論過于復雜后，這件事的參與方越多，就越無法操作了。

這位歐洲跨國公司的朋友說在他們實際工作中，企業架構主要是解決跨區域、跨職能的頂層設計的共性問題，抓能集中管控的對象，這個過程牽涉到無數的總部和下屬單元之間的博弈。具體到系統的詳細功能設計，業務部門畫流程圖，都沒有辦法由企業架構管理的職能來統統抓完。

最近幾年，國內最大的幾家銀行開風氣之先河，開始實施企業架構管理體系；在銀行IT管理體系常見的“一部兩中心”組織模式之下，提升管理部門和研發中心、數據中心之間的協作效率，明確工作界面：

今天很多銀行都在因應技術發展在開展系統升級，尤其是基于業務流程和業務能力分析，基于“解耦-重構-復用”的思想，來設計并構建數字化產品，支持業務流程和業務實體對象（例如科目、客戶、賬戶、產品、合約、渠道等等），企業架構本身是支持業務和技術融合，持續開展技術創新的一種工作方式。

來源：某銀行新一代核心系統公開宣傳材料

然而，企業架構能做什么、不能做什么，企業架構管理的范圍、邊界、組織治理模式是什么？為什么要做企業架構，帶給企業的價值是什么？這是企業IT管理者首先要想搞明白的問題。想通過一個企業架構咨詢項目，就產出寫代碼能用的系統設計文檔是不現實的。