1.3 業務架構（Business Architecture）

企業架構開發方法各階段——業務架構

1.3.1 目標

• 描述基線業務架構
• 開發基於原則、業務目標和策略驅動力的目標業務架構，描述產品和/或服務策略，以及業務環境在組織、功能、過程、資訊和地理這些方面的內容
• 分析基線和目標業務架構之間的差距
• 選擇和開發相關的架構視角，通過這些視角架構師可以闡述業務架構是如何對各干係人的關注點進行解答的。
• 選擇與選中的視角相關的工具和技術

1.3.2 方法

      針對業務架構的瞭解是進行其他領域（資料、應用和技術）架構工作的前提條件，因而如果不是因為組織中其他一些諸如企業規劃、業務戰略規劃以及業務流程再造等方面流程，針對業務架構的制定應該是要首選進行的架構活動。業務架構是用來將其後架構工作的業務價值闡述給相關干係人所必不可少的工具，它也可用來為各個支援和參與後續架構工作的干係人闡明企業架構的投資回報。在實踐過程中，業務架構的關鍵元素也許已經在其他工作中被明確，而在這種情況下，組織就需要驗證和更新當前已經文件化的業務戰略和規劃，並/或在已經明確的業務驅動力、業務戰略、目標與架構開發工作相關的特定業務需求之間建立關聯。而在另外一種情況下，業務架構工作也許並沒有或者很少被執行，而這就需要架構團隊研究、驗證架構將要支援的各個關鍵業務目標和流程，並獲得相關干係人的認同。然而不論處在以上哪種情況，TOGAF ADM的業務情景技術，或者是其他用來闡明關鍵業務需求以及為IT架構指明其技術需求的方法，都需要被納入到架構師的工具箱之中。

      需要注意的是，在架構活動中應儘量重用各種已經存在的材料，並且針對資訊的收集和分析也應該依據架構工作的範圍而採用那些能夠促成明智決策的資訊。如果架構活動關注於業務流程的定義，則在此階段組織需要在此方面進行很多細緻的工作，而如果關注點更著重於其他領域（資料/資訊、應用系統和基礎設施）中的目標架構，那麼組織就需要在這個階段構建一幅無需包含眾多非必要細節的全景圖。

      除此之外，在此階段所涉及到的方法還包括：

開發基線描述

      如果企業中已經存在了架構的描述，那麼他們可以被用來作為基線描述的基礎。這些輸入可能在架構願景階段中已被用來開發架構願景，但對於基線描述來說應該也是夠用的。而如果這些描述並不存在，組織就需要從各種渠道對這些資訊進行收集。針對目標架構的開發通常是採用自上而下的方法，而對基線描述來說，針對當前狀態的分析經常是自下而上的，特別是當只有很少或沒有架構資產存在時。在這種情況下架構師需要記錄關於高層次框架的工作假設，並逐步收集能夠將這些工作假設轉變為現實的證據。

業務建模

      業務模型是架構願景中各業務情景的邏輯擴充套件，架構可以藉此將高層次的業務需求細化為更詳細的需求。在實踐中存在著一系列建模工具和技術可以供組織選擇使用，例如：

