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

　　這個維度描述涉及數(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è)中的集成的各個方面，包括人員、系統(tǒng)和數(shù)據(jù)庫的內(nèi)部和外部集成。開發(fā)靈活高效的復(fù)合業(yè)務(wù)服務(wù)需要檢查集成的不同方面，這些集成子視圖包括：

　　訪問/呈現(xiàn)集成視圖 處理訪問系統(tǒ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ù)信息。這種集成在一個統(tǒng)一的信息資產(chǎn)視圖上支持一致的搜索、訪問、復(fù)制、轉(zhuǎn)換和分析，從而滿足業(yè)務(wù)需求。

　　流程集成視圖 處理企業(yè)內(nèi)外部業(yè)務(wù)中的變化，以及它如何在跨人員和異構(gòu)系統(tǒ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)。這個維度還評估已開發(fā)的軟件組件利用開放技術(shù)標(biāo)準(zhǔn)的程度。

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

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

　　圖 2. 定性和定量迭代

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

　　一個定性評估可以從以下調(diào)查問卷開始?？梢愿鶕?jù)組織提供解決方案的業(yè)務(wù)領(lǐng)域和功能區(qū)域評估該組織。首先，應(yīng)檢查組織的基礎(chǔ)設(shè)施方面，以支持業(yè)務(wù)需求。以下是一些需要考慮的重點問題（請參閱 “參考資料” 部分提到的文章“Exploring Business Process Management Systems and the impact of BPM on developers”）：

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

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

　　組織建立了一個 BPM Center of Excellence （BPM-COE） 中心來實踐這樣的框架、工具和方法學(xué)，以便將業(yè)務(wù)要求有效地轉(zhuǎn)換為 IT 系統(tǒng)嗎？

　　組織擁有幫助確保公司方向在運營層面上實現(xiàn)的流程治理嗎？

　　RFI 中的 “業(yè)務(wù)要求” 部分需要將預(yù)定義的業(yè)務(wù)子功能包含到企業(yè)從事的業(yè)務(wù)領(lǐng)域。我們可以將一個客戶銀行自助服務(wù)門戶作為一個示例。這個門戶可能包含以下子功能：賬戶開立、賬戶查看、支票簿和 ATM 復(fù)制 PIN 的服務(wù)請求、賬單支付、資金轉(zhuǎn)賬和信用卡服務(wù)等。組織需要在這些子功能中或圍繞這些子功能提供它們的業(yè)務(wù)解決方案。根據(jù)從企業(yè)獲取的 RFI 響應(yīng)，組織業(yè)務(wù)遵循應(yīng)該考慮以下幾點：

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

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

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

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

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

　　組織采用了一些行業(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ù)來識別 RUP for SOA、SOMA 等業(yè)務(wù)服務(wù)嗎？

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

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

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

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

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

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

　　通道和呈現(xiàn)層

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

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

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

　　服務(wù)注冊層

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

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

　　通道和呈現(xiàn)層

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

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

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

　　如果組織正在使用某種自主框架，那么應(yī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)添加一個新的物理設(shè)備的靈活性如何？