企業架構研究總結（45）——企業架構與建模之使用ArchiMate進行分析（全系列完）

4. 使用ArchiMate進行分析

      正如前面所說的那樣，一個企業總體效率的提高有時並非經過某一個領域內的優化就能達到的，並且這種忽視全局的作法每每還會形成沒必要要的浪費。因而可知，一個可以跨越各個領域、一致性的全局模型是實現企業總體效率提高的重要基礎，而這也正是前面幾個章節所描述的ArchiMate建模語言的終極目標。不過這樣一個全面的企業架構模型的創建並非最終的目標，如何使得企業內外各干係人在決策時可以作到對企業各層面中各自關注的部分有着深刻、一致的洞察纔是此模型的終極價值所在。要達到這樣一個目標並不容易，這牽扯到如何對企業架構模型進行使用的問題，可是使用這樣一個一應俱全的模型並非一件簡單的事情，僅從企業架構的規模和複雜度這兩個方面來看足夠讓人望而生畏了。

      在解釋如何使用企業架構模型來輔助干係人進行決策以前，咱們首先要明確這一「輔助」的目標是什麼，亦即干係人「決策」的含義。「決策」的背後老是「變化」，由於有了變化或將要發生變化干係人才須要進行決策，這既包括在「變」與「不變」進行選擇，也包括在各類變化方案之間進行的抉擇，而只有對企業各領域具備深刻的洞察才能儘可能確保選擇的正確性。在決策過程當中，各干係人須要對各類設計方案進行對比，在成本、質量和性能之間取得權衡，並可以對變化所帶來的影響具有明晰的認識。雖然企業架構模型在邏輯上具有這些決策所須要的信息，不過就其自己的複雜度和規模而言，這些信息的獲取並非經過前面所說的幾個視角以及相關的幾張平鋪直敘的視圖就能實現的，這須要以企業架構模型爲基礎進行各類針對性的分析才能達成，而這些分析都包括什麼，以及如何進行分析正是本章闡述的重點。

      須要注意的是，架構分析技術並不只是一種或一套新式的用於分析架構的方法。與前面所講的ArchiMate建模語言相相似，本章提到的架構分析方法是對全部以企業架構模型爲分析對象的方法的總稱，而不是僅要從新創建一套分析方法，他既包括了各領域中已經存在的分析方法，也包括了本章後面將會介紹的新的具有跨領域特性的企業架構分析方法。雖然在各領域當中現存的各類分析方法只是針對其領域自己，而且對於模型的詳細度要求又廣泛高於企業架構模型這一高抽象度模型所能提供的，可是這並不意味着這些技術或思想不能運用到企業架構分析當中，實際上基於跨領域的企業架構模型的分析每每須要領域已有的技術分析結果做爲輸入，並且因爲企業架構模型的這種高度抽象性，這些已有的分析技術思想在企業架構模型中相關領域內也是兼容的。

4.1 分析技術分類

      在對架構分析技術進行詳細描述以前，咱們先對架構分析技術的種類劃分進行歸納。 《Enterprise Architecture at Work》從兩個維度將各類架構分析技術劃分到以下圖所示的四個象限之中：

      根據各類分析技術的輸入和輸出的類別，企業架構分析方法可分爲「功能性（Functional）」和「量化（Quantitative）」這兩種：

• 功能性（Functional）：功能性架構分析方法着眼於架構的功能方面。此種類型的方法可被用於判斷系統與架構內容是否相符、瞭解變動對於架構所帶來的影響，以及驗證架構的正確性等。
• 量化（Quantitative）：功能性分析並不能解答諸如「多快」、「多省」這樣的具備量化指標的問題，而這正是量化分析所要產出的結果。

      從分析過程所採用的方式這一維度進行區分，不管是功能性的仍是量化的架構分析方法都可被劃分爲「分析（Analytical）」和「模擬（Simulation）」這兩種：