• 活動模型（Activity Models）：活動模型也稱為業務流程模型（Business Process Model），他描述了各種與組織業務活動相關的功能、活動之間進行交換的資料和/或資訊（內部交換）以及與模型範圍之外的其他活動進行交換的資料和/或資訊（外部交換）。活動模型在本質上是具有層次型結構的，它涵蓋了在業務流程中所進行的各種活動，以及這些活動的輸入、控制、輸出和所使用的機制或資源（ICOMs：inputs，controls，outputs，and mechanism/resources），並且各種用於描述ICOMs之間關係的業務規則也可被明確地標註在業務模型之中。當前在業界存在著多種用來構建活動模型的技術，其中之一就是IDEF（Integrated Computer Aided Manufacturing （ICAM）DEFinition）建模技術。除此之外，OMG（The Object Management Group）也開發了BPMN（Business Process Management Notation）標準，用於為業務流程建模提供一種標準性語言。
• 用例模型（Use-Case Model）：依據建模關注點的不同，該模型既可以用來描述業務流程也可以描述系統功能，並且它可以從用例、與業務流程相關的角色以及組織參與者的角度來對企業的業務流程進行描述。通常情況下，用例模型是通過用例圖和用例說明來進行表述的。
• 類模型（Class Models）：此模型與邏輯資料模型相類似，主要用於描述靜態的資訊以及這些資訊之間的關係。除此之外，類模型還可被用來描述資訊的行為。與其他各種模型類似，類模型也是可以在多種粒度層次上進行模型建設的。根據建模意圖的不同，類模型既可以用來表達各種業務領域實體，亦可以被用來描述各個用於進行系統實現的類。一個業務領域模型表達了關鍵的業務資訊、他們的性質、行為和關係。類模型的描述通常通過類圖進行表現，不過更加詳盡的說明和資訊將被記錄在額外的說明文件之中。

      以上三種模型都可以通過統一建模語言（UML：Unified Modeling Language）來進行描述，並且在現實生活中存在著很多可以生成這些模型的工具。除了這些通用性的模型之外，每個行業也有著符合自身特點的各種模型和建模技術。以國防部門為例，如下幾種模型就是比較有代表性的（需要注意的是，雖然這些模型源於國防部門，但是在其他政府部門中也逐漸得以採納，而對於非政府環境來說也具有借鑑意義）：

• 節點連線圖（Node Connectivity Diagram）：描述了業務位置（即節點）、業務位置之間的需求關係以及節點間所交換的資訊的性質。該模型可以在三種層次之上進行描述，即概念層次、邏輯層次和物理層次。每條節點之間的需求連線代表其所連線的兩個節點之間對於資訊傳輸的需求，而每個節點則用來代表一個角色、組織單位、業務位置或設定等。標註在連線上的箭頭用於表示資訊流的傳輸方向，而箭頭附近的標註則被用來描述所傳輸的資料或資訊的性質（例如，內容、媒介、安全或分類等級、時限和資訊系統互操作需求等）。
• 資訊交換矩陣（Information Exchange Matrix）：記錄企業架構的資訊交換需求。資訊交換需求表述了三種基本實體（活動、業務節點和他們的元素、資訊流）之間的關係，並著眼於資訊交換的各種特性（例如效能和安全性）。簡單來說，該模型表述了什麼人與其他何人交換何種資訊，這些資訊的必要性以及資訊交換的形式。

使用架構資源庫

      在這一階段的各項活動中，架構團隊需要考慮在架構資源庫中是否存在與業務架構相關的資源可供使用，特別是在如下幾個方面的資源：

• 組織所在行業的通用業務模型（儲存在架構資源庫的參考資料庫中）。前面提到過的聯邦企業架構業務參考模型就是個很好的例子。
• 與在IT行業釋出的通用高層次業務領域（例如電子商務、供應鏈管理等）相關的業務模型，例如主要用於財會系統建模的REA（Resource-Event-Agent）業務模型和關注於產品設計和供應鏈互動方面的STEP（Standard for the Exchange of Product model data）框架。
• 企業特定的構建塊（流程元件、業務規則、工作描述等）。
• 各種適用的標準。

1.3.3 輸入與輸出

      在當前階段所需的輸入材料以及此階段輸出的各種交付物歸納如下：

1.3.4 步驟

      在當前階段中所要執行的各個步驟歸納如下：

• 選擇參考模型，視角和工具
• 開發基線業務架構描述
• 開發目標業務架構描述
• 進行差別分析
• 定義架構路線圖元件
• 通觀整個架構景觀來明確和解決相關影響。
• 進行正式的干係人審查
• 最終確定業務架構
• 建立架構定義文件