建設SOA需從企業架構開始
企業總體架構（EA）是對企業多角度的一種描述，並綜合反映企業中的人、流程以及技術，爲企業中的不同參與者提供不同的視圖，並用他們易於理解的方式和語言反映企業的狀態。
然而，目前國內的現實應用情況是，很多企業都是隨着業務的發展設立並開發很多分割的部門、流程和系統，而它們之間卻無法進行有機的合作，並且還會經常出現信息與業務報告不準、部門之間無法銜接等問題。更可怕的是，企業沒有方法和工具來解決這些問題。
根據國際和國內的經驗，通過企業總體架構的方法可以解決上述這些問題。目前，國內對企業架構設計的使用還主要集中 在IT層面，業務人員還沒有開始利用這類工具進行業務的設計和規劃。其實，企業總體架構是一個涵蓋業務、IT的全面企業藍圖設計工具，可以幫助企業的管理 者瞭解企業的構成，發現問題並不斷改進。
事實上，架構設計經過漫長的演變到現在，已經成爲現實生活中必不可少的工作。比如，要建一棟房子，就需要進行很多 的架構設計工作，首先要進行外部架構的效果設計，在客戶滿意之後進一步設計內部結構，並進行相配套的包括線路和上下水等多方面的設計。這就好比我們談到的 企業架構設計一樣，是從不同的層次和角度去描述一個企業的特徵。
項目建設和施工沒有架構圖就開始進行是很不可思議的一件事情，但是在企業內部管理方面，卻完全是另外一番景象。很 多公司雖然運轉了一段時間，但是一直沒有明確的企業架構和藍圖，或者說並不是很清晰，從而導致了很多運營中的問題，比如部門之間的職責界定不清晰、配合不 順暢; 運營的效率較低，很難提高客戶滿意度; 流程改進的效果不明顯; 業務部門與IT部門之間的關係緊張、系統問題比較多等。如果這些問題在企業中非常突出，那麼，企業就應該考慮總體架構的方法，因爲企業總體架構能夠幫助企 業有效地解決這些問題。
談到企業總體架構設計，我們首先要澄清幾個概念: 框架、方法論以及方案等，企業只有深刻理解了這些概念，才能建立有效的企業總體架構。
首先，框架（framework）定義瞭解決一個問題的相關因素以及它們之間的關聯關係，並描述了這些關聯因素是如何設計的。在實際應用中，框架會結合不同的方法論和方案來解決問題。一般，一個好的框架會支持多種方法論和方案，比如SOA框架、Zachman框架、DoDF框架等都是解決問題的框架。框架涉及的範圍一般都比較廣，但又都不是很具體，只是起指導作用，因此在具體實施的時候，可以採取不同的路徑。
其次，方法論（methodology/method）是由一系列相關的流程、任務和活動組成，也是如何達到一個 特定目標的理論。一般包括誰（who）、做什麼（what）、地點（where）、何時（when）和爲什麼（why）等要素。很多時候也會包括一些標 準、政策、規則等方面的內容，比如IT規劃方法論、系統開發方法論以及CMM方法論等。
最後，方案（approach）則是面對一個具體的問題，如何去解決它，比如有全面質量管理（TQM）、流程再造（BPR）等。
在企業的信息化建設中，需要用方法論定義什麼是獲得成功必備的系統。方法論是指如何從現有的狀態通過一系列的項目建設達到目標的狀態; 而方法則是指企業如何開發和改造各個系統。
現在，企業架構設計在國內的應用還並不廣泛，也沒有明確的定義，不同的公司和專家有相近但卻又不同的看法，還並沒 能形成一種相對統一的認知。比如，有人認爲，企業架構是定義企業各組成部分是如何構架的及它們之間的關係、它們設計和演變的原則和規定; 也有人認爲，企業架構是企業的邏輯藍圖，定義了企業的結構以及如何運轉，使企業能夠達到現有和未來的目標。
追本溯源，全球第一個總體架構的框架理論是由John Zachman在1987年創立的。到今天，這個架構還是最被企業和組織所接受的理論，國際上通稱之爲Zachman總體架構框架。
的確，儘管在IT業界有幾種比較流行的總體架構框架理論，比如TOGAF、DoDF等，但Zachman總體架構 框架被公認爲是最爲完善的，在企業領域的應用也最廣。Zachman的著作《信息系統架構框架》（Framework for Information System Architecture）直到今天也在業界普遍被認爲是一個權威的框架。（如表1所示）
在Zachman架構框架中最有代表性的是6列5行、共有30個元素的矩陣圖形。架構框架圖形以最簡單的形式描述了總體架構內的元素及其關係，說明了這些元素在設計中的功能和作用。而Zachman框架矩陣中的行是架構的層次和相關人。
第一行:規劃人員（Planner）
第二行: 屬主，通常是業務屬主部門（Owner）
第三行:設計人員（Designer）
第四行:開發實施人員（Builder）
第五行: 廠商/承包商（Contractor）
不過，Zachman架構框架還是比較側重在IT層面。然而，隨着企業架構的不斷進化，企業架構理論越來越與戰略和業務相融合，圖1展示了近幾年來很多企業架構的層次和內容。
可以看出，圖1中的企業架構由四個部分組成。
第一層: 在架構的最上層是企業的戰略思想，其清晰地定義了企業的願景和目標，描述了未來企業發展的戰略方向、外部環境的影響和競爭策略，以及如何建立核心競爭力、如何衡量企業未來的業績、是否成功達到目標等。
第二層: 中間一層是業務架構，業務架構是各個層次中最有影響力的部分，它定義了企業的業務流程以及信息系統應該如何支持業務的需求。其是將高層次的業務目標轉換成了可操作的業務模型，並描述了業務應該以何種方式運作才能滿足企業成功所需要的能力和靈活性。
第三層: 業務架構下面一層是信息架構，信息架構是一個廣義的概念，包含了信息的定義和內容，以及與信息結合的數據的定義和內容。
第四層: 最下面一層是IT架構，IT架構包括了應用架構、技術架構和底層的基礎設施等，是總體架構的最底層，也是實現企業運營的基礎。
對於企業來說，企業運營模式也是非常重要的，並且，運營模式與企業架構還有着非常緊密的聯繫。企業的運營模式主要包括了三個方面的內容，如表2所示。
業務架構（EBA）
業務架構定義了企業是如何創造價值以及企業內外部的協作關係，描述了企業如何滿足客戶的需求、進行市場競爭、與合作伙伴合作、建立運營以及培養員工等信息。
可以說，業務架構建立了企業戰略與日常運營之間的關聯關係，通過運營對戰略的支持，才能達到企業建立的業務目標。 同時，業務架構也是通過戰略影響其他一系列企業組成的工具，因爲十分宏觀的戰略需要通過業務結構進行分解，從戰略範疇轉化到戰術範疇。比如，從降低運營成 本20%的戰略措施，到提供網絡自助服務、裁減客戶服務人員40%等。事實上，IT、組織、流程等都是由業務架構進一步推導出來的，如果沒有業務架構而直 接進行企業細節的設計，就會出現與戰略不一致的問題。
信息架構
在歐美的很多企業中，數據架構與信息架構在涉及到總體架構的概念時，常常被交互使用。這裏的信息架構和數據架構是一個廣義的概念，包含了信息的定義和內容、與信息結合的數據的定義和內容。如果遇到某些理論中提及信息架構時，其實與這裏定義的數據架構是一致的。
信息（數據）架構包括數據實體和數據的交換與流動，保證數據有效地共享和交換是企業總體架構的主要目的之一。信息架構描述了企業現在和未來是如何使用信息和數據的，主要包括信息的分類和定義、與業務模塊結合的信息內容和信息流、數據的採集、存儲、轉換、發佈和傳輸、企業的數據庫設計和使用、數據標準和格式，以及數據字典、數據管理、知識管理、數據倉庫、數據集市、數據挖掘等與數據相關的應用系統等。
IT架構
IT架構包括應用架構、技術架構和基礎設施。
應用架構
應用架構描述了支持企業運作的系統，比如財務系統、交易處理系統、人力資源、辦公系統等。應用架構可以採用多種方式來表達，通行的架構有客戶機/服務器(C/S)模式、瀏覽器/服務器模式（3層架構或者4層架構）等。在應用架構中有許多行業標準，比如J2EE和.NET等，它們都體現了模塊化和集成化的思想。
技術架構
技術架構是定義企業IT的科技管理和技術標準，從最高層次的政策（Technology Policy）、原則(Principles)、指導綱要(Guideline)到技術領域的技術標準化（Technology Standardization）、技術選擇（Technology Selections）和技術組件(Technology Components)。
可以說，制定技術標準和推廣標準化是企業的兩項重要任務。圍繞着技術標準化，有一系列的流程與管理。技術元素包含 了一系列的總體架構技術組件，這些組件可以是一個可重複應用的系統或模塊，也可以是最小的可獨立在架構中使用單個技術的組件，比如一個安全軟件、一個插入 的外圍設備等。完整的企業標準技術架構是涉及了信息架構、應用架構和基礎設施等層面的標準。
基礎設施
基礎設施是整個企業IT系統的基礎，是包括硬件、操作系統、數據庫系統、網絡系統等企業數據和應用程序可以運行的環境，同時要滿足企業的數據量、用戶數、反應速度、在線率等要求。企業70%的IT投資都花在了建設基礎設施上，對分佈在企業各個部門、地區的IT資產的瞭解可以降低資源的浪費，並提高系統的利用率。
而基礎設施標準的定義是: 一系列技術和服務的組合，提供了一個穩定的、低成本的數據和信息的採集、錄入、處理和傳送的物理及邏輯設施。大型企業可以根據基礎設施的種類不同進行分 類，如數據中心、網絡、指揮中心、服務器組等。而具體的業務應用，如財務、HR、銷售、採購、研發、製造系統等爲非基礎設施的IT應用，它們是運行在企業基礎設施之上的應用系統。
目前，被越來越廣泛使用的SOA系統規劃和開發方式改變了以前的舊有方法，使得IT系統變得更加靈活，並能夠重複 使用。SOA模式不僅要求IT要採用組件化的開發，而且要求業務也要同時使用組件化和服務化的運營模式。圖2展示瞭如何從業務的組件化中提出SOA的需 求，並實現IT的組件化。
在業務範疇之內，由流程/子流程能夠歸納出業務組件。而業務組件可以提供一系列的服務，在提供服務的同時，也需要 使用其他組件的服務，這就是SOA業務服務化的重點。在系統範疇之內，系統組件是提供服務的單位，它提供的服務與業務的服務是一一對應的。這是在SOA框 架下，業務與IT的緊密連接之處。系統組件是由多個組件組成的，這些組件可以分成功能性組件和技術性組件，並且，系統組件組成了子系統合系統。
在實際的業務服務設計中，一般會對業務組件和業務組件內部的活動進行定義，如下圖3所示。比如，在保險業務的理賠 業務中，接報案是一個業務組件，組件內部的活動有接聽報案、查詢信息、記錄、案件分類等，接報案組件能夠提供的服務在表格的右邊; 接報案需要的其他業務組件提供的服務列在表格的左邊。
當設計好業務服務的架構以後，能夠很容易地開始SOA在IT階段的開發; 這也從另一個角度說明，SOA的建設是需要從業務開始的。
總之，如果企業總體架構的理論和模型可以被企業管理層、CIO、規劃部門、IT分析人員和開發人員理解並使用，就可以規範並提高國內IT管理和規劃的水平。當然，先進的管理理念和方法的採納及運用需要一段時間，而一旦能夠得以實施，會給企業帶來很大的效益。