敏捷團隊使用迭代的、需求驅動的、務實的方法來實現IT實施、變更和執行。這些團隊的業務範圍如果是有限的，效果則很好。這有助於團隊以靈活和富有成效的方式執行任務。

但是帶來副作用是：增加了生產率和靈活性的同時也增加了相互配合的節拍越來越大。沒有軟體架構上的指導機制，傳統的長期業務目標最終將越來越難實現。例如，允許每個敏捷專案僅根據短期需求選擇自己的實現，毫無疑問，這將在整個企業提出的合規性和其他要求方面造成問題。

如何才能使敏捷團隊識別並彌合企業業務目標與個人開發計劃之間的差距，而又不會失去他們的重點、靈活性和生產力？  

約翰·A·扎克曼（John A. Zachman）在80年代中期提出了類似的問題，他最終通過建立所謂的“扎克曼框架”（Zachman Framework）回答了這一問題。

基本上，Zachman框架被定義為一個本體圖，它使任何人都可以描述涵蓋所有（可能相關的）業務觀點的任何設計。今天，Zachman框架提供了整個企業的一目瞭然的概述。

Zachman圖是六乘六矩陣圖，在橫軸上顯示“ 5W1H模型[1] ”。基本上，5W1H模型會強迫您一遍又一遍地問6個問題（什麼，如何，哪裡，誰，什麼時候，為什麼），以便對潛在動機有最佳的瞭解。

在垂直軸上，該圖區分了六個不同的（業務）透檢視（上下文，概念，邏輯，物理，資訊/資料，可用性）。面對這些關鍵要素中的每一個，都會產生36個觀點，在這些觀點中，可以描述，解釋和正確理解任何給定的設計。下圖顯示了Zachman框架的圖形表示。

令人遺憾的是，對於Zachman框架存在一些誤解。最常見的一種方法是將Zachman框架視為一種方法，因此可以將其與諸如TOGAF，IEEE1471或EA 等架構框架進行比較。我認為，這是將方法論（如何實現目標）與本體（如何進行分類）進行比較的錯誤比較。

另一個誤解是Zachman框架不再適用的觀念，因此應該忽略。我認為這是一個應該拒絕的概念。Zachman框架中使用的元件沒有規定，也沒有時間限制。我的猜測是，例如回答：“什麼業務模型，為什麼我們要實現這些業務目標”將持續很長時間。

Zachman的有效性也得到了各種架構框架的認可，其中Zachman在其工具集中被積極採用。例如，當檢視TOGAF “開發體系結構檢視”時，您可能會注意到該參考。最終，已經提出了採用行動研究方法，在較小的環境中採用Zachman的新研究建議。

Zachman親自幫助我計劃，觀察，反思和挑戰設計及其實現。一個很好的例子是在歐洲引入了新的GDPR法規。在不確定從何處開始實施有關隱私以及這將如何影響其業務的新監管要求的地方分配我的客戶。在這些情況下，Zachman幫助我指導客戶確定受影響的域並討論它們如何受到影響。

總之，Zachman框架提供了一個參考框架，可以幫助任何規模的組織：指導，組織，關注，跟蹤和審查其高階設計工作，並有助於提高團隊對更廣泛的業務需求的認識。