如何評估企業(yè)是否適合開發(fā)復合業(yè)務？

申請免費試用、咨詢電話：400-8352-114

本文討論企業(yè)計劃和開發(fā)一個CBS支持策略，從傳統(tǒng)企業(yè)架構過渡到支持CBS的參考架構所需的步驟。我們將討論一些用于分析和評估企業(yè)架構是否遵守業(yè)務、應用程序、集成和技術、以及它們的相關關鍵參數的不同維度的方法。這將有利于我們理解企業(yè)是否準備好使用Composite Business Services (CBS)構建解決方案，發(fā)現(xiàn)當前存在的差距，并滿足企業(yè)落后的每個維度中的要求。 　　

多數組織已經逐漸自動化了它們的業(yè)務流程要求，它們的方法是：將業(yè)務流程要求分割為應用用例，然后在預算之內基于需求將業(yè)務功能實現(xiàn)為IT應用程序。大多數這些應用程序在企業(yè)內的發(fā)展通常沒有計劃，有時，為了滿足新的業(yè)務流程要求，這些應用程序需要和其他程序集成。這些應用程序也許是內部應用程序，也可能是伙伴應用程序。這樣，對集成產品和技術的需求就越來越強烈。很多供應商都盯著這個市場，致力于成為Enterprise Application Integration (EAI)領域的市場領袖。同時，不同的企業(yè)架構藍圖，比如Zachman、TOGAF、TeA和IAF，也在尋求消除業(yè)務需求和已實現(xiàn)的IT解決方案之間的差距。許多這些企業(yè)架構方法寄希望于通過這些應用程序的集成來滿足業(yè)務流程要求，這導致了人們更加關注集成工作，而不是在企業(yè)層面上提供一個清晰的業(yè)務流程全貌。當這些應用程序本身面臨變革以滿足新的業(yè)務需求時，應用程序集成就變得困難重重。人們對項目提出了額外的需求：以更少的開發(fā)成本、更短的交付時間交付解決方案。業(yè)務驅動的 SOA 開發(fā)以復合應用程序或復合業(yè)務服務的形式對這個問題提供了一種可行的解決方案。一個Composite Business Service 是一個 Business Services集合，這些業(yè)務服務相互協(xié)作，與客戶的現(xiàn)有應用程序一起提供一個特定的業(yè)務解決方案。CBS（基于一些松散耦合的分布式資產的合成）實現(xiàn)一個資產模型，從而提供靈活的可重用解決方案。CBS可能包含遺留應用程序、打包應用程序和網絡交付服務。Composite Business Services的架構、設計和開發(fā)方法學有助于我們構建可重用的業(yè)務服務，這些服務處于一個更高的功能級別，開辟了進行無編碼業(yè)務驅動開發(fā)的美好前景。

對于已經采納了SOA的企業(yè)來說，可以通過采用可靠的行業(yè)內容模型輕松快速地遷移到復合應用程序開發(fā)。行業(yè)內容模型提供服務定義、可靠的數據模型以及基于行業(yè)標準和最佳實踐的公共服務。惟一需要完成的額外工作是使用這些可重用模型來重新遵循業(yè)務架構，針對適當的分解和粒度水平重新評估業(yè)務服務，以及根據調用它們的角色或通道增強或修改不同的功能特性。

如果一個企業(yè)還沒有采用業(yè)務驅動開發(fā)和SOA，且它想要開發(fā)復合應用程序，那么該企業(yè)需要在實踐中研究和評估組織本身的企業(yè)架構，以便直接遷移到CBS參考架構。應用程序和數據架構以及它們的集成方法本身不足以評估企業(yè)的SOA成熟度，就像Service Integration Maturity Models (SIMM)通常所做的那樣。此外，評估時還需要考慮業(yè)務功能和技術架構的企業(yè)支持。

企業(yè)架構評估方法

有一些可靠的定性和定量方法可用于評估實踐中存在的企業(yè)架構。定性方法試圖通過檢查設計周期中的架構決策來幫助評估企業(yè)架構處理提出的要求的能力。這種評估的結果派生出關于評價目標的定性結論。定量方法是更具追溯能力的方法，它們基于在實現(xiàn)階段執(zhí)行的數量測量。下面詳細介紹：

定性方法