• 模擬（Simulation）：「模擬」能夠看做是將模型所描述的客觀對象在邏輯上進行虛擬執行的過程。根據前面所述的劃分方式，模擬能夠進一步劃分爲功能性模擬和量化模擬這兩種：
• 功能性模擬：用於對系統的動態行爲進行描述，從而以一種更加直觀的方式爲各干係人提供更加深刻的有關架構的性質和行爲的信息，而也正由於這一特性，功能性模擬在促進干係人間的溝通中也扮演了重要的角色。
• 量化模擬：經過往復循環的屢次量化模擬，相關干係人能夠獲取有關係統量化指標的統計性信息，從而在指定狀況下對系統性能指標進行全面的檢驗。
• 分析（Analytical）：與模擬相比，分析並不具有統計方面的特性，而是用於爲各相關干係人提供惟一且可重複的結果。分析也可被進一步劃分爲量化分析和功能性分析這兩種：
• 量化分析：用於爲相關干係人提供有各關係統量化指標的初始印象，並藉此識別出系統的瓶頸所在。
• 功能性分析：用於對架構的內在功能和性質進行分析，這既包括對做爲架構組成部分的各結構元素的靜態分析，還包括了針對架構行爲方面的動態分析。

      從以上敘述中咱們能夠看出，企業架構的分析方法能夠被概括到由兩個維度所組成的四個象限之中，不過對於採用「模擬」方式進行的分析來講，不管是功能性的仍是量化的，其本質上是以對模型的虛擬執行爲基礎，其具體實施算法仍是以「分析」方式爲基礎，於是本章後續部分的重點將放到各類架構分析方法之上。

 

4.2 量化分析方法

      企業架構是個跨越組織中多個領域的架構，雖然組織採用的架構方法可能不一樣，不過就企業架構的本質來講，一個完整的企業架構至少應該包括業務、應用和技術基礎設施這三個層面，於是針對企業架構的量化分析方法也應該將這些層面聯繫起來，從而爲企業給出總體性的量化評估。這些量化評估包括多個方面的指標，他既包括諸如響應時間、資源利用率、吞吐量這樣的與時間相關的性能指標，也多是可靠性方面的度量，亦或是對成本方面所進行的考量。在本章中，咱們將着眼於性能指標，介紹一種量化分析方法，用於計算企業架構模型所描述的系統的性能指標。

      經過基於企業架構模型的量化分析，咱們首先能夠在企業的總體範圍內得到優化，由於其分析的對象包含了企業各個領域中的內容，從而避免開篇提到過的單獨領域的進化非但沒有致使效率的提高，反倒促成了浪費的生成；其次，雖然咱們能夠經過變化影響分析這一功能性分析方法來獲取變動所帶來的影響，不過只有結合量化分析，咱們才能對這一影響具有更加深刻的認識，這同時也說明量化分析和功能性分析並非相互隔絕的，在實踐過程當中應該結合使用才能發揮出最大效能；再次，經過量化分析咱們能夠把企業這一複雜「系統」的輸入（業務工做）和支持性資源（用於對業務進行支持的各領域資源，例如業務流程、應用、軟硬件環境等）結合在一塊兒，並造成聯動關係，從而實現容量規劃，即獲取在假定業務工做量的前提下各支持性資源的容量需求。

