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

2.4 技術層模型元素

      技術層模型元素包括了企業在信息基礎設施方面(企業中基本的軟硬件環境,包括物理設備、系統軟件等爲信息化提供基本支持的設施)的各類概念元素,以及他們之間的關係。與應用層模型元素相相似,技術層模型元素中的大部分概念元素也來源於UML 2.0,這一樣也是由於UML 2.0在這一領域已經成爲被普遍接受的事實標準。在ArchiMate 2.0中,對企業技術層進行建模的各類概念元素以及他們之間的主要關係(元模型)被定義以下:數據庫

image

 

2.4.1 結構元素

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

image

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

image

 
2.4.1.2 設備(Device)
  • 定義:用於表示存儲或部署執行各類製品的硬件資源。設備概念元素是節點元素的特化,他表明了具備處理能力的各類物理資源,例如大型機、我的計算機或路由器等。設備所涉及到的主要關係可概括爲:
    • 設備能夠組合或聚合其餘的子設備。
    • 設備之間經過網絡進行互聯。
    • 製品能夠被分配給設備,用以表示製品被存儲或部署到此設備之上。
    • 系統軟件能夠被分配給設備,用以表示系統軟件的安裝或部署位置。
    • 一個節點能夠包含一個或多個設備。
  • 表示圖符:

image

  • 實例:本案例展現了三種設備,分別爲:「前臺應用服務器」、「後臺應用服務器」和「Web服務器」,而且他們之間經過「局域網」這一網絡概念元素進行互聯。

image

 
2.4.1.3 系統軟件(System Software)
  • 定義:用於表示一種軟件環境,使得各類特定類型的軟件組件和對象能以製品的形式部署於其中。系統軟件概念元素也是節點的特化,專門用於對各類製品所處的軟件環境進行建模。系統軟件和設備一般組合在一塊兒來造成一個節點。系統軟件所涉及到的主要關係可概括爲:
    • 系統軟件可被分配給設備。
    • 製品可被分配給系統軟件。
    • 節點能夠組合或聚合系統軟件。
  • 表示圖符:

image

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

image

 
2.4.1.4 基礎設施接口(Infrastructure Interface)
  • 定義:表示用於獲取由節點提供的基礎設施服務訪問點。與前面介紹過的接口概念相仿,基礎設施接口也具備雙向性,一個用於表示節點經過此基礎設施接口對外提供服務,另一個則用於表示節點須要從外界獲取何種基礎設施服務。不一樣的基礎設施接口能夠提供相同的基礎設施服務。基礎設施接口所涉及到的主要關係可概括爲:
    • 基礎設施接口能夠經過組合關係而做爲節點的一個組成部分。
    • 基礎設施接口能夠被其餘節點所使用。
    • 基礎設施服務能夠被分配給基礎設施接口,用於表示該服務是經過此接口而被提供給外界環境的。
  • 表示圖符:

image

  • 實例:在本案例中,名爲「數據庫管理系統」的系統軟件具備「數據訪問接口」這一基礎設施接口,於是外界對數據的操做均可以經過此接口來實現。

image

 
2.4.1.5 網絡(Network)
  • 定義:用於表示在兩個或兩個以上設備之間進行通訊的媒介,同時它也是不一樣節點之間各類通訊路徑的物理實現。網絡元素通常具備諸如帶寬、延遲之類的屬性。網絡所涉及到的主要關係可概括爲:
    • 網絡鏈接兩個或兩個以上的設備。
    • 網絡實現了一個或多個通訊路徑。
    • 網絡能夠包含其餘子網絡。
  • 表示圖符:

image

  • 實例:在本案例中,「大型機」和「終端機」這兩臺設備之間經過帶寬爲100Mbits/s的局域網進行互聯。

image

 
2.4.1.6 通訊路徑(Communication Path)
  • 定義:用於表示多個節點之間的邏輯鏈接,而且經過這些連接節點才能夠進行節點之間的數據交換。通訊路徑所涉及到的主要關係可概括爲:
    • 通訊路徑鏈接兩個或兩個以上的節點。
    • 一條通訊路徑可由一個或多個網絡所實現。
  • 表示圖符:

image

  • 實例:在本案例中,節點「應用服務器」和節點「客戶端」之間經過「消息隊列」這一通訊路徑進行數據交互。

image

 

2.4.2 行爲元素

2.4.2.1 基礎設施功能(Infrastructure Function)
  • 定義:用於對節點所執行的基礎設施行爲進行組織的行爲元素,他描述了節點的內部功能。基礎設施功能所涉及到的主要關係可概括爲:
    • 基礎設施功能能夠實現基礎設施服務。
    • 基礎設施功能可使用由其餘基礎設施功能所實現的基礎設施服務。
    • 基礎設施功能能夠訪問製品。
    • 基礎設施功能可被分配給節點,用於表示該節點所可以執行的行爲。
  • 表示圖符:

image

  • 實例:在本案例中,「數據庫管理系統」節點具備(須要注意是,這裏雖然採用嵌套的表述方式,但節點與基礎設施功能之間是經過指派關係來聯繫的)「提供數據訪問功能」和「管理數據功能」這兩個基礎設施功能,而且前者實現了名爲「數據訪問服務」的基礎設施服務,然後者則實現了「數據管理服務」。

image

 
2.4.2.2 基礎設施服務(Infrastructure Service)
  • 定義:用於表示由一個或多個節點經過基礎設施接口對外提供的對外界具備意義的功能單元。基礎設施服務所涉及到的主要關係可概括爲:
    • 基礎設施服務能夠被應用組件或節點所使用。
    • 基礎設施服務能夠被節點所實現。
    • 基礎設施服務能夠被基礎設施功能所實現。
    • 基礎設施服務能夠被分配到基礎設施接口之上。
    • 基礎設施服務能夠訪問製品。
  • 表示圖符:

image

  • 實例:在本案例中,「面向消息中間件」系統軟件實現了「消息服務」這一基礎設施服務。

image

 

2.4.3 信息元素

2.4.3.1 製品(Artifact)
  • 定義:用於表示在軟件開發過程或系統的部署和運行過程當中使用和產生的數據的物理表現。製品一般被用來描述諸如源文件、可執行文件、腳本、數據庫表、消息、文檔、規範說明,以及模型文件這樣的軟件產品。製品所涉及到的主要關係可概括爲:
    • 一個應用組件或系統軟件能夠被一個或多個製品所實現,便可執行組件類型的製品。
    • 一個數據對象能夠被一個或多個製品所實現,即數據文件類型的製品。
    • 製品能夠被分配到節點之上,用於表示該製品被部署到此節點之上。
  • 表示圖符:

image

  • 實例:在本案例中,「風險管理EJB」這一製品被指派給(部署到)了系統軟件「J2EE應用服務器」之上,而這其中「風險管理EJB」表明了一個可部署的代碼單元。

image

 

2.5 模型元素擴展——動機

      動機模型元素擴展是ArchiMate 2.0版本中依照ArchiMate擴展規則而新加入的內容。ArchiMate以前的版本從操做角度對企業的運行狀況進行了描述和建模,但這些內容並不能說明採用當前方式進行建模的原因。缺失瞭如此重要的一環,咱們沒法回答建模的合理性,於是更沒法促使企業的戰略目標與戰術實現相協調。經過結合TOGAF標準,咱們能夠看出:這些缺失的內容實際上就是TOGAF中「預備階段」、「架構願景階段」、「架構變動階段」,以及充當各階段運行引擎的「需求管理階段」所要創建或維護的核心。爲了填補這一空白,ArchiMate 2.0引入了新的概念元素、關係和視角。本章將詳細描述其新加入的概念元素,而對於新加入的關係和視角將分別在後面的部分中進行描述。ArchiMate 2.0對於動機擴展所引入的新概念元素,以及他們之間的主要關係概括以下:服務器

