Read this post in: de_DEen_USes_ESfr_FRhi_INid_IDjapl_PLpt_PTru_RUvizh_CN

ArchiMate 範例視圖:完整圖庫 – 動機、策略、業務、應用、技術與遷移

框架視圖

框架視圖。

此視圖代表建立所有開發面向與相關圖表的框架。此視圖可依情況進行調整,因此可用於圖表之間的導航。此版本的視圖源自 ArchiMate (3) 框架。在此,動機被視為「層」而非「面向」。

動機觀點

動機觀點

動機觀點。

此視圖可用於分析引導組織及其企業架構設計或變革的動機或驅動因素。這些動機分析是組織內所有變革活動或業務轉型的起點。此視圖代表開發工作的願景——無論範圍與規模涵蓋整個組織,或其中一部分(例如某業務線),或單一計畫或專案(解決方案層級)。注意:可將「價值」加入至成果(或任何其他 ArchiMate 元素)以表明實際增加的價值!

動機元素基於商業動機模型(BMM)[規格 v.1.3,2015,OMG]。

使命 – 願景 – 價值觀視圖

使命 – 願景 – 價值觀。

此視圖可用於呈現組織的使命、願景與核心價值。使命可說明例如:「組織的目的是什麼,實際上做什麼或打算做什麼,以及其存在的主要理由為何?」願景是組織希望朝向的未來狀態。核心價值支持願景、塑造文化,並反映組織的價值。要實現組織的願景,必須達成戰略目標。

參考來源:Aldea, A. – Iacob, M.-E. – Hillegersberg, J. – Quartel, D. – Franken, H. (2015) 使用 ArchiMate 建模策略。

戰略價值地圖視圖

價值地圖 – 戰略地圖視圖。

此視圖可用於呈現組織的策略。此視圖包含戰略價值元素,所有開發活動都必須直接或間接源自這些戰略價值元素。透過呈現戰略價值,可追蹤所有與實際戰略執行相關的其他元素。透過此視圖,策略可具體化:可視化、傳達並與現實連結。

利害關係人分析視圖

利害關係人分析視圖。

此視圖可用於業務發展的利害關係人分析:變革的驅動因素為何?首先識別相關利害關係人,再確定與其利益相符的變革驅動因素。可使用「評估」概念進一步分析驅動因素,例如依 SWOT(優勢、劣勢、機會、威脅)方法。通常可從不同觀點建立不同的利害關係人視圖。將整體圖景拆分成較小部分的另一原因,是為了保持圖表緊湊且易於閱讀——以求簡化。

利害關係人觀點

利害關係人觀點。

此視圖可用於將利害關係人的驅動因素與業務目標連結。目標是組織發展的關鍵要素。所有後續元素都應追溯至所有變革活動的主要驅動因素。

原則視圖

原則視圖。

風險與安全視圖

風險與安全視圖。將風險與安全概念映射至 ArchiMate。安全與資料保護問題屬於風險管理的一部分。此建模方法涵蓋兩者。

參考來源:

  • 如何使用 ArchiMate® 語言建模企業風險管理與安全,開放集團,文件編號:W172,2017。
  • 使用ArchiMate®語言建模企業風險管理與安全,開放集團,2015年。

SWOT分析視圖

SWOT分析視圖。

目標視圖

目標視圖(含價值元素)。

目標與關鍵成果

OKR模式。

OKR是一種流行的管理策略,用於定義目標並追蹤結果。它有助於在可衡量的目標周圍建立一致性和參與度。OKR包含兩個重要部分:您希望達成的目標,以及衡量目標達成情況的關鍵成果。

目標:

  • 對您希望達成之事的令人難忘且定性的描述。目標應簡短、鼓舞人心且具有吸引力。目標應能激勵並挑戰團隊。

關鍵成果:

  • 一組衡量您向目標進展程度的指標。每個目標應有2至5個關鍵成果。數量不宜過多,否則無人會記得。

以下為OKR的另一種版本。

OKR模式(2)。

策略觀點

策略層視圖

策略視圖

策略視圖。

ArchiMate 3版本現在支援與商業策略相關的概念,例如「行動路徑」、「能力」和「資源」,這些可用於建模組織的商業策略。此視圖的價值與重要性在於,組織的目標可與策略連結,並透過能力與企業架構建立關聯。此視圖可用於應用「基於目標的策略建模」(Azevedo等,2015),其中目標形成層級結構,使高階目標可被分解為低階目標。

商業策略視圖

商業策略。

商業動機模型(BMM)視圖

商業動機模型(BMM)視圖。

需求視圖

需求視圖。

