企業架構研究總結（41）——企業架構與建模之ArchiMate的由來和詳述（上）

      終於完成了關於企業架構框架理論的總結，謝謝各位看官的支持，能挺過以前過於理論化的敘述而堅持到如今着實不易，筆者也自愧沒有實踐經驗能夠分享，但願往後有興趣的看官可以不吝賜教。在本系列後面的也是最後一個大部分中，筆者將以ArchiMate語言爲核心，盡力描述企業架構和建模之間的關係，以及基於企業架構模型的分析，其內容大多來源於ArchiMate 2.0標準以及《Enterprise Architecture at Work》這兩部資料，有興趣的看客能夠對其進行參考比照。在此，再一次感謝支持本系列的各位看客，另外這一部分的內容應該不會想以前那麼理論化，這也算是個好消息吧 ^_^。那麼咱們就開始吧：

      經過在前幾章中對當前在業界比較知名的幾種企業架構和企業架構框架的介紹，咱們能夠將企業架構的內容看爲由若干企業架構元素以及他們之間的關係組合而成。這些企業架構元素以及他們之間的關係覆蓋範圍廣闊，縱貫了企業戰略、原則、目標、需求、業務、信息系統以及基礎設施這些層面。正由於須要照顧到如此普遍的範圍，企業架構必將不可避免地面對企業內外各具備不一樣背景、關注點和利益的干係人（Stakeholder），而他們也正是企業架構的終極用戶。因此，如何在這些干係人之間創建針對企業情況的無障礙的溝通是企業架構的最終目標，而在此基礎之上纔有可能實現諸如業務-IT相協調（Business-IT Alignment）、企業從單一領域優化到全局範圍優化的演進等目標。爲了達到這一目標，咱們便須要對「企業」這一客觀對象進行描述，並在各干係人之間得到一致性的認同，而這一過程也正是採用各類企業架構框架來進行企業架構建設過程的核心。若是用IT方面的詞彙來描述，咱們能夠將其稱爲對企業進行「建模」。

      雖則能夠將如此複雜之事用「建模」這兩個字來歸納，可是若是要實現它，咱們還須要面對以下幾個問題：

• 如何進行建模？
• 針對什麼進行建模？
• 採用何種方式來進行表述？

      對於如何進行建模，在一些著名的企業架構框架（例如TOGAF）中已經有了相關闡述，羅列出了企業架構建設的各個實施、維護階段以及相關的輸入、輸出和目標，於是在這裏就再也不贅述。

      對於針對什麼進行建模，這涉及到企業架構的內容範疇。從前面各章可知，各類企業架構框架對於企業架構內容都有着不一樣程度的分類和歸納，而經過將它們概括起來，我能夠把企業架構的內容範疇界定爲：企業架構的內容應表述企業的當前以及指望的狀態，而這些內容應該以企業的戰略、原則和目標爲起點，以企業的文化和現有管理方法爲背景，在縱向結合並貫穿業務、信息系統和基礎設施這三個層面，而在橫向則應反映各干係人的關注點和利益。

      對於採用何種方式進行表述是本章的敘述重點。因爲「企業」這一客觀對象很是複雜，它既包含實實在在的信息系統和基礎設施，又包括虛無縹緲的企業戰略、企業文化等方面，於是如何將這一既實又虛的對象描述出來的確不容易。此外，因爲企業中各個干係人的背景不一樣，於是其看問題的角度、深度和廣度也不盡相同，因此他們都傾向於採用本身認知範圍內的方式來對企業進行描述，而怎樣彌合這些不一樣就成爲了一個莫大的挑戰。爲了解決這些問題，企業架構描述語言應運而生，這其中就包括了諸如ArchiMate、ARIS（ARIS框架不僅僅是一種表述方式，它自己是一個被普遍使用的企業架構框架）等描述方式。本章的後面將針對ArchiMate進行詳細地描述。須要注意的是，使用企業架構描述語言所產生的企業架構描述只是企業架構內容的重要組成部分，而採用天然語言的描述內容是永遠不會被替代的，而且因爲企業架構的高層次抽象性，各類採用專門語言進行表述的詳細設計內容也永遠不會被替代。

      不管是採用架構描述語言仍是使用天然語言對企業進行建模，都是對企業這一客觀對象進行描述，從理論上講，只要描述得當針對企業進行無障礙的一致性溝通這一目標都可達成。不過兩種描述方式相比，企業架構描述語言更加「正式」，由於它採用統一的方式爲「企業」創建數學模型，而這正是將「企業」進行信息化的基礎，也爲各類分析方法提供了良好的鋪墊。

      創建企業架構模型並非最終目的，建而不用反而是最大的浪費，除了記錄企業架構真實狀況、描述目標狀態和過渡狀態、對實施和遷移過程進行指導，並在各干係人中對以上行爲產生共識和創建溝通基礎以外，在平常運營中，企業架構模型也能產生很是大的幫助，從而爲干係人的決策提供依據，而這就是基於企業架構模型的分析。在本章的最後一個部分，筆者將以採用ArchiMate語言所描述的企業架構模型爲基礎介紹一些分析方法。

