企業架構研究總結（42）——企業架構與建模之ArchiMate詳述（中）

2.4 技術層模型元素

      技術層模型元素包括了企業在信息基礎設施方面（企業中基本的軟硬件環境，包括物理設備、系統軟件等為信息化提供基本支持的設施）的各種概念元素，以及他們之間的關系。與應用層模型元素相類似，技術層模型元素中的大部分概念元素也來源於UML 2.0，這同樣也是因為UML 2.0在這一領域已經成為被廣泛接受的事實標准。在ArchiMate 2.0中，對企業技術層進行建模的各種概念元素以及他們之間的主要關系（元模型）被定義如下：

 

2.4.1 結構元素

2.4.1.1 節點（Node）

• 定義：用於表示存儲或部署執行各種制品的計算資源的主動性概念元素。這一概念與UML 2.0中的節點概念是相同的，是構成技術層結構方面的基本單元，也是此領域建模中的核心元素。節點可以用來對應用服務器、數據服務器或客戶工作站來進行建模，概括來講，其所描述的內容是組合了硬件資源以及系統軟件並對外提供計算資源的邏輯單元。節點所涉及到的主要關系可歸納為：
• 節點元素之間通過通信路徑進行互聯。
• 制品可以被分配給節點，用於表示該制品被存儲或部署在此節點之上。
• 表示圖符：

• 實例：在本案例中，“應用服務器”節點包含了“刀片服務器設備”這一硬件資源，以及“J2EE服務器”這一系統軟件資源。

 

2.4.1.2 設備（Device）

• 定義：用於表示存儲或部署執行各種制品的硬件資源。設備概念元素是節點元素的特化，他代表了具有處理能力的各種物理資源，例如大型機、個人計算機或路由器等。設備所涉及到的主要關系可歸納為：
• 設備可以組合或聚合其他的子設備。
• 設備之間通過網絡進行互聯。
• 制品可以被分配給設備，用以表示制品被存儲或部署到此設備之上。
• 系統軟件可以被分配給設備，用以表示系統軟件的安裝或部署位置。
• 一個節點可以包含一個或多個設備。
• 表示圖符：

• 實例：本案例展示了三種設備，分別為：“前台應用服務器”、“后台應用服務器”和“Web服務器”，並且他們之間通過“局域網”這一網絡概念元素進行互聯。

 

2.4.1.3 系統軟件（System Software）

• 定義：用於表示一種軟件環境，使得各種特定類型的軟件組件和對象能以制品的形式部署於其中。系統軟件概念元素也是節點的特化，專門用於對各種制品所處的軟件環境進行建模。系統軟件和設備通常組合在一起來形成一個節點。系統軟件所涉及到的主要關系可歸納為：
• 系統軟件可被分配給設備。
• 制品可被分配給系統軟件。
• 節點可以組合或聚合系統軟件。
• 表示圖符：

• 實例：在本案例中，“大型機”這一設備之上部署了兩個系統軟件，他們分別是：“客戶交易服務器”和“數據庫管理系統”。

 

2.4.1.4 基礎設施接口（Infrastructure Interface）

• 定義：表示用於獲取由節點提供的基礎設施服務訪問點。與前面介紹過的接口概念相仿，基礎設施接口也具有雙向性，一個用於表示節點通過此基礎設施接口對外提供服務，另外一個則用於表示節點需要從外界獲取何種基礎設施服務。不同的基礎設施接口可以提供相同的基礎設施服務。基礎設施接口所涉及到的主要關系可歸納為：
• 基礎設施接口可以通過組合關系而作為節點的一個組成部分。
• 基礎設施接口可以被其他節點所使用。
• 基礎設施服務可以被分配給基礎設施接口，用於表示該服務是通過此接口而被提供給外界環境的。
• 表示圖符：

• 實例：在本案例中，名為“數據庫管理系統”的系統軟件具有“數據訪問接口”這一基礎設施接口，因而外界對數據的操作都可以通過此接口來實現。

 

2.4.1.5 網絡（Network）

• 定義：用於表示在兩個或兩個以上設備之間進行通信的媒介，同時它也是不同節點之間各種通信路徑的物理實現。網絡元素一般具有諸如帶寬、延遲之類的屬性。網絡所涉及到的主要關系可歸納為：
• 網絡連接兩個或兩個以上的設備。
• 網絡實現了一個或多個通信路徑。
• 網絡可以包含其他子網絡。
• 表示圖符：