4.2.1 量化分析方法基本原理

      對於架構的量化分析方法種類繁多，不過他們大多都是基於某一特定領域模型的量化分析方法，而對於企業架構模型來講，各類工具所關注的仍是主要在於建模部分，其對於企業架構的量化分析支持的並不充分，因此接下來筆者將重點闡述《Enterprise Architecture at Work》中所介紹的企業架構量化分析方法。此企業架構量化分析方法的目標在於對企業架構模型所描述系統的各項性能指標進行考量。從前面有關ArchiMate語言的介紹中咱們能夠知道，並非全部的概念元素是與性能指標掛鉤的，諸如「含義」、「價值」之類的概念元素是不該該處於此量化分析方法的計算以內的，於是借鑑以前提到過的視角概念，此量化分析方法的分析基礎也應該是處在某種視角下的模型視圖。下圖（源自《Enterprise Architecture at Work》圖8.3）展現了這一視角的元素構成，以及此量化分析方法所需的輸入和最終計算目標：

      從上圖咱們能夠看出，此企業架構量化分析方法視角實際上與前面ArchiMate衆視角中的層次視角很是相像，二者都是採用相互交疊的層次對各類概念元素進行組織，其中層次視角中的專用層（Dedicated layer）對應於此量化分析視角中的實現層（Realisation layer），而他們所同名的服務層（Service layer）在本質上是相同的。除此以外，這兩種視角中對於層次之間的關係定義也是一致的，即都是經過「使用」和「實現」關係進行關聯，其中位於下層的服務層（Service layer）爲上層的服務層或實現層提供各類服務，而位於服務層（Service layer）下方的實現層（Realisation layer）或專用層（Dedicated layer）又對各類服務層所提供的服務進行了內部實現支持。須要注意的是，雖然這兩種視角之間具備很高的類似度，但從定義上看二者仍是具備明顯的區別，因爲層次視角並不針對特定的應用環境，於是在此視角之下的視圖能夠包含全部的概念元素，而對於企業架構量化分析方法視角來講，因爲他所面對是針對各類性能指標的考量，於是此視角只包含與性能指標相關的各類概念元素。所以咱們能夠說，此企業架構量化分析方法視角是層次視角的一個子集或具體應用特化。

      在企業架構量化分析方法視角的兩種組成層次中，服務層（Service layer）包括了業務、應用和技術領域中的各類服務行爲元素，而實現層（Realisation layer）則是由以上三個領域中的各類主動性結構元素（Resource）、被動性結構元素（Object）和用於表示內部實現功能的行爲元素（Internal behavior）所組成的。在實現層中，主動性結構元素（Resource）經過分配關係與內部行爲元素（Internal behavior）相關聯，用於表示由誰執行了何種行爲；內部行爲元素（Internal behavior）經過訪問關係與被動性結構元素（Object）相聯繫，用於表示各類內部行爲的執行所涉及到的各類信息以及他們之間的讀/寫關係。

      除了企業架構量化分析視角的概念元素構成以外，上圖還展現了此分析方法的輸入以及目標性能指標。圖中標註在各概念元素圖符以外變量表明瞭此分析方法所須要的各類輸入（n、f、S、C），而位於各概念元素圖符以內的變量則表明了此分析方法中對各概念元素所考量的各類性能指標（R、T、U），即此分析方法的輸出：

