Zachman框架起源于John Zachman的題為“信息系統(tǒng)開發(fā)框架”（A Framework for Information Systems Development）的學術(shù)論文，文中闡述了在信息系統(tǒng)開發(fā)工作中對軟件體系結(jié)構(gòu)的看法：系統(tǒng)開發(fā)是由具有不同關(guān)注視點的若干層面人員共同完成的，這與認識到系統(tǒng)開發(fā)是由不同階段完成的同等重要；在系統(tǒng)開發(fā)中，考察對象不應(yīng)僅限于數(shù)據(jù)和功能，還應(yīng)包括地點。Zachman給出了一個矩陣，將關(guān)注視點放在列上，角色層面放在行上。
此矩陣最初有是什么（What）、如何做（How）和在哪里（Where）三列。后來，Zachman又增加了是誰（Who）、什么時間（When）時間和為什么（Why）三列。Zachman框架可以用來指導信息化建設(shè)過程，并管理此過程中的設(shè)計產(chǎn)物。
Zachman框架如下圖所示：
圖2.1 Zachman框架
| | 做什么（What） | 如何做（How） | 在哪里（Where） | 誰 | 何時（When） | 為什么（Why） |
| 數(shù)據(jù) | 功能 | 網(wǎng)絡(luò) | 人員 | 時間 | 動機 | |
| 范圍 （背景） 規(guī)劃者 | | | | | | |
| 業(yè)務(wù)模型 （概念） 所有者 | | | | | | |
| 系統(tǒng)模型 （邏輯） 設(shè)計者 | | | | | | |
| 技術(shù)模型 （物理） 承建者 | | | | | | |
| 詳細表示 （背景之外） 分包者 | | | | | | |
| 最終用戶 | | | | | | |
Zachman框架是一個6×6矩陣：縱向從規(guī)劃者、所有者、設(shè)計者、承建者、分包者和最終用戶六個視角來劃分，建立目標/范圍、業(yè)務(wù)模型、系統(tǒng)模型、技術(shù)模型、詳細表達、運行功能等模型；橫向從數(shù)據(jù)（What）、功能（How）、網(wǎng)絡(luò)（Where）、人員（Who）、時間（When）、動機（Why）等6個方面的模型，并分別由實體－關(guān)系模型（Entity-Relationship）、流程－I/O模型（Input-Process-Output）、節(jié)點－鏈接模型（Node-Link）、人員－工作模型（People-Work）、時間－周期模型（Time-Cycle）、目標－手段模型（Ends-Means）來表達。
Zachman理論發(fā)展到今天，稱之為“企業(yè)架構(gòu)框架”（EAF，Enterprise Architecture Framework），簡稱為“Zachman框架”。Zachman也被公認為企業(yè)架構(gòu)領(lǐng)域的理論開拓者，現(xiàn)有的企業(yè)架構(gòu)框架大都由Zachman框架派生而來。
Zachman框架具有容易理解、描述全面、獨立于各種工具與方法學等優(yōu)點，因而得到了廣泛的認可，很多咨詢方法都從Zachman框架中獲得借鑒。Zanman框架完全可以作為SOA咨詢方法論的理論基礎(chǔ)，是一個非常適合于SOA咨詢的思考框架和咨詢模式。
SOA作為一種技術(shù)架構(gòu)而言，涉及與信息系統(tǒng)建設(shè)和IT基礎(chǔ)設(shè)施相關(guān)的方方面面，這已經(jīng)超出技術(shù)架構(gòu)本身，其復雜性難以單純從技術(shù)角度進行評估。為了全面分析SOA知識背景中各個要素之間的關(guān)系，應(yīng)該采用適當?shù)姆椒▉砻枋觥?/font>
經(jīng)過對SOA研究領(lǐng)域的綜合分析，我們認為目前最為可行的方法是：基于Zachaman框架建立服務(wù)架構(gòu)模型，采用結(jié)構(gòu)化方法自頂向下進行分解，從不同的維度來進行描述，為現(xiàn)階段依然模糊的SOA提供一個全景視圖。
基于Zachman框架的服務(wù)架構(gòu)模型采用矩陣來表示，橫向從邏輯概念范疇的角度，分為六個維度：Why、With Who、What、How、With What、When，縱向從信息系統(tǒng)架構(gòu)的角度，分為四個維度：業(yè)務(wù)架構(gòu)、信息架構(gòu)、應(yīng)用架構(gòu)和技術(shù)架構(gòu)。通過對矩陣中的單元格進行功能聚類，可以發(fā)現(xiàn)服務(wù)架構(gòu)模型劃分為以下五個領(lǐng)域：
（1）SAA（SOA架構(gòu)的采納）
面向服務(wù)提供了一種理想的世界：里面的資源劃分整齊，以服務(wù)這種形式加以一致地呈現(xiàn)。因此，企業(yè)想從服務(wù)方面設(shè)計企業(yè)架構(gòu)，就一定要采用SOA架構(gòu)。所以，企業(yè)在業(yè)務(wù)、信息、信息系統(tǒng)和技術(shù)基礎(chǔ)設(shè)施的各個層面都要從功能服務(wù)方面加以分解。采用一致、合理的做法可以提供松散耦合的功能服務(wù)，它們可以在所謂的共享服務(wù)中心里面進行外包、內(nèi)包或者組合。與不想采用SOA架構(gòu)的組織相比，采用SOA架構(gòu)、并且以合理方式進行實施的企業(yè)可以獲得更大的靈活性、適應(yīng)性及敏捷性。
（2）SOE（面向服務(wù)的企業(yè)）
面向服務(wù)的企業(yè)其實以一種極其水平的方式連接業(yè)務(wù)流程。它采用的企業(yè)基礎(chǔ)設(shè)施可以提供企業(yè)架構(gòu)和安全基礎(chǔ)，能夠跨企業(yè)以一致的方式運行這些服務(wù)。雖然在過去的三十年里，面向服務(wù)的架構(gòu)這一概念被系統(tǒng)架構(gòu)師奉為最佳實踐，但現(xiàn)在它得到了各個地方許多組織的接受，被認為是獲得業(yè)務(wù)敏捷性的關(guān)鍵。但SOE和SOA既不是即開即用的成套系統(tǒng)，也不是什么單一技術(shù)，更不會讓所有問題都能迎刃而解。盡管SOE能夠帶來甚至促進組織上的變化，但它也要求主管人員、企業(yè)架構(gòu)師及項目經(jīng)理要有不同的思考和行事方式，否則完全會發(fā)現(xiàn)自己遇到新問題，根本得不到多少好處。
（3）SOA（面向服務(wù)的架構(gòu)）
SOA體現(xiàn)的是一種新的系統(tǒng)架構(gòu)。在基于SOA架構(gòu)的系統(tǒng)中，具體應(yīng)用程序的功能是由一些松耦合并且具有統(tǒng)一接口定義方式的組件（也就是服務(wù)）組合構(gòu)建起來的?？梢哉fSOA的出現(xiàn)，為整個企業(yè)級軟件架構(gòu)設(shè)計帶來巨大的影響。
（4）SOC（面向服務(wù)的計算）
SOC就是用服務(wù)作為基本單元來開發(fā)應(yīng)用程序。SOC是依賴面向服務(wù)的架構(gòu)來構(gòu)造服務(wù)模型的。
（5）STP（SOA架構(gòu)的遷移）
遷移管理是在通向面向服務(wù)的漫長道路當中最關(guān)鍵的問題之一。盡管遷移至面向服務(wù)的平臺意義重大、關(guān)鍵的Web服務(wù)標準繼續(xù)面臨不確定性，加上大規(guī)模部署SOA往往會產(chǎn)生重大影響，現(xiàn)在是開始考慮遷移的時候了。成功遷移的關(guān)鍵在于，在有關(guān)SOA的活動當中找到一個平靜點，然后制訂直觀的方案，指導貴組織走過面臨技術(shù)障礙、組織阻力及不斷變化的行業(yè)趨勢的道路。
政府機構(gòu)內(nèi)與SOA相關(guān)的人員的關(guān)注點有所不同，如下：
對于組織的決策者和信息主管來說，需要考慮SOA的必要性、可行性等（SAA－SOA架構(gòu)的采納）；
企業(yè)架構(gòu)咨詢?nèi)藛T要從IT規(guī)劃層面，考慮基于SOA的戰(zhàn)略規(guī)劃、業(yè)務(wù)規(guī)劃和技術(shù)規(guī)劃等（SOE－面向服務(wù)的企業(yè)）；
軟件開發(fā)商需要從技術(shù)實現(xiàn)層面，考慮基于SOA的信息系統(tǒng)架構(gòu)設(shè)計（SOA－面向服務(wù)的架構(gòu)）；
硬件和平臺廠商需要從IT基礎(chǔ)設(shè)施層面，考慮如何優(yōu)化基于SOA的系統(tǒng)的效率和性能（SOC－面向服務(wù)的計算）；
系統(tǒng)集成商需要考慮如何從原有的IT架構(gòu)遷移到SOA架構(gòu)（STP－SOA架構(gòu)的遷移）。
基于Zachman框架的服務(wù)架構(gòu)模型如下圖所示：
圖2.2 服務(wù)架構(gòu)模型（基于Zachman框架）
在服務(wù)架構(gòu)模型中，從技術(shù)實現(xiàn)和運營管理兩個方面來看，以下的關(guān)鍵問題關(guān)系SOA項目的成敗。在SOA項目啟動之前，就應(yīng)予以重點關(guān)注。
（1）服務(wù)規(guī)劃
在基于SOA的信息系統(tǒng)中，服務(wù)是構(gòu)建信息系統(tǒng)的基本單元，應(yīng)該確定到底有哪些服務(wù)、服務(wù)封裝什么內(nèi)容、服務(wù)之間關(guān)系如何，需要重點關(guān)注服務(wù)粒度的劃分和服務(wù)的相互引用問題。
服務(wù)粒度表示的是一個服務(wù)的大小，可以理解為服務(wù)操作的范圍和內(nèi)容。粗粒度的服務(wù)設(shè)計，可以減小服務(wù)之間的耦合性，但付出的代價就是增加服務(wù)的復雜性，服務(wù)具備了太多的功能，增加了設(shè)計的復雜性和維護的難度；細粒度的服務(wù)，可以讓服務(wù)的實現(xiàn)變得簡單，但這樣會增加服務(wù)的數(shù)量，那樣就增加了服務(wù)之間的耦合度。因此，應(yīng)該確定一個準則來指導服務(wù)的粒度劃分。
（2）服務(wù)編排
為了實現(xiàn)可以靈活定義和調(diào)整的業(yè)務(wù)流程，應(yīng)該確定業(yè)務(wù)流程的流轉(zhuǎn)范圍、策略實現(xiàn)和定義方法等，需要重點關(guān)注服務(wù)編排問題。
服務(wù)編制關(guān)注于一種說明性的方式（不是編程方式）創(chuàng)建合成服務(wù)，定義了組成編制的服務(wù)，以及這些服務(wù)的執(zhí)行順序。服務(wù)流程的編制和編排，服務(wù)編制用于定義合成服務(wù)，關(guān)注重用已有服務(wù)的內(nèi)部流程；服務(wù)編排關(guān)注與多方參與的交換消息，進行對等的業(yè)務(wù)協(xié)作。因此，應(yīng)該確定一個標準來指導服務(wù)編排。
（3）服務(wù)質(zhì)量（QoS）
為了對處于運行時（Runtime）的服務(wù)例程的服務(wù)質(zhì)量進行跟蹤、記錄和分析，應(yīng)該確定服務(wù)等級（SLA）劃分、服務(wù)質(zhì)量監(jiān)控、事故記錄分析、服務(wù)質(zhì)量問題處理等方法，重點關(guān)注服務(wù)質(zhì)量監(jiān)控問題。
服務(wù)質(zhì)量是SOA 應(yīng)用的典型非功能服務(wù)需求，它使得在服務(wù)全生命周期中，根據(jù)可用的系統(tǒng)資源，使服務(wù)請求者的需要與服務(wù)提供者的能力達成一致，主要是指性能、可靠性、可用性和安全性等。因此，應(yīng)該確定一個規(guī)范來指導服務(wù)質(zhì)量管理。
（4）服務(wù)運營