定性評估一個解決方案的架構的方法是借助基于調查問卷和檢查表技術來檢查系統(tǒng)，這些方法適用于軟件開發(fā)周期（SDLC）中原型模型構建之前的早期階段。架構的定性評估方法也可以稱為預測性評估方法。它們試圖通過檢查 SDLC 早期階段做出的架構設計（決策）來評估架構處理提出的要求的能力。這種評估的結果提供關于評價目標的定性結論。類似的方法也可以應用于現(xiàn)有的企業(yè)軟件架構，這只需檢查基于調查問卷和檢查表的方法，無需任何定量測量。

基于調查問卷的方法：如果軟件系統(tǒng)的目標很容易識別并定性，則可以定義一個問題列表，這些問題可以應用到軟件系統(tǒng)的總體架構。這些問題構成用于評估架構的調查問卷，可以處理架構定義的各個不同方面。

基于檢查表的方法：這種方法類似于基于調查問卷的方法，但是，它通常關注架構將解決的特定特性。與基于調查問卷的方法相比，基于檢查表的方法需要一個更成熟的評估實踐。

定量方法

一個解決方案的架構的定量評估方法是在現(xiàn)有系統(tǒng)上執(zhí)行一些實驗。這些方法更具追溯能力，它們基于在實現(xiàn)階段執(zhí)行的數量測量。原型模型在 SDLC 早期階段構建，在這些模型上執(zhí)行定量測量，然后根據這些結果對架構進行定量評估。

基于指標的方法：這種方法是基于架構組件的測量的定量分析。這種測量的目的是發(fā)現(xiàn)總體架構中存在問題的地方，以便引入一些更改來改進設計。

基于概念證明（Proof-of-Concept，PoC）的方法：采用這種方法時，用于實驗和模擬的原型是開發(fā)過程生成的工件。在這種方法中，我們通過考慮一個表示架構的模型的復雜應用程序用例來實際測試一個實現(xiàn)。在設計和開發(fā)在大量用例中發(fā)生前，這些原型結果用于回答一些關鍵的架構問題。

根據可用時間和組織對評估的支持，我們可以遵循定性方法和定量方法中的一種，或者同時使用兩種方法來評估企業(yè)架構及其開發(fā)復合應用程序的可行性。圖 1 展示了一個明確定義的聯(lián)合評估方法。

圖 1. 評估過程方法

CBS的維度

為了適應IBM的CBS基礎參考架構，需要設計一個評估過程來評估企業(yè)架構。CBS有4個維度，下面逐一介紹。

業(yè)務架構

這個維度解決用戶、規(guī)劃人員和業(yè)務經理關注的問題，主要從用戶角度考察系統(tǒng)功能。它主要關注業(yè)務性能、功能和可用性。它擁有以下幾個子視圖（請參見 “參考資料” 部分獲取一個Open Group鏈接，可以從該鏈接鏈接到以下子視圖）：

●人員視圖 關注系統(tǒng)的人力資源方面，它檢查系統(tǒng)中的人類角色。 　　

●業(yè)務流程視圖 處理系統(tǒng)中涉及的用戶流程。 　　

●業(yè)務功能視圖 處理支持流程所需的功能。 　　

●業(yè)務信息視圖 處理支持流程所需的信息。 　　

●可用性視圖 考慮系統(tǒng)及其環(huán)境的可用性。 　　

●業(yè)務性能視圖 考慮系統(tǒng)及其環(huán)境的性能方面。 　　

應用程序和數據架構

這個維度描述涉及數據和應用程序系統(tǒng)領域的架構，它包括應用程序軟件庫存、圖表和應用程序之間的接口（這包括事件、消息和數據流）。數據架構包括概念、邏輯和物理數據模型及其元數據模型。

集成架構

集成架構描述企業(yè)中的集成的各個方面，包括人員、系統(tǒng)和數據庫的內部和外部集成。開發(fā)靈活高效的復合業(yè)務服務需要檢查集成的不同方面，這些集成子視圖包括：

訪問/呈現(xiàn)集成視圖 處理訪問系統(tǒng)功能的不同方法，以及對各種類型的客戶端（門戶、移動、內聯(lián)網、電話設備、電子郵件設備、PDAs 等）的支持。 　　

