業務架構（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）框架。

• 企業特定的構建塊（流程組件、業務規則、工作描述等）。

• 各種適用的標準。

      想要了解更多關于TOGAF認證資訊信息，請關注中培偉業李老師微信（18034262135）：