雲計算時代企業架構：使用混合的軟體即服務（SaaS）雲計算（英語：Cloud Computing），是一種基於網際網路的計算方式，通過這種方式，共享的軟硬體資源和信息可以按需求提供給計算機和其他設備，主要是基於網際網路的相關服務地增加、使用和交付模式，通常涉及通過網際網路來提供動態易擴展且經常是虛擬化的資源。雲是網路、網際網路的一種比喻說法。
基本介紹
- 中文名：雲計算時代企業架構
- 外文名：Cloud Computing
- 分類：網際網路技術
- 主要功能：共享的軟硬體資源和信息
基本內容,1.摘要,2.服務,3.消費者場景,3.1角色,3.2服務類型,4.雲平台模型,4.1TOGAF框架和ArchiMate模型,4.2SaaS的功能要求,4.3SaaS解決方案的使用,4.4新的套用模型,
基本內容
目錄
1.摘要 1
2.服務 1
3.消費者場景 1
3.1角色 2
3.2服務類型 2
4.雲平台模型 2
4.1TOGAF框架和ArchiMate模型 3
4.2SaaS的功能要求 5
4.3SaaS解決方案的使用 6
4.4新的套用模型 7
1.摘要
良好的企業架構（EA）是有效採用面向服務的架構（SOA）的主要推動因素，該觀點已在數年前提出，許多客戶已經因為缺乏對EA的“盡職調查”而付出了項目失敗或半失敗的代價。架構的主要部分（業務流程與IT服務之間的端到端連線）以及已建立的企業架構所提供的日常治理機制，這些都是SOA保持其改造業務和企業的技術能力承諾的基本要素。
2.服務
“服務”是指我們願意承認，對於關於手頭特定問題而言，架構IT的粒度可能是不是最優的，我們也願意接受過度設計（over-engineer）的某些組成部分，以便支持更靈活的重新安排的業務操作。（以標準化接口為例。它不是免費的，而且僅當您真正重用其功能時才會獲得回報）。這種水平的靈活性本身只是實現靈活的業務流程的一種手段。同樣，這些流程只有在支持靈活、明智的業務戰略時才會提供有意義的經濟回報。
在實現雲（或SOA）架構時，必須將這樣的因果鏈擺在架構師的面前。否則，他們的決策將會永遠缺乏對問題的某些關鍵方面的考慮。
這意味著，轉換該領域的企業架構模型就是執行識別業務對IT的關係、依賴關係、需求和約束的盡職調查。
3.消費者場景
雲參考架構，IBM或美國商務部的國家標準與技術研究院（NIST）提供的雲參考架構，從所涉及的角色集合開始架構雲業務。每個操作員都有一個明確的角色。
圖1.IBMCloudReferenceArchitecture，與NIST的雲參考架構類似
3.1角色
IBM參考架構識別了以下角色：
CloudServiceCreator（雲服務創建者），開發將通過雲基礎架構被使用的新服務
CloudServiceProvider（雲服務提供者），管理和運營雲基礎架構
CloudServiceConsumer（雲服務消費者），使用在雲基礎架構中託管的服務
NIST則列出了以下角色：
CloudProvider（雲提供者，類似於IBM的雲服務提供者）
CloudConsumer（雲消費者，相同）
CloudAuditor（雲審計者），可以對雲服務進行獨立評估
CloudBroker（雲經紀人），能夠起中介作用、組成Provider的服務，並使其增值
CloudCarrier（雲運營商），有能力提供連線到CloudServiceProvider的傳輸服務
如您所見，Provider（供應商）和Consumer（消費者）是核心角色。雖然供應商的業務和IT模型與傳統外包商的模型非常相似，但消費者是最充分利用雲創新功能的人。
3.2服務類型
回到IBMCloudReferenceArchitecture，消費者可以選擇四種類型的服務：
基礎架構服務（被稱為“基礎架構即服務”，或IaaS），消費者使用相當於硬體系統的服務
平台服務（PaaS，平台即服務），其中服務等價於一個完整的硬體和軟體基礎架構
軟體服務（SaaS，軟體即服務），消費者使用業務應用程式
業務流程即服務（有時被稱為BPaaS），消費者將部分業務流程外包給外部供應商
提供者和消費者可能是在同一家公司中的兩個部門（例如，IT運營部門和IT開發部門），他們使用私有雲；他們也可能是兩個獨立的業務實體，其中一個負責通過雲提供服務。後者是最有趣的示例子，因為它涉及到企業業務模型的變更，而不僅僅是它的其中一個組織實體的模型變更。
4.雲平台模型
雲模型的目標是提供服務，但所提供的服務的質量取決於平台所提供的技術和業務支持功能（IBMReferenceArchitecture中的兩個粉紅色方框）。
IBMCloudReferenceArchitecture識別以下支持服務：
服務產品目錄及管理
服務請求管理
訂單和訂閱管理
契約和協定管理
定價、計量和計費
客戶帳號管理
等級
結算與交收、應付賬款、應收賬款
服務交付目錄
服務自動化管理
變更與配置管理
映像生命周期管理
配置
事件和問題管理
IT服務水平管理
監控和事件管理
IT資產和許可管理
容量和性能管理
平台和虛擬化管理
這些服務中，有些明確支持提供者的業務和技術流程，有些則需要消費者的參與，對他們而言，有些服務實際上可能是新服務，如服務的支付帳單、外部監測信息的關聯（用於控制所購買服務的質量），等等。
4.1TOGAF框架和ArchiMate模型
TheOpenGroupArchitectureFramework（TOGAF）是一個企業架構框架。在1995年開發了TOGAFVersion1，它以TechnicalArchitectureFrameworkforInformationManagement（TAFIM）為基礎，TAFIM由美國國防部開發。TOGAF的核心是ArchitectureDevelopmentMethod（ADM），它描述了一個流程，該流程在8+1個階段中管理企業架構的開發。
ADM在三個層面上進行疊代：在整個過程中、在各階段之間，以及在階段內。它是一種通用的方法，可以定製ADM，以滿足組織的特定需求。例如，一些使用ADM的美國聯邦機構開發了針對其特定部門需求的架構可交付成果。
ArchiMate是一個OpenGroupStandard，是一個開放和獨立的企業架構建模語言，它提供了一些工具，以明確的方式描述、分析和可視化在業務、套用和技術領域之間的關係。
正如在經典建築結構的建築圖描述了建築物的建設和使用的各個方面，ArchiMate提供一個通用語言來描述業務流程、組織結構、信息流、IT系統和技術基礎架構的建設與運營。這種洞察可以幫助利益相關者設計、評估和溝通這些業務領域內部以及它們之間的決策與變更結果。（來源：TheOpenGroup）
ArchiMate的組織包括三個核心層和兩個擴展。
業務層這一層模擬組織結構和它產生的服務、業務角色和流程，以及產品與契約等業務對象。
應用程式層它描述了應用程式組件和它們的互動、邏輯數據實體和它們之間的關係，並向上一層（業務層）提供所生成的服務。
技術層這一層模擬硬體和軟體系統，以及連線網路，顯示如何將它們轉化為提供給上一層（套用層）的服務。
AchiMate2.0規範對核心層增加了兩個擴展。
動機動機的概念用於模擬影響、引導或限制企業架構的某個部分的設計或變更的動機或原因。
實現和遷移這個擴展包括的概念可用於模擬變更項目和遷移規劃，以及支持計畫、組合和項目管理。
圖2.ArchiMate表示法
與任何良好的架構模型一樣，除了架構層以外，ArchiMate規範還支持觀點。觀點用於溝通架構的特定方面。這些方面由利益相關者的關注點決定。因此，特定的觀點和不應該包括的內容應該完全取決於利益相關者的關注點。
4.2SaaS的功能要求
所涉及的利益相關者的動機
它必須支持的業務模型
向其他應用程式或從其他應用程式暴露的接口
如果雲和內部系統之間需要連線，則提供消費者的技術水平所要求的服務
SaaS解決方案的非功能性方面
4.3SaaS解決方案的使用
我們將擴展來自TheOpenGroup的ArchiMate。一家名為Archinsurance的虛構保險公司，該示例假定Archinsurance已將現有的CRM應用程式確定為實現其業務目標的阻礙。
與所有利益相關者分享動機
Motivation模型捕獲利益相關者的動機和要求。如圖3的流程圖所示，CEO的動機是雙重的：
增加對給定客戶的重複銷售次數
在年終之前賺錢
CFO在現金緊張的時期關注的是資本開支的ROI，而CIO主要擔心的則是現有數據中心地板上的可用空間。安全部門的人會反對每一個異地解決方案，因為他們擔心客戶記錄等公司重要數據被盜或丟失，並要求執行公司進行安全實踐。
從CEO、CFO、CIO和安全部門的要求來看，似乎要在雲計算解決方案和更傳統的外包之間進行選擇，並且更傾向於前者。但是，安全要求難以得到滿足，並會將合資格的供應商限制為能夠對運動中的數據和靜止數據都提供數據加密的供應商。
此外，選中的SaaS解決方案不能是一個“純”雲服務，因為它必須包含保護機制，避免數據受到未經授權的訪問，並且保證雲和數據中心之間的數據一致性。因此，它將是一個混合解決方案。
識別來自業務模型的功能性要求
正如前面提到的，該示例假設新應用程式支持前一個應用程式的業務模型和流程。我們的EA業務模型將提供指導，以確定需要支持什麼。
例如，目前的CRM提供了客戶管理服務和印刷服務，以支持索賠處理流程。以這種方式識別的服務將是新的SaaS解決方案的功能性要求（例如：“索賠的列印輸出必須包含以下數據：”）以及非功能性要求（例如：“索賠的格式和列印不得超過3分鐘“）的來源。
圖4.受到新CRM影響的應用程式服務
4.4新的套用模型
當我們對未來的SaaS解決方案可以滿足所有功能性要求感到滿意時，下一步是設計如何驗證它與其他應用程式（內部應用程式，甚至在雲上的應用程式）的接口要求。
圖5.新的應用程式組合
當我們對未來的SaaS解決方案可以滿足所有功能性要求感到滿意時，下一步是設計如何驗證它與其他應用程式（內部應用程式，甚至在雲上的應用程式）的接口要求。
圖5.新的應用程式組合
Archinsurance應用程式組合將改變從圖5左邊的組合修改為右邊的組合，其中CRM已經成為企業外部的組件。CRM組件的作用不變，但重要的是要仔細考慮它與其他組件（如，客戶數據訪問和策略資料庫管理）的接口，因為無論是簽名（被交換的數據）還是協定（用於交換的技術），都可能會發生變化。（請注意，在ArchiMate中，關係的方向與UML模型中的關係方向相反。）
為了強調這一方面，我們重新繪製了應用程式模型，讓應用程式接口和技術組件（如果有必要）顯式實現它們。對於圖5所示的兩個接口，鑒於SaaS實現的技術功能，這意味著在我們的網路邊緣添加ESB技術組件，這些組件能夠向公司數據提供Web服務接口。我們將對企業數據倉庫使用一個安全的ESB和一個安全的FTP服務，以滿足該公司的安全管理人員的要求。
對於Web門戶的接口，我們已經確定，真正的需求是單一用戶ID和密碼模式可以支持的一個簡單的HTTP重定向。因此，接觸代理將使用一個ID和密碼對來登錄到內部系統和新的CRM應用程式。
接口位於LDAP數據與雲中的CRM所使用的身份驗證機制中的數據之間（在本例中，我們將LDAP更新作為事件推送到CRM）。LDAP身份驗證和CRM合作，以提供（新的）用戶身份驗證功能，就像CRM數據和內部數據集市合作，提供了新的數據倉庫功能。
新的應用程式模型將指導我們設計利用現有的內部基礎架構來適應新的SaaS服務所需的變更。
圖6.修訂後的應用程式模型圖
描述非功能性
SaaS解決方案必須能夠支持哪些非功能性要求（NFR）
我們需要做什麼來連線兩個系統，這將如何影響內部基礎架構的NFR
事實上，新服務必須滿足一組複雜的NFR，其中一些NFR源於業務需求（例如，列印時間），另一些來自其他利益相關者，如安全管理人員。
此外，可能會增加一些要求，形成強調新服務的複雜組合（例如，有大量並發用戶時的回響時間），在我們宣布可以接受SaaS解決方案之前，必須驗證這些要求。
服務供應商的內部架構和基礎架構並不是我們所關注的（盡職調查除外）。因此，無論我們執行何種驗收測試，都將執行一個黑箱測試。但是，必須考慮到基礎架構。在我們的模式中，必須對保護ArchinsuranceESB的XML防火牆和HTTP/FTP防火牆進行配置，以便考慮到公司與服務供應商之間的新流程。
圖7.CRMSaaS非功能性觀點