• 實例：在本案例中，“大型機”和“終端機”這兩台設備之間通過帶寬為100Mbits/s的局域網進行互聯。

 

2.4.1.6 通信路徑（Communication Path）

• 定義：用於表示多個節點之間的邏輯連接，並且通過這些鏈接節點才可以進行節點之間的數據交換。通信路徑所涉及到的主要關系可歸納為：
• 通信路徑連接兩個或兩個以上的節點。
• 一條通信路徑可由一個或多個網絡所實現。
• 表示圖符：

• 實例：在本案例中，節點“應用服務器”和節點“客戶端”之間通過“消息隊列”這一通信路徑進行數據交互。

 

2.4.2 行為元素

2.4.2.1 基礎設施功能（Infrastructure Function）

• 定義：用於對節點所執行的基礎設施行為進行組織的行為元素，他描述了節點的內部功能。基礎設施功能所涉及到的主要關系可歸納為：
• 基礎設施功能可以實現基礎設施服務。
• 基礎設施功能可以使用由其他基礎設施功能所實現的基礎設施服務。
• 基礎設施功能可以訪問制品。
• 基礎設施功能可被分配給節點，用於表示該節點所能夠執行的行為。
• 表示圖符：

• 實例：在本案例中，“數據庫管理系統”節點具有（需要注意是，這里雖然采用嵌套的表述方式，但節點與基礎設施功能之間是通過指派關系來聯系的）“提供數據訪問功能”和“管理數據功能”這兩個基礎設施功能，並且前者實現了名為“數據訪問服務”的基礎設施服務，而后者則實現了“數據管理服務”。

 

2.4.2.2 基礎設施服務（Infrastructure Service）

• 定義：用於表示由一個或多個節點通過基礎設施接口對外提供的對外界具有意義的功能單元。基礎設施服務所涉及到的主要關系可歸納為：
• 基礎設施服務可以被應用組件或節點所使用。
• 基礎設施服務可以被節點所實現。
• 基礎設施服務可以被基礎設施功能所實現。
• 基礎設施服務可以被分配到基礎設施接口之上。
• 基礎設施服務可以訪問制品。
• 表示圖符：

• 實例：在本案例中，“面向消息中間件”系統軟件實現了“消息服務”這一基礎設施服務。

 

2.4.3 信息元素

2.4.3.1 制品（Artifact）

• 定義：用於表示在軟件開發過程或系統的部署和運行過程中使用和產生的數據的物理表現。制品通常被用來描述諸如源文件、可執行文件、腳本、數據庫表、消息、文檔、規范說明，以及模型文件這樣的軟件產品。制品所涉及到的主要關系可歸納為：
• 一個應用組件或系統軟件可以被一個或多個制品所實現，即可執行組件類型的制品。
• 一個數據對象可以被一個或多個制品所實現，即數據文件類型的制品。
• 制品可以被分配到節點之上，用於表示該制品被部署到此節點之上。
• 表示圖符：

• 實例：在本案例中，“風險管理EJB”這一制品被指派給（部署到）了系統軟件“J2EE應用服務器”之上，而這其中“風險管理EJB”代表了一個可部署的代碼單元。

 

2.5 模型元素擴展——動機

      動機模型元素擴展是ArchiMate 2.0版本中依照ArchiMate擴展規則而新加入的內容。ArchiMate之前的版本從操作角度對企業的運行情況進行了描述和建模，但這些內容並不能說明采用當前方式進行建模的緣由。缺失了如此重要的一環，我們無法回答建模的合理性，因而更無法促使企業的戰略目標與戰術實現相協調。通過結合TOGAF標准，我們可以看出：這些缺失的內容實際上就是TOGAF中“預備階段”、“架構願景階段”、“架構變更階段”，以及充當各階段運行引擎的“需求管理階段”所要建立或維護的核心。為了填補這一空白，ArchiMate 2.0引入了新的概念元素、關系和視角。本章將詳細描述其新加入的概念元素，而對於新加入的關系和視角將分別在后面的部分中進行描述。ArchiMate 2.0對於動機擴展所引入的新概念元素，以及他們之間的主要關系歸納如下：

      由於動機擴展的目標是解釋為何建模，以及建模與具體原因之間的關系，因而動機擴展中新加入的概念元素都是用來敘述緣由的描述性概念，他們既不具備結構化的實體，亦不會執行什么樣的“行為”，同時在意義上還有着“信息元素”的影子，並且從上面的元模型圖示中我們可以看到，動機元素（Motivational Element）並不繼承於結構元素（Structure Element），所以不同於業務、應用和技術層面中對概念元素所采用的“結構元素”、“行為元素”和“信息元素”分類歸納方法，在ArchiMate中，動機擴展的概念元素被統一概括為“動機概念元素（Motivational Concepts）”。

 

 

 

