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

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

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

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

對(duì)于已經(jīng)采納了SOA的企業(yè)來說，可以通過采用可靠的行業(yè)內(nèi)容模型輕松快速地遷移到復(fù)合應(yīng)用程序開發(fā)。行業(yè)內(nèi)容模型提供服務(wù)定義、可靠的數(shù)據(jù)模型以及基于行業(yè)標(biāo)準(zhǔn)和最佳實(shí)踐的公共服務(wù)。惟一需要完成的額外工作是使用這些可重用模型來重新遵循業(yè)務(wù)架構(gòu)，針對(duì)適當(dāng)?shù)姆纸夂土６人街匦略u(píng)估業(yè)務(wù)服務(wù)，以及根據(jù)調(diào)用它們的角色或通道增強(qiáng)或修改不同的功能特性。

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

企業(yè)架構(gòu)評(píng)估方法

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

定性方法

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

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

基于檢查表的方法：這種方法類似于基于調(diào)查問卷的方法，但是，它通常關(guān)注架構(gòu)將解決的特定特性。與基于調(diào)查問卷的方法相比，基于檢查表的方法需要一個(gè)更成熟的評(píng)估實(shí)踐。

定量方法

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

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

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

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

圖 1. 評(píng)估過程方法

CBS的維度

為了適應(yīng)IBM的CBS基礎(chǔ)參考架構(gòu)，需要設(shè)計(jì)一個(gè)評(píng)估過程來評(píng)估企業(yè)架構(gòu)。CBS有4個(gè)維度，下面逐一介紹。

業(yè)務(wù)架構(gòu)

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

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

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

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

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

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

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

應(yīng)用程序和數(shù)據(jù)架構(gòu)

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

集成架構(gòu)

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

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

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

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

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

技術(shù)架構(gòu)

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

如何評(píng)估企業(yè)架構(gòu)的CBS就緒程度

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

圖 2. 定性和定量迭代

業(yè)務(wù)架構(gòu)遵循

一個(gè)定性評(píng)估可以從以下調(diào)查問卷開始。可以根據(jù)組織提供解決方案的業(yè)務(wù)領(lǐng)域和功能區(qū)域評(píng)估該組織。首先，應(yīng)檢查組織的基礎(chǔ)設(shè)施方面，以支持業(yè)務(wù)需求。以下是一些需要考慮的重點(diǎn)問題：

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

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

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

●組織當(dāng)前同時(shí)支持多少業(yè)務(wù)子功能？ 　　

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

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

有多少業(yè)務(wù)子功能當(dāng)前不受支持，但有明確的路線圖以便在一個(gè)規(guī)定的時(shí)間范圍內(nèi)支持那些服務(wù)？ 　　“業(yè)務(wù)架構(gòu)評(píng)估”

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

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

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

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

●組織遵循任何標(biāo)準(zhǔn)方法或技術(shù)來識(shí)別RUP for SOA、SOMA等業(yè)務(wù)服務(wù)嗎？ 　　

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

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

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

●上述問卷調(diào)查的所有答案將針對(duì)遵循CBS服務(wù)的開發(fā)進(jìn)行研究和分析，并最終針對(duì)這個(gè)部分準(zhǔn)備一個(gè)定性評(píng)估圖表。

應(yīng)用程序和數(shù)據(jù)架構(gòu)遵循

在這個(gè)小節(jié)中，我們將詳細(xì)介紹如何評(píng)估一個(gè)組織的應(yīng)用程序和數(shù)據(jù)架構(gòu)，以便遵循CBS參考架構(gòu)?？傮w應(yīng)用程序架構(gòu)成熟度可以根據(jù)以下幾個(gè)標(biāo)準(zhǔn)進(jìn)行評(píng)估：與CBS參考架構(gòu)的接近程度、IBM 的電子商務(wù)模式、企業(yè)應(yīng)用程序架構(gòu)模式、以及是否使用模型驅(qū)動(dòng)的架構(gòu)工具進(jìn)行開發(fā)。這個(gè)部分將嚴(yán)格評(píng)估一些架構(gòu)原則，比如層與層之間的松散耦合、遵循的MVC模式、實(shí)踐的分層概念以及應(yīng)用程序的伸縮能力。來自他們的應(yīng)用程序架構(gòu)的關(guān)鍵架構(gòu)層和關(guān)鍵評(píng)估點(diǎn)包括：

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

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

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

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

●服務(wù)注冊(cè)層 　　

●數(shù)據(jù)和數(shù)據(jù)訪問層 　　

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

通道和呈現(xiàn)層

