ArchiMate指南：區分ArchiMate中的業務服務與應用服務

企業架構框架提供了理解組織運作方式所需的結構。在這些框架中，ArchiMate規範因其能夠在多個層級上建模複雜關係而脫穎而出。此框架中最重要的區分之一涉及服務概念。具體而言，理解「業務服務與應用服務之間的差異，對於準確建模至關重要。

當架構師混淆這兩種類型時，所產生的模型將失去精確性。利益相關者可能誤解價值流與技術能力交付之間的差異。本指南探討這些服務的細微之處、它們之間的關係，以及對架構設計的影響。

🔍 ArchiMate中的服務概念

在分析具體類型之前，有必要定義在此背景下什麼構成了服務。在ArchiMate中，服務不僅僅是軟體功能。它是一種針對特定接收者所提供的內容的抽象表示。

• 提供：服務是由一個主動結構所提供的內容。

• 使用：服務是由一個被動結構所使用的內容。

• 介面：服務由介面實現。

此定義適用於所有層級。然而，提供者與接收者的性質會根據上下文而變化。業務服務由業務參與者或業務功能提供。應用服務由應用功能或應用組件提供。

🏢 業務服務：價值主張

業務服務代表組織向其客戶或內部利益相關者提供的價值。它們是業務能力在實際運作中的體現。當客戶與組織互動時，他們正在使用業務服務。

這些服務可能是面向外部或內部的，但始終與業務成果相關。它們獨立於技術實現。例如，處理付款的能力是一項業務服務。無論該付款是由大型主機、雲端API還是手動帳本處理，都與服務本身的定義無關。

業務服務的特徵

• 焦點：業務成果與價值創造。

• 提供者：業務參與者或業務功能。

• 接收者：業務參與者、業務角色或其他業務功能。

• 細粒度：通常為粗粒度，代表重要的業務流程。

• 穩定性：即使技術變更，也相對穩定。

考慮一個零售情境。服務「處理客戶訂單」是一項商業服務。它封裝了接收訂單、驗證庫存以及啟動履行的邏輯。用來記錄訂單的特定軟體是一項應用服務。無論使用何種工具，商業服務都保持不變。

💻 應用服務：技術推動者

應用服務位於應用層。它們代表了IT環境所提供的功能。這些服務支援商業服務的實現。它們是使商業邏輯得以執行的技術機制。

如果商業服務是「做什麼」，那麼應用服務就是「如何做」。它描述了軟體環境所提供的特定功能。例如，「驗證信用卡」就是一項應用服務。它是支付軟體堆疊中的特定功能。

應用服務的特徵

• 焦點：技術功能與資料處理。

• 提供者：應用功能或應用組件。

• 接收者：其他應用功能、商業功能或商業參與者。

• 細粒度： 可從粗粒度到細粒度不等。

• 穩定性： 由於技術演進，其穩定性低於商業服務。

應用服務通常透過介面暴露自身。它們可能被負責協調工作流程的商業功能存取，或被另一項分解複雜任務的應用服務存取。

🆚 關鍵差異：比較分析

理解這兩者的區別，需要觀察這些服務如何與模型的其他部分互動。下表概述了主要差異點。

特徵	商業服務	應用服務
層級	商業層	應用層
主要目的	提供價值	啟用能力
實現方式	由商業流程/功能實現	由應用功能/組件實現
依賴	依賴應用程式服務	支援商業服務
範例	管理客戶帳戶	更新帳戶資料庫
消費者	商業實體、商業角色	應用程式功能、商業功能

注意依賴流程。商業服務依賴應用程式服務才能運作。若應用程式服務失效，商業服務便無法提供。此依賴關係在 ArchiMate 中明確建模，以追蹤影響。

🔗 關係與連接

這些服務之間的關係對於理解架構至關重要。ArchiMate 定義了特定的關係類型，以明確說明服務之間的互動方式。

實現

「實現關係是各層之間最常見的連結。它表示高階概念由低階概念實現。

• 商業服務實現： 商業服務由商業功能或商業流程實現。

• 應用程式服務實現： 應用程式服務由應用程式元件或應用程式功能實現。

• 跨層實現： 關鍵的是，商業服務由應用程式服務實現。

此跨層實現定義了架構的核心價值鏈。它清楚顯示了資訊技術環境如何促成商業價值。例如，商業服務「出貨產品」由應用程式服務「產生運輸標籤」實現。

存取

「存取關係定義了一個結構如何使用另一個結構的功能。通常用來表示商業功能存取應用程式服務。

• 商業功能存取應用程式服務： 這在由人力驅動的流程中很常見，使用者與系統互動。

• 應用程式功能存取應用程式服務： 這發生在自動化工作流程中，其中一個軟體組件調用另一個。

通訊

這通訊此關係描述結構之間的資訊流動。雖然服務之間直接使用較少見，但當服務交換資料時，此關係仍具相關性。

• 資料流： 商業服務可能與另一個商業服務通訊資料。

• 系統互動： 應用服務可能與後端應用服務通訊以取得資料。

🧠 模型設計最佳實務

為維持 ArchiMate 模型的清晰度與實用性，請遵循這些最佳實務。服務模型中的模糊性會導致實作與維護階段產生混淆。

1. 命名慣例

• 商業服務： 使用描述商業價值的名詞片語。範例：「管理庫存」、「處理申訴」、「提供支援」。

• 應用服務： 使用動詞-物件片語來描述技術性動作。範例：「儲存客戶資料」、「計算稅率」、「呈現儀表板」。

一致的命名有助於利害關係人快速辨識層級。若看到「計算稅率」，代表是應用服務；若看到「決定稅務責任」，則代表是商業服務。

2. 避免跨層放置

