實用SOA

        最近，ZapThink和一個跨國金融業務公司的CIO會面，一同討論了他們在面向服務架構（SOA）的實施方面所取得的成就。該CIO提出了一個十分有趣並且頗具建設性的一點：儘管自己在業務價值方面已經取得了很大的成功，他將SOA方面的努力歸結到一套特定的領域。

　　依照CIO的經驗，許多看好SOA技術的機構採用SOA的基本策略是：SOA可以解決一些但不是所有的問題，當SOA特有的收益超過了日常開支和SOA所要求的結構改變開支時，SOA就得以良好實施。因此，SOA的成功並不需要全面的改變；相反，那些經過縝密思考，而選擇SOA的設計師會通過有限範圍內的專案，履行SOA對於業務方面的承諾。那些不得要領的設計師為成功實現SOA製造了重重障礙——但是，只要採用幾步實用措施，SOA的成功並沒有那麼困難。

　　SOA不是一勞永逸的辦法

　　正如我們在2004 的ZapFlash上介紹的一樣， ZapThink一直都在討論，SOA不是解決所有IT難題的辦法。畢竟，銀彈只能用於射殺狼人，如果有一個吸血鬼追著你跑，你最好還是用來木樁對付他們——機構在解決IT問題時，也是這個道理。首先著手解決業務問題，並根據該業務問題設計解決方案，顯然這是處理IT問題以及SOA問題的最佳方法.

　　在SOA中採用解決方案定向的方法只是實用SOA的一個方面。 一方面，將具有潛能的SOA專案置於首位，這對於架構團隊來說非常重要。另一方面，這也是在SOA實施中採用可重用方法的已建立的最佳實施。每個專案迭代都產生了業務價值。將二維的評價流程和風險/效益評估相結合，這樣你就有了一個解決SOA的實際方法，該方法能夠將潛在的SOA專案從你的規劃圖中整個消除，並關注那些風險最小，效益最高的專案。

　　以專案為基礎的實用SOA

　　要想知道如何用實際的方法解決SOA,，最好的辦法就是探討機構如何採用特定措施的一些例子。下面是常見的情況：

　　·實用SOA治理。現今，機構面臨的大多數治理問題並沒有直接涉及IT——如果它們的確涉及到了IT。許多策略並不只是簡單的可自動化，正因為如此，IT只起到了輔助作用即使書面策略得以交流傳達。在設計一個SOA治理措施時，區分可自動化策略和其它需要手動完成的策略十分重要。

　　因此，SOA治理措施的迭代應該關注，比方說，服務的安全策略，然後是重用和服務策略的質量，最後是服務消費策略。從業務角度來說，就是所有機構需要建立、通訊、執行、和升級的策略。這樣，IT就可以利用SOA將一個特定使用者機自動化並通過基於風險/效益的評估，把特定的策略置於首位，實現特定使用者機的自動化。

　　·實用的重用。許多人把重用看做是SOA帶來的主要收益，但是，在實際操作中，重用很難實現。畢竟，重用實際上意味著資源共享——就像我們在幼兒園學到的共享一樣，我們那時不喜歡共享，現在也不喜歡。高效的重用需要治理，儘管如此，機構目前面臨的主要問題就是從不斷增加的重用中尋求業務價值。

　　因此，設計師必須理解，重用需要經過很長時間才能建立起來。畢竟，“重用”這個詞本身意味著首先要“用”。 只有當機構使用服務過程中，建立了一個舒適度時，才會重用這些服務。實用重用，因此意味著將重用延後到迭代。並試圖從SOA措施中獲取不同的短期效益，讓重用按照自己的速度增長。

　　·實用舊功能重用. SOA的可重用帶來的另外一個重大的好處就是舊功能重用。當談到令服務得以實現的舊功能時，拇指工程異常持久的80/20規則頗見成效。分析一下在所有特定的系統和程式，你用得最多的舊功能是什麼，使用的機率有多大？你在80%的時間裡使用了20%的舊功能。20%的服務實現就可能為舊復原投資，既為增加的使用也為更好的重用舊資產，提供最好的價值。實際上，你可能會發現，在剩下80%的功能中很難實現服務。

　　·實用面向服務業務應用. 面向服務業務應用由執行業務流程的服務組成。當ZapThink討論面向服務業務應用(SOBAs)的創立和管理時，所有為了建立和維護SOBAs所採取的措施似乎都成了麻煩。事實上，SOBAs的確為機構執行的許多業務流程帶來了麻煩。畢竟，依靠新增支援SOBA所需的內務操作和複雜性，穩定、可靠的業務流程收效甚微。

　　在一個要求高度靈活性和SOBAs提供的使用者權力收益機構，驗證這些業務流程對於設計師來說非常重要。就像全球財政服務公司討論的一樣，機構執行的業務流程中只有很小的一部分證明這些SOBAs要求的額外支出和日常開支是合理的。

　　·實用使用者權利.不需要通過IT，而使特定的業務使用者能夠管理業務流程並推動業務流程的發展是SOA最大的目標。該前景的實現需要安全的治理以及最近才上市的成熟工具。使用者權利的一個更為實用的方法就是利用目前可以使用的終端使用者工具，該終端使用者工具包括瀏覽器、資料表、移動裝置以及SOA啟用的服務，為使用者提供一個更為豐富，更為實用的介面，將更為複雜的組合任務留給了IT處理。

　　這樣的實用使用者權利可以通過多種形式實現，包括Ajax啟用的協議，業務服務的手持介面，以及將服務問題放入單元格的電子資料表等其它的形式，換句話說Web 2.0運動代表了一個為企業設計的自助餐選項。但是，設計師檢視自己的“廢料”，並選出那些風險小，業務價值高的新聞。因此，不需要用那些新工具和他們在日常工作中不能或者不願使用的功能。實用使用者權利著眼於增加業務價值，建立在使用者的功能和需求之上。

　　ZapThink採取的措施

　　我們很少能看到人們在一個句子中同時使用“實用”和“架構”這兩個詞。更不用說使用“實用SOA”這個詞了。實際上，如果你搜尋這個詞，大多數的討論都集中在具體細節的網路服務，而不是SOA的企業架構方面，但是，我們認為，機構為企業架構（EA）採用一個實用方法非常重要，尤其是在實施SOA時。所有處理過Zachman框架的人都知道在EA中採取一個過於正規，全有或者全無的方法是註定要失敗的。相反，設計師必須在工作中必須尋求技術方面和人力方面的平衡，並把主要時間用於為機構建立快速、有形價值的實用效能。

　　在設計師實施SOA過程中，關注實用效能尤為重要。一方面，是因為結構方法的不成熟性，另一方面是因為要為SOA措施建立和維持業務支援的需要。好訊息是，成功使用實用SOA 的機構數目在不斷的增加，不考慮SOA要解決的問題，SOA的實用方法降低了風險，增加了成功的機率——無論是短期的單個專案還是企業長期的結構改變。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14780828/viewspace-406976/，如需轉載，請註明出處，否則將追究法律責任。