應(yīng)用程序或系統(tǒng)的架構(gòu)評(píng)估要考慮架構(gòu)如何與通道和呈現(xiàn)層相關(guān)。復(fù)合應(yīng)用程序需要從一個(gè)共享的公共托管環(huán)境服務(wù)多個(gè)客戶機(jī)。通道和呈現(xiàn)層從以下幾個(gè)點(diǎn)評(píng)估。

呈現(xiàn)層應(yīng)該支持STRUTS、JSF和Dot Net U等開放標(biāo)準(zhǔn)框架，必須可以輕松擴(kuò)展或修改來構(gòu)建自定義呈現(xiàn)層框架。 　　

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

●如果組織正在使用某種自主框架，那么應(yīng)該評(píng)估該框架與開源框架之間的關(guān)系。 　　

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

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

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

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

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

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

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

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

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

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

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

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

●如何訪問服務(wù)？是通過Web服務(wù)或SCA接口這樣的開放技術(shù)標(biāo)準(zhǔn)嗎？ 　　

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

●組織的邊界服務(wù)遵循ACCORD、HiPAA等行業(yè)標(biāo)準(zhǔn)進(jìn)行企業(yè)數(shù)據(jù)共享和訪問嗎？ 　　

●服務(wù)使用適當(dāng)?shù)姆纸夂土６燃?jí)別實(shí)現(xiàn)嗎？ 　　

●服務(wù)同時(shí)支持同步和異步調(diào)用嗎？ 　　

●服務(wù)同時(shí)支持異常處理和故障恢復(fù)嗎？ 　　

●服務(wù)在設(shè)計(jì)時(shí)和運(yùn)行時(shí)都有在注冊(cè)表中發(fā)布的條件嗎？ 　　

●設(shè)計(jì)時(shí)和運(yùn)行時(shí)都支持服務(wù)版本控制嗎？ 　　

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

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

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

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

現(xiàn)有規(guī)則引擎支持第三方規(guī)則引擎連接，以便添加新的規(guī)則或?qū)F(xiàn)有規(guī)則傳輸?shù)降谌揭鎲幔?　　

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

服務(wù)注冊(cè)層

服務(wù)注冊(cè)表提供服務(wù)的注冊(cè)、元數(shù)據(jù)的管理和自動(dòng)化服務(wù)。這個(gè)層根據(jù)以下問題的答案進(jìn)行評(píng)估：

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

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

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

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

●服務(wù)訪問控制和更改管理政策是如何治理的？是否有適當(dāng)?shù)目刂苼砥胶獍踩⒖尚薷男?、以及遵循IT和其他標(biāo)準(zhǔn)？ 　　

●注冊(cè)表正用于服務(wù)調(diào)用的動(dòng)態(tài)路由（比如，故障轉(zhuǎn)移、負(fù)載平衡和應(yīng)用程序分區(qū)）嗎？如果是，注冊(cè)表安裝是單個(gè)故障點(diǎn)嗎？它滿足性能和故障轉(zhuǎn)移時(shí)間要求嗎？ 　　

●注冊(cè)表是公開的還是私有的？注冊(cè)表實(shí)現(xiàn)能恰當(dāng)?shù)靥幚韮?nèi)部和外部服務(wù)之間的區(qū)別嗎？ 　　

數(shù)據(jù)和數(shù)據(jù)訪問層

●這個(gè)小節(jié)評(píng)估應(yīng)用程序的架構(gòu)與數(shù)據(jù)和數(shù)據(jù)訪問之間的關(guān)系。進(jìn)行這個(gè)小節(jié)的評(píng)估時(shí)要考慮以下幾點(diǎn)：

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

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

●組織利用toplink、hibernate或iBatis等對(duì)象關(guān)系映射工具嗎？ 　　

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

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

●企業(yè)數(shù)據(jù)架構(gòu)如何通過更少的數(shù)據(jù)延遲幫助處理從事務(wù)型數(shù)據(jù)到分析型數(shù)據(jù)的轉(zhuǎn)換？ 　　

●企業(yè)數(shù)據(jù)架構(gòu)如何幫助對(duì)數(shù)據(jù)進(jìn)行分析性處理，以便根據(jù)需要向業(yè)務(wù)用戶交付信息？ 　　

集成架構(gòu)遵循

這個(gè)小節(jié)從以下角度評(píng)估應(yīng)用程序的架構(gòu)：它與包含第三方和遺留系統(tǒng)的應(yīng)用程序、組件和服務(wù)的集成之間的關(guān)系。評(píng)估集成層的成熟度時(shí)應(yīng)考慮以下幾點(diǎn)。

需要詢問的關(guān)于集成層的幾個(gè)樣例評(píng)估問題是：

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

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

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

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

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

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

●當(dāng)前遵循的應(yīng)用程序架構(gòu)提供了一個(gè)條件來將這個(gè)集成層引入到擁有具有集成架構(gòu)的成熟解決方案的層之間嗎？ 　　

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

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

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

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

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