2.5.1 動機概念元素

      動機概念元素對企業架構建設的緣由進行了描述，並將這些元素與前面所說的企業三層領域建模元素聯系了起來。從比較高的抽象層次來看，動機概念元素包括 “干系人（Stakeholder）”和“動機元素（Motivational Element）”這兩個概念元素，他們之間的關聯關系體現了：建立企業架構的每個動機都應該反映某干系人的意圖。如果把抽象層次降低，我們會發現“動機元素”被特化成了六個更為具體的“動機”概念，他們分別是：“驅動力（Driver）”、“評估（Assessment）”、“目標（Goal）”、“原則（Principle）”、“需求（Requirement）”和“約束（Constraint）”。這六個概念元素以及他們之間的關系以一種從抽象到具體的順序描述了建立企業架構的緣由：

• “驅動力”描述了企業架構建立的根本緣由，他既可以是由於外部環境的變化而引起，也可能是源自企業內部，而這種內部驅動力往往也反映了某個干系人的關注點，因而該元素通常與一個“干系人”元素相關聯。
• 要想將“驅動力”做進一步的落實，企業需要對其進行分析和評估，而這正是“評估”概念元素所描述的目標。
• “驅動力”經過評估后，企業可由此分析出企業的優勢、弱點、機會和風險，而這些內容可以轉化為各個具體的企業戰略“目標”。
• 為了將確立后的“目標”付諸實現，企業需要將其細化為若干“原則”和“需求”。這兩者均是為了實現“目標”而建，但“原則”具有更加廣闊的范圍，它是在一定上下文環境之下針對若干具體需求共性的抽象，所以在元模型中我們可以發現：“需求”實現了“目標”，同時也實現了“原則”，而“需求”和“原則”都是為了實現“目標”而生的。
• “需求”不僅僅是對需要做什么所進行的描述，還可能是對不能做什么而進行的界定。對於后一種情況，ArchiMate采用特化了的“需求”概念元素，亦即“約束”概念元素，來進行描述。

      動機概念元素並不是一套密閉的元模型，況且ArchiMate建模基本原則也不允許這種領域隔離的情況存在，因而他與前述三個領域有着緊密的關系。在后面的跨領域關聯章節中，筆者將會對此進行更加詳細的闡述。

2.5.1.1 干系人（Stakeholder）

• 定義：用於代表對於架構產生的結果具有利益關系，或對其進行關注的個人、團隊或組織的類別。干系人涉及到的主要關系可歸納為：
• 干系人之間通過聚合關系來表現他們之間的組織結構。
• 干系人與其他動機概念元素之間通過關聯關系來表示對其他各種動機概念具有的利益關系或關注點。
• 表示圖符：

• 實例：在本案例中，名為“董事會”的干系人包含了三個子干系人，分別是：“CEO”、“CIO”和“CFO”。

 

2.5.1.2 驅動力（Driver）

• 定義：用於表示引起或驅動組織發生變化的事物。驅動力涉及到的主要關系可歸納為：
• 來源於組織內部的驅動力需要通過關聯干系人來表示其具體來源，以及涉及到了誰的利益和關注。
• 驅動力之間可以通過聚合關系來表示其層級結構。
• 驅動力和評估之間通過關聯關系來描述評估所對應的驅動力。
• 驅動力和目標之間通過關聯關系來描述兩者之間的相關性。
• 表示圖符：

• 實例：在本案例中，“經濟環境變化”是一個外部驅動力，而“股東滿意”和“客戶滿意”則是兩個內部驅動力，因而他們有相關干系人與之關聯。“客戶滿意”這一內部驅動力涉及到了干系人“CEO”和“客戶”的利益和關注，而“股東滿意”這一內部驅動力僅與干系人“CEO”相關。驅動力“股東滿意”還包含了兩個子驅動力，分別為“股價”和“利潤”，而且前者受外部驅動力“經濟環境變化”所影響（兩者之間通過“影響”關系相連，這是動機擴展新加入的關系，在后面章節將會對其進行詳細描述）。

 

2.5.1.3 評估（Assessment）