應用程序集成視圖 處理組織內應用程序的集成，或者使用企業(yè)應用程序的業(yè)務伙伴。這允許應用程序互相連接，以便它們能夠在企業(yè)層面上更好共享和使用信息。 　　

信息（數據）集成視圖 處理可以跨企業(yè)集成的各種形式的業(yè)務信息。這種集成在一個統(tǒng)一的信息資產視圖上支持一致的搜索、訪問、復制、轉換和分析，從而滿足業(yè)務需求。 　　

流程集成視圖 處理企業(yè)內外部業(yè)務中的變化，以及它如何在跨人員和異構系統(tǒng)的流程建模、自動化和監(jiān)控過程中操作。 　　

技術架構

本質上，技術架構是包含硬件和軟件組件的基礎設施，它包含企業(yè)服務器、數據服務器、防火墻、應用程序基礎設施、安全、監(jiān)控和中間件。技術架構還描述企業(yè)中使用的編程語言和操作系統(tǒng)。這個維度還評估已開發(fā)的軟件組件利用開放技術標準的程度。

如何評估企業(yè)架構的CBS就緒程度

評估企業(yè)架構的第一步是完成一個Request for Information (RFI)，在其中處理前面提到的 4 個維度。這個RFI將發(fā)送給客戶。從客戶獲得響應之后，準備一個基于檢查表的模板，針對這個模板驗證響應。這些模板最終結果針對CBS參考架構和CBS服務的開發(fā)對現(xiàn)有架構進行定性評估。如果一個組織在所有 4 個維度的定性評估中均合格，那么將繼續(xù)進行第二個步驟 —— 定量評估，這需要該組織準備一個基于各種場景開發(fā)一個原型模型的說明。這個說明將描述如何根據場景設計、開發(fā)這個原型模型并描述將用于評估的指標，“基于場景的PoC評估” 小節(jié)將詳細介紹這個說明。圖 2 展示了用于遵循CBS的定性和定量方法。

圖 2. 定性和定量迭代

業(yè)務架構遵循

一個定性評估可以從以下調查問卷開始。可以根據組織提供解決方案的業(yè)務領域和功能區(qū)域評估該組織。首先，應檢查組織的基礎設施方面，以支持業(yè)務需求。以下是一些需要考慮的重點問題：

組織有良好定義的Business Process Management System (BPMS)來定義、維護、測量、分析和持續(xù)改進它們的業(yè)務流程嗎？ 　　

企業(yè)擁有業(yè)務流程建模器、可執(zhí)行流程建模器、流程執(zhí)行引擎、業(yè)務活動監(jiān)視器、流程管理門戶等工具來支持BPMS的完整生命周期管理嗎？ 　　

組織建立了一個BPM Center of Excellence (BPM-COE)中心來實踐這樣的框架、工具和方法學，以便將業(yè)務要求有效地轉換為IT系統(tǒng)嗎？ 　　組織擁有幫助確保公司方向在運營層面上實現(xiàn)的流程治理嗎？ 　　RFI中的 “業(yè)務要求” 部分需要將預定義的業(yè)務子功能包含到企業(yè)從事的業(yè)務領域。我們可以將一個客戶銀行自助服務門戶作為一個示例。這個門戶可能包含以下子功能：賬戶開立、賬戶查看、支票簿和ATM復制PIN的服務請求、賬單支付、資金轉賬和信用卡服務等。組織需要在這些子功能中或圍繞這些子功能提供它們的業(yè)務解決方案。根據從企業(yè)獲取的RFI響應，組織業(yè)務遵循應該考慮以下幾點：

●組織當前同時支持多少業(yè)務子功能？ 　　

●有多少業(yè)務子功能需要根據預定義的功能進行修改？ 　　

●有多少業(yè)務子功能需要從頭開發(fā)？ 　　

有多少業(yè)務子功能當前不受支持，但有明確的路線圖以便在一個規(guī)定的時間范圍內支持那些服務？ 　　“業(yè)務架構評估”

●部分還包含一個關于通過業(yè)務流程模型和業(yè)務服務實現(xiàn)業(yè)務子功能的問卷調查。在評估他們的業(yè)務服務實現(xiàn)時應該考慮以下幾點：

●組織采用了一些行業(yè)特有的業(yè)務流程模型了嗎？ 　　