技術(shù)架構(gòu)遵循

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

基礎(chǔ)設(shè)施服務(wù) 　　

●安全架構(gòu) 　　

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

●開放技術(shù)標(biāo)準(zhǔn) 　　

●經(jīng)營模型和部署架構(gòu) 　　

●性能 　　

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

●當(dāng)前遵循的應(yīng)用程序架構(gòu)提供了一個(gè)條件來將這個(gè)集成層引入到擁有具有集成架構(gòu)的成熟解決方案的層之間嗎？

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

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

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

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

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

基礎(chǔ)設(shè)施服務(wù)

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

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

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

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

●組織中有哪些不同的主數(shù)據(jù)管理服務(wù)可用？自定義數(shù)據(jù)集成服務(wù)和產(chǎn)品主數(shù)據(jù)管理服務(wù)屬于這個(gè)類別。 　　

安全架構(gòu)

重要的是要理解當(dāng)前安全模型、用戶角色、權(quán)限和應(yīng)用程序功能。以下幾點(diǎn)可以幫助評(píng)估安全架構(gòu)的成熟度：

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

●確認(rèn)IT安全是否可以在所有應(yīng)用程序?qū)訉?shí)現(xiàn)？ 　　

●更改和更新安全架構(gòu)的難度如何？ 　　

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

●應(yīng)用程序是否支持單點(diǎn)登錄（SSO）？SSO同時(shí)處于應(yīng)用程序和Web服務(wù)級(jí)別嗎？ 　　

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

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

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

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

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

檢查監(jiān)控?cái)?shù)據(jù)是否正在幫助管理架構(gòu)師調(diào)優(yōu)基礎(chǔ)設(shè)施，并幫助業(yè)務(wù)分析師重新定義優(yōu)化的業(yè)務(wù)流程。

部署架構(gòu)

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

檢查組織在凍結(jié)他們的拓?fù)浼軜?gòu)時(shí)是否遵循了任何標(biāo)準(zhǔn)電子商務(wù)部署架構(gòu)模式？

檢查系統(tǒng)的經(jīng)營模型和拓?fù)浼軜?gòu)，它們將展示將在一個(gè)典型生產(chǎn)環(huán)境中運(yùn)行的硬件節(jié)點(diǎn)以及軟件組件的各種版本。檢查模型是否完整清晰，是否提供了關(guān)于區(qū)域、硬件、軟件以及連接規(guī)范或細(xì)節(jié)的詳細(xì)信息。

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

性能

通過檢查組織針對(duì)低、中和復(fù)雜用例提供的性能指標(biāo)結(jié)果來評(píng)估應(yīng)用程序的性能。根據(jù)用戶數(shù)量和事務(wù)數(shù)量，通過支持的硬件配置獲取關(guān)于系統(tǒng)伸縮性的信息。多數(shù)組織都不夠成熟，不能提供服務(wù)級(jí)別的性能基準(zhǔn)測(cè)試。重點(diǎn)關(guān)注這樣的服務(wù)水平性能指標(biāo)：能夠幫助預(yù)測(cè)構(gòu)建復(fù)合應(yīng)用程序時(shí)的端到端響應(yīng)時(shí)間和計(jì)劃服務(wù)器容量。另外，檢查以下幾個(gè)方面：

●根據(jù)事務(wù)響應(yīng)時(shí)間和流量，組織擁有任何能夠改進(jìn)解決方案性能的軟件架構(gòu)組件或產(chǎn)品嗎？ 　　

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

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

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

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

●當(dāng)系統(tǒng)受到未授權(quán)或未格式化的消息的攻擊時(shí) 　　

●當(dāng)系統(tǒng)超載時(shí) 　　

●在維護(hù)期間 　　

●在軟件版本更改期間 　　

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

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

●恢復(fù)之后維護(hù)相同的數(shù)據(jù) 　　

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

為了更好地理解對(duì)CBS架構(gòu)的遵循程度的定量評(píng)估概念，下面討論一個(gè)基于應(yīng)用程序架構(gòu)維度中的PoC評(píng)估的樣例場(chǎng)景。

基于場(chǎng)景的PoC評(píng)估方法

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

場(chǎng)景：

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

定量評(píng)估基于以下這組預(yù)先定義的評(píng)估點(diǎn)進(jìn)行。每個(gè)確認(rèn)點(diǎn)都以以下方式定義：它擁有一個(gè)獨(dú)立的不同于它的理想遵循度的差別水平。查看以降序排列的數(shù)據(jù)點(diǎn)，它們偏離CBS服務(wù)遵循度，因此，針對(duì)每個(gè)點(diǎn)的評(píng)估得分逐漸減小。

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

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

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

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

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

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

結(jié)束語

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