此視圖可用於根據戰略目標收集需求。這將策略與實現聯繫起來:策略可追溯至執行。

策略至能力視圖

策略至能力視圖。

此視圖可用於能力導向規劃(CBP)等目的,以及如圖所示的其他ArchiMate概念,例如「驅動因素」和「目標」。此視圖可用於支援戰略規劃(及執行)目的。因此,此視圖可用於策略至能力階段,該階段可包含在IT4IT的「策略至投資組合」中。

能力地圖視圖

能力地圖檢視。

此檢視可用於提供組織能力的整體概覽:組織所執行或能夠執行的事項。

能力規劃檢視

能力規劃檢視。

此檢視可用於能力導向規劃(CBP)等目的,即「策略與企業架構之間的連結」。此檢視可用於將策略映射至所需的能力,並將能力映射至資源及其他構建模組。

能力實現檢視

能力實現檢視。

能力實現檢視 2

另一種定義能力如何由哪些元素實現的檢視……

能力實現檢視 2。

價值流檢視

價值流檢視(模式)。

注意!「定向關聯」用於價值鏈/價值流的起點。價值流可由價值「階段」組成。同樣地,整體性的高階價值流可為「價值鏈」,而價值鏈本身又由多個價值流組成。例如,IT4IT(連結)引入了一個由四個價值流組成的價值鏈,分別為:投資組合策略、部署需求、履行請求、偵測至修正(連結).

價值流-能力交叉映射檢視

下圖展示了一個價值交付鏈的簡單範例。價值鏈、價值網絡與價值流可透過 ArhiMate 3.1 版本中包含的 ArhiMate 價值流元素進行建模。

從構想到生產的價值鏈範例檢視。

價值交付鏈。這是一個擴展範例,用以說明功能如何支援(服務)價值流。此檢視可用於定義組織所執行的事項(商業模式),說明為何需要特定能力,以及這些能力與價值創造之間的關聯。

此檢視包含於精益企業架構框架(LEAF)的參考實作(連結)。導航至「價值流」、「價值交付鏈」。

商業模式畫布檢視

商業模式檢視。

這是 A. Osterwalder 的 商業模式畫布(BMC)的基本形式,但可依情境調整。亦有版本化的方法,例如「服務模式畫布」或「精益畫布」。BMC 可用於商業模式設計與創新等用途。

使用 ArhiMate 建模 BMC「有助於從業務需求追蹤至設計規格。這有助於發現商業模式變更對架構設計的影響。」[LO Meertens 等]

整體發展包括內建的架構支援,用於策略與商業模式分析。這使得業務分析師與開發人員能夠觀察例如商業模式如何支援策略,以及商業模式如何適應組織,反之亦然。

如果在建模工具中建立 BMC,此方法的優勢在於 BMC 的所有元素都可在同一模型倉庫中的其他視圖中使用。當商業模式被調整時,所有變更會立即可見。業務模型設計師可以建立新元素(例如服務),或使用倉庫中所有現有的元素(例如組織單位或資源)。

概念畫布檢視

概念畫布。BMC 可有不同的變體,如下方圖示所示。此概念畫布的佈局與 ArchiMate 的分層方法一致。

業務觀點

業務架構層次檢視。

業務服務地圖檢視

業務服務檢視。

此檢視提供組織業務服務的整體概覽。此檢視可用作管理用的「服務目錄」或「服務組合」。識別組織向客戶提供的業務服務至關重要。此外,業務服務是建模所有底層組織流程與結構的起點。因此,業務服務是企業架構中最重要的元素之一。

業務流程地圖檢視

業務流程檢視。

此檢視可用作「流程地圖」,提供組織業務流程的整體概覽。

業務流程協作檢視

業務流程協作檢視。

此檢視可用於例如建模營運模式。

業務參與者地圖檢視

業務參與者檢視。

業務參與者可分為 a) 內部或 b) 外部。內部業務參與者例如組織單位,而外部業務參與者例如客戶、商業夥伴或其他與組織合作的利害關係群體(例如公共部門組織或其他管理機構)。

業務參與者協作檢視

業務參與者協作檢視。

兩個使用案例如下:

  1. 企業內部檢視:業務參與者協作觀點,描述內部業務參與者如何合作以及如何交換資訊。
  2. 企業間檢視:生態系統觀點,呈現組織運作的營運環境。生態系統是由組織與商業夥伴透過協作互動所形成的網絡。其中包括供應商、分包商及其他 B2B 合作夥伴、客戶等。

業務流程檢視

業務流程檢視。