1. ArchiMate的由來

      ArchiMate起源於本世紀初的荷蘭，是由荷蘭在信息技術領域的研究組織Telematica Instituut（2009年重組並重命名爲Novay）組建的開發團隊定製而成，而且其建設過程受到了荷蘭政府以及各工業和學院的支持和合做。這一建設過程開始於2002年7月，並於2004年12月截止，這期間消耗了35人年以及將近400萬歐元的資金。2008年，ArchiMate的主導權被轉移到了Open Group的手中。2009年2月，Open Group將ArchiMate 1.0版做爲正式的技術標準進行了發佈，而截止到目前最新的版本是2012年1月發佈的ArchiMate 2.0版。做爲最新的ArchiMate 2.0版，相對於1.0版本，Open Group不只在多個方面對原來的內容進行了修訂，並將ArchiMate與其手中的TOGAF標準進行了很好的整合，從而使ArchiMate不只僅能夠在企業的業務、信息系統（數據和應用）和技術層面進行描述，還經過了擴展對企業戰略和遷移與實現進行了描述，並與前面所說的三個層面相結合。下圖展現了ArchiMate 2.0版與TOGAF之間的契合關係：

      ArchiMate的基礎是IEEE 1471標準，該標準定義了一系列用於描述系統架構的基本概念元素以及他們之間的關係，從而爲系統的定義、分析和描述提供了堅實的理論基礎。IEEE 1471以民用建築爲類比來對軟件系統架構進行描述，在這一點上它與Zachman框架有着殊途同歸之妙，不過與之不一樣的是，IEEE 1471並非經過一系列固定的視角和視圖來對系統架構進行標準化，而是採用了架構描述實踐中可以被普遍接受的各類有價值的概念和關係：

 

2. ArchiMate建模詳述

      ArchiMate語言爲企業架構的描述提供了一種圖形化的表述方式，尤爲是在2.0版本發佈以後，ArchiMate具備了時間這一維度，從而使其能夠對企業隨着時間推移而演進的過程當中所涉及到的轉化和遷移狀況進行建模。做爲一種企業架構建模語言，ArchiMate所描述的範圍須要涵蓋企業的各個領域，並可以體現出各干係人的關注點，於是與各個領域的專用建模語言相比，ArchiMate具有以下特色：

• ArchiMate可以跨越企業中的各個領域，這至少包括業務、應用、數據和技術基礎設施層面。
• ArchiMate不只能對企業中的各個領域進行描述，還可將這些領域關聯在一塊兒，從而使得各干係人可以得到一個完整且完備的企業模型，而這也是業務與IT相校準（Business-IT Alignment）的重要基礎。當前各個企業和組織中都不乏採用了各個領域建模語言而進行描述的各類模型，因爲這些模型採用的描述方式不一樣，且每每採用多人分別負責的方式進行建模，因此這些模型很難在各個領域之間保持一致性（更況且每一個模型還有着因爲版本演進而帶來的不一致性問題），從而也沒法時時保證模型與客觀對象的一致性。雖然以UML 2.0爲表明的建模語言能夠涵蓋當前所可以遇到的全部領域，不過他們也仍是沒有可以徹底打通各個領域之間的描述壁壘，各個領域之間的模型依然是相對隔絕的。
• 因爲是企業架構建模語言，ArchiMate描述所採用的抽象層級和描述粒度應該是全局級別的，於是其描述不能像各領域的專用建模語言那樣詳細。不過在實踐過程當中，基於ArchiMate的擴展規則，ArchiMate也能夠對其描述粒度和抽象程度進行擴展，從而得到爲各干係人提供多抽象層次和描述粒度的企業架構。
• 雖然ArchiMate能夠被用來描述一個完整且完備的企業架構，但對於某一具體干係人來講，如此龐大且面面俱到的企業模型的確是過於繁雜了。因爲每一個干係人都有着本身的關注點和利益關係，於是其所在意的每每只是企業模型的某一個方面的內容，而爲了使各個干係人可以得到反映其關注點的企業模型的側面，ArchiMate經過定製各類典型的視角與視圖來對企業模型的建立和使用進行了概括。

2.1 ArchiMate語言基本結構

      ArchiMate語言的建設初衷並非要從新創建一種全新的建模語言，由於這樣作只會帶來新的學習挑戰，而且還會陷入到與其餘建模語言的競爭和兼容陷阱之中，於是從其開發初期開始，開發團隊就着眼於提供一套可以儘可能兼容和重用當前各領域中的建模語言元素的方式，而不是替代他們。而也正是由於這種指導思想，ArchiMate才得以可以將本來隔絕的各個建模領域聯繫起來。雖說起來簡單，但真要建設這樣一種語言實際上是一項巨大的挑戰，由於這語言須要在以下兩個層面獲取良好的平衡：