●他們使用自己的自定義構建模型嗎？如果是，這些自定義構建模型吸收業(yè)務要求中的變化的靈活性如何？ 　　

●他們的業(yè)務服務支持ACCORD、HiPAA和SWIFT等行業(yè)特有的數據模型來在其他服務之間交換數據嗎？ 　

●組織遵循任何標準方法或技術來識別RUP for SOA、SOMA等業(yè)務服務嗎？ 　　

●已實現(xiàn)的業(yè)務服務提供基于業(yè)務政策和用戶上下文的靈活的可調節(jié)行為嗎？ 　　

●業(yè)務服務是通過多個通信通道提供的嗎？ 　　

●業(yè)務服務是從不同的IT系統(tǒng)實現(xiàn)的嗎？如果是，它來自一個Silo格式嗎？是集成的嗎？或者，它是來自組件化的流程集成的嗎？ 　　

●上述問卷調查的所有答案將針對遵循CBS服務的開發(fā)進行研究和分析，并最終針對這個部分準備一個定性評估圖表。

應用程序和數據架構遵循

在這個小節(jié)中，我們將詳細介紹如何評估一個組織的應用程序和數據架構，以便遵循CBS參考架構。總體應用程序架構成熟度可以根據以下幾個標準進行評估：與CBS參考架構的接近程度、IBM 的電子商務模式、企業(yè)應用程序架構模式、以及是否使用模型驅動的架構工具進行開發(fā)。這個部分將嚴格評估一些架構原則，比如層與層之間的松散耦合、遵循的MVC模式、實踐的分層概念以及應用程序的伸縮能力。來自他們的應用程序架構的關鍵架構層和關鍵評估點包括：

●通道和呈現(xiàn)層 　　

●業(yè)務流程和精編層 　　

●服務或呈現(xiàn)功能 　　

●業(yè)務規(guī)則 　　

●服務注冊層 　　

●數據和數據訪問層 　　

以下小節(jié)將詳細介紹上述每個主題：

通道和呈現(xiàn)層

應用程序或系統(tǒng)的架構評估要考慮架構如何與通道和呈現(xiàn)層相關。復合應用程序需要從一個共享的公共托管環(huán)境服務多個客戶機。通道和呈現(xiàn)層從以下幾個點評估。

呈現(xiàn)層應該支持STRUTS、JSF和Dot Net U等開放標準框架，必須可以輕松擴展或修改來構建自定義呈現(xiàn)層框架。 　　

●呈現(xiàn)層還應該足夠靈活，以便添加PDA客戶端、表單和電子郵件等新通道。 　　

●如果組織正在使用某種自主框架，那么應該評估該框架與開源框架之間的關系。 　　

●檢查通過Web服務接口的無外設（headless）系統(tǒng)功能調用。 　　

●檢查呈現(xiàn)層是否與當前系統(tǒng)/應用程序松散耦合。 　　

●系統(tǒng)支持哪些不同類型的物理設備/通道？向現(xiàn)有系統(tǒng)添加一個新的物理設備的靈活性如何？ 　　

業(yè)務流程和精編層

應用程序架構的評估要考慮業(yè)務流程和精編功能。評估人員應該檢查組織，查看他們是否采用任何業(yè)務流程層和運行時引擎來編排他們的業(yè)務服務/應用程序功能。以下幾點用于評估這個架構層。

如果組織使用了任何自主流程流或工作流層，通過將其移植到外部BPEL設計工具和運行時引擎來檢查它是否遵循BPEL標準。識別在開放標準運行是引擎上運行這樣的自主工作流需要遵循的步驟和程序。 　　

●組織是否擁有任何自動為部署而生成BPEL運行時代碼的業(yè)務流程建模工具？ 　　

●檢查遵循BPEL的運行時引擎如何實現(xiàn)為一個可伸縮的成熟產品，并擁有補償、業(yè)務和技術異常處理功能以及指標、交易量監(jiān)控功能。 　　

●檢查當前流程流是否支持調用人工任務、選擇器、業(yè)務規(guī)則和ESB。 　　

●檢查BPEL流程流和服務交互是如何實現(xiàn)的：它們是緊密耦合還是松散耦合的？BPEL流程本身可以使用開放標準呈現(xiàn)嗎？ 　　

