看看阿里架構師是如何分析SOA的業務價值實現

作了SOA實施不少年，不得再也不來回顧SOA業務價值這個話題，SOA是一種商業模式，一種架構方法，一種方法論。而企業實施SOA真正的業務價值又體現 在哪裏？有多少企業實施SOA後真正體現了業務價值？至少從最近幾年SOA的實施效果來看，SOA要走到真正能體現業務價值的實現和實現業務敏捷性還有很 長的一段路要走。

在實施SOA的初期，不少時候都僅僅是EAI企業應用集成的一個延伸，包括SOA自己產品也僅僅是消息中間件的進一步發展。從這個層面上SOA很難發揮其真正的業務價值，而對於SOA的核心業務價值必定是體現可重用資產庫的積累，業務敏捷方面的內容。

SOA自己是一種架構方法學，該方法學不是對已有的面向結構，面向對象方法的否認，而是一種延伸，這種延伸的重點即在於流程驅動IT，業務驅動架構，從端到端的流程到業務組件化和服務化，又從可重用的業務組件和服務來快速構建業務應用。

在SOA架構方法出來後，構建IT系統的時候咱們會更加關注業務流程梳理，業務架構和業務建模，這也是可以真正實現業務和技術解耦的基礎，沒有這層解耦就談不上後續的快速服務組合和編排。而在整個方法裏面，業務組件自己就佔據了很重要的位置，業務組件提供業務能力，而業務能力自己又以服務的方式提供出來。這種架構方法必需要引入到系統內，從一個系統的構建之初就採用這種方法來構建應用，包括端到端流程的分析，業務建模和業務組件，服務組件和服務識別，跨組件的數據CRUD分析，組件間的服務交互等。

對於遺留系統的SOA化改造和集成，每每很難對已有歷史系統進行全SOA化改造，只能對現有的系統集成接口進行SOA化服務改造，在這種思路下咱們很難真正的去分析和識別各個業務系統已有的業務組件和業務能力。也很難遵循咱們的從頂向下的端到端流程分析和建模的思路進行，這天然致使了業務組件和業務服務沒法真正的有效識別，後續的服務編排和流程編排更難以真正落地。要知道BPEL服務編排的重點是業務服務，而不是數據接口和數據服務。

業務價值1-造成真正的服務資產庫

能夠講造成真正可複用的服務目錄和服務資產庫是SOA實施的一個重要業務價值體現，SOA一直在強調服務的粒度和服務的可重用性，服務的每一次重用都是在下降IT系統建設和實施的成本。服務資產庫正是將各個業務系統可重用的業務能力提取出來以服務的方式提供出來。

當咱們在構建新的業務系統的時候，咱們就優先考慮有哪些服務資產或能力能夠借用，有哪些是咱們須要全新構建和開發的功能。能複用的服務和資產越多，咱們構建IT系統的成本和時間越短。

服務資產自己就是業務組件和業務能力，用戶或新構建的業務系統並不會關注提供這個能力的業務系統(SOA自己談的透明性)，這種服務自己就是粗粒度的，實現機制徹底黑盒的。SOA自己重點就在於提供這個服務目錄，而不是自身去實現這個服務。若是SOA和雲計算結合，那則纔是既自身產生這個能力，也提供這個服務。

服務資產庫即能力提供中心，而支撐這個能力提供中心的仍是各個已有的業務系統，是各個業務系統將可複用的能力抽取出來註冊到了ESB企業服務總線上。爲了更好的爲ESB提供這種服務和能力，對各個業務系統的組件化和模塊化開發要求天然就更高。

業務價值2-業務敏捷性和效率

業務流程或業務的變化能夠經過BPEL服務編排調整快速適應，這是咱們談SOA可以實現業務敏捷性的基礎。可是這條路每每是任重道遠。一個全新的業務功能實現徹底能夠經過服務組合和編排，流程的編排來實現，這是咱們的指望，可是卻至關有難度。

首先是咱們的服務資產庫是否足夠完備？這裏面涉及到兩個方面的問題，其一是業務服務的識別而不是單純的數據服務，要知道數據服務很難真正用到服務的編排。其二是服務的識別過程自己是否從流程分析入手，識別出業務組件，再來分析流程驅動的組件間的交互，這樣分析出來的服務才真正支持從底向上的組裝。

其次要實現業務的快速構建，經過單純的BPEL是遠遠不夠的，在BPM業務流程管理，BPMN2.0推出來後，這個方面前進了一步。能夠部分實現從業務流程建模到IT實現的平滑過渡。可是這裏面又有一個關鍵問題，即規則引擎，這塊作很差快速應用開發，流程編排和組裝僅僅是泡影很難真正落地。接觸了太多的快速開發平臺，企業級應用不是簡單的增刪改查，若是規則沒法剝離，沒法複用，就談不上覆雜業務流程自己的複用。

打破業務系統的邊界，解決煙囪式的豎井結構，不是單純的服務集成，而是實現跨系統的流程集成。這個時候業務系統下沉爲能力單元，浮在上面的是可組裝和編排的流程和應用。孤立的業務系統的概念越強，業務敏捷性的推進就愈加困難。

如何落地實施的問題

對於落地的問題也是咱們考慮的比較多的一個問題，方法論再完美若是沒法落地那麼也僅僅是空中樓閣。而落地的過程自己又是一個整體規劃和分佈實施的過程，前期的基礎打的越好後續越容易實施落地。對於具體的落地，主要考慮以下幾方面內容：

1.流程驅動業務架構思路，跨業務部門和系統邊界，進一步分析和識別業務服務。

2.整合已有的服務資產，造成可複用的服務資產庫

3.弱化各個業務系統的概念，業務系統變化爲業務能力單元，而服務能力又集成到ESB

4.抽取各個業務系統可複用部分，進一步下沉和集中化，造成企業內PAAS雲平臺

5.選擇合適的新業務系統或業務功能，採用BPM等工具，藉助已有服務能力構建應用

6.逐步遷移傳統的業務功能和業務單元