• 若是要兼容各領域的專有建模語言，最容易想到的方式就是對這些語言中的建模元素和關係進行抽象，從而得到個語言的共通之處，並以此來對企業架構進行描述。雖然這的確是一個兼容各方不一樣的辦法，可是因爲各領域建模方法的差別太大，抽象到最後的結果只能剩下「實體」和「關聯」這兩個基礎建模元素，而企業架構的領域特點則無從着落，於是ArchiMate的抽象層級也不能如此之高。
• 不管如何，ArchiMate的終極目標仍是要在各領域模型之間創建聯繫，於是其抽象層次又不能像各領域建模語言那樣事無鉅細，必要的抽象仍是須要的。

      所以，正如ArchiMate 2.0規範中圖示那樣，ArchiMate語言中的建模元素及其之間關係的定義層級應在上述兩個層次之間取得平衡：

      雖然ArchiMate語言跨越多個領域，其所包含的建模元素種類以及他們之間關係的種類也較爲繁雜，但綜合來說，ArchiMate語言的基本結構和特色可總結以下：

• ArchiMate的建模概念元素雖然種類繁多，但究其性質而言不外乎結構元素（Structure Element）和行爲元素（Behavior Element）兩種（也可稱爲靜態元素和動態元素），前者表明了各類結構化的實體（如參與者、應用組件以及數據等），然後者則用來描述結構化元素所能執行的各類行爲（如業務活動、應用功能以及服務等）。此外，根據與行爲元素之間的關係進一步劃分，結構元素又可被分爲主動性結構元素（Active Structure Element）和被動性結構元素（Passive Structure Element），前者表示發起動做的結構元素（例如參與者、應用組件等），然後者則被用來描述行爲元素的各類目標（例如業務數據、信息數據等）。因而可知，ArchiMate所使用的描述方式與不少標準化的描述方式（例如RDF語言）有着殊途同歸之妙，他們都符合人們平常所用的天然語言的「主-謂-賓」方式，亦即主動性結構元素類比於主語、行爲元素類比於謂語，而被動性結構元素類比於賓語。
• ArchiMate中的行爲元素還能夠從內與外兩個維度進行進一步區分，前者用於描述某種功能的內部實現方式，然後者則用於表述系統對於外界所能提供的（抑或外界須要系統可以提供）對外界具備價值且隱藏了內部實現的功能單元。經過借鑑面向服務架構（SOA）中的概念，ArchiMate用「服務（Service）」這一行爲概念元素來表明這種功能的外部表現形式，而對於用於實現服務的內部行爲元素則包括了業務流程、業務功能、應用功能等多種行爲概念元素。
• ArchiMate採用分層的方式對企業架構進行描述，這主要包括了（自上而下）業務、應用和技術三個層面。每一個層次中包含了該領域中的各類概念元素和他們之間的關係，而不一樣層面之間的關聯則是經過前面提到過的「服務」行爲元素來進行關聯，亦即上面層次（如業務層）中的概念元素使用下面層次（如應用層）中概念元素所實現並經過接口對外提供的服務。
• 因爲在實踐過程當中，一個行爲元素每每是由多個結構元素共同執行，而且這裏所說的「共同執行」並不只僅是將這些參與的架構元素的努力進行簡單地加合，而是有着更加複雜的「合做」意義。爲了對這種集合性質的情形進行描述，ArchiMate中引入了合做集合（Collaboration）和交互（Interaction）這兩個概念，前者是結構元素的特化，用於表述包含多個結構元素的協同集合，然後者則是行爲元素的特化，用於表述一個合做集合所執行的行爲。
• ArchiMate經過各類關係來聯接不一樣的概念元素，這些關係中的大多數來源於當前已經存在的建模語言中的關係。
• ArchiMate中相同種類的不一樣概念元素實例之間都有着默認的組合、聚合和特化關係。
• ArchiMate中定義的各類結構化關係都有着各自的優先級，而且由結構化關係間接相連的概念元素之間能夠等效爲一條直接的結構化鏈接，且此等效的直接鏈接將等同於這一系列實際關係鏈中具備最低優先級的關係鏈接。這一原則對於基於企業架構模型的定性分析（如影響分析）有着重要的意義。
• ArchiMate中對於大多數概念元素都定義了兩種表示圖符，在實際應用中能夠根據須要進行選擇。這符合ArchiMate的模型、視圖（反映某一視角的模型子集）與展示方式相分離的設計思想。通常來說，採用矩形輪廓的表示圖符給人感受更加正式，每每用在企業架構建設的中後期，或面對更加關注於實現細節干係人，而採用更加具備表現力的後者給讀者的感受不如前者正式，於是一般用在企業架構建設初期，或面對不太關注於細節的干係人以及面對大範圍的具備不一樣背景和關注點的干係人羣體。

      在本章的後面部分，筆者將以各領域層次爲單位對其中的概念元素進行詳細描述，對元素之間的關係進行集中闡述，並在最後對ArchiMate的擴展規則進行描述。這些內容來源於《ArchiMate 2.0 Specification》中第三至七章（對各領域中的建模概念元素和關係進行了定義和描述）和第九章（ArchiMate擴展規則），筆者以這些章節中關於建模概念元素的定義、表示圖符和示例爲藍本，以我的理解爲出發點對其進行了翻譯和適當修改（如業務接口的示例與規範中的對應示例就略有不一樣，筆者根據我的理解對其進行了適當的修改）。

 