服務和呈現(xiàn)功能

現(xiàn)在，我們將從另一個角度檢查如何評估系統(tǒng)和應用程序的架構：它如何與作為接口和API的服務或呈現(xiàn)功能相關。服務成熟度從以下幾點確定：

●如何訪問服務？是通過Web服務或SCA接口這樣的開放技術標準嗎？ 　　

●服務如何通過底層系統(tǒng)實現(xiàn)，它們是緊密耦合的還是松散耦合的？ 　　

●組織的邊界服務遵循ACCORD、HiPAA等行業(yè)標準進行企業(yè)數據共享和訪問嗎？ 　　

●服務使用適當的分解和粒度級別實現(xiàn)嗎？ 　　

●服務同時支持同步和異步調用嗎？ 　　

●服務同時支持異常處理和故障恢復嗎？ 　　

●服務在設計時和運行時都有在注冊表中發(fā)布的條件嗎？ 　　

●設計時和運行時都支持服務版本控制嗎？ 　　

●技術服務如何組織，以及應用程序服務或業(yè)務服務在實現(xiàn)業(yè)務交易時如何與這些技術服務交互？ 　　

業(yè)務規(guī)則

本小節(jié)評估應用程序的架構與業(yè)務規(guī)則之間的關系。業(yè)務規(guī)則是如何實現(xiàn)的？它們與系統(tǒng)緊密耦合且不能被外部化嗎？盡管有些實現(xiàn)是松散耦合的，但它們仍舊不能被外部化，要修改規(guī)則需要代碼級別的修改。有些實現(xiàn)被松散耦合和外部化，但使用一個自主規(guī)則引擎和自主編程框架。有些業(yè)務規(guī)則也是松散耦合和外部化的，它們的編程模型遵循JSR94等標準，規(guī)則可以隨業(yè)務要求輕松改變。以下幾點用于評估解決方案的架構中采用的業(yè)務規(guī)則的強度。

規(guī)則引擎是如何構建的？它是純Java類或EJB嗎？它實現(xiàn)為一個可伸縮的成熟產品，具有在線編輯和完整的生命周期管理支持嗎？ 　　

現(xiàn)有規(guī)則引擎支持第三方規(guī)則引擎連接，以便添加新的規(guī)則或將現(xiàn)有規(guī)則傳輸到第三方引擎嗎？ 　　

檢查這個規(guī)則組件是否可以呈現(xiàn)為一個Web服務或SCA服務，以便從外部BPEL流程流編排（orchestrate）或從第三方客戶機調用。 　　

服務注冊層

服務注冊表提供服務的注冊、元數據的管理和自動化服務。這個層根據以下問題的答案進行評估：

●是否正在使用一個注冊表？如果沒有，使用共享服務的各方如何知道服務的可用性和功能？如何維護服務信息以避免不必要的復制？ 　　

●有什么政策來確保注冊表的正確使用？ 　　

●如何在注冊表內部和外部定義和管理服務元數據？設計中考慮了未來可能出現(xiàn)的長期需求了嗎？ 　　

●在SOA生命周期（從開始到結束）中的哪個階段使用這個注冊表？ 　　

●服務訪問控制和更改管理政策是如何治理的？是否有適當的控制來平衡安全、可修改性、以及遵循IT和其他標準？ 　　

●注冊表正用于服務調用的動態(tài)路由（比如，故障轉移、負載平衡和應用程序分區(qū)）嗎？如果是，注冊表安裝是單個故障點嗎？它滿足性能和故障轉移時間要求嗎？ 　　

●注冊表是公開的還是私有的？注冊表實現(xiàn)能恰當地處理內部和外部服務之間的區(qū)別嗎？ 　　

數據和數據訪問層

●這個小節(jié)評估應用程序的架構與數據和數據訪問之間的關系。進行這個小節(jié)的評估時要考慮以下幾點：

●數據模型有多健壯和多靈活？它遵循成熟的行業(yè)標準嗎？可以輕松添加新的數據元素嗎？ 　　

●數據訪問層使用什么實現(xiàn)？它是緊密耦合且使用自主框架嗎？它是松散耦合且遵循諸如開源數據對象之類的成熟框架嗎？ 　　

●組織利用toplink、hibernate或iBatis等對象關系映射工具嗎？ 　　