此業務流程檢視提供「一個或多個業務流程(或其部分)的高階結構與組成,其中提供服務、參與者被指派至角色,且業務流程使用資訊」[ArchiMate 2.1 規格]。流程圖包含「連接點」元素,用於模擬流程中的「分叉」與「匯合」。

下方顯示高階流程檢視。此檢視基於從商業模式推導出的營運模式,如上方價值流程圖所示。

從構想到生產的流程。

SIPOC(供應商、輸入、流程、輸出、客戶)

SIPOC。

稱為SIPOC(供應商、輸入、流程、輸出、客戶)的六西格瑪工具可用於定義所有流程共有的元素。這是一種用於分析商業案例的簡單工具:客戶獲得什麼價值,以及該價值是如何被提供的。

以業務角色作為流程「泳道」的業務流程視圖——分層方法

業務流程泳道視圖(模式)2.0。

「業務角色A」代表客戶,而最上方的「泳道」代表客戶旅程路徑。

注意!流程步驟(活動)嵌套於業務角色內(以「泳道」形式呈現),這表示:這些業務角色被分配給這些業務流程/流程步驟。因此,此視圖是業務流程視圖與分層視圖的結合。

以下版本展示了資訊與資料流(流動關係)。最上方的「泳道」代表客戶旅程路徑(由觸發關係關聯的活動)。

業務流程泳道視圖(模式)2.0(資訊流)。

以下版本代表一種服務設計方法。最上方的「泳道」(角色A)代表客戶旅程路徑,透過業務服務(1和2)與組織(角色B和C)相連。

業務流程泳道視圖(模式)2.0(服務)。

分層業務流程視圖

分層流程視圖。

此視圖可用於建模包含手動與自動步驟的業務流程。

客戶旅程地圖視圖

在高階分析客戶旅程時,此版本使用動機與策略元素建立。

客戶旅程地圖(高階)。

在更詳細地分析客戶服務路徑時,此版本使用業務層與應用層(核心)元素建立。

客戶旅程視圖(範例)1.0。

此以客戶為中心的視圖專注於客戶體驗。與「服務設計」相關的此「外向內」開發方法強調一個重要觀點:服務與產品的設計旨在為客戶創造價值——間接也為組織本身創造價值。客戶旅程路徑可用於呈現跨越多個應用服務與應用程式的客戶價值流。

服務藍圖視圖

服務藍圖視圖 1(服務與流動)

此視圖以客戶與服務為中心,同時也強調服務的「內向」部分。透過此方法,以服務為導向的開發可識別出即將設計的服務可能產生的行為與結構性影響。因此,此視圖透過流程與功能面向,補足了以客戶體驗為導向的方法。

此視圖有數種變體。上述範例專注於各層級與元素之間的資訊流。

使用者故事視圖

使用者故事視圖。

此視圖可用於呈現使用者故事。

雲端服務模型視圖

雲端服務模型視圖。

資訊視圖

資訊視圖。

資訊可依不同抽象層級進行建模,如下:a) 概念層級,b) 逻辑層級,c) 物理層級。上圖說明了這些抽象層級。

概念資料模型檢視

概念資料模型檢視。

企業架構的資訊架構包含於業務流程中使用的業務物件,也就是概念。這些概念及其關係可透過概念資料模型來呈現。

「服務」概念

服務概念。

服務概念經常存在問題,且可被理解為許多不同方式。為了清楚區分所涉及的服務類型,建議加上前綴:業務服務、應用服務或技術服務。根據ITIL,IT服務與生產服務相關。例如,IT服務最接近應用服務。

服務對產品

產品檢視。

產品概念可用作組合元素,以歸納服務。根據ArchiMate規格:

「產品代表一組協調一致的服務和/或被動結構元素,並附帶一組合約/協議,整體提供給(內部或外部)客戶。」

「產品可聚合或組成業務服務、應用服務與技術服務、業務物件、資料物件與技術物件,以及合約。因此,產品可聚合或組成非業務層的元素。」

「產品可與價值相關聯。產品名稱通常是與客戶溝通時使用的名稱,或可能是一個更通用的名詞(例如:『旅遊保險』)。」

應用檢視點

應用架構層檢視。

應用服務地圖檢視

應用服務檢視。

應用程式地圖檢視

應用程式地圖檢視。

應用程式組合,其中應用程式可依業務單位進行分組。

應用程式協作檢視(資料流程)

應用程式協作檢視。

應用程式整合檢視(動態關係)

下例顯示了多種替代方式,用以模擬應用程式之間的資料切換(1 至 10)。

  • 「應用程式 A」擁有「A-1」資料物件,該物件由「應用程式 B」請求。
  • 資料由「應用程式 A」流向「應用程式 B」。
  • 「應用程式 A」實現「A-1」服務,該服務由「應用程式 B」使用。
  • 實際上,「應用程式 B」請求應用程式介面「A-1」,並收到回應……