2.2 業務層模型元素

      業務層模型元素包括了業務領域中的各類概念元素以及他們之間的關係，除此以外還包括了一些與業務領域相關的信息概念（Informational Concept）元素：產品、與產品關聯的合同、業務對象的意義，以及產品或業務服務的價值。這些概念元素及其之間的主要關係以下圖所示：

 

2.2.1 結構元素

2.2.1.1 業務參與者（Business Actor）

• 定義：業務參與者被定義爲可以執行某種行爲的組織單元。與各類技術實體不一樣，業務參與者是業務領域的概念，他包括了實際企業內外的各類組織單元，例如人員、部門、客戶以及第三方合做者等。一個業務參與者能夠被指派擔當一個或多個業務角色。
• 表示圖符：

• 實例：某保險公司被建模爲包含了「行李保險部」和「旅遊保險部」兩個部門，其中旅遊保險部在「獲取旅遊保險」這一業務流程中擔當了「旅遊保險銷售」的角色。「獲取旅遊保險」業務流程對外提供了「提供旅遊保險」服務，而這一服務被公司的「客戶」這一業務參與者而使用。

 

2.2.1.2 業務角色（Business Role）

• 定義：可以賦予業務參與者的執行某一特定行爲的責任。業務角色所涉及到的主要關係可概括爲：
• 一個業務角色能夠被指派給一個或多個業務流程或業務功能。
• 一個業務角色能夠被分配給一個業務參與者。
• 一個業務接口或應用接口能夠被一個業務角色所使用。
• 一個業務接口能夠經過組合關係而做爲一個業務角色的一個組成部分。
• 表示圖符：

• 實例：「旅遊保險部」在這一案例中充當了「旅遊保險銷售」這一角色，而且此角色經過一個「電話」業務接口來對外提供服務。「客戶」在此案例中充當了「保險購買者」角色，而且此角色具備一個「電話」接口來表示此角色對外須要經過一個「電話」業務接口來獲取服務。

 

2.2.1.3 業務合做集合（Business Collaboration）

• 定義：兩個或兩個以上共同執行某種協做和交互的角色的集合。業務合做集合所涉及到的主要關係可概括爲：
• 業務合做集合包括多個業務角色。
• 業務合做集合能夠被指派給一個或多個業務交互。
• 業務合做集合可使用業務接口或應用接口。
• 業務合做集合能夠經過組合關係而具備業務接口。
• 表示圖符：

• 實例：今後案例能夠看出，銷售一個保險產品（例如行李保險）須要「行李保險銷售者」和「銷售支持者」這兩個角色共同協做而成。

 

2.2.1.4 業務接口（Business Interface）

• 定義：外部環境獲取業務服務的訪問點。業務接口能夠分爲提供性接口和需求性接口兩種，前者表示結構元素對外經過何種接口提供服務，然後者則用來表述結構元素須要何種接口來獲取服務。業務接口所涉及到的主要關係可概括爲：
• 業務接口能夠經過組合關係成爲業務角色的一個組成部分。
• 業務角色可使用業務接口。
• 業務接口能夠被分配給一個或多個業務服務，即業務服務能夠經過分配到其上的業務接口而獲得。
• 表示圖符：右邊的兩個圖符中：位於左邊的圖符用於表述提供性接口，而位於右邊的則用來表示需求性接口。

• 實例：此案例中「聯合保險銷售服務」和「行李保險銷售服務」這兩個業務服務分別被分配到業務接口「呼叫中心」和「Web表單」之上，並被「客戶」所使用。

 

2.2.1.5 位置（Location）

• 定義：表明空間上的一個點或範圍。位置所涉及到的主要關係可概括爲：
• 位置概念元素能夠經過分配關係指派到結構元素之上，用以表述結構元素所處的空間位置。
• 因爲結構元素與行爲元素相互關聯，於是位置概念元素也能夠間接的關聯到行爲元素之上用以表述行爲發生的空間位置。
• 表示圖符：

• 實例：保險公司的各個部門分佈在不一樣的位置，其中法律部和財務部位於總公司，而索賠處理部則位於本地辦事處之中。

 

2.2.1.6 業務對象（Business Object）

• 定義：表明從業務的視角來進行考慮的重要的信息化或概念化的元素，屬於被動性概念元素。業務對象所涉及到的主要關係可概括爲：
• 業務對象可被業務流程、業務功能、業務交互、業務事件或業務服務所訪問。
• 不一樣的業務對象之間能夠具備關聯、特化、組合及聚合關係。
• 業務對象能夠由表達方式或數據對象所實現（或由二者共同實現）。
• 表示圖符：