●如果一個數據資源庫跨企業(yè)分發(fā)，它遵循哪種機制來允許對應用程序的訪問？ 　　

●支持 “信息即服務”，組織需要利用哪些種類的工具或產品？ 　　

●企業(yè)數據架構如何通過更少的數據延遲幫助處理從事務型數據到分析型數據的轉換？ 　　

●企業(yè)數據架構如何幫助對數據進行分析性處理，以便根據需要向業(yè)務用戶交付信息？ 　　

集成架構遵循

這個小節(jié)從以下角度評估應用程序的架構：它與包含第三方和遺留系統(tǒng)的應用程序、組件和服務的集成之間的關系。評估集成層的成熟度時應考慮以下幾點。

需要詢問的關于集成層的幾個樣例評估問題是：

●集成層的健壯程度如何？它實現(xiàn)為一個可伸縮的成熟產品嗎？或者，它基于一個按需（as-needed）基礎，使用一個開源API或使用多個連接器和適配器來實現(xiàn)嗎？ 　　

●受到支持的集成架構模式是什么？它將使用ESB、hub and spoke或者point-to-point嗎？ 　　

●集成層支持的功能有哪些，比如消息路由、數據格式轉換、針對所有服務的中央安全網關？它將支持發(fā)布和訂閱消息模型和消息聚合嗎？

●集成層與系統(tǒng)或應用程序的其余部分松散耦合或緊密耦合的程度如何？ 　　

●組織當前支持哪些不同類型的集成規(guī)范/標準/框架？例如，它支持RPC、RMI、SOAP/JMS或SOAP/HTTP嗎？ 　　

集成層支持異常處理、事件管理、審計、日志記錄等輔助功能并支持訪問控制嗎？ 　　

●當前遵循的應用程序架構提供了一個條件來將這個集成層引入到擁有具有集成架構的成熟解決方案的層之間嗎？ 　　

我們特意通過獲取關于下面的問題的信息來采集關于遺留應用程序集成在企業(yè)內部發(fā)生方式的信息：

●為新系統(tǒng)和遺留系統(tǒng)的集成采用了什么機制？我們尋找的機制包括屏幕搜刮器、Web服務調用、帶有用于遺留平臺的適配器的ESB、消息傳遞系統(tǒng)、直接遺留軟件API調用、特定于技術的網關和橋接。 　　

●已選擇的機制是如何根據復雜性和實現(xiàn)成本進行比較的？ 　　

●根據預期的調用數量、理想的響應時間，已選擇的機制滿足系統(tǒng)性能要求嗎？ 　　

●訪問控制和數據隱私等安全要求在現(xiàn)有和遺留系統(tǒng)中都得到滿足了嗎？ 　　

技術架構遵循

下面我們檢查軟件基礎設施將如何支持任務關鍵的核心應用程序的部署。企業(yè)服務器、應用程序服務器、流程服務器、數據庫服務器、安全服務器、通知服務器以及它們的部署配置屬于這個類別。技術架構評估涵蓋以下主題：

基礎設施服務 　　

●安全架構 　　

●系統(tǒng)管理和支持服務 　　

●開放技術標準 　　

●經營模型和部署架構 　　

●性能 　　

●其他NFR、可用性和可靠性 　　

●當前遵循的應用程序架構提供了一個條件來將這個集成層引入到擁有具有集成架構的成熟解決方案的層之間嗎？

●我們特意通過獲取關于下面的問題的信息來采集關于遺留應用程序集成在企業(yè)內部發(fā)生方式的信息：

為新系統(tǒng)和遺留系統(tǒng)的集成采用了什么機制？我們尋找的機制包括屏幕搜刮器、Web服務調用、帶有用于遺留平臺的適配器的ESB、消息傳遞系統(tǒng)、直接遺留軟件API調用、特定于技術的網關和橋接。 　　

●已選擇的機制是如何根據復雜性和實現(xiàn)成本進行比較的？ 　　

●根據預期的調用數量、理想的響應時間，已選擇的機制滿足系統(tǒng)性能要求嗎？ 　　

●訪問控制和數據隱私等安全要求在現(xiàn)有和遺留系統(tǒng)中都得到滿足了嗎？ 　　

基礎設施服務

