簡介

　　本文討論企業(yè)計劃和開發(fā)一個 CBS 支持策略，從傳統(tǒng)企業(yè)架構(gòu)過渡到支持 CBS 的參考架構(gòu)所需的步驟。我們將討論一些用于分析和評估企業(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è)落后的每個維度中的要求。

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

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

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

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

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

　　定性方法

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

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

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

　　定量方法

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

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

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

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

　　圖 1. 評估過程方法

　　CBS 的維度

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

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

　　這個維度解決用戶、規(guī)劃人員和業(yè)務(wù)經(jīng)理關(guān)注的問題，主要從用戶角度考察系統(tǒng)功能。它主要關(guān)注業(yè)務(wù)性能、功能和可用性。它擁有以下幾個子視圖（請參見 “參考資料” 部分獲取一個 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)境的性能方面。