image

      因爲動機擴展的目標是解釋爲什麼建模,以及建模與具體緣由之間的關係,於是動機擴展中新加入的概念元素都是用來敘述原因的描述性概念,他們既不具有結構化的實體,亦不會執行什麼樣的「行爲」,同時在乎義上還有着「信息元素」的影子,而且從上面的元模型圖示中咱們能夠看到,動機元素(Motivational Element)並不繼承於結構元素(Structure Element),因此不一樣於業務、應用和技術層面中對概念元素所採用的「結構元素」、「行爲元素」和「信息元素」分類概括方法,在ArchiMate中,動機擴展的概念元素被統一律括爲「動機概念元素(Motivational Concepts)」。網絡

 

 

 

2.5.1 動機概念元素

      動機概念元素對企業架構建設的原因進行了描述,並將這些元素與前面所說的企業三層領域建模元素聯繫了起來。從比較高的抽象層次來看,動機概念元素包括 「干係人(Stakeholder)」和「動機元素(Motivational Element)」這兩個概念元素,他們之間的關聯關係體現了:創建企業架構的每一個動機都應該反映某干係人的意圖。若是把抽象層次下降,咱們會發現「動機元素」被特化成了六個更爲具體的「動機」概念,他們分別是:「驅動力(Driver)」、「評估(Assessment)」、「目標(Goal)」、「原則(Principle)」、「需求(Requirement)」和「約束(Constraint)」。這六個概念元素以及他們之間的關係以一種從抽象到具體的順序描述了創建企業架構的原因:架構

  • 「驅動力」描述了企業架構創建的根本原因,他既能夠是因爲外部環境的變化而引發,也多是源自企業內部,而這種內部驅動力每每也反映了某個干係人的關注點,於是該元素一般與一個「干係人」元素相關聯。
  • 要想將「驅動力」作進一步的落實,企業須要對其進行分析和評估,而這正是「評估」概念元素所描述的目標。
  • 「驅動力」通過評估後,企業可由此分析出企業的優點、弱點、機會和風險,而這些內容能夠轉化爲各個具體的企業戰略「目標」。
  • 爲了將確立後的「目標」付諸實現,企業須要將其細化爲若干「原則」和「需求」。這二者均是爲了實現「目標」而建,但「原則」具備更加廣闊的範圍,它是在必定上下文環境之下針對若干具體需求共性的抽象,因此在元模型中咱們能夠發現:「需求」實現了「目標」,同時也實現了「原則」,而「需求」和「原則」都是爲了實現「目標」而生的。
  • 「需求」不只僅是對須要作什麼所進行的描述,還多是對不能作什麼而進行的界定。對於後一種狀況,ArchiMate採用特化了的「需求」概念元素,亦即「約束」概念元素,來進行描述。

      動機概念元素並非一套密閉的元模型,何況ArchiMate建模基本原則也不容許這種領域隔離的狀況存在,於是他與前述三個領域有着緊密的關係。在後面的跨領域關聯章節中,筆者將會對此進行更加詳細的闡述。ui

2.5.1.1 干係人(Stakeholder)
  • 定義:用於表明對於架構產生的結果具備利益關係,或對其進行關注的我的、團隊或組織的類別。干係人涉及到的主要關係可概括爲:
    • 干係人之間經過聚合關係來表現他們之間的組織結構。
    • 干係人與其餘動機概念元素之間經過關聯關係來表示對其餘各類動機概念具備的利益關係或關注點。
  • 表示圖符:

image

  • 實例:在本案例中,名爲「董事會」的干係人包含了三個子干係人,分別是:「CEO」、「CIO」和「CFO」。

image

 
2.5.1.2 驅動力(Driver)
  • 定義:用於表示引發或驅動組織發生變化的事物。驅動力涉及到的主要關係可概括爲:
    • 來源於組織內部的驅動力須要經過關聯干係人來表示其具體來源,以及涉及到了誰的利益和關注。
    • 驅動力之間能夠經過聚合關係來表示其層級結構。
    • 驅動力和評估之間經過關聯關係來描述評估所對應的驅動力。
    • 驅動力和目標之間經過關聯關係來描述二者之間的相關性。
  • 表示圖符:

image

  • 實例:在本案例中,「經濟環境變化」是一個外部驅動力,而「股東滿意」和「客戶滿意」則是兩個內部驅動力,於是他們有相關干係人與之關聯。「客戶滿意」這一內部驅動力涉及到了干係人「CEO」和「客戶」的利益和關注,而「股東滿意」這一內部驅動力僅與干係人「CEO」相關。驅動力「股東滿意」還包含了兩個子驅動力,分別爲「股價」和「利潤」,並且前者受外部驅動力「經濟環境變化」所影響(二者之間經過「影響」關係相連,這是動機擴展新加入的關係,在後面章節將會對其進行詳細描述)。

image

 
2.5.1.3 評估(Assessment)
  • 定義:用於表示對於驅動力進行分析的結果。針對驅動力進行分析而獲取的評估將會揭示企業的優點、缺陷、機會和風險,而這些內容將會直接引發現有目標的變化或新目標的設立,並觸及到企業架構的變化。評估涉及到的主要關係可概括爲:
    • 評估能夠與一個或多個驅動力進行關聯,而一個驅動力亦能夠關聯一個或多個評估。
    • 評估之間能夠經過聚合來表現其層次關係。
    • 評估與目標之間經過關聯關係來體現他們之間的相關性。
  • 表示圖符:

image

  • 實例:本案例列舉了兩個驅動力,分別爲「客戶滿意」和「技術支持」。對於驅動力「客戶滿意」來講,它具備兩個評估結果:「客戶流失」和「客戶投訴」,然後者還可細分爲「缺少對索賠情況認識」、「索賠提交不便」、「缺少對產品組合的認識」和「信息不完整或不一致」這四個評估元素;對於「技術支持」驅動力來講,其評估結果爲「等待隊列漫長」和「長服務時間」。

image

 
2.5.1.4 目標(Goal)
  • 定義:用於表示干係人所指望達到的最終狀態。對於目標的描述一般採用定性的詞語,例如「增長」、「改善」等,而且一個目標能夠被進一步解構爲更詳盡的子目標,例如「增長利潤」目標能夠被細分爲「節省開支」和「增長銷售」這兩個目標。目標涉及到的主要關係可概括爲:
    • 目標之間能夠經過聚合關係來體現其層次關係。
    • 目標與評估之間經過關聯關係來體現二者之間的相關性。
    • 目標與驅動力之間經過關聯關係來體現二者之間的相關性。
    • 原則、需求和約束能夠用來實現目標。
  • 表示圖符:

image

  • 實例:在本案例中,驅動力「利潤」包含兩個方面的驅動力,分別爲「銷售」和「成本」,而經過對驅動力「成本」的分析,咱們獲得了兩個評估結果:「應用成本太高」和「人員成本太高」。針對兩個評估作進一步分析後咱們能夠得出:「應用成本太高」能夠經過實現「下降維護成本」和「下降應用的直接成本」這兩個目標來解決,而「人員成本太高」則能夠經過實現「下降人員工做量」來解決;「下降人員工做量」這一目標又能夠被進一步細分爲「減小人工工做」和「減小與客戶交互」這兩個子目標。

image

 
2.5.1.5 需求(Requirement)
  • 定義:用於表示系統爲了達成目標所必須作的實現。需求涉及到的主要關係可概括爲:
    • 一個需求能夠實現一個或多個目標,且一個目標能夠被一個或多個需求所實現。
    • 一個需求能夠實現一個或多個原則,且一個原則能夠被一個或多個需求所實現。
  • 表示圖符:

image

  • 實例:在本案例中,爲了改善「缺少對產品組合的認識」這一評估結果,企業制定了「提升產品組合管理」的目標,而這一目標能夠經過實現「指派我的助理」和/或「提供在線產品組合服務」這兩個需求來達成。在這兩個需求中,前者能夠經過一我的工服務來實現(經過參與者「助理」提供的名爲「我的產品組合服務」的業務服務),然後者則能夠經過一個自動化服務來實現(經過應用組件「產品組合管理應用」實現的名爲「在線產品組合服務」的應用服務)。