常見錯誤是將應用服務放置於商業層，或反之亦然。請確保每個元素都放置於正確的層級。若服務具有技術性質，即使支援商業目標，也應屬於應用層。

• 確認： 誰提供此服務？

• 確認： 主要成果為何？

• 確認： 實作是否依賴軟體？

3. 粒度一致性

在層級內維持一致的粒度。不要在同一服務清單中混合高階商業策略與低階資料操作。將相關服務分組為邏輯群組。

• 分組： 按領域分組應用服務（例如：「訂單管理領域」、「財務領域」）。

• 分組： 按價值鏈對業務服務進行分組（例如：「採購」、「銷售」、「履行」）。

🚧 常見的陷阱與誤解

即使經驗豐富的架構師在區分這些服務時也可能出錯。認識到這些陷阱有助於優化模型。

陷阱 1：「黑箱」業務流程

通常，架構師在建模業務流程時，未詳細說明支援它的應用服務。這會形成一個黑箱，導致「做什麼」與「如何做」之間的聯繫喪失。

• 解決方案： 始終確保關鍵的業務服務由特定的應用服務實現。追蹤從價值到程式碼的路徑。

陷阱 2：功能思維與服務思維

架構師有時會建模功能而非服務。功能是一種主動結構，用於執行工作；服務則是該工作成果的輸出，提供給接收者。

• 區別： 一個業務功能「處理訂單」是一種主動結構。業務服務「訂單處理」是所提供的價值。應用服務「訂單驗證」是技術能力。

• 影響： 將這兩者混淆會導致模型看起來像流程圖，而非架構地圖。

陷阱 3：忽略介面

服務由介面實現。跳過介面層會使定義合約與協議變得困難。

• 要求： 為每個應用服務定義介面。

• 要求： 若業務服務與外部參與者互動，則需為其定義介面。

📈 對策略與實施的影響

業務服務與應用服務之間的區別不僅是理論上的。它對戰略規劃與技術實施具有直接影響。

戰略對齊

當業務服務被明確定義時，策略便變得可衡量。您可以直接將業務目標映射到服務上。若目標是「縮短訂單處理時間」，便可追溯至「處理訂單」業務服務，進而識別出哪些應用服務是瓶頸。

• 投資： 有助於根據業務價值來優先安排 IT 投資。

• 優化： 可針對特定應用服務進行精準優化，而無需更改業務服務。

技術實施

對開發團隊而言，應用服務定義了需建立的微服務或模組。明確的定義可確保程式碼與架構意圖一致。

• 模組化： 應用程式服務促進模組化設計。

• 整合： 應用程式服務上定義的介面引導 API 合約。

🔄 演化與維護

架構並非靜態。服務會隨時間演變。理解各層次有助於管理此種演變。

技術遷移

從本地系統遷移至雲端時，應用程式服務可能會改變。然而，商業服務應保持相對穩定。

• 穩定性： 商業服務「管理訂閱」保持不變。

• 變更： 應用程式服務「主機訂閱資料」從資料庫伺服器移至雲端儲存服務。

這種分離確保即使底層技術發生變動，業務連續性也能維持。

服務分解

隨著組織成長，粗粒度的服務經常會被分解。高階的商業服務可能被拆分成多個應用程式服務。

• 範例： 「管理使用者身分」可能拆分成「驗證使用者」與「管理個人檔案」應用程式服務。

• 結果： 商業服務保持不變，但技術實作變得更細緻。

📊 關係總結

為了直觀呈現流程，請考慮以下層級結構：

• 商業策略： 定義服務的需求。

• 商業服務： 為客戶提供價值。

• 應用程式服務： 提供技術能力。

• 應用程式元件： 實作應用程式服務。

• 基礎設施： 主機應用程式元件。

每一層都支援其上層。應用層是發動機房，但業務層才是最終目標。

🛠️ 建模中的實際應用

建立模型時，請遵循以下步驟，以確保正確區分。

1. 識別利益相關者：誰在使用此服務？如果是客戶或員工，這很可能是業務服務。

2. 識別提供者：誰提供此服務？如果是軟體組件，則為應用服務。

3. 定義介面：此服務如何被存取？定義協定或互動點。

4. 映射實現：使用實現箭頭將業務服務連結至應用服務。

5. 驗證流程：確保不存在違反分層原則的循環。

遵循此紀律嚴明的方法，模型將保持清晰且可執行。它能避免在業務層使用技術術語，或在技術層使用業務術語的陷阱。

🌐 更廣泛的影響

這種區分支援其他架構框架。在整合ArchiMate與TOGAF或Zachman時，服務層扮演橋樑的角色。

• TOGAF：業務架構定義服務；資訊系統架構定義應用程式。

• ITIL：服務管理專注於業務服務；IT運營專注於應用服務。

這種互操作性使組織能在不同方法論之間使用單一的真理來源。

🔒 安全與治理

安全控制通常應用於應用服務層級，但其目的是保護業務服務的價值。

• 驗證：應用於應用服務介面。

• 審計：應用於業務服務的使用。

• 合規性：確保應用服務符合業務服務的要求。

理解各層次有助於正確分配安全責任。業務所有者擁有價值；IT所有者擁有能力。

📝 服務建模的最終想法

區分業務服務與應用服務所帶來的清晰度，對於成功的企業架構而言至關重要。它創造出一份利益相關者可以閱讀、開發人員可以遵循的指南。若缺乏此區分，模型將變成無法引導實作的抽象圖示。

專注於業務服務所交付的價值，以及應用服務所提供的能力。保持各層次的區分，但又相互連結。這種紀律確保架構在組織演進過程中仍具相關性。

透過遵循這些原則，架構師所建立的模型不僅是文件，更是變革的工具。