• 實例：業務流程「建立發票」在收到事件「請求發票」後建立了「發票項」和「發票」這兩個業務對象，其中「發票」業務對象聚合了若干「發票項」對象。隨後「發送發票」業務流程對「發票」業務對象進行讀取，並執行後面的發送行爲。今後案例中咱們還能夠看出，「發票」這一業務對象包含了兩種具體實現，其中一個是「電子發票」這一數據對象，另一個是「紙質發票」這一表現形式。

 

2.2.2 行爲元素

2.2.2.1 業務流程（Business Process）

• 定義：業務元素被定義爲一種基於活動順序來對各類行爲進行組織的行爲概念元素，其目的在於產生一系列通過定義的產品或業務服務。與爲外界提供有意義的行爲的業務服務不一樣，一個業務流程描述了由某業務角色執行的內部行爲，於是對於外界來說，業務流程只是一隻「黑盒子」。在ArchiMate中雖然對業務流程進行了定義，不過它並不能對其進行詳細定義，用戶能夠經過使用諸如BPMN這樣的流程建模語言對其ArchiMate中的流程定義進行擴展。業務流程所涉及到的主要關係可概括爲：
• 業務流程和業務功能之間具備潛在的多對多關係。
• 業務流程能夠被其餘行爲元素（例如業務事件、業務流程、業務功能或業務交互）所觸發，也能夠觸發其餘行爲元素。
• 業務流程能夠訪問業務對象。
• 業務流程能夠實現一個或多個業務服務。
• 業務流程可使用其餘的一個或多個業務服務和應用服務。
• 業務角色或應用組件能夠被指派給業務流程，分別用以表示該業務流程是人工流程或自動化流程。
• 表示圖符：

• 實例：在此案例中，「處理保險申請」業務流程包含了三個子流程，而且當「保險申請」這一業務事件發生後，這三個子流程將依次進行。「處理保險申請」被指派給「保險銷售人」這一業務角色，即由其負責該內部行爲的實施。有兩個業務接口（「電話」和「Web」）被分配給了「保險銷售人」，於是他將經過這兩個接口來對外提供「處理保險服務」這一業務服務，而且此業務服務的內部實現就是「處理保險申請」這一業務流程。

 

2.2.2.2 業務功能（Business Function）

• 定義：業務功能被定義爲一種根據某選定標準來對各類行爲進行組織的行爲概念元素。與業務流程同樣，業務功能也被用來描述某角色的內部實現行爲，而且也被用來對各類行爲元素進行組織。而與之不一樣的是，業務流程將爲了實現業務服務或產品而須要的各行爲的發生時序做爲組織原則，而業務功能對行爲元素的組織方式卻更加多樣化，例如根據行爲所需的資源、技能或競爭力等方面。業務流程所涉及到的主要關係可概括爲：
• 業務功能和業務流程之間具備潛在的多對多關係。
• 業務功能能夠被其餘行爲元素（例如業務事件、業務流程、業務功能或業務交互）所觸發，也能夠觸發其餘行爲元素。
• 業務功能能夠訪問業務對象。
• 業務功能能夠實現一個或多個業務服務。
• 業務功能可使用其餘的一個或多個業務服務和應用服務。
• 業務角色或應用組件能夠被指派給業務功能。
• 表示圖符：

• 實例：在此案例中，不一樣的業務流程元素按照其所使用的信息資源被分配到三個業務功能之中，其中「顧客接待」業務功能包括「接受保險申請」和「提交索賠」兩個業務流程，並且此業務功能須要讀取「客戶信息」這一業務對象，即其中的兩個業務流程均須要對此業務對象進行訪問；「基本管理」業務功能包括了「處理申請」業務流程；「財務處理」業務功能包括了「收取保費」業務流程，而且此業務功能使用了由「金融支持系統」應用組件所實現的「計費服務」這一應用服務，這表示「收取保費」業務流程中使用了「計費服務」這一應用服務才得以實現「保費收取服務」這一業務服務。

 

2.2.2.3 業務交互（Business Interaction）

 

• 定義：用於描述業務合做集合的行爲，即處在業務合做集合中的各個業務角色將對業務交互所表述的行爲共同負責。業務交互所涉及到的主要關係可概括爲：
• 業務交互能夠被其餘行爲元素（例如業務事件、業務流程、業務功能或業務交互）所觸發，也能夠觸發其餘行爲元素。
• 業務交互能夠訪問業務對象。
• 業務交互能夠實現一個或多個業務服務。
• 業務交互可使用其餘的一個或多個業務服務和應用服務。
• 一個業務合做組合或應用合做組合能夠被指派給一個業務交互。
• 表示圖符：