• 輸入：
• 使用次數權重（n）：標註在「使用」和「訪問」關係上的參數n用於表示服務元素被使用的平均次數，或被動性結構元素被各行爲元素所訪問的平均次數。
• 到達頻率（f）：標註在概念元素旁邊的參數f用於表示到達此節點的外部事務的頻率。須要注意的是，雖然在定義方面能夠容許對任何概念元素標明此參數，但在實踐過程當中咱們一般只爲處於模型最高層次（通常爲業務層）的概念元素設置此參數的具體值，其他概念元素的此變量值能夠經過分析方法推算而得。
• 服務時間（S）：用於表示行爲元素在執行過程所消耗的淨時間，即行爲元素的總執行時間減去在執行過程當中等待其餘支持性服務的執行所消耗的時間。例如，假設業務流程A的總執行時間是2秒，並且此流程A使用了B和C兩個應用服務，且此二者的服務時間都是0.5秒，那麼流程A的服務時間應爲2-（0.5 + 0.5）= 1秒。須要注意的是，一般狀況下咱們均假設由某內部行爲元素現實的服務行爲元素的服務時間應與這一內部實現元素的服務時間相同。
• 容量（C）：用於表示執行各類行爲的主動性結構元素或資源（Resource）的處理容量。
• 輸出：
• 響應時間（R）：用於表示自發起請求開始到收到最終結果這一過程所消耗的時間。
• 處理時間（T）：用於表示某一行爲元素在事務處理過程當中所消耗的時間，即此行爲元素的服務時間與全部對其進行支持的服務的服務時間之和。例如，若是業務流程A的服務時間是1秒，而且此業務流程的執行過程當中使用了應用服務B和C，且此二者的服務時間分別爲0.5秒，那麼處理時間應爲1+（0.5 + 0.5）= 2秒。
• 利用率（U）：用於表示一個資源（Resource）處於「忙」時的時長所佔的比例。利用率是用來衡量各類資源（人力資源或信息系統資源）有效性的客觀指標，較高的利用率表示資源被充分利用，不過這也可能標誌着性能瓶頸的所在。一般狀況下，咱們能夠經過增長資源的容量來突破性能瓶頸，不過這也可能導致資源的利用率降低，從而造成浪費。因而可知，不一樣的性能指標相互制約，於是在他們之間如何權衡是決策過程的重點所在，而經過基於企業架構模型的量化分析，各干係人能夠在一個信息充分的基礎上進行決策，從而保證決策的正確性。

      在明確了此企業架構量化分析方法所採用的視角、輸入與目標性能指標以後，咱們再來了解一下此方法的算法邏輯：

      上圖展現了一個較爲完整的企業架構層次模型。這一模型自下而上涵蓋了技術、應用和業務這三個領域，不一樣的領域之間經過「使用」關係進行鏈接，即位於下方的領域爲處於上訪的領域提供各類服務。每一個領域的內部又被細分爲兩個層次，而在這兩個層次中，位於上方的層次包括了此領域對外所能提供的各類服務，而處於下方的層次則包括了實現本領域服務的各類內部實現元素。須要注意的是，上圖所展現的是一個企業架構量化分析方法所適用的較爲完整的企業架構層次模型，但這並不意味這該分析方法只能針對這種跨越三個領域（業務、應用和技術）的企業架構模型進行分析，實際上在輸入信息充分的狀況下，此方法也能夠適用於跨域兩個領域，甚至是僅有一個領域的狀況下。此外，雖然圖中不一樣層次之間相互疊加遮掩，好像只有相鄰的兩個領域之間纔會有直接的「使用」關係，但在實踐過程當中跨層次的「使用」關係是家常便飯的，例如業務流程既可使用應用領域提供的應用服務，也可使用技術層所提供的基礎設施服務。

      本章介紹的企業架構量化分析方法的計算過程能夠分爲兩個步驟：

• 首先是按照自上而下的順序（業務—>應用—>技術）未來源於外部的工做負載（到達頻率f，例如600個客戶請求/天）換算爲每一個層次中各個節點的被訪問頻率，即計算出每一個節點的到達頻率。其計算公式爲：

      此公式用於計算某個節點a的使用頻率，即單位時間內被使用的次數。在公式中：

• ：用於表示某個節點a的總使用頻率。

• ：用於表示此節點a自己的到達頻率，即除了被其餘節點所使用或訪問以外，節點a在單位時間內被使用的頻率。

• ：用於表示其餘節點中對節點a進行直接使用或訪問的節點序列的長度。

• ：用於表示其餘節點中對節點a進行直接使用或訪問的某個具體節點。

• : 用於表示節點a與對其進行直接使用或訪問的某個節點之間的使用或訪問關係的「使用次數權重」。

• ：用於表示其餘節點中對節點a進行直接使用或訪問的某個具體節點的總使用頻率。

      因而可知，雖然此公式看起來較爲繁瑣，實際上其意義卻較爲直白，即任意一個節點的總使用頻率等於其自己的到達頻率與對其進行直接使用或訪問的其餘節點各自的總使用頻率在通過「使用次數權重」加權後的總和。

• 而後按照自下而上的順序（技術—>應用—>業務），以每一個節點的到達頻率f和服務時間S爲基礎計算出每一個節點的響應時間R、處理時間T和利用率U。在此過程當中所涉及到的公式包括：

             此公式用於計算某行爲元素節點a的處理時間，即該行爲元素節點處理某一事務所消耗的時間（不包括等待其所使用的其餘行爲元素節點在處理同一事務時所消耗的時間）。在公式中：