image

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

image

  • 實例:本案例展現了實現一個「產品組合管理應用」受制於兩個約束:其一是「須要採用Java實現應用」,而另一個是「軟件實現項目」的預算被限制於「500k歐元」以內。

image

 
2.5.1.7 原則(Principle)
  • 定義:用於表示在給定的上下文環境下全部系統的共通性質或實現方式。原則與需求相相似,他們都描述了爲了達成目標而必須遵循的規則,但從適用範圍來說,原則比需求具備更普遍的適用性,它所描述的是肯定的環境下全部系統必須遵循的通用規則,而需求則是針對特定系統而制定的。原則所涉及到的主要關係可概括爲:
    • 一個原則能夠實現一個或多個目標,而一個目標能夠被一個或多個原則所實現。
    • 一個原則能夠被一個或多個需求所實現。
  • 表示圖符:

image

  • 實例:在本案例中,爲了實現「減小與客戶交互」和「較少人工工做」這兩個目標,系統須要遵循「系統必須面向客戶」這一原則,而此原則能夠經過實現「提供在線產品組合服務」和「提供在線信息服務」這兩個需求來達成。

image

 

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

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

image

 

2.6.1 實施和遷移概念元素

2.6.1.1 工做包(Work Package)
  • 定義:用於表示爲了在指定時間內完成某一特定目標的一系列行爲。因而可知,一個工做包具備明確的起止時間,並應具有清晰的目標,它既能夠對各個項目進行建模,也能夠用來描述方案、項目或項目組合中的子項目或任務。工做包所涉及到的主要關係可概括爲:
    • 一個工做包能夠被一個或多個交付物所實現。
    • 業務角色能夠被指派給工做包。
    • 工做包能夠被指派到某個位置之上。
  • 表示圖符:

image

  • 實例:在本案例中,爲了將應用組合進行合理化建設,公司啓動了「應用組合合理化方案」,並經過工做包概念元素對其進行建模。該方案包含兩個先後銜接的項目(均用工做包概念元素進行描述):首先是經過「後臺系統集成項目」對除了客戶關係管理系統以外的各個後臺系統進行集成,而後經過「客戶關係管理系統集成項目」來對客戶關係管理系統進行整合。

image

 
2.6.1.2 交付物(Deliverable)
  • 定義:用於表示通過精肯定義的工做包的輸出產物。工做包執行的最終結果是產生一系列的交付物,這些交付物既能夠用來描述報告、服務、軟件和硬件產品等有形事物,能夠對諸如組織架構變更等無形事物進行建模。交付物所涉及到的主要關係可概括爲:
    • 交付物之間經過聚合關係來體現其層次結構。
    • 交付物能夠被工做包所實現。
    • 交付物能夠被指派到某個位置之上。
    • 交付物能夠實現架構或架構的一個部分,於是交付物和各個核心元素(應用組件、業務流程或服務等)之間能夠經過實現關係進行關聯。而且因爲工做包與交付物之間具備實現關係,工做包與核心元素之間也具備着間接的實現關係。
  • 表示圖符:

image

  • 實例:在本案例中,「集成的後臺系統」這一交付物所包含的子交付物體系被解構爲下圖:

image

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

image

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

image

 
2.6.1.4 差距(Gap)
  • 定義:用於表示在兩個穩定階段之間進行差距分析的結果。差距能夠經過關聯關係與穩定階段相關的各個核心概念元素相聯繫,用以表示在兩個穩定階段之間是哪些元素造成了「差距」。
  • 表示圖符:

image

  • 實例:本案例展現了基線架構與目標架構之間在基礎設施方面的差距:增長「後 臺應用服務器」;刪除「車輛保險應用服務器」和「法律援助後臺服務器」。

image

相關文章
相關標籤/搜索