汽車貸款架構採納步驟和價值分析
SOA是一個既簡單又複雜的技術。簡單地說，SOA就是一組設計原則，這些設計原則既有SOA特有的，如服務是第一概念[CBDI]，業務和IT對齊，為靈活而構建;也有被早已被業界廣泛接受和使用的，如鬆散耦合、隔離關注、模組化、再使用性等。複雜地說，SOA是由這些設計原則衍生出的各種技術，如SOA成熟度模型、服務建模方法學、SOA程式設計模型、企業服務匯流排、服務註冊庫等。
同樣，對SOA的採納(Adoption)形式也具有從簡單到複雜各種形式。一個分散式企業IT系統全面向SOA轉型固然是SOA，而像HousingMap.com這樣將Google Map提供的Web服務和Craiglist提供的Web服務集成起來提供全新的業務模式也不能不算SOA。筆者作為主要的技術人員主導或參加了若干SOA的實施案例，這裡面有短暫的SOA試點專案，也有大跨度的SOA實施。從實踐的角度而言，筆者認為一般的SOA的實施專案應該包含如下步驟：
1. SOA採納步驟和價值分析
由於客戶現有IT環境和業務環境的不同，採納SOA的價值和採納的步驟也會相應不同。對任何一個企業或者是應用提供商，在採納SOA之前最好深刻理解SOA的內涵和外延，並客觀分析採納SOA的好處以及帶來的風險，並實際情況規劃SOA實施的步驟。
1. SOA監管：和傳統技術不同的是，SOA是一個橫向的技術，它不僅影響IT系統的設計者和開發者，它更需要改變業務部門對IT系統的看法，也需要運營部門改變系統運營的方式。幾乎所有的相關人的活動都會圍繞著服務模型和服務中繼資料。因此服務模型和服務中繼資料品質直接決定著企業向SOA轉型的效果。簡單的說，SOA監管通過建立適當組織和流程保證服務模型和服務中繼資料在創建時和運行時的品質。可以預見的是，一個企業採納了SOA後，SOA監管會成為企業IT部門的重要任務之一。
2. 服務建模：如何根據服務建模方法學創建符合SOA設計原則的服務模型是實施SOA中及其重要的一步。發現服務候選、決定服務暴露和進行服務規約是這一步的重要內容。
3. 服務實現和架構設計：根據確定的服務模型，結合現有IT環境確定服務和服務元件的實現策略，並設計用於實現服務的基礎架構(如ESB、流程服務引擎、人工服務容器等)是也是實施SOA過程中及其重要的一步。服務元件劃分、服務實現決策和服務基礎設施設計是這一步的重要內容。
4. 以服務為中心的開發和集成：在SOA的實施專案中，開發和集成的模式都會發生相應的變化，服務會成為開發階段的中心概念。服務模型映射到程式設計模型，逐步實現服務，並在服務層次上進行持續的集成是這一階段的主要內容。
5. 服務管理：以上的步驟主要側重在功能層次上如何一步步實現SOA，而服務管理則側重于在SOA實施中如何實現非功能性需求，這包括服務性能、服務安全等。
本系列文章將圍繞SOA的實施步驟組織，但是SOA監管和服務管理不在本系列文章的範圍內。
2. 示例場景介紹
本系列文章所涉及的場景是一個汽車貸款審批業務流程，從申請人提交申請到汽車銷售商接受貸款併發貨(或者申請人接收拒絕通知)。
從銀行的業務角度，該業務流程的外部參與者包括最終使用者(申請人、汽車銷售商)和合作夥伴(保險公司)，內部參與者包括業務執行人員(信貸員)以及風險管理人員(信貸經理)。從技術實現的角度，該業務流程既包含自動化的內部功能(查詢存貸款記錄)和外部功能(保險公司提供擔保)，也包括人工活動(信貸經理審批)。因此，該場景具備一般業務流程的典型性，基於該場景的SOA實施示例具備更大的借鑒意義。
信貸員是整個業務流程的樞紐，負責與客戶、信貸經理、相關應用系統打交道。這種業務模式既增大了信貸員的工作強度，也增加了過程中的操作風險以及道德風險。
在業務流程中起到樞紐作用的信貸員，通過不同的方式訪問不同的系統，獲取申請人的相關資訊，同時通過電子辦公系統向信貸經理提交貸款審批申請。多樣化的人機界面既增加了對信貸員的IT技能要求，也極大的降低了信貸員的工作效率。
3. SOA 評估框架和 SOA 成熟度模型簡介
如上所述，SOA是由一些設計原則衍生出的一系列技術。和傳統的方法不同的是，SOA的這些衍生技術遍佈企業IT生命週期，以及企業IT系統的各個層次。為了評估一個企業的實施SOA的程度，我們需要一個覆蓋全面的評估標準和一種對成熟度的劃分。SOA評估框架就是這裡說的評估標準，而SOA成熟度模型就是一種對SOA成熟度的劃分。借錢SOA的評估框架和SOA成熟度模型是瞭解企業IT和業務環境現狀，分析企業採納SOA的步驟和價值的重要工具。這裡我們以IBM的SOA評估框架和SOA成熟度模型為例進行介紹。
IBM的SOA評估框架主要分析企業IT系統在如下四個方面的特性：
1. 組織和流程：企業是否有實施SOA的經驗，實施SOA的範圍多大，企業是否規劃過需要實現的SOA的能力，業務部門是否理解SOA實施的價值和過程，特別是業務部門參與重要性，是否有系統的方法指導服務的發現和設計，業務部門在服務的發現和設計中參與的程度如何;
2. 應用：目前應用如何暴露可重用的邏輯?應用間連通的即時和異構特性如何?企業開始在多大構建複合應用?
3. 架構：目前企業應用集成現狀?企業應用的元件化程度如何?是否存在服務模型?範圍多大?
4. 基礎架構：基礎架構如何保持可擴展性和靈活性保證滿足業務部門的需要?基礎設施如何回應業務流程性能的變化?是否存在統一的安全架構和規範?
同時，IBM的SOA成熟度模型將SOA成熟度劃分為7個層次：
L1. 孤立的：大多數為孤立應用，存在集成也基本上以資料集成為主;當需求發生變化時，需要大量的瑣碎的架構調整;
L2. 集成的：應用間存在大量集成，但是以點到點的連接方式為主，應用程式的重構主要通過資料集成完成;
L3. 元件化的：將主要的或關鍵的應用從功能角度進行了元件劃分，原有的J2EE/.Net等應用通過重構實現這些元件，元件間的集成通過元件介面和相互間的契約完成;
L4. 簡單服務：存在業務部門內的服務模型和構建在服務上的業務流程集成;
L5. 組合服務：存在企業範圍內和企業間的服務模型，已經在服務模型基礎上完成價值鏈集成;
L6. 虛擬化服務：基礎設施如伺服器和存儲已經完成虛擬化，服務運行在這些虛擬化的基礎設施之上;基礎設施、服務元件、服務、業務流程被極大解耦;通過對基礎設施的監控和管理來保證服務品質;
L7. 動態配置服務：服務可以根據業務策略和IT策略進行動態組裝;
4. 示例場景的 SOA 現有成熟度和目標成熟度
我們對示例場景中SOA現有成熟度分析總結如下：
1. 組織和流程：無論是在貸款業務部門，還是在其他業務部門，都沒有進行過SOA的實施;業務人員普遍認為SOA是技術層面的事情，是IT部門的事情，業務部門在SOA實施中沒有任何責任;
2. 應用：構建在主機上的核心銀行系統業務邏輯體現為CICS的事務，業務邏輯劃分清晰，但是邏輯和表示緊耦合，而且其業務邏輯劃分和整體需求有一定差距，該銀行已經構建EAI的基礎設施，核心銀行系統的業務邏輯可以通過EAI中的消息匯流排訪問;房貸和車貸系統分佈構建在J2EE和.Net平臺之上，設計系統時對元件化考慮的很充分，主要的業務邏輯都構建在公共的元件基礎之上，如果其他系統需要訪問房貸和車貸系統，需要進行點到點的集成;保險公司擔保閘道是外部系統，已經服務化。
3. 架構：企業消息匯流排可以連通除房貸和車貸系統以外的大部分系統，但是消息匯流排仲介能力不強，主要集中在消息轉換，對重複業務邏輯的訪問需要應用層處理;
4. 基礎架構：伺服器、存儲和網路設施異構性很大，業務系統性能的調控相當剛性;已經具有統一的安全架構，如認證、授權和加密;
綜合分析可見，對於整體企業而言其SOA成熟度，位於L2和L3之間;房貸和車貸系統SOA成熟度位於L3。
對於SOA的轉型，該企業的近期目標是希望能夠在現在的現有的房貸和車貸系統之上構建複合應用以支援汽車借款審批流程;而該企業的長遠目標是構建企業範圍的服務模型，並逐步改造所有的應用為複合應用，並期望實現價值鏈集成。由此可見，對於圍繞汽車借款審批流程的房貸和車貸系統SOA改造的目標成熟度是L5;從企業範圍而言，希望現在房貸和車貸構建SOA應用，而逐步擴展到整個企業，所以其目標成熟度先是L4，然後遷移到L5。
5. 示例場景的 SOA 採納步驟和價值分析
結合示例場景的特點和SOA轉型的需要，我們建議如下SOA採納步驟：
第一步：以借款審批流程為中心進行SOA試點 ( L2/3 -> L4 )在這一步中，圍繞汽車貸款審批流程進行服務建模分析，並在現有系統上構建企業服務匯流排。這一步的主要目標有四：第一)測量SOA可能帶來的業務層面的價值，通過服務組裝完成汽車借款流程，來驗證如何通過服務仲介、服務替換和服務重新組裝適應可能的業務變化，從而實現業務流程從建模"自動化"監控"優化的全生命週期;第二)測量SOA可能帶來的IT層面價值，通過將已有系統暴露為服務，並構建ESB實現虛擬化的服務，來驗證將現有系統暴露為服務的技術可行性，驗證ESB如何通過實現廣泛連線性、驗證如何通過服務仲介完成重複邏輯合併和異構系統集成、驗證如何SOA架構如何適應IT層面的變化如系統集中、系統合併和系統升級;第三)深化IT部門對實施SOA的技術理解，包括服務建模方法學、SOA架構設計、相關技術和產品的成熟度(安全，性能，…); 第四)深化IT部門和業務部門對實施SOA的方法和價值理解，包括SOA背後的價值驅動，如何建立SOA組織和流程進行SOA監管等;
第二步：重構貸款系統以實現貸款部門的服務模型，並將業務流程實現為複合應用 ( L2/3 -> L4 ) 在這一步中，圍繞貸款部門的業務流程進行服務建模(這不僅包括貸款業務部門內部的服務，還包括可能訪問到的核心銀行系統的服務)，並將主要業務流程遷移為複合應用。這一步的主要目標有三：第一)繼續深化IT部門對實施SOA的技術理解，並培養SOA實施的各層次的技能;為企業範圍內的SOA實施做技術準備，如各種SOA實施技術規範-SOA參考架構，服務模型規範，企業服務匯流排規範等; 第二)繼續深化IT部門和業務部門對實施SOA方法和價值理解，初步建立業務部門內的SOA監管組織、流程和基礎設施(如服務註冊庫)等;第三)驗證現有SOA技術和產品在大規模應用時的成熟度;
第三步：以消息匯流排的改造為中心，構建SOA監管組織和流程，並創建企業服務模型和企業範圍內SOA的基礎架構;( L4 -> L5) 這一步選擇以消息匯流排為中心的原因在於，1)消息匯流排涉及主要的業務邏輯和業務流程，而且該企業在構建消息匯流排時已經對核心的業務進行了必要的調查和分析，這是服務建模的良好基礎;2)消息匯流排是主要的應用集成設施，這是企業服務匯流排構建的良好基礎。通過這一步驟，企業範圍的SOA基礎架構基本形成，這包括SOA監管組織和流程、企業範圍內服務模型、企業服務匯流排和SOA參考架構;
第四步：逐步遷移主要業務流程為複合應用，並完善SOA監管和服務模型;(L4->L5) 這一步主要是在前一步的建立的SOA基礎架構之上逐步將應用遷移到複合應用。實際上第三步和第四步應該是融和在一起的;
第五步：圍繞價值鏈整合實現快速回應IT系統; (L5) 當完成SOA基礎設施建設和複合應用遷移後，企業已經具備條件進行流程優化和價值鏈整合。這種條件下，無論是IT層面的調整，還是業務層面的調整，都可以通過服務模型和企業服務匯流排隔離變化，從而使用盡量小的代價完成對變化的適應，也即達到快速回應的IT。
本系列文章的後續部分將圍繞SOA採納的第一步 -- 以借款審批流程為中心進行SOA試點 為背景介紹SOA實施的其他步驟。
留言列表