• 實例：在此案例中由「旅遊保險銷售者」和「行李保險銷售者」這兩個業務角色組成了「聯合保險銷售」這一業務合做集合，而且該合做集合負責執行「處理聯合保險」這一業務交互，同時該業務交互對外提供了「聯合保險銷售服務」這一業務服務，並在交互過程當中對「政策信息」業務對象進行了訪問。

 

2.2.2.4 業務事件（Business Event）

• 定義：業務事件表明了企業或系統內外所發生的瞬時的並對其餘行爲元素具備影響的事物。業務事件所涉及到的主要關係可概括爲：
• 業務流程、業務功能或業務交互能夠產生業務事件。
• 業務事件能夠觸發業務流程、業務功能或業務交互。
• 業務事件能夠對業務對象進行訪問。
• 業務事件能夠包含其餘業務事件。
• 表示圖符：

• 實例：在此案例中，「保險申請」業務事件觸發了「接受保險申請」這一業務流程，而爲了使客戶可以更加了解保險公司的產品從而購買更多的保險產品，在「接受保險申請」業務流程以後觸發了「發送產品組合」這一業務事件，然後者接着啓動了「爲客戶發送產品組合」這一業務流程。此外，「保險申請」和「發送產品組合」這兩個業務事件對於「客戶信息」業務對象均有訪問，前者修改對客戶信息進行了修改（例如，記錄客戶這次所申請的保險產品信息），然後者則對此業務對象進行讀取。

 

2.2.2.5 業務服務（Business Service）

• 定義：表明了用於實現組織內外客戶需求的服務。業務服務將業務角色或業務合做集合的功能提供給外界，而且對於這些功能的訪問須要經過各類業務接口，而這些功能的實現則是由各業務角色或業務合做集合所執行的一個或多個業務流程、業務功能或業務協做來落實。因爲業務服務的客戶存在於組織內外，於是其既包含了面向外部客戶的服務，也包括了對於內部客戶的支持性服務。業務服務所涉及到的主要關係可概括爲：
• 因爲業務服務須要對外界環境具備價值，於是業務服務概念元素須要關聯價值概念元素。
• 業務服務能夠被業務流程、業務功能和業務交互所使用。
• 業務流程、業務功能和業務交互能夠實現業務服務。
• 業務接口或應用接口能夠被指派給業務服務，用於表示業務服務的訪問方式。
• 業務服務能夠訪問業務對象。
• 表示圖符：

• 實例：在此案例中，「基本管理」業務功能提供了兩個支持性內部服務：「客戶信息處理」和「客戶保險檢索」。這兩個內部業務服務均被業務流程「處理旅遊保險」和「處理行李保險」所分別使用，而且這兩個業務流程分別對組織外部客戶提供了兩個外部業務服務：「旅遊保險銷售服務」和「行李保險銷售服務」。這兩個外部業務服務組合而成「保險銷售服務」，而且處於組織外部的「保險購買者」業務角色能夠經過「電話」這一業務接口從「保險銷售人」角色那裏訪問到這一業務服務。因爲業務服務須要對外界具備價值，這表如今本案例中便是：「保險銷售服務」對其使用者「保險購買者」業務角色應具備價值，而這一價值則被「受保」這一價值概念元素所表示，即對於使用「保險銷售服務」的「保險購買者」來講，該業務服務可以使其處於「受保」的狀態之下。

 

2.2.3 信息元素

      業務結構元素和行爲元素中所包含的種種概念元素關注於描述企業的運行方面，而與之相比，業務信息元素則站在「主觀意識」的角度對上述兩種元素進行進一步的闡述。例如，對於業務服務來講，除了要從企業的運行層面來描述實現和負責業務服務的各個元素，咱們還須要闡述業務服務對其外部環境的意義和價值。由此咱們也能夠看出，信息元素是一條將企業的業務目標和產品與其運行方面關聯起來的路徑。

2.2.3.1 表現方式（Representation）

• 定義：用於表示業務對象所具有的信息的認知形式。一個業務對象能夠同時具有多種認知形式，而且這些認知形式能夠按照其特性被分爲多個種類。例如，從信息載體方面區分能夠包括電子、紙質等，而從信息格式方面又能夠包含HTML、XML等。表現方式所涉及到的主要關係可概括爲：
• 一個表現方式能夠實現一個或多個業務對象。
• 一個業務對象能夠由一個或多個表現方式所實現。
• 一個意義元素能夠關聯一個表現方式，用以表示該表現方式具有某種意義。
• 表示圖符：

• 實例：在此案例中，「接受保險申請」業務流程所讀取的「申請」這一業務對象在物理層面上是由「申請表單」所實現的；「收取保費」這一業務流程所產生的「單據」業務對象則表現爲實際中的「紙質帳單」。

 

2.2.3.2 含義（Meaning）

• 定義：用於表示在特定上下文環境中業務對象或其表現方式所具備的知識或專業含義。表現方式所涉及到的主要關係可概括爲：
• 含義元素能夠關聯到業務對象之上。
• 含義元素能夠關聯到業務對象的表現方式之上。
• 表示圖符：