• ：用於表示行爲元素節點a的處理時間。
• ：用於表示行爲元素節點a的服務時間。
• ：用於表示行爲元素節點a所使用的其餘行爲元素節點序列的長度。
• ：用於表示行爲元素節點a所使用的某個具體行爲元素節點。
• ：用於表示行爲元素節點a與其所使用的某行爲元素節點之間的使用關係的「使用次數權重」。
• ：用於表示行爲元素節點a所使用的某行爲元素節點的響應時間。

           因而可知，任意一個行爲元素節點的處理時間等於其所使用的各行爲元素節點的響應時間通過「使用次數權重」加權後所得結果與其自己服務時間的總和。因爲在計算性能指標時採用的是自下而上的方式，於是首先被計算的是處於最下層的基礎設施行爲元素的處理時間，而在這一過程當中，因爲這些首先被計算的基礎設施行爲元素並不使用其餘任何行爲元素，因此他們的處理時間應與服務時間相等。

            在得到行爲元素節點的處理時間後，咱們須要經過上面的公式計算分配到該行爲節點的資源節點的利用率。在公式中：

• ：用於表示資源節點r的利用率。
• ：用於表示分配到資源節點r上的各行爲元素的數量。
• ：用於表示分配到資源節點r上的某行爲元素。
• ：用於表示分配到資源節點r上的某行爲元素的總使用頻率。
• ：用於表示分配到資源節點r上的某行爲元素的處理時間。
• ：用於表示資源節點的容量。

           因而可知，資源節點的容量和其利用率成反比，這意味着若是在資源的利用率太高而成爲性能瓶頸的狀況下，提升資源的容量能夠解決這一問題，不過過度提升資源的容量也會致使其利用率的降低，從而導致浪費的產生。

             行爲元素節點的處理時間和資源利用率是決定其響應時間的兩個主要因素，於是在經過以上的公式得到這兩個參量的值以後，咱們須要對行爲元素節點的響應時間進行考量。在公式中：

• ：用於表示行爲元素節點a的響應時間。
• ：用於表示以節點a和相應的資源節點 的各項性質（基本爲節點a的處理時間和資源節點 的利用率）爲變量的用以計算其響應時間的函數。

           須要注意的是，這裏並無給出具體的響應時間計算公式，而是代替以函數，這是由於各個節點在事務處理中的各異性致使沒法採用統一的計算公式。例如，若是某個節點對於事務處理的數學模型符合M/M/1隊列(對於節點a的訪問頻率符合泊松分佈，且此節點的處理時間的統計特性知足指數分佈)模型，那麼此函數的具體表現形式就應爲（其中， 爲節點a的處理時間，而爲此節點所關聯的資源的利用率），而若是節點的處理時間的統計特性不知足指數分佈，那麼此函數就可能須要採用M/G/1隊列模型來進行表述了。須要注意的是，採用各類數學模型對節點進行建模並非惟一辦法，咱們還能夠結合諸如模擬技術等其餘更爲詳盡的技術來對其進行計算。

 

4.2.2 量化分析方法示例

      爲了詳盡闡述企業架構量化分析方法，本章以《Enterprise Architecture at Work》中的企業架構量化分析方法示例爲藍本，對此分析方法的使用進行演示。在進行分析以前，咱們先來了解一下示例的相關背景：有一家保險公司將文檔管理系統做爲其中心辦公系統，公司中的多個部門都使用此係統進行辦公，那麼在已知工做負載和各系統的處理能力的狀況下，此文檔管理系統以及其餘的系統或服務的性能指標如何？是否存在性能瓶頸，以及如何突破這些瓶頸呢？經過企業架構的量化分析方法，咱們能夠對以上問題具備明晰的認識。

      上圖所示的企業架構模型視圖對該保險公司的平常運行狀況做了描述。爲了對其中的各個元素節點計算其性能指標，此視圖中還對各類輸入信息進行了標註：