我們檢查了應用程序部署的重用或在企業(yè)層面的重用所需的各種基礎設施組件。如果這些服務在企業(yè)的所有層面上都是可重用的，那么這說明組織是統(tǒng)一的，擁有一個統(tǒng)一的方法來使用含有成熟服務的架構解決方案。通過此前使用這樣的服務構建的解決方案提供的歷史數據，可以很容易地確定組織能否滿足服務水平協(xié)議。評估基于組織中可用的各種服務。為確定如何最好地建立基礎設施架構，我們將考慮以下幾個問題：

●組織中有哪些公共組件/服務可用于開發(fā)自定義應用程序/打包應用程序？這些服務可能包括數據服務、日志服務、故障處理服務、審計、搜索、通知以及會話管理服務。 　　

●組織中有哪些不同類型的門戶服務可重用并獲得統(tǒng)一的觀感？這些服務包括個性化、報告、本地化和Web流量監(jiān)控服務。 　　

●組織中有哪些不同類型的企業(yè)基礎設施服務可用？我們將尋找LDAP、電子郵件、協(xié)作（聊天/IM/白板）和內容管理等服務。 　　

●組織中有哪些不同的主數據管理服務可用？自定義數據集成服務和產品主數據管理服務屬于這個類別。 　　

安全架構

重要的是要理解當前安全模型、用戶角色、權限和應用程序功能。以下幾點可以幫助評估安全架構的成熟度：

●組織中實現(xiàn)了哪些不同的IT安全服務？ 　　

●確認IT安全是否可以在所有應用程序層實現(xiàn)？ 　　

●更改和更新安全架構的難度如何？ 　　

●查明安全架構是否通過一個協(xié)議防火墻、域防火墻和企業(yè)防火墻配置實現(xiàn)。 　　

●應用程序是否支持單點登錄（SSO）？SSO同時處于應用程序和Web服務級別嗎？ 　　

●組織擁有現(xiàn)成的安全政策管理框架嗎？ 　　

系統(tǒng)管理和支持服務

在這個小節(jié)中，我們將評估應用程序的架構與應用程序管理和支持服務之間的關系。有些應用程序架構完全沒有系統(tǒng)管理服務支持，而有些應用程序的架構和設計優(yōu)良，擁有完整的生命周期服務支持/應用程序管理，比如治理、訪問、授權和監(jiān)控。

檢查系統(tǒng)監(jiān)控和管理服務是否使用JMX、開源SNMP API等開放標準和API實現(xiàn)。

檢查是否所有這些管理服務或使用的開放標準產品正在實現(xiàn)監(jiān)控業(yè)務和 IT 關鍵性能指標的要求。

檢查監(jiān)控數據是否正在幫助管理架構師調優(yōu)基礎設施，并幫助業(yè)務分析師重新定義優(yōu)化的業(yè)務流程。

部署架構

下面我們檢查各種中間件服務器，它們用于支持通過指定的應用程序架構實現(xiàn)的解決方案。通常，組織將提供解決方案的一個詳細部署模型。

檢查組織在凍結他們的拓撲架構時是否遵循了任何標準電子商務部署架構模式？

檢查系統(tǒng)的經營模型和拓撲架構，它們將展示將在一個典型生產環(huán)境中運行的硬件節(jié)點以及軟件組件的各種版本。檢查模型是否完整清晰，是否提供了關于區(qū)域、硬件、軟件以及連接規(guī)范或細節(jié)的詳細信息。

檢查其他方面，比如解決方案是否虛擬化，解決方案網格是否允許您利用集群化和工作負載平衡。

性能

通過檢查組織針對低、中和復雜用例提供的性能指標結果來評估應用程序的性能。根據用戶數量和事務數量，通過支持的硬件配置獲取關于系統(tǒng)伸縮性的信息。多數組織都不夠成熟，不能提供服務級別的性能基準測試。重點關注這樣的服務水平性能指標：能夠幫助預測構建復合應用程序時的端到端響應時間和計劃服務器容量。另外，檢查以下幾個方面：

●根據事務響應時間和流量，組織擁有任何能夠改進解決方案性能的軟件架構組件或產品嗎？ 　　

●組織擁有性能建模和容量計劃工具嗎？當前解決方案考慮了未來 2 至 3 年的用戶工作負載增長計劃了嗎？ 　　