• 實例：在此案例中，「保險政策」業務對象表現爲「保險政策文檔」，而與此文檔相關的含義是「保險政策通知」，而且該含義元素還包括了「覆蓋範圍描述」、「政策解讀」和「保險登記」這三個含義，他們組織在一塊兒闡述了「保險政策文檔」的「主觀意圖」。

 

2.2.3.3 價值（Value）

• 定義：用於表示業務服務或產品的相對價值、用途或重要性。價值所涉及到的主要關係可概括爲：
• 價值元素能夠關聯到業務服務之上，並由此間接關聯到包含該業務服務的產品以及使用該服務的業務角色和業務參與者之上。
• 價值元素能夠關聯到產品之上。
• 表示圖符：

• 實例：今後案例中咱們能夠看到：「保險銷售服務」能夠對外提供「受保」這一價值，而此價值還能夠進一步細分爲 「保護免受損失」、「下降風險」和「安全性」這三個更加具體的價值。

 

2.2.3.4 產品（Product）

• 定義：一個產品被定義爲具有一份合同或協議的一系列服務的組合，而且這些內容將被做爲一個總體提供給內部或外部的客戶。這一針對產品的定義主要是針對金融的、基於服務的或信息化的產品，而不是物理化產品，於是對於信息密集型企業來說是適用的。產品所涉及到的主要關係可概括爲：
• 產品能夠聚合業務服務和/或應用服務，以及一個合同元素。
• 價值元素能夠關聯到產品元素之上。
• 表示圖符：

• 實例：在此案例中，某銀行爲其客戶提供了「電話銀行」產品，該產品包括了由客戶關係部門實現的「開戶」和「應用支持」這兩個業務服務，以及一個由「電話銀行應用」這一應用組件所實現的名爲「銀行服務」的業務服務（該服務使用了「帳戶狀態查詢服務」和「匯款服務」這兩個應用服務，而他們均由「電話銀行應用」實現）。

 

2.2.3.5 合同（Contract）

• 定義：合同被定義爲一份關於雙方協議的正式或非正式的規範說明，他描述了與產品相關的各項權利和義務。合同元素既能夠表述具備法律意義的合同，也能夠描述與產品相關的非正式協議。合同元素是業務對象的一個特化，他繼承了業務對象的各類屬性和關係。合同所涉及到的主要關係可概括爲：
• 業務對象能夠具有的關係均可以應用在合同元素之上。
• 產品元素能夠聚合合同元素。
• 表示圖符：

• 實例：在此案例中，「電話銀行」產品包含了「電話銀行合同」，而且此合同還包括了「服務條件」和「服務水平協議」這兩個子合同。

 

2.3 應用層模型元素

      應用層模型元素包括了企業在應用層面的各類概念元素以及他們之間的關係。因爲該層次的目標是描述企業中的各類信息/軟件系統，因此這其中大部分概念元素都來源於UML 2.0，由於在這一領域中UML 2.0無疑是受衆最廣的事實標準。在ArchiMate 2.0中，對企業應用層進行建模的各類概念元素以及他們之間的主要關係（元模型）被定義以下：

 

 

2.3.1 結構元素

2.3.1.1 應用組件（Application Component）

• 定義：用於表示一個模塊化、可部署且可替代的軟件系統的一個組成部分，他對軟件系統的行爲和數據進行了封裝，並經過接口對外提供被封裝的內容。因而可知，應用組件是一個自包含的功能單元，雖然被定義爲軟件系統的一個組成部分，但此概念元素也能夠被用來對一個完整的軟件應用、子軟件應用或信息系統進行建模。應用組件所涉及到的主要關係可概括爲：
• 一個應用組件能夠被指派給一個或多個應用功能、業務流程或業務功能。
• 一個應用組件能夠具備一個或多個應用接口。
• 應用組件可使用其餘應用組件的接口。
• 表示圖符：

• 實例：在此案例中，「金融應用」軟件被建模爲一個應用組件，他包含了兩個子應用組件，分別爲「財務組件」和「計費組件」，而且前者對外提供了「財務服務」這一應用服務，然後者則提供了「計費服務」。這兩個應用服務可經過一個名爲「財務及計費接口」的共享應用接口來進行訪問，而此應用接口也是「金融應用」軟件的一個組成部分。

 

 

2.3.1.2 應用合做集合（Application Collaboration）

• 定義：兩個或兩個以上共同執行某種行爲的應用組件的集合。應用合做集合一般用來對邏輯的或臨時性的應用組件組合進行建模，在實際中並不做爲一個獨立的實體而存在。應用合做集合是應用組件的特化，於是他自己也是一個主動性的結構元素，其所涉及的主要關係可概括爲：
• 一個應用合做集合能夠被分配給一個或多個應用交互或業務交互之上。
• 應用合做集合可使用應用接口。
• 應用合做集合能夠包含應用接口。
• 表示圖符：

