SOA治理在于平衡流程與敏捷度

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

我見過許多公司在試圖實(shí)施SOA治理的時(shí)候落入兩個(gè)不同的陷阱。第一個(gè)陷阱是治理模型不夠有力;而另一個(gè)則是流程過多阻礙進(jìn)程。要解決這兩個(gè)問題秘訣在于平衡流程與敏捷度。

流程不足導(dǎo)致混亂

公司的治理模型不夠有力有許多原因，以下是我曾經(jīng)見過的原因之一：

· 缺乏對(duì)于設(shè)計(jì)時(shí)間和運(yùn)行時(shí)間最佳實(shí)踐的完整理解

· 企業(yè)文化不支持標(biāo)準(zhǔn)和最佳實(shí)踐

· 缺少資金購(gòu)買治理資源和工具

· 不切實(shí)際的最終期限

· 缺少執(zhí)行力支持

如果沒有一個(gè)有效的治理模型，你夢(mèng)想的SOA天堂可能會(huì)變成一場(chǎng)惡夢(mèng)：系統(tǒng)故障、高開發(fā)成本、難以管理的生產(chǎn)環(huán)境和不滿意的客戶。為了達(dá)到SOA所承諾的重新利用、靈活性、敏捷度以及易于整合，設(shè)計(jì)時(shí)間治理必須確保服務(wù)的建立與業(yè)務(wù)價(jià)值一致，滿足一定的性能和安全要求，保持平臺(tái)的中立并且不能打破任何已經(jīng)部署的東西。

由于SOA的分布式和抽象性的特點(diǎn)，運(yùn)行時(shí)間管理是至關(guān)重要的。一個(gè)單一的商務(wù)服務(wù)也許由許多組件構(gòu)成，這些組件存在于架構(gòu)的各個(gè)層次。而當(dāng)服務(wù)出現(xiàn)故障的時(shí)候，你最好具備恰當(dāng)?shù)牧鞒毯凸ぞ咭匝杆俚淖R(shí)別問題，并在客戶發(fā)現(xiàn)之前將其恢復(fù)。

還有一個(gè)問題就是管理服務(wù)版本、主動(dòng)監(jiān)控性能和安全、確保遵守協(xié)議和執(zhí)行調(diào)整性控制等等的復(fù)雜性。

在沒有堅(jiān)實(shí)的治理模型情況下實(shí)施SOA無異于一個(gè)沒有控制塔的機(jī)場(chǎng)。盡管我們可能擁有很優(yōu)秀的飛行員和先進(jìn)的飛機(jī)，但沒有恰當(dāng)?shù)挠?jì)劃和實(shí)時(shí)信息，結(jié)果將會(huì)是災(zāi)難性的。因此，你應(yīng)該保證建立一個(gè)控制塔并雇用一些空中交通管制員。

過多的流程抑制創(chuàng)新和敏捷度

這個(gè)問題的另一個(gè)方面就是那些為了流程而相信流程的公司。他們創(chuàng)建了過多的流程使得團(tuán)隊(duì)陷入了文件的深淵而忽略了業(yè)務(wù)驅(qū)動(dòng)器。我曾經(jīng)見到有人打破那些設(shè)計(jì)精細(xì)但不能提供任何價(jià)值或從未得到重復(fù)利用的服務(wù)。往往來說“冗余治理”或“流程致死”模型使得架構(gòu)師們機(jī)械的思考, 按照文件和清單所說的去做。然后還需要花上好幾個(gè)禮拜而不是一兩天來批準(zhǔn)提議。造成這樣的模型的原因如下：

· 將SOA看作是一個(gè)技術(shù)問題而非業(yè)務(wù)推動(dòng)器

· 對(duì)于架構(gòu)師和領(lǐng)導(dǎo)力缺乏信任和授權(quán)

· 冗長(zhǎng)的流程的使用導(dǎo)致長(zhǎng)交付期限

· 領(lǐng)導(dǎo)力層面缺乏技術(shù)和業(yè)務(wù)專業(yè)知識(shí)

尋求合適的平衡點(diǎn)

每一個(gè)企業(yè)文化、每一個(gè)SOA倡議都是獨(dú)一無二的，我們沒有一勞永逸或者放之四海而皆準(zhǔn)的治理模型。棧(Stack)供應(yīng)商、SOA實(shí)施顧問公司和標(biāo)準(zhǔn)團(tuán)體都具有充分文件說明的SOA治理方法論。選擇一款最適合你的企業(yè)文化并根據(jù)公司需求進(jìn)行個(gè)性化。

那么我們要如何同時(shí)得到敏捷度并實(shí)施SOA治理呢?其中一個(gè)方法就是從文檔文件向視覺文件的轉(zhuǎn)換。換句話說，那就是以UML模型、業(yè)務(wù)流程模型、應(yīng)用范例和架構(gòu)范例代替數(shù)百頁的文件。這些配置就象是建筑架構(gòu)的藍(lán)圖一樣。如果你要建造你夢(mèng)想的房子，你會(huì)將房子的細(xì)節(jié)輸入Word文檔交給你的建筑師嗎?還是說你會(huì)將交給她藍(lán)圖呢?我的座右銘一直是“重視會(huì)增值的配置并舍棄掉其他無價(jià)值的東西”。千萬不要讓你的員工僅僅為了任務(wù)清單去做一些毫無價(jià)值的步驟。SOA治理不應(yīng)該由項(xiàng)目經(jīng)理還建立，需要識(shí)別和定義治理的人是架構(gòu)師。這是服務(wù)生命周期管理，標(biāo)準(zhǔn)的N層流程并不適用。

讓治理隨著時(shí)間演變

即使你達(dá)到了流程和敏捷適當(dāng)?shù)钠胶庖膊灰淮涡詫?shí)施。像SOA一樣，SOA治理也是一趟沒有盡頭的旅程。從小處開始，在必要的時(shí)候按部就班。

比如，如果你第一次的實(shí)施含有15到20項(xiàng)服務(wù)，你也許就不需要充滿活力的SOA精英團(tuán)隊(duì)(COE)的存在，特別是當(dāng)團(tuán)隊(duì)只有幾個(gè)技術(shù)人員的時(shí)候。隨著服務(wù)數(shù)量的增加，架構(gòu)師和開發(fā)人員的隊(duì)伍也隨之壯大，治理模型也是如此。我曾經(jīng)見過一個(gè)公司花費(fèi)一整年的時(shí)間來部署恰當(dāng)?shù)闹卫砹鞒?，這一整年沒有為業(yè)務(wù)帶來任何增值。我的建議是將SOA治理作為關(guān)鍵部分納入你的SOA路線圖中。最終我們會(huì)從SOA創(chuàng)造的商業(yè)價(jià)值來接受判斷，因此就要確保你的SOA治理模型在SOA最佳實(shí)踐和業(yè)務(wù)敏捷度之間取得平衡。（IT專家網(wǎng)）