SOA業(yè)務(wù)價值的實現(xiàn)
SOA團隊 2020-03-16
做了SOA實施很多年，不得不再來回顧SOA業(yè)務(wù)價值這個話題，SOA是一種商業(yè)模式，一種架構(gòu)方法，一種方法論。而企業(yè)實施SOA真正的業(yè)務(wù)價值又體現(xiàn) 在哪里？有多少企業(yè)實施SOA后真正體現(xiàn)了業(yè)務(wù)價值？至少從最近幾年SOA的實施效果來看，SOA要走到真正能體現(xiàn)業(yè)務(wù)價值的實現(xiàn)和實現(xiàn)業(yè)務(wù)敏捷性還有很 長的一段路要走。
在實施SOA的初期，很多時候都僅僅是EAI企業(yè)應(yīng)用集成的一個延伸，包括SOA本身產(chǎn)品也僅僅是消息中間件的進一步發(fā)展。從這個層面上SOA很難發(fā)揮其真正的業(yè)務(wù)價值，而對于SOA的核心業(yè)務(wù)價值一定是體現(xiàn)可重用資產(chǎn)庫的積累，業(yè)務(wù)敏捷方面的內(nèi)容。
SOA本身是一種架構(gòu)方法學(xué)，該方法學(xué)不是對已有的面向結(jié)構(gòu)，面向?qū)ο蠓椒ǖ姆穸?，而是一種延伸，這種延伸的重點即在于流程驅(qū)動IT，業(yè)務(wù)驅(qū)動架構(gòu)，從端到端的流程到業(yè)務(wù)組件化和服務(wù)化，又從可重用的業(yè)務(wù)組件和服務(wù)來快速構(gòu)建業(yè)務(wù)應(yīng)用。
在SOA架構(gòu)方法出來后，構(gòu)建IT系統(tǒng)的時候我們會更加關(guān)注業(yè)務(wù)流程梳理，業(yè)務(wù)架構(gòu)和業(yè)務(wù)建模，這也是能夠真正實現(xiàn)業(yè)務(wù)和技術(shù)解耦的基礎(chǔ)，沒有這層解耦就談不上后續(xù)的快速服務(wù)組合和編排。而在整個方法里面，業(yè)務(wù)組件本身就占據(jù)了很重要的位置，業(yè)務(wù)組件提供業(yè)務(wù)能力，而業(yè)務(wù)能力本身又以服務(wù)的方式提供出來。這種架構(gòu)方法必須要引入到系統(tǒng)內(nèi)，從一個系統(tǒng)的構(gòu)建之初就采用這種方法來構(gòu)建應(yīng)用，包括端到端流程的分析，業(yè)務(wù)建模和業(yè)務(wù)組件，服務(wù)組件和服務(wù)識別，跨組件的數(shù)據(jù)CRUD分析，組件間的服務(wù)交互等。
對于遺留系統(tǒng)的SOA化改造和集成，往往很難對已有歷史系統(tǒng)進行全SOA化改造，只能對現(xiàn)有的系統(tǒng)集成接口進行SOA化服務(wù)改造，在這種思路下我們很難真正的去分析和識別各個業(yè)務(wù)系統(tǒng)已有的業(yè)務(wù)組件和業(yè)務(wù)能力。也很難遵循我們的從頂向下的端到端流程分析和建模的思路進行，這自然導(dǎo)致了業(yè)務(wù)組件和業(yè)務(wù)服務(wù)無法真正的有效識別，后續(xù)的服務(wù)編排和流程編排更難以真正落地。要知道BPEL服務(wù)編排的重點是業(yè)務(wù)服務(wù)，而不是數(shù)據(jù)接口和數(shù)據(jù)服務(wù)。
業(yè)務(wù)價值1-形成真正的服務(wù)資產(chǎn)庫
可以講形成真正可復(fù)用的服務(wù)目錄和服務(wù)資產(chǎn)庫是SOA實施的一個重要業(yè)務(wù)價值體現(xiàn)，SOA一直在強調(diào)服務(wù)的粒度和服務(wù)的可重用性，服務(wù)的每一次重用都是在降低IT系統(tǒng)建設(shè)和實施的成本。服務(wù)資產(chǎn)庫正是將各個業(yè)務(wù)系統(tǒng)可重用的業(yè)務(wù)能力提取出來以服務(wù)的方式提供出來。
當(dāng)我們在構(gòu)建新的業(yè)務(wù)系統(tǒng)的時候，我們就優(yōu)先考慮有哪些服務(wù)資產(chǎn)或能力可以借用，有哪些是我們需要全新構(gòu)建和開發(fā)的功能。能復(fù)用的服務(wù)和資產(chǎn)越多，我們構(gòu)建IT系統(tǒng)的成本和時間越短。
服務(wù)資產(chǎn)本身就是業(yè)務(wù)組件和業(yè)務(wù)能力，用戶或新構(gòu)建的業(yè)務(wù)系統(tǒng)并不會關(guān)注提供這個能力的業(yè)務(wù)系統(tǒng)(SOA本身談的透明性)，這種服務(wù)本身就是粗粒度的，實現(xiàn)機制完全黑盒的。SOA本身重點就在于提供這個服務(wù)目錄，而不是自身去實現(xiàn)這個服務(wù)。如果SOA和云計算結(jié)合，那則才是既自身產(chǎn)生這個能力，也提供這個服務(wù)。
服務(wù)資產(chǎn)庫即能力提供中心，而支撐這個能力提供中心的還是各個已有的業(yè)務(wù)系統(tǒng)，是各個業(yè)務(wù)系統(tǒng)將可復(fù)用的能力抽取出來注冊到了ESB企業(yè)服務(wù)總線上。為了更好的為ESB提供這種服務(wù)和能力，對各個業(yè)務(wù)系統(tǒng)的組件化和模塊化開發(fā)要求自然就更高。
業(yè)務(wù)價值2-業(yè)務(wù)敏捷性和效率
業(yè)務(wù)流程或業(yè)務(wù)的變化可以通過BPEL服務(wù)編排調(diào)整快速適應(yīng)，這是我們談SOA能夠?qū)崿F(xiàn)業(yè)務(wù)敏捷性的基礎(chǔ)。但是這條路往往是任重道遠。一個全新的業(yè)務(wù)功能實現(xiàn)完全可以通過服務(wù)組合和編排，流程的編排來實現(xiàn)，這是我們的期望，但是卻相當(dāng)有難度。
首先是我們的服務(wù)資產(chǎn)庫是否足夠完備？這里面涉及到兩個方面的問題，其一是業(yè)務(wù)服務(wù)的識別而不是單純的數(shù)據(jù)服務(wù)，要知道數(shù)據(jù)服務(wù)很難真正用到服務(wù)的編排。其二是服務(wù)的識別過程本身是否從流程分析入手，識別出業(yè)務(wù)組件，再來分析流程驅(qū)動的組件間的交互，這樣分析出來的服務(wù)才真正支持從底向上的組裝。
其次要實現(xiàn)業(yè)務(wù)的快速構(gòu)建，通過單純的BPEL是遠遠不夠的，在BPM業(yè)務(wù)流程管理，BPMN2.0推出來后，這個方面前進了一步?？梢圆糠謱崿F(xiàn)從業(yè)務(wù)流程建模到IT實現(xiàn)的平滑過渡。但是這里面又有一個關(guān)鍵問題，即規(guī)則引擎，這塊做不好快速應(yīng)用開發(fā)，流程編排和組裝僅僅是泡影很難真正落地。接觸了太多的快速開發(fā)平臺，企業(yè)級應(yīng)用不是簡單的增刪改查，如果規(guī)則無法剝離，無法復(fù)用，就談不上復(fù)雜業(yè)務(wù)流程本身的復(fù)用。
打破業(yè)務(wù)系統(tǒng)的邊界，解決煙囪式的豎井結(jié)構(gòu)，不是單純的服務(wù)集成，而是實現(xiàn)跨系統(tǒng)的流程集成。這個時候業(yè)務(wù)系統(tǒng)下沉為能力單元，浮在上面的是可組裝和編排的流程和應(yīng)用。孤立的業(yè)務(wù)系統(tǒng)的概念越強，業(yè)務(wù)敏捷性的推動就越發(fā)困難。
如何落地實施的問題
對于落地的問題也是我們考慮的比較多的一個問題，方法論再完美如果無法落地那么也僅僅是空中樓閣。而落地的過程本身又是一個總體規(guī)劃和分布實施的過程，前期的基礎(chǔ)打的越好后續(xù)越容易實施落地。對于具體的落地，主要考慮如下幾方面內(nèi)容：
1.流程驅(qū)動業(yè)務(wù)架構(gòu)思路，跨業(yè)務(wù)部門和系統(tǒng)邊界，進一步分析和識別業(yè)務(wù)服務(wù)。
2.整合已有的服務(wù)資產(chǎn)，形成可復(fù)用的服務(wù)資產(chǎn)庫。
3.弱化各個業(yè)務(wù)系統(tǒng)的概念，業(yè)務(wù)系統(tǒng)變化為業(yè)務(wù)能力單元，而服務(wù)能力又集成到ESB。
4.抽取各個業(yè)務(wù)系統(tǒng)可復(fù)用部分，進一步下沉和集中化，形成企業(yè)內(nèi)PAAS云平臺。
5.選擇合適的新業(yè)務(wù)系統(tǒng)或業(yè)務(wù)功能，采用BPM等工具，借助已有服務(wù)能力構(gòu)建應(yīng)用。
6.逐步遷移傳統(tǒng)的業(yè)務(wù)功能和業(yè)務(wù)單元。
遠行科技
遠行云商