• 實例：在此案例中，「財務組件」和「計費組件」這兩個應用組件組成了「交易管理」這一應用合做集合，並參與到了名爲「交易管理」的應用交互之中。

 

2.3.1.3 應用接口（Application Interface）

• 定義：應用接口被定義爲應用服務的訪問點，用戶或其餘應用組件能夠經過應用接口來獲取各應用服務。應用接口具備方向性，他定義了應用組件功能如何可以被外界獲取，或應用組件須要從外界環境獲取什麼樣的功能。應用接口所涉及到的主要關係可概括爲：
• 一個應用接口能夠做爲一個應用組件的組成部分（經過組合關係）。
• 應用組件可使用其餘組件的應用接口。
• 應用接口能夠被分配到一個或多個應用服務或業務服務之上，用於表示外界能夠經過該應用接口獲取這些服務。而且，相同的服務（應用服務或業務服務）也能夠被分配到不一樣的應用接口之上。
• 表示圖符：與業務接口相似，因爲應用接口也有着方向性，於是其圖符有着兩種表現形式。如下圖爲例，在處於右邊的兩個圖符中，左手邊的圖符表示應用接口將功能提供給外界，然後手邊的圖符則表示應用接口須要從外界獲取何種功能。

• 實例：在此案例中，「財務組件」對外提供了「交易數據交換」應用接口，而這正是「計費組件」所須要的，於是在這兩個應用組件的應用接口之間有着使用和被使用的關係。

 

2.3.1.4 數據對象（Data Object）

• 定義：用於表示適合於自動化處理的被動性結構元素。數據對象應該是一份自包含的信息體，而且對於業務領域應該具備清晰的含義，而不是僅僅侷限於應用層面。數據對象所涉及到的主要關係能夠概括爲：
• 應用功能、應用交互或應用服務能夠訪問數據對象。
• 數據對象能夠實現業務對象。
• 數據對象能夠被製品（技術層模型元素之一）所實現。
• 數據對象之間能夠具備關聯、繼承、聚合及組合關係。
• 表示圖符：

• 實例：在此案例中，「計費」業務功能使用了由「財務」業務功能所提供的「交易處理」應用服務，而在此應用服務執行過程當中，名爲「交易數據」的數據對象被用來進行信息交換。

 

2.3.2 行爲元素

2.3.2.1 應用功能（Application Function）

• 用於對應用組件所執行的各自動化行爲進行組織的行爲元素。應用功能描述了應用組件的內部功能，而這些功能須要經過應用接口提供給外界。應用功能所涉及到的主要關係能夠概括爲：
• 一個應用功能能夠實現一個或多個應用服務。
• 應用功能可使用由其餘應用組件實現的應用服務或位於技術層的基礎設施服務。
• 應用功能能夠訪問數據對象。
• 應用功能能夠被分配給應用組件，用以表示該應用組件執行了此應用功能。
• 表示圖符：

• 實例：在本案例中，名爲「財務應用」的應用組件的行爲被建模爲「財務管理功能」這一業務功能，而此業務功能包含「財務功能」和「計費功能」這兩個子應用功能，而且前者對外提供了「顯示帳戶狀態」應用服務，然後者則提供了「建立單據」和「發送單據」這兩個應用服務。

 

2.3.2.2 應用交互（Application Interaction）

• 定義：用於描述應用合做集合行爲的行爲元素。應用交互所涉及到的主要關係能夠概括爲：
• 一個應用合做集合能夠被指派給一個應用交互。
• 應用交互能夠實現應用服務。
• 應用交互可使用應用服務或位於技術層的基礎設施服務。
• 應用交互能夠訪問數據對象。
• 表示圖符：

• 見「應用合做集合示例」。

 

2.3.2.3 應用服務（Application Service）

• 定義：對外提供自動化行爲的服務。站在外部環境的角度來看，應用服務必須對外界具備意義，即他必須對他的用戶提供有價值的功能。對於企業來講，其外部環境總離不來業務層面，於是應用服務也應該是業務相關的。應用服務所涉及到的主要關係可概括爲：
• 應用服務能夠被業務流程、業務功能、業務交互或應用功能所使用。
• 應用功能或應用交互能夠實現應用服務。
• 應用接口能夠被指派給應用服務。
• 應用服務能夠訪問數據對象。
• 表示圖符：

實例：在本案例中，名爲「財務組件」的應用組件具備「財務功能」這一應用功能，且此應用功能對外提供了名爲「交易處理服務」的應用服務。「交易處理」應用服務被指派給「交易處理接口」這一應用接口，而此應用接口屬於「財務組件」，即對於「交易處理服務」的訪問須要經過「交易處理接口」；與之類似，「計費組件」、「計費功能」、「單據建立服務」和「單據界面」之間也具備同樣的關聯；在上述兩組內容之間，「計費功能」使用着「交易處理服務」，而這一「使用」關係也體如今「計費組件」對做爲「財務組件」組成部分的「交易處理接口」使用之上。