●在解決方案階段的Software Development Life Cycle過程中，我們想查看性能工程生命周期方法學/工具是否已經被遵循或應用。 　　

其他非功能要求（可用性和可靠性）

●在以下關鍵條件下檢查系統(tǒng)可用性：

●當系統(tǒng)受到未授權或未格式化的消息的攻擊時 　　

●當系統(tǒng)超載時 　　

●在維護期間 　　

●在軟件版本更改期間 　　

●為以下項目檢查故障和恢復之下的系統(tǒng)可靠性：

●事務性流程狀態(tài) 　　

●恢復之后維護相同的數據 　　

上述每個維度中提到的問卷調查幫助您使用一些定性屬性評估企業(yè)架構，比如低度、中度和高度遵循IBM CBS參考架構。

為了更好地理解對CBS架構的遵循程度的定量評估概念，下面討論一個基于應用程序架構維度中的PoC評估的樣例場景。

基于場景的PoC評估方法

我們應該通過構建基于場景PoCs來定量評估此前提到過的架構維度。我們應該通過按照企業(yè)定義的功能來生成功能測試案例來評估業(yè)務架構。這些測試案例將在已部署的解決方案上運行，并使用提交的功能特性來驗證。定量評估基于功能測試期間確定的測試案例的數量進行。類似的定量評估將基于一個評估場景分別針對信息、集成和技術架構部分進行。例如，我們將考慮一個來自應用程序架構維度的典型場景，我們將在一個組織轉向CBS參考架構的架構轉換階段基于這個場景評估該組織。

場景：

現(xiàn)有應用程序服務和組件可以直接用于開發(fā)一個復合應用程序嗎？

定量評估基于以下這組預先定義的評估點進行。每個確認點都以以下方式定義：它擁有一個獨立的不同于它的理想遵循度的差別水平。查看以降序排列的數據點，它們偏離CBS服務遵循度，因此，針對每個點的評估得分逐漸減小。

組織擁有一些服務/組件，它們直接呈現(xiàn)為Web服務，正在從BPEL流程使用。這些服務在UDDI或一些等效注冊表中發(fā)布（得分：100%）。

組織擁有一些服務/組件，它們直接呈現(xiàn)為Web服務，正在從BPEL流程使用。但這些服務沒有在UDDI或一些等效注冊表中發(fā)布（得分：75%）。

組織擁有一些服務/組件，它們通過某個架構框架組件（網關服務）間接呈現(xiàn)為 Web 服務，但能夠從 BPEL 流程使用（得分：50%）。

組織擁有一些服務/組件，它們直接呈現(xiàn)為Web服務，但不能從外部客戶機調用，原因是：由于不遵守WSDL，SOAP地址綁定URL規(guī)范缺失（得分：25%）。

組織擁有一個作為EJB接口實現(xiàn)和呈現(xiàn)的服務/組件（得分：0%）。

根據這個場景，我們通過將一個Web服務導入其組裝環(huán)境來構建一個小型PoC，并通過一個已構造的BPEL流程、使用針對一個Web服務的直接以及間接（通過UDDI）端點URL查詢來調用它。如果使用條件 4 中指定的Web服務類型，那么這種類型的WSDL不允許導入WID本身?；谶@些PoC執(zhí)行和觀察，定量評估針對這個場景進行。類似的PoC模型基于集成和技術架構維度中的場景構建，并對它們的架構進行定性評估。

結束語

在本文中，我們通過從一個組織獲取的RFI響應檢查了企業(yè)架構。首先，我們參照CBS解決方案參考架構，根據前面小節(jié)中提到的評估點對他們的業(yè)務、應用程序和數據、集成和技術架構遵循度進行初始定性評估。由于評估基于企業(yè)提供的信息，因此企業(yè)架構的定量評估通過在現(xiàn)場執(zhí)行一個PoC來進行，這樣您就能確定企業(yè)的狀態(tài)——企業(yè)是否準備好利用企業(yè)的現(xiàn)有資產，因為這些資產可能與復合業(yè)務服務有關。最終的PoC評估報告將解釋組織需要彌補的差距，以便繼續(xù)前進，構建復合業(yè)務服務。如果組織還不能完全滿足CBS解決方案的要求，那么需要準備一個支持策略并提交給組織。