• 定義：用於表示對於驅動力進行分析的結果。針對驅動力進行分析而獲取的評估將會揭示企業的優勢、缺陷、機會和風險，而這些內容將會直接引起現有目標的變化或新目標的設立，並觸及到企業架構的變化。評估涉及到的主要關系可歸納為：
• 評估可以與一個或多個驅動力進行關聯，而一個驅動力亦可以關聯一個或多個評估。
• 評估之間可以通過聚合來表現其層次關系。
• 評估與目標之間通過關聯關系來體現他們之間的相關性。
• 表示圖符：

• 實例：本案例列舉了兩個驅動力，分別為“客戶滿意”和“技術支持”。對於驅動力“客戶滿意”來說，它具有兩個評估結果：“客戶流失”和“客戶投訴”，而后者還可細分為“缺乏對索賠狀況認識”、“索賠提交不便”、“缺乏對產品組合的認識”和“信息不完整或不一致”這四個評估元素；對於“技術支持”驅動力來說，其評估結果為“等待隊列漫長”和“長服務時間”。

 

2.5.1.4 目標（Goal）

• 定義：用於表示干系人所期望達到的最終狀態。對於目標的描述通常采用定性的詞語，例如“增加”、“改善”等，並且一個目標可以被進一步解構為更詳盡的子目標，例如“增加利潤”目標可以被細分為“節省開支”和“增加銷售”這兩個目標。目標涉及到的主要關系可歸納為：
• 目標之間可以通過聚合關系來體現其層次關系。
• 目標與評估之間通過關聯關系來體現兩者之間的相關性。
• 目標與驅動力之間通過關聯關系來體現兩者之間的相關性。
• 原則、需求和約束可以用來實現目標。
• 表示圖符：

• 實例：在本案例中，驅動力“利潤”包含兩個方面的驅動力，分別為“銷售”和“成本”，而通過對驅動力“成本”的分析，我們得到了兩個評估結果：“應用成本過高”和“人員成本過高”。針對兩個評估做進一步分析后我們可以得出：“應用成本過高”可以通過實現“降低維護成本”和“降低應用的直接成本”這兩個目標來解決，而“人員成本過高”則可以通過實現“降低人員工作量”來解決；“降低人員工作量”這一目標又可以被進一步細分為“減少人工工作”和“減少與客戶交互”這兩個子目標。

 

2.5.1.5 需求（Requirement）

• 定義：用於表示系統為了達成目標所必須做的實現。需求涉及到的主要關系可歸納為：
• 一個需求可以實現一個或多個目標，且一個目標可以被一個或多個需求所實現。
• 一個需求可以實現一個或多個原則，且一個原則可以被一個或多個需求所實現。
• 表示圖符：

• 實例：在本案例中，為了改善“缺乏對產品組合的認識”這一評估結果，企業制定了“提高產品組合管理”的目標，而這一目標可以通過實現“指派個人助理”和/或“提供在線產品組合服務”這兩個需求來達成。在這兩個需求中，前者可以通過一個人工服務來實現（通過參與者“助理”提供的名為“個人產品組合服務”的業務服務），而后者則可以通過一個自動化服務來實現（通過應用組件“產品組合管理應用”實現的名為“在線產品組合服務”的應用服務）。

 

2.5.1.6 約束（Constraint）

• 定義：用於表示針對系統實現方式的限制。約束概念元素是需求概念元素的特化，因而他繼承了需求的屬性和關系，但約束並不描述系統需要實現什么，而是界定了系統實現所不能觸及的領域。
• 表示圖符：

• 實例：本案例展示了實現一個“產品組合管理應用”受制於兩個約束：其一是“需要采用Java實現應用”，而另外一個是“軟件實現項目”的預算被限制於“500k歐元”之內。

 

2.5.1.7 原則（Principle）

• 定義：用於表示在給定的上下文環境下所有系統的共通性質或實現方式。原則與需求相類似，他們都描述了為了達成目標而必須遵循的規則，但從適用范圍來講，原則比需求具有更廣泛的適用性，它所描述的是確定的環境下所有系統必須遵循的通用規則，而需求則是針對特定系統而制定的。原則所涉及到的主要關系可歸納為：
• 一個原則可以實現一個或多個目標，而一個目標可以被一個或多個原則所實現。
• 一個原則可以被一個或多個需求所實現。
• 表示圖符：

• 實例：在本案例中，為了實現“減少與客戶交互”和“較少人工工作”這兩個目標，系統需要遵循“系統必須面向客戶”這一原則，而此原則可以通過實現“提供在線產品組合服務”和“提供在線信息服務”這兩個需求來達成。

 