應用程式整合檢視。

應用程式結構檢視

此檢視有助於設計或理解應用程式的主體結構及其子組件與相關資料。該圖表可用於分解正在建構的應用程式系統的結構,以說明模組化/分解:有哪些子系統/子組件,它們提供哪些應用服務(或應用介面)。

應用結構檢視。

請注意,應用程式服務(上方圖示)是由結構介面(下方圖示中的 GUI 和/或 API)所提供的行為功能。應用程式服務與應用程式介面是「同一枚硬幣的兩面」。

應用結構檢視 2。

應用架構檢視

此檢視結合了企業架構層級與解決方案層級的方法,因為應用程式與應用程式模組均存在於同一檢視中。

應用架構。

應用元件模型(CM)

應用元件模型 0-n 是一種應用架構建模方法,包含不同抽象層級的圖示,如下所示:

  • 在 CM-0 層級,圖示描述目標應用程式如何與其環境互動,以及與相鄰應用程式和使用者之間存在哪些互動。目標應用程式被描述為一個黑箱。
  • 在 CM-1 層級,目標應用程式被分解為模組(主要元件),並說明這些模組提供與需要哪些應用程式服務(或應用程式介面)。目標應用程式被描述為一個白箱。
  • 在 CM-2 層級,模組被進一步分解為次元件。(所需層級數量取決於具體情況。)

下方的應用元件模型(CM)圖示包含應用程式元件與應用程式服務。根據情況,也可使用應用程式介面取代應用程式服務。一如往常,使用適合目的的建模風格非常重要,僅建模能提供足夠資訊並具備價值的元素。這取決於建模者——他或她是否偏好強調功能面向,或更為具體地建模,例如實際介面並使用精確名稱。

下方的元件模型圖示包含應用程式元件與應用程式服務。根據情況,也可使用應用程式介面取代應用程式服務。

應用元件模型 – 0(CM-0)

應用元件模型 – 0。

元件模型 – 0(CM-0)層級(上方)說明目標應用程式與相鄰應用程式之間的互動。所有相關的應用程式服務(或應用程式介面)均被引入。層級 0 圖示由企業架構層級元件及其服務組成,目標應用程式位於中央。

應用元件模型 – 1(CM-1)

應用元件模型 – 1。

元件模型 – 1(CM-1)層級(上方)說明目標應用程式如何被分解為模組(或主要元件),以及每個模組實現哪些應用程式服務(或應用程式介面)。注意!外部應用程式可在此層級排除,但其服務(或介面)仍需顯示。當顯示更多底層元素時,可/必須省略部分高層元素——為求簡化:保持圖示清晰易讀。

應用元件模型 – 2(CM-2)

應用元件模型 – 2。

元件模型 – 2(CM-2)層級(上方)說明目標應用程式的模組如何由次元件組成,以及它們之間如何互動。

應用功能檢視

應用功能分解:系統包含哪些功能,並提供哪些應用程式服務?

應用功能檢視。

應用流程檢視

應用流程檢視。

應用流程檢視 – 嵌套。

應用流程檢視 – 內部結構。

應用元件序列表示檢視

序列圖並不在 ArchiMate 的完整範圍之內,而是在 UML 範圍內。然而,我們可以使用 ArchiMate 來模擬應用組件所採取的動作序列,如下所示。

應用程式序列檢視。

動態關係「觸發」和「流程」可用來模擬應用組件之間的動態。此檢視的佈局可類似於 UML 序列圖的配置。

應用組件序列圖檢視 2

此版本(如下)說明了如何使用 ArchiMate 來模擬應用組件內部部分所採取的動作序列。內部部分例如:a) 行為流程或功能,以及 b) 結構性子組件。這些皆可使用應用流程、應用功能和應用組件元素來建模。這裡僅作為替代方案呈現。

應用程式序列檢視(2)。

此序列圖(上方)中的操作流程:

  1. 應用組件「A」的子流程「X」向應用程式 B 發送帶有參數「A」的請求訊息。
  2. 應用組件「B」的子流程「B-1」接收傳入的請求,然後(同步地)呼叫應用組件 C,其中應用功能「Y」接收請求,執行一些操作,並回應。
  3. 應用組件「B」的另一個子流程「B-2」向應用組件 D 發送帶有參數的訊息並接收確認。應用組件「D」包含執行處理的子組件。
  4. 應用組件「A」從應用組件「B」接收回應訊息。

