EA不僅僅是壹個架構，更是壹門學科。同時強調通過需求獲取將it和業務策略結合起來。SOA也是壹種架構，主要是根據企業的需求關聯資源。與EA不同，SOA中的所有資源都是統壹的服務形式。兩者壹般都采用層級組織架構，其中EA概念提出較早，不同廠商有各自獨立的方法論，所以EA中的層級體系中垂直劃分了很多視圖(微軟稱之為面向業務的概念視圖、面向應用的邏輯視圖和面向部署的物理視圖；IBM稱之為各種技術領域的技術部分，業務的業務部分)。但是如果我們觀察EA和SOA的每個領域，仍然有許多不同之處:
領域SOA框架EA框架
業務業務流程業務架構
應用服務和組件應用架構
集成和中間件集成架構/ESB技術架構
數據數據架構信息架構
運營服務質量、安全性、監控和基礎設施技術架構
不難看出，SOA的每個域只是EA對應域的細化，這種情況很容易理解，因為從技術上來說，SOA調用的資源只是服務，而這只是EA中資源的壹種形式，所以從每壹個層面來說，SOA都是服務的特例。就環境集成而言，SOA使用ESB來集成服務，但在EA中，除了基於服務的集成，還可以通過多種方式進行集成:
數據集成:在很多企業中，這種方法非常普遍。由於網絡隔離、應用構建時間、開發平臺等因素，企業中的應用很多，但關鍵數據(尤其是核心業務數據)始終處於中心，應用是圍繞數據進行集成的。
功能集成:當多個應用程序使用同壹個開發平臺時也很常見。例如，在。NET平臺可以由WCF完成。NET遠程處理和COM+。Java平臺可以通過EJB、RMI等進行集成。還有很多簡單的跨平臺技術，比如Socket。
展示集成:這在現在的Web應用中也很常見:企業在添加新的Web應用後，在門戶中添加壹個超鏈接，這樣也可以通過UI部分進行集成。
這樣看來，SOA似乎只是EA的壹個分支，專門從事技術領域？不完全是。文章的第二部分解釋了SOA和EA在系統和治理方面的許多差異。
那麽我們作為用戶而不是IT廠商如何選擇呢？
如果信息化剛剛起步，根據未來的IT規劃，確定關鍵的IT資源並選擇壹種短期預期的集成方法是經濟的。EA意味著企業給自己提供了更多的選擇。
如果有壹定數量的應用，需要統壹安排，但是所有的開發都基於單壹的開發平臺(。NET或Java)，沒必要盲目跟風SOA。也許在企業內部建立壹個集中的數據交換平臺，無論從成本、運營管理、投資和執行效率來看，都是壹個不錯的選擇。本文從EA的角度來分析自己的事情。
如果企業的運營依賴於互聯網上的合作夥伴，但是企業內部的應用非常單壹，不壹定使用SOA，將關鍵的業務資源暴露為服務就足夠了。但是要註意這些服務的標準化(公共標準和行業標準)，這樣如果有壹天需要過渡到SOA，我們也可以開著車去換輪子。
如果企業應用類型、開發平臺、運營平臺、消息機制很多，不如把它們加起來，而不是相乘，把每個人都連接到服務總線上，用SOA中相對簡單的“服務”概念解決復雜的“大麻煩”。
還有壹點，壹定要算好經濟賬。無論是EA還是SOA，在三五年內肯定都會過時。需要從EA或者SOA的角度來規劃it和業務願景的契合度，但是現在在妳的IT環境上大做文章“劃算”嗎？