2.6 模型元素擴展——實施和遷移

      與動機擴展一樣，實施和遷移擴展模型元素也是ArchiMate 2.0中依照ArchiMate擴展規則而新加入的內容。通過對各種項目管理領域中的標准和最佳實踐進行抽象和概括，這些新的概念元素以及他們之間的關系能夠用來支持TOGAF后期的幾個將企業架構付諸實現的階段（“機會與解決方案階段”、“遷移規划階段”和“實施治理階段”）。不過作為高層次的抽象，這些概念元素並不能涵蓋某一具體項目管理方法（例如PMBok, PRINCE2等）中的具體細節，但是在實際應用中建模者可以通過“特化”來進一步豐富這一擴展中的內容，從而達成與實際環境的無縫連接。ArchiMate 2.0對於實施和遷移擴展所引入的新概念元素以及他們之間的主要關系歸納如下：

 

2.6.1 實施和遷移概念元素

2.6.1.1 工作包（Work Package）

• 定義：用於表示為了在指定時間內完成某一特定目標的一系列行為。由此可見，一個工作包具有明確的起止時間，並應具備清晰的目標，它既可以對各個項目進行建模，也可以用來描述方案、項目或項目組合中的子項目或任務。工作包所涉及到的主要關系可歸納為：
• 一個工作包可以被一個或多個交付物所實現。
• 業務角色可以被指派給工作包。
• 工作包可以被指派到某個位置之上。
• 表示圖符：

• 實例：在本案例中，為了將應用組合進行合理化建設，公司啟動了“應用組合合理化方案”，並通過工作包概念元素對其進行建模。該方案包含兩個前后銜接的項目（均用工作包概念元素進行描述）：首先是通過“后台系統集成項目”對除了客戶關系管理系統之外的各個后台系統進行集成，然后通過“客戶關系管理系統集成項目”來對客戶關系管理系統進行整合。

 

2.6.1.2 交付物（Deliverable）

• 定義：用於表示經過精確定義的工作包的輸出產物。工作包執行的最終結果是產生一系列的交付物，這些交付物既可以用來描述報告、服務、軟件和硬件產品等有形事物，可以對諸如組織架構變動等無形事物進行建模。交付物所涉及到的主要關系可歸納為：
• 交付物之間通過聚合關系來體現其層次結構。
• 交付物可以被工作包所實現。
• 交付物可以被指派到某個位置之上。
• 交付物可以實現架構或架構的一個部分，因而交付物和各個核心元素（應用組件、業務流程或服務等）之間可以通過實現關系進行關聯。並且由於工作包與交付物之間具有實現關系，工作包與核心元素之間也具有着間接的實現關系。
• 表示圖符：

• 實例：在本案例中，“集成的后台系統”這一交付物所包含的子交付物體系被解構為下圖：

 

2.6.1.3 穩定階段（Plateau）

• 定義：用於表示在一個有限的時間區間內架構所處的相對穩定的狀態。從前面關於TOGAF的介紹中我們可以知道，在“業務架構”、“信息系統架構”和“技術架構”這三個階段中，企業可以制定出基線架構以及目標架構，由於這兩個架構可能差距很大，且這一從“基線”到“目標”的轉變會持續很長一段時間，因而在接下來的“機會與解決方案”階段中，企業可以制定一系列過渡架構，將原本冗長繁復的變革過程細化為一系列的過渡階段，並且以此為基礎將一個個獨立的工作包和項目組織為受管控的項目組合和方案。為了對這些中間過渡狀態進行描述，實施和遷移擴展便引入了“穩定階段”這一概念元素。穩定階段所涉及到的主要關系可歸納為：
• 穩定階段可以聚合一系列核心元素，從而體現了穩定階段對應的是哪些架構元素（應用組件、業務流程或服務等）。
• 表示圖符：

• 實例：本案例描述了從基線架構到目標架構的遷移過程，以及在此期間所需經歷的幾個過渡狀態。

 

2.6.1.4 差距（Gap）

• 定義：用於表示在兩個穩定階段之間進行差距分析的結果。差距可以通過關聯關系與穩定階段相關的各個核心概念元素相聯系，用以表示在兩個穩定階段之間是哪些元素形成了“差距”。
• 表示圖符：

• 實例：本案例展示了基線架構與目標架構之間在基礎設施方面的差距：增加“后 台應用服務器”；刪除“車輛保險應用服務器”和“法律援助后台服務器”。