簡介
良好的企業(yè)架構(gòu)（EA）是有效采用面向服務(wù)的架構(gòu)（SOA）的主要推動因素，該觀點已在數(shù)年前提出（參閱 參考資料 中 Ibrahim 和 Long 的引文），許多客戶已經(jīng)因為缺乏對 EA 的 “盡職調(diào)查” 而付出了項目失敗或半失敗的代價。架構(gòu)的主要部分（業(yè)務(wù)流程與 IT 服務(wù)之間的端到端連接）以及已建立的企業(yè)架構(gòu)所提供的日常治理機制，這些都是 SOA 保持其改造業(yè)務(wù)和企業(yè)的技術(shù)能力承諾的基本要素。
現(xiàn)在，您心里可能在想 “我一定是打開了不對的文章。這本來應(yīng)該是關(guān)于云計算的文章，而不是關(guān)于 SOA 的文章。”
事實是，無論我們討論云還是 SOA，都要處理服務(wù)。
“服務(wù)” 是指我們愿意承認，對于關(guān)于手頭特定問題而言，架構(gòu) IT 的粒度可能是不是最優(yōu)的，我們也愿意接受過度設(shè)計（over-engineer）的某些組成部分，以便支持更靈活的重新安排的業(yè)務(wù)操作。（以標準化接口為例。它不是免費的，而且僅當您真正重用其功能時才會獲得回報）。這種水平的靈活性本身只是實現(xiàn)靈活的業(yè)務(wù)流程的一種手段。同樣，這些流程只有在支持靈活、明智的業(yè)務(wù)戰(zhàn)略時才會提供有意義的經(jīng)濟回報。
在實現(xiàn)云（或 SOA）架構(gòu)時，必須將這樣的因果鏈擺在架構(gòu)師的面前。否則，他們的決策將會永遠缺乏對問題的某些關(guān)鍵方面的考慮。
這意味著，轉(zhuǎn)換該領(lǐng)域的企業(yè)架構(gòu)模型就是執(zhí)行識別業(yè)務(wù)對 IT 的關(guān)系、依賴關(guān)系、需求和約束的 盡職調(diào)查。
在本文中，我們將從云服務(wù)的消費者的角度來探討如何表示這種模型，以及如何通過它去了解需要做什么和為什么這樣做。該消費者可能是一個希望利用云技術(shù)將更高水平的靈活性注入其運營的組織。
云服務(wù)消費者場景
云參考架構(gòu)，例如 IBM 或美國商務(wù)部的國家標準與技術(shù)研究院（NIST）提供的云參考架構(gòu)，從所涉及的角色集合開始架構(gòu)云業(yè)務(wù)。每個操作員都有一個明確的角色。
圖 1. IBM Cloud Reference Architecture，與 NIST 的云參考架構(gòu)類似
IBM 參考架構(gòu)識別了以下角色：
Cloud Service Creator（云服務(wù)創(chuàng)建者），開發(fā)將通過云基礎(chǔ)架構(gòu)被使用的新服務(wù)
Cloud Service Provider（云服務(wù)提供者），管理和運營云基礎(chǔ)架構(gòu)
Cloud Service Consumer（云服務(wù)消費者），使用在云基礎(chǔ)架構(gòu)中托管的服務(wù)
NIST 則列出了以下角色：
Cloud Provider（云提供者，類似于 IBM 的云服務(wù)提供者）
Cloud Consumer（云消費者，相同）
Cloud Auditor（云審計者），可以對云服務(wù)進行獨立評估
Cloud Broker（云經(jīng)紀人），能夠起中介作用、組成 Provider 的服務(wù)，并使其增值
Cloud Carrier（云運營商），有能力提供連接到 Cloud Service Provider 的傳輸服務(wù)
如您所見，Provider（供應(yīng)商）和 Consumer（消費者）是核心角色。雖然供應(yīng)商的業(yè)務(wù)和 IT 模型與傳統(tǒng)外包商的模型非常相似，但消費者是最充分利用云創(chuàng)新功能的人。
回到 IBM Cloud Reference Architecture，消費者可以選擇四種類型的服務(wù)：
基礎(chǔ)架構(gòu)服務(wù)（被稱為 “基礎(chǔ)架構(gòu)即服務(wù)”，或 IaaS），消費者使用相當于硬件系統(tǒng)的服務(wù)
平臺服務(wù)（PaaS，平臺即服務(wù)），其中服務(wù)等價于一個完整的硬件和軟件基礎(chǔ)架構(gòu)
軟件服務(wù)（SaaS，軟件即服務(wù)），消費者使用業(yè)務(wù)應(yīng)用程序
業(yè)務(wù)流程即服務(wù)（有時被稱為 BPaaS），消費者將部分業(yè)務(wù)流程外包給外部供應(yīng)商
提供者和消費者可能是在同一家公司中的兩個部門（例如，IT 運營部門和 IT 開發(fā)部門），他們使用私有云；他們也可能是兩個獨立的業(yè)務(wù)實體，其中一個負責通過云提供服務(wù)。后者是最有趣的示例子，因為它涉及到企業(yè)業(yè)務(wù)模型的變更，而不僅僅是它的其中一個組織實體的模型變更。
在這四種類型的服務(wù)中，本文集中介紹使用通過云服務(wù)（公共 SaaS）提供的業(yè)務(wù)應(yīng)用程序獲得新業(yè)務(wù)功能的特定情況。
云模型的能力所涉及的最后一點是 “平臺”。當然，目標是提供服務(wù)，但所提供的服務(wù)的質(zhì)量取決于平臺所提供的技術(shù)和業(yè)務(wù)支持功能（IBM Reference Architecture 中的兩個粉紅色方框）。
即使我們建議將他們的（EA）分析作為采用任何基于云的服務(wù)的技術(shù)盡職調(diào)查的一部分，但本文篇幅有限，不會重點介紹。
TOGAF 框架和 ArchiMate 模型
The Open Group Architecture Framework（TOGAF）是一個企業(yè)架構(gòu)框架。在 1995 年開發(fā)了 TOGAF Version 1，它以 Technical Architecture Framework for Information Management（TAFIM）為基礎(chǔ)，TAFIM 由美國國防部開發(fā)。TOGAF 的核心是 Architecture Development Method（ADM），它描述了一個流程，該流程在 8 +1 個階段中管理企業(yè)架構(gòu)的開發(fā)。
ADM 在三個層面上進行迭代：在整個過程中、在各階段之間，以及在階段內(nèi)。它是一種通用的方法，可以定制 ADM，以滿足組織的特定需求。例如，一些使用 ADM 的美國聯(lián)邦機構(gòu)開發(fā)了針對其特定部門需求的架構(gòu)可交付成果。
ArchiMate 是一個 Open Group Standard，是一個開放和獨立的企業(yè)架構(gòu)建模語言，它提供了一些工具，以明確的方式描述、分析和可視化在業(yè)務(wù)、應(yīng)用和技術(shù)領(lǐng)域之間的關(guān)系。
正如在經(jīng)典建筑結(jié)構(gòu)的建筑圖描述了建筑物的建設(shè)和使用的各個方面，ArchiMate 提供一個通用語言來描述業(yè)務(wù)流程、組織結(jié)構(gòu)、信息流、IT 系統(tǒng)和技術(shù)基礎(chǔ)架構(gòu)的建設(shè)與運營。這種洞察可以幫助利益相關(guān)者設(shè)計、評估和溝通這些業(yè)務(wù)領(lǐng)域內(nèi)部以及它們之間的決策與變更結(jié)果。（來源：The Open Group）
ArchiMate 的組織包括三個核心 層和兩個擴展。
業(yè)務(wù)層
這一層模擬組織結(jié)構(gòu)和它產(chǎn)生的服務(wù)、業(yè)務(wù)角色和流程，以及產(chǎn)品與合同等業(yè)務(wù)對象。
應(yīng)用程序?qū)?/strong>
它描述了應(yīng)用程序組件和它們的交互、邏輯數(shù)據(jù)實體和它們之間的關(guān)系，并向上一層（業(yè)務(wù)層）提供所生成的服務(wù)。
技術(shù)層
這一層模擬硬件和軟件系統(tǒng)，以及連接網(wǎng)絡(luò)，顯示如何將它們轉(zhuǎn)化為提供給上一層（應(yīng)用層）的服務(wù)。
AchiMate 2.0 規(guī)范對核心層增加了兩個擴展。
動機
動機的概念用于模擬影響、引導(dǎo)或限制企業(yè)架構(gòu)的某個部分的設(shè)計或變更的動機或原因。
實現(xiàn)和遷移
這個擴展包括的概念可用于模擬變更項目和遷移規(guī)劃，以及支持計劃、組合和項目管理。
圖 2. ArchiMate 表示法的示例
與任何良好的架構(gòu)模型一樣，除了架構(gòu)層以外，ArchiMate 規(guī)范還支持觀點。觀點用于溝通架構(gòu)的特定方面。這些方面由利益相關(guān)者的關(guān)注點決定。因此，特定的觀點和不應(yīng)該包括的內(nèi)容應(yīng)該完全取決于利益相關(guān)者的關(guān)注點。
使用 EA 在企業(yè)中集成云服務(wù)
即使這里只是一個粗略的介紹，也可以明顯地看出，ArchiMate 模型的重點是服務(wù)和服務(wù)實現(xiàn)。這非常適合于云模型。
我們可以很容易地定義一個 SaaS 應(yīng)用程序服務(wù)，支持通過應(yīng)用程序組件實現(xiàn)的業(yè)務(wù)流程。
我們還可以模擬使用一個 PaaS 作為技術(shù)服務(wù)（或服務(wù)的集合），支持某個特定應(yīng)用程序的組件和數(shù)據(jù)，這樣做也很容易。
因此，SaaS 的功能要求可描述為：
所涉及的利益相關(guān)者的動機
它必須支持的業(yè)務(wù)模型
向其他應(yīng)用程序或從其他應(yīng)用程序暴露的接口
如果云和內(nèi)部系統(tǒng)之間需要連接，則提供消費者的技術(shù)水平所要求的服務(wù)
SaaS 解決方案的非功能性方面
示例場景：將流程外部化到云
為了更好地理解 EA 模型的使用，從而指定如何使用 SaaS 解決方案，我們將擴展來自 The Open Group 的 ArchiMate 示例。此示例使用一家名為 Archinsurance 的虛構(gòu)保險公司，該示例假定 Archinsurance 已將現(xiàn)有的 CRM 應(yīng)用程序確定為實現(xiàn)其業(yè)務(wù)目標的阻礙。
與所有利益相關(guān)者分享動機
Motivation 模型捕獲利益相關(guān)者的動機和要求。如圖 3 的流程圖所示，CEO 的動機是雙重的：
1.增加對給定客戶的重復(fù)銷售次數(shù)
2.在年終之前賺錢
CFO 在現(xiàn)金緊張的時期關(guān)注的是資本開支的 ROI，而 CIO 主要擔心的則是現(xiàn)有數(shù)據(jù)中心地板上的可用空間。安全部門的人會反對每一個異地解決方案，因為他們擔心客戶記錄等公司重要數(shù)據(jù)被盜或丟失，并要求執(zhí)行公司進行安全實踐。
圖 3. 新 CRM 的 Motivation 模型
從 CEO、CFO、CIO 和安全部門的要求來看，似乎要在云計算解決方案和更傳統(tǒng)的外包之間進行選擇，并且更傾向于前者。但是，安全要求難以得到滿足，并會將合資格的供應(yīng)商限制為能夠?qū)\動中的數(shù)據(jù)和靜止數(shù)據(jù)都提供數(shù)據(jù)加密的供應(yīng)商。
此外，選中的 SaaS 解決方案不能是一個 “純” 云服務(wù)，因為它必須包含保護機制，避免數(shù)據(jù)受到未經(jīng)授權(quán)的訪問，并且保證云和數(shù)據(jù)中心之間的數(shù)據(jù)一致性。因此，它將是一個混合解決方案。
識別來自業(yè)務(wù)模型的功能性要求
正如前面提到的，該示例假設(shè)新應(yīng)用程序支持前一個應(yīng)用程序的業(yè)務(wù)模型和流程。我們的 EA 業(yè)務(wù)模型將提供指導(dǎo)，以確定需要支持什么。
例如，目前的 CRM 提供了客戶管理服務(wù)和印刷服務(wù)，以支持索賠處理流程。以這種方式識別的服務(wù)將是新的 SaaS 解決方案的功能性要求（例如：“索賠的打印輸出必須包含以下數(shù)據(jù)：”）以及非功能性要求（例如：“索賠的格式和打印不得超過 3 分鐘“）的來源。
圖 4. 受到新 CRM 影響的應(yīng)用程序服務(wù)
設(shè)計新的應(yīng)用程序模型
當我們對未來的 SaaS 解決方案可以滿足所有功能性要求感到滿意時，下一步是設(shè)計如何驗證它與其他應(yīng)用程序（內(nèi)部應(yīng)用程序，甚至在云上的應(yīng)用程序）的接口要求。
圖 5. 新的應(yīng)用程序組合
在本例中，Archinsurance 應(yīng)用程序組合將改變從圖 5 左邊的組合修改為右邊的組合，其中 CRM 已經(jīng)成為企業(yè)外部的組件。CRM 組件的作用不變，但重要的是要仔細考慮它與其他組件（如，客戶數(shù)據(jù)訪問和策略數(shù)據(jù)庫管理）的接口，因為無論是簽名（被交換的數(shù)據(jù)）還是協(xié)議（用于交換的技術(shù)），都可能會發(fā)生變化。（請注意，在 ArchiMate 中，關(guān)系的方向與 UML 模型中的關(guān)系方向相反。）
為了強調(diào)這一方面，我們重新繪制了應(yīng)用程序模型，讓應(yīng)用程序接口和技術(shù)組件（如果有必要）顯式實現(xiàn)它們。對于圖 5 所示的兩個接口，鑒于 SaaS 實現(xiàn)的技術(shù)功能，這意味著在我們的網(wǎng)絡(luò)邊緣添加 ESB 技術(shù)組件，這些組件能夠向公司數(shù)據(jù)提供 Web 服務(wù)接口。我們將對企業(yè)數(shù)據(jù)倉庫使用一個安全的 ESB 和一個安全的 FTP 服務(wù)，以滿足該公司的安全管理人員的要求。
對于 Web 門戶的接口，我們已經(jīng)確定，真正的需求是單一用戶 ID 和密碼模式可以支持的一個簡單的 HTTP 重定向。因此，接觸代理將使用一個 ID 和密碼對來登錄到內(nèi)部系統(tǒng)和新的 CRM 應(yīng)用程序。
接口位于 LDAP 數(shù)據(jù)與云中的 CRM 所使用的身份驗證機制中的數(shù)據(jù)之間（在本例中，我們將 LDAP 更新作為事件推送到 CRM）。LDAP 身份驗證和 CRM 合作，以提供（新的）用戶身份驗證功能，就像 CRM 數(shù)據(jù)和內(nèi)部數(shù)據(jù)集市合作，提供了新的數(shù)據(jù)倉庫功能。
新的應(yīng)用程序模型將指導(dǎo)我們設(shè)計利用現(xiàn)有的內(nèi)部基礎(chǔ)架構(gòu)來適應(yīng)新的 SaaS 服務(wù)所需的變更。
圖 6. 修訂后的應(yīng)用程序模型圖
描述非功能性觀點
我們需要考慮的最后一個項目是非功能性觀點。
我們的重點在于以下兩個方面：
SaaS 解決方案必須能夠支持哪些非功能性要求（NFR）
我們需要做什么來連接兩個系統(tǒng)，這將如何影響內(nèi)部基礎(chǔ)架構(gòu)的 NFR
事實上，新服務(wù)必須滿足一組復(fù)雜的 NFR，其中一些 NFR 源于業(yè)務(wù)需求（例如，打印時間），另一些來自其他利益相關(guān)者，如安全管理人員。
此外，可能會增加一些要求，形成強調(diào)新服務(wù)的復(fù)雜組合（例如，有大量并發(fā)用戶時的響應(yīng)時間），在我們宣布可以接受 SaaS 解決方案之前，必須驗證這些要求。
服務(wù)供應(yīng)商的內(nèi)部架構(gòu)和基礎(chǔ)架構(gòu)并不是我們所關(guān)注的（盡職調(diào)查除外）。因此，無論我們執(zhí)行何種驗收測試，都將執(zhí)行一個黑箱測試。但是，必須考慮到基礎(chǔ)架構(gòu)。在我們的模式中，必須對保護 Archinsurance ESB 的 XML 防火墻和 HTTP/FTP 防火墻進行配置，以便考慮到公司與服務(wù)供應(yīng)商之間的新流程。
圖 7. CRM SaaS 非功能性觀點
結(jié)束語
本文介紹了 EA 模型如何在 SaaS 解決方案的采用中提供出色的指導(dǎo)，包括對供應(yīng)商的要求，以及作為內(nèi)部基礎(chǔ)架構(gòu)適應(yīng)新服務(wù)的需求的規(guī)范和設(shè)計。這種方法的示例使用了 Rational System Architect 中通過 Corso 插件提供的 TOGAF ArchiMate 表示法。
第三十四屆CIO班招生
北達軟EXIN網(wǎng)絡(luò)空間與IT安全基礎(chǔ)認證培訓(xùn)
北達軟EXIN DevOps Professional認證培訓(xùn)
責編：yangjun
免責聲明：本網(wǎng)站（http://www.www.gypb.net/）內(nèi)容主要來自原創(chuàng)、合作媒體供稿和第三方投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
本網(wǎng)站刊載的所有內(nèi)容（包括但不僅限文字、圖片、LOGO、音頻、視頻、軟件、程序等）版權(quán)歸原作者所有。任何單位或個人認為本網(wǎng)站中的內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，請及時通知本站，予以刪除。
搶沙發(fā)