如圖所示,我們可以透過結合這些元素(應用組件、應用流程、應用功能及關係(觸發、流程))來模擬相當複雜的整合案例。UML 序列圖在軟體設計中有其專門用途,但 ArchiMate 可用於許多建模目的——也包括應用設計。

應用整合是企業架構(EA)中最重要的部分之一。因此,若能更詳細地模擬應用程式如何交換資料以及使用哪些互動機制,將會非常有益。深入了解整合模式的良好資源是《企業整合模式》一書,這裡是連結.

新增的最終使用者序列(如下)遵循使用 ArchiMate 動態關係「觸發」與「流程」的相同概念,可用來模擬同步與非同步通訊模式(請求-回應、回呼,以及發佈-訂閱等)。

序列模式檢視。

ETL 流程檢視

ETL 流程檢視。

EAI / ESB 檢視

EAI – ESB 模式檢視。

分層檢視

分層檢視。

分層檢視可用作目標區域的整體概觀上下文圖。此檢視的主要優勢在於說明應用程式如何應用於業務流程及其所提供的服務。上方圖示使用 ArchiMate 的群組元素來模擬不同層級,而下方圖示則使用工具提供的視覺群組元素(Archi).

在 ArchiMate 中,基本上有三個層級:1) 商務層、2) 應用層,以及 3) 技術層。它們的顏色通常如下:商務層為黃色,應用層為青綠色,技術層為綠色(參見 ArchiMate 核心架構,連結).

分層檢視。

應用程式與資料庫檢視

資料庫是組織整體企業架構中具有意義的單位。例如「客戶資料庫」或「客戶資料庫」、「產品資料庫」等。或者,資料庫也可以是應用程式中所有資料表的集合(例如「客戶資料表」、「訂單資料表」、「發票資料表」等),這些資料表共同構成一個資料庫。根據ArchiMate規格,資料物件可用來建模邏輯資料庫(下圖),第9.4.1節「資料物件」指出:「資料物件的典型範例包括客戶記錄、客戶資料庫或保險理賠。」「一個重要的例外是當資料物件用來建模資料集合(例如資料庫)時,其中僅存在一個實例。」ArchiMate具備優雅的內建機制,允許某些概念在不同抽象層級(與細節層級)中使用。因此,例如資料物件可用來建模邏輯資料庫、資料表、訊息結構(在應用程式之間切換)等。

資料庫建模考量事項。

資料庫作為應用程式元件。

資料庫抽象層級。

資料模型檢視。

使用案例檢視

ArchiMate 可用於從應用程式的功能觀點分析使用案例。使用案例(在UML中已知)可如下方圖示所示,對應至應用程式服務。

使用案例檢視(模式 1)。

使用案例可分為:a) 商業使用案例與 b) 系統使用案例(又稱系統使用案例)。下圖說明如何將「主要使用案例」建模為商業服務,而後續的系統使用案例則建模為應用程式服務。

使用案例檢視(範例)。

當使用案例被識別為應用程式服務時,可進一步用於其他圖表中的目標應用程式之功能元件(例如在分層檢視中)。換句話說:應用程式服務代表應用程式的行為(功能)。有關使用案例分析的更多詳細資訊,請參閱ArchiMate食譜,連結.

技術觀點

技術架構層次檢視。

基礎設施檢視

此檢視代表應用程式的平台。此模式可用來建模執行環境的設定以及商業應用程式的部署。

基礎設施檢視。

基礎設施檢視(巢狀)。

實作與遷移層/轉型架構層檢視

實作路徑圖檢視

實作路徑圖檢視。

看板檢視

看板(企業架構)。

看板可用來視覺化工作與工作流程。看板可顯示開發需求、大型功能、使用者故事等如何從待辦事項流至準備就緒狀態(完成)。看板可依開發案例的規模與範圍應用於各種用途。例如,「大型功能」可用於企業架構層級,而「使用者故事」或「需求」則可用於專案層級。工作項目之細節程度可依情境而異。

通用檢視

通用檢視。

此簡化檢視可用於例如作為特定服務、計畫或專案的背景圖。

額外功能

上下文概覽 – 銀河系地圖

這是一種盡可能在相同視圖中呈現更多內容的方法。詳細資訊請參閱 ArchiMate 的銀河系地圖,連結.

FM 銀河系地圖(第二層)。(注意!此色彩方案使用 ArchiMate 的預設色彩。如有需要,可使用其他色彩。)

合作視圖

如下方資料流程圖範例所示,各層可混合使用。

應用合作視圖(擴展版)。

元模型

元模型。

Leave a Reply