• 在「索賠處理流程」和「索賠提交流程」這兩個業務流程之上分別標註了各自的事務到達頻率：600次/天和200次/天。
• 對於每一個服務元素則標註了其服務時間S。
• 在視圖中的每條「使用」關係之上分別標註了各自的「使用次數權重」n。

      爲了明確和簡化企業架構量化分析方法的使用，除了上述的幾項輸入以外，咱們還要作以下的限定：

• 假設天天的工做時間是8小時，即上面輸入的「600次/天」和「200次/天」這兩個到達頻率實際上爲600次/8小時和200次/8小時。
• 每一個節點的事務處理數學模型採用M/M/1隊列模型。
• 每一個相關資源節點的容量默認爲1。

      在得到了如上的輸入和限定後，咱們就能夠按照下面所示的步驟進行此企業架構量化分析：

• 模型歸一化處理。
• 自上而下的工做負載計算。
• 自下而上的性能指標計算。

4.2.2.1 模型歸一化

      在實踐過程當中，企業架構模型一般與前面所述的企業架構量化分析元模型並不相符，這是由於在建模過程當中建模人員常用各類抽象化規則來簡化企業架構。例如，在一系列連續的由使用關係和實現關係組成的關係鏈能夠被簡化爲關係鏈的兩端元素經過一條使用關係而直接相連，以下圖所示：

      在上圖的示例中咱們能夠看到：在處於左半邊的模型中，「數據庫管理系統」應用組件直接被「管理員」所使用，不過這樣的模型很明顯並不符合咱們正在討論的企業架構量化分析方法元模型的要求，於是經過歸一化處理後咱們獲得了右側的架構模型，二者具體含義並沒有太大差異，只不過通過歸一化的模型知足了此量化分析方法的要求，而且具有更加詳盡的信息。

因而可知，所謂的模型歸一化操做就是以此企業架構量化分析方法的元模型爲基準，對須要進行性能指標考量的企業架構模型進行轉換，其實可以符合分析方法的模型要求。就本章節的示例來講，將此示例圖中所示的模型進行歸一化後咱們能夠獲得以下的模型：

      相對於原始的示例模型，此歸一化後的模型所作的修改主要在於對內部行爲元素的添加。從上圖咱們能夠看出，原來的資源節點並不對外部服務進行直接的實現，而是經過分配關係爲每一個資源節點關聯了新添加的用於表示其內部行爲的功能概念元素，而且這些內部行爲元素與相應的服務元素之間的實現關係也替代了原來的資源節點和服務元素之間的直接實現關係。此外，原來資源節點與其所使用的服務元素之間的使用關係也被轉移到內部行爲元素之上。須要注意的是，新添加的各內部行爲元素節點及相關的使用或訪問關係都須要分別註明服務時間和相應的使用次數權重，這其中，服務時間應與其所實現的外部服務元素的服務時間相同，而因爲內部實現元素繼承了原資源元素針對其餘服務的使用和訪問關係，因此使用次數權重也與之相同。經過以上的轉換，當前通過歸一化的模型符合了前面所提到過的企業架構量化分析方法元模型，但這僅僅是一個示例，並不意味着全部的非歸一化模型都要遵守這個規則來進行轉化，這是由於原始模型所具有的多樣性，而這一規則也只是較爲常見歸一化規則之一，但不管採用何種規則，其最終目的都是要使進行計算的模型符合此量化分析方法的元模型。

 

 

4.2.2.2 工做負載計算

      在得到歸一化的模型以後，接下來咱們須要將最上層所承擔的工做負載自上而下地傳遞給下面的各個層次。在進行計算以前，咱們須要再次對此步驟所需的輸入和限制進行明確：

• 工做負載來源於最上層，即索賠處理流程和索賠提交流程這兩個業務流程的到達頻率（分別爲600件/天和200件/天）。
• 工做時間爲8小時而不是24小時，因此上述的到達頻率可分別換算爲：

      下表展現了不一樣的資源元素所提供的服務元素在前述的工做負載下所承擔的工做負載（須要注意的是，與《Enterprise Architecture at Work》中的相應示例相比，本示例中有關的計算結果與原書中的計算結果0.0278不一致，並由此致使了的計算結果也出現了不一致的狀況。筆者懷疑原書中的這兩個結果與其所示的模型並不相符，若是當「損害報告搜索服務」被索賠處理流程和索賠提交流程這兩個流程所共同使用，且其與索賠提交流程之間使用關係的使用次數權重 時會得出0.0278這樣的結果，但若是這一結果成立，那麼最終的就會由於的改變而由0.02777變爲0.0347，這又與原書示例結果相矛盾，於是再一次證明了書中示例的計算結果之間存在矛盾）：

 

4.2.2.3 性能指標計算

      量化分析方法的最後一步採用自下而上的方式，對各個資源節點以及相應的行爲元素節點的利用率、處理時間和響應時間進行計算。在進行計算以前，咱們須要再次明確一下必要的輸入和限制：

• 每一個行爲元素（服務元素和內部行爲元素）都須要註明其服務時間。
• 每一個元素節點的工做負載應已在上一步計算中得到。
• 每一個資源元素節點的容量應已經肯定。本示例中，每一個資源節點的容量均默認爲1。
• 每一個行爲元素節點的事務處理數學模型應已經肯定。在本示例中，每一個行爲元素節點的事務處理數學模型均採用M/M/1隊列模型。

      本示例中各個元素節點的性能指標以及計算過程總結以下：

      從上表中咱們能夠看出，因爲資源的容量有限，因此其所分配的行爲元素的處理時間會小於響應時間，而且在資源處在高利用率的狀況之下，這二者之間的差異還可能會很是大，例如對於「查看組件」來講，其利用率達到84.4%，而同時其響應時間達到了處理時間的6倍以上，這也印證了雖然資源利用率高代表資源被充分利用，不過這同時也很是多是性能的瓶頸所在，經過增長資源的容量能夠改善這個問題，可是也可能致使浪費的產生，於是這二者之間須要作好權衡，但無論如何權衡，這種分析方法起碼賦予了決策者更好的洞察力，使其決策更加有理有據。

      除了針對一套輸入數據進行分析以外，咱們還能夠經過編制不一樣的輸入數據而獲取相應的分析結果，從而對某個性能指標隨輸入的變化而產生變化的趨勢進行更爲直觀的觀察。下圖來源於《Enterprise Architecture at Work》中圖8.8，他展現了索賠處理流程的不一樣到達頻率與查看組件的響應時間之間的關係：

      如圖所示，當索賠處理流程的事務到達頻率達到大約651件/天時，查看組件的相應時間趨近無窮，這就證實在此種狀況下該組件的利用率已經達到滿負荷的100%，這也代表了此組件在當前容量下的處理極限。在此，咱們能夠驚喜的發現業務中的問題和IT方面的支持能力有了量化性的關聯，而這種跨領域的聯繫也正是此量化分析方法甚至是企業架構精神的最佳體現。

 

4.3 功能性分析方法

      從分析目標來看，針對企業架構的功能性分析方法能夠細分爲靜態分析和動態分析兩種，前者分析的目標是企業架構的結構關係，然後者則是針對架構所描述的各類行爲進行分析。相對於量化分析方法，用於分析架構基本結構和行爲的方法長期以來一直是各架構分析方法的重點，不一樣的組織已爲其貢獻了不少很是成熟的分析方法，並且這其中的每一個方法都須要耗費一部整書的篇幅才能描述清楚，於是本節只能對其中具備表明性的方法進行列舉，詳細內容還須要有興趣的讀者進一步閱讀。

      靜態分析是以企業架構的結構組成爲目標的功能性分析方法，於是其分析主體是各類概念元素以及他們之間的結構關係，而這其中最具表明性的就當數影響分析了（Impact-of-change analysis）。顧名思義，影響分析是以因爲變化而產生的影響爲分析目標的功能性分析方法，這是一種通用性的分析方法，而並非企業架構所獨具的。據筆者考證，影響分析首先是被 Bohner 和 Arnold在1996年於《Software Change Impact Analysis》中所定義的，從書名咱們就能夠看出，該分析方法起源於軟件設計領域，是用來對軟件設計中的變動所產生的影響進行界定的方法。不過此書對於變動影響分析的定義卻有着更爲寬泛的含義，即變動影響分析旨在明確變動所可能產生的潛在結果，並對爲了適應變動所應做的修改進行估計。因而可知，這必定義並無綁定軟件設計這一領域，因此將此分析方法放在企業架構中也應該是適用的。

      《Enterprise Architecture at Work》對變動影響分析在企業架構中的應用作了簡要的描述，其中心思想在於：以發生變化的結構元素爲起點，沿着結構型關係進行搜索，尋找與其發生關聯的受到影響的各個結構性元素，再以這些結構性元素爲起點，沿着以前的結構關係方向重複這個搜索過程，直到全部受影響的結構性元素被搜索出來爲止。書中還經過一個示例形象化地描述了變動影響分析在企業架構方面的應用：有一個保險公司在銷售保險的過程當中除了本身銷售外還經過第三方的代理來進行保險推銷，這些代理的工做也只在於向客戶推銷保險產品，並保證保險合同簽署以前各類文件工做的正確性。目前該公司考慮可否拋開這個代理的角色，但又不知道如此會產生什麼樣的影響。

      誠然這種事情的影響是沒法精確估計和定義的，由於這其中包括了各類沒法估計的有形和無形的影響，可是經過對企業架構進行影響分析，公司至少仍是能對從業務到IT各層面中的有形的結構性影響有所認識。如下三張視圖就對這種影響進行了展現：

變動影響示例—視圖1

變動影響示例—視圖2

變動影響示例—視圖3

      以上三張視圖中：第一張視圖展現了因爲業務角色「第三方代理」發生變化而受到影響的業務合做集合「洽談」和「合同訂立」；第二張視圖展現了「合同訂立流程」中因爲變動而受到影響的業務交互「規範化申請」和「檢查並簽署合同」；最後一張視圖展現了在應用層面進而受到影響的應用服務「客戶管理服務」和應用組件「客戶關係管理系統」。雖然這三張視圖分別展現了受到變動影響的各個結構元素，可是這並不意味着全部的影響都被這三張圖所涵蓋了，由於視圖是視角的具體表現內容，其所反映的只是企業架構的某一個方面的內容，於是對於變動影響結果的展現須要站在相關干係人視角的基礎之上。實際上《Software Change Impact Analysis》根據所分析的目標對象的不一樣，將變動影響分析方法分爲可追溯性方法和依賴性方法兩種，前者着眼於需求、規範、設計元素和相關測試之間的關係，然後者則關注於程序模塊、變量和邏輯等之間關係，這實際上也是站在不一樣視角對於變動分析方法的具體應用，與企業架構的視角精神是一致的。於是在實踐過程當中，咱們的企業架構分析方法應該不是一個具備惟一形式的分析方法，根據視角的不一樣，此分析方法所實際關注的概念元素和關係應該是有所區別的。

      與靜態分析方法不一樣，動態分析方法將企業架構的行爲做爲分析目標。目前，在各個領域（例如業務領域）中已經存在了不少成熟的動態分析方法。藉助於這些方法，咱們也能夠對企業架構中的某一領域進行深刻分析，並根據企業架構的跨領域特性，將分析結果延展到企業架構的其餘領域以內。這其中常常用到的就是進程代數（Process algebra）和數據流網絡（Data flow network）分析方法。經過這些動態分析方法，咱們能夠對企業架構的正確性加以驗證，也可使干係人對企業架構的行爲得到更爲深刻的共識。