觀察過去一年 SOA 在美國的發展，一個愈來愈明顯的趨勢是，SOA 和傳統 EA (Enterprise Architecture；企業架構) 領域逐漸在協作和融合。不久前，美國知名的 SOA 顧問大衛•林錫肯，David Linthicum 在一個由 The Open Group 主辦的大會上預言：五年後，大家將不再像現在這麼看待 SOA，因為 SOA 將逐漸融入 EA，變成只是 EA 實踐中的一部份。此話一出，引發各方激烈的討論。
對於絕大多數 IT 從業人員來說，”EA” 一直是個模糊而遙遠的名詞，儘管它已經悄悄存在約二十來年了（這點，從 EA 相關書籍數量之少，便可看出）。在許多世界五百大、一千大的大企業中，儘管在 IT 中存在著 EA 的組織，但這些架構師在組織外的其他 IT 同事眼中，往往是一小撮象牙塔里的文書官僚 (paper-pushers)，對於他們實際的工作內容，往往非常陌生，也不關心；許多項目實施團隊，對於 EA 架構小組所制定的各種標準和規範，甚至採取 “上有政策，下有對策” 的態度。
要正確了解什麼是“企業架構”？首先必須先對 “Enterprise”、即“企業”有一個清楚的界定。制定 EA 規範的機構 The Open Group，對 “Enterprise” 所下的定義是：
若干個組織的集合體，具有共同的目標和/或單一的財務底線。
一個企業可以是：
- 一個政府機關
- 整個公司
- 某公司的一個分支
- 一個單獨的部門
- 一個組織鏈，所有權同屬於某群人/組織
- 一個“延伸型企業”，其中包括夥伴、供應商，和客戶，以及內部的業務單位
由此可見，EA 架構方法論，對“企業”適用的範圍，相當具有彈性。不過，任何企業或組織在實施 EA 之前，應先在憲章中，對 “企業” 的範疇，有清楚的界定。必也正名乎。
把 EA 中的 “E” 交待了以後，我們可以把 EA 簡單定義為：一套管理企業 IT 轉型計畫和變革的一連串動態流程和方法論。它為企業提供一個何去何從的 roadmap，為業務和 IT 變化提供路線，計畫，和藍圖。作為一個專業科目，EA 的工作在透過架構督導和治理，來促成業務和 IT 的緊密配合。
在這裏，我們看到一個在 SOA 領域不斷出現的關鍵字 — governance（常見翻譯包括：治理、管控、督導、監管）。由此可看出，EA 和 SOA 有著相同的總目標 — 讓業務和 IT 更緊密地配合 (alignment)，以 IT 作為重要的競爭工具，進而達成企業的戰略目標，包括為客戶提供更好的服務、提升客戶滿意度，進而為股東創造最大的價值。至於 SOA 究竟為 EA 帶來什麼樣的新思維和新方法，稍後再來談 。
上面對於 EA 的解釋，比較抽象。我們可以進一步用城市規劃 (City Planning) 來比喻：EA 要做的工作，就是一個城市的整體規劃，具體的工作和內容，涉及多幾種角色，包括市政府官員（業務擁有者、stakeholder）、建築師（架構設計）、土建包商（專案管理）、專業施工團隊（程式設計師）。大家都知道，軟體設計有許多靈感來自可重複套用的建築模式 (Design Patterns)，被 Gamma 等進一步體系化，一轉眼已經走過一輪生肖了；其實 EA 甚至更早便從建築中得到靈感，例如著名的 Zachman （紮克曼）框架體系，正是受建築和航太工業的啟發，這是二十年前的事了（註：”ch” 在此發 /k/ 的音，美國著名的投資銀行 Goldman Sachs，和一家大銀行 Wachovia 名字中的 “ch”，也是相同的發音）。紮克曼以建築作比喻，讓規劃者能將複雜的企業架構內容，分解成水平六層不同的視角來分析，就像前面比喻的城市規劃，市政府官員、建築師、包商，和施工隊成員，各層有各層關心和需要的資訊；在縱向的維度，再根據六大問句來切割 — What（資料）、How（功能）、Where（網路）、Who（人、演員）、When（時間、事件）、Why（動機）– 來一一整理出不同層面的架構資訊。紮克曼提供了一個很好的邏輯分類結構，來描述企業資訊化的各個層面。
除了紮克曼架構外，其他幾個最主流的 EA 架構，包括 The Open Group 的 TOGAF（The Open Group Architecture Framework；讀作：偷蓋夫）、美國聯邦政府的標準架構 FEA、美國國防部的 DoDAF。
TOGAF 的主幹是一個包括業務、資訊、應用，和技術架構的四維模型：
- 業務架構：定義業務戰略、業務驅動因素、治理 (governance)、組織結構、角色定義，和重要的業務流程
- 資訊/資料架構：描述一個組織的邏輯資料模型、物理結構，和資料管理資源，包括資料的規類、與業務應用的關係、資料的使用和管理策略等
- 應用架構：對要部署的應用系統，提供一個藍圖，應用間的相互關係，和他們與核心業務流程之間的關係
- 技術架構：描述用來支援業務、資料、應用服務部署的基礎設施能力，包括中介軟體、網路、通信等軟硬體，及相關的平台和技術標準等
TOGAF 提供一套詳細的方法流程（稱作 ADM; Architecture Development Method），依據業務需求，來指導企業架構的開發。ADM 和 Zachman、FEA
等框架間沒有衝突或矛盾，而是為所有的框架，提供一個從收集、記錄現況，然後制定未來藍圖願景，再分析鴻溝，並制定如何填滿鴻溝的計畫；一個自上而下的規劃流程。
看到這裏，可能有人會問：EA 工作如果做得好，規劃出來的專案都能一一落實，是不是就不需要 SOA 了？換一個角度問，SOA 是否給傳統 EA 領域，帶來什麼新的理念和方法？
前面一開始提到，多年下來，許多企業的 EA 組織，在一般 IT 同事的心目中，往往是一群訂標準規範、做 PPT、畫藍圖，定架構發展路線圖的理論家。換句話說，EA 規劃和專案的執行成效，落實與否之間，往往有一個斷層。在許多企業中，EA 的角色，最後往往流於只是在制定軟硬體採購標準這類的工作。但制定標準規範這件事本身，並不能使業務更加敏捷靈活（應該說只有比較間接的幫助），而這樣的貢獻，更是很難訂出指標來衡量其績效；在這樣的惡性循環之下，EA 的 ROI 很難得到充分的支撐。
有人批評 SOA 的 “S”，認為到底什麼是“服務”，已經說不清楚了；而這兩年市場上關於 SOA 的炒作和雜音，似乎只讓問題更為加劇。這是個非常有趣的話題，因為 SOA 給 EA 帶來的關鍵價值，我認為其實正在於此 — 表面上看，“服務” 的確是個模糊的概念，從業務人員、架構師，到程式設計師，各自對“服務”的解讀，都不相同；但這恰好是 SOA 給 EA 、傳統應用導向的需求管理，和專案交付方式，所帶來的最大價值。“服務”概念的出現，其最大意義，在於提供了我們一個能貫穿從業務需求、架構規劃、專案交付，一路到上線後的營運監控的統一概念 — 一個具有很長的生命週期、能夠全程管理的單元。業務功能能透過“服務”來溝通，並且針對個別服務，制定契約來規範它的功能，以及效能指標、安全要求等非功能性需求。用紮克曼層次化的概念來看，儘管“服務”在各個層次所著重的內容不同，但最終是個統一貫穿的概念；更重要的，是它跨越了傳統 EA 和專案交付兩大迭代 (iterations)，讓 EA 所規劃出來的模型和規範，能真正貫徹、落實到項目的執行，甚至於上線後的生產營運，和監控管理（第三個迭代），將績效回饋給業務的 stakeholder，形成一個能不斷迭代精煉的循環。這是 SOA 概念及方法論給 EA 和傳統應用導向的需求、專案管理方式，所帶來最大價值。