應用程序和數(shù)據(jù)架構

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

　　集成架構

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

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

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

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

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

　　技術架構

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

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

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

　　圖 2. 定性和定量迭代

　　業(yè)務架構遵循

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

　　組織有良好定義的 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è)務解決方案。根據(jù)從企業(yè)獲取的 RFI 響應，組織業(yè)務遵循應該考慮以下幾點：

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

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

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

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

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

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

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

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

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

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

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

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

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

　　應用程序和數(shù)據(jù)架構遵循

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

　　通道和呈現(xiàn)層

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

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

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

　　服務注冊層

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

　　以下小節(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)添加一個新的物理設備的靈活性如何？