--正確的SOA開發要求對軟件開發方法進行重新設計

　　面向服務架構（SOA）的概念已經成為一個非常時髦的技術術語。盡管技術確實扮演了重要角色，但是正確的SOA方法要求對軟件開發方法進行重新設計（或重構）。我們習慣采用基于組件或基于項目的方法來進行應用程序開發，但是SOA要求采用自頂向下（top-down）的方法。這意味著我們應以全新的眼光來看待應用程序設計和項目管理。

　　讓我們來探討一下成功實施SOA的非常重要的10個關鍵要素。

　　1. 企業架構團隊
　　 SOA是企業范圍的長期戰略。因此，大多數公司都通過成立中心團隊（企業架構團隊）來實施SOA，該中心團隊掌管并向前推動SOA。在大多數情況下，該團隊是一個小而嚴密的工作組，具有多樣且互補的技術，掌管企業的總體架構。企業架構團隊負責制定內部標準、藍圖、參考架構、設計模式、模板、一些共享和水平服務等。它與業務線專家緊密合作，或者擁有領域專家作為該團隊的一部分。這個高瞻遠矚的中心團隊對于減少各個工作組和部門重復開發工作策略以及制定其自己工作方法的風險十分重要。
企業架構團隊是成功實施SOA的最關鍵要素。沒有一個理解如何操作和掌控SOA的優秀團隊，實施SOA的工作很難成功。

　　2. 實施路線圖
　　 一旦成立了企業架構團隊，接下來的主要任務是與業務和IT團隊合作，然后制定實施路線圖。就像任何一個好的項目，計劃得越細致，成功的機會就越大。

　　 一個常見策略是開始創建當前狀態和未來狀態的文檔，這些文檔使得查看整體情況和理解系統的交互變得更加容易。這一方法還能幫助確定哪些是公司“痛點”的系統。

　　 下一步是確定可行的里程碑（在大多數情況中，為6個月、12個月、24個月或36個月）。

　　 一些遺留下來的關鍵任務系統會隨著時間的推移而修修補補，包括“粘縫在一起的借助于繃帶”的解決方案。像這樣的系統就是定時炸彈。有時候，這些就是實現SOA的很好的初始候選項目。通常，根據系統功能的紊亂情況如何、修復它的可行性如何以及投資回報率（ROI）來挑選初始候選項目。

　　該路線圖應與公司的戰略利益聯系在一起。諸如項目進度、資金籌集、人員安排、業務驅動因素和業界競爭等因素都可能影響實施的進程。由于一些因素可能使得SOA脫離正確的軌道，應當仔細地定期追蹤進程。記住，最初的一些成功對于贏得對SOA的支持和給機構帶來的重構十分重要。因此，從策略的角度看，在初始階段選擇正確的候選項目十分重要。

　　SOA路線圖一般具有多個階段。在第一階段中，公司進行前期摸索并試圖了解技術挑戰。在這一階段，實施諸如驗證、授權、確認和數據轉換等簡單的水平服務。在第二階段中，制定更多的面向業務的服務。這些服務常常從門戶中冒出來，因此很容易獲得收集在后端系統中的信息。第三階段包括聚合服務、開發工作流和集成各個不同的系統。

　　3. 架構
　　只有具備健全的架構基礎才可發揮SOA的主要優點（松散耦合、重用以及技術和服務的抽象）。企業架構團隊是一個中心機構，掌控著整個企業的架構。從SOA的立場上看，架構和設計的以下方面十分重要。

　　平臺：最根本的決定之一是使用什么技術。來自底層平臺的支持很重要，因為它能幫助我們避免自己編寫解決方案。用戶還需要考慮團隊對具體平臺的滿意度。一個好的平臺能顯著減少開發和維護的總體成本。一些公司也使用多個平臺的組合。SOA的優點是，當服務成熟到一定程度之后，界面比底層技術更加重要。由于ROI的原因，技術也變得“可插拔”，即可以任意選用技術。

　　標準：對于SOA來說，Web服務是業界最常選用的技術。在這一領域，標準正在不斷發展，并且多個相互競爭的標準解決的是同一個特定問題。良好地掌握這些基本原理和要素的實施方向可確保資金不會花在錯誤的技術上。遵從標準的平臺能夠保護投資，并且使得與外部合作伙伴和軟件開發商的的集成變得更輕松。

　　第三方：公司總是和外部合作伙伴保持聯系。盡管我們不能控制第三方的架構，但是我們應試圖使他們遵循SOA，這樣在長期內使得每一方都更輕松和經濟高效。這一點同樣適用于系統集成商和開發商。盡量減少戰略合作伙伴的數量對于控制復雜性非常有幫助。

　　服務：一個機構可能有幾種服務。有一些是垂直的和以業務為中心的，而其他的更加廣泛。后一類別中的服務——例如安全、數據轉換、翻譯和事件服務——一般是較好的初始SOA候選項目。企業架構團隊負責在實現“橫切”服務中提供設計模式和指導準則。

　　企業架構團隊（與各垂直團隊相合作）還負責培養Gartner所說的“生產力層”，該“生產力層”促進服務的重用和聚合。Garner稱：“沒有它，在Web服務和其他服務方向中的投資將很難得到回報?！币虼?，其中一些服務屬于該類別。

　　像Web服務這樣的技術使得這些服務獨立于環境。這種獨立性使得服務可以跨多個水平項目而方便地使用。消息傳遞可以使應用程序松散地耦合聯結，但是為了實現最佳的重用，甚至環境也應被抽象掉。

　　強烈建議這些服務要經過具體計劃和架構審查。這將為與之合作的垂直開發團隊提供一致的和相似的模式樣式、名稱空間以及其它。較好的策略是，在利用架構模式的同時，采用業界或領域模式。

　　管理服務：一旦開發和測試了這些服務，就需要將它們部署在生產環境中。正如Web開發世界中那樣，開發應用程序是一回事，在生產環境中管理它們完全是另外一回事。服務水平目標（SLO）、服務質量（QoS）、安全、訪問控制、故障轉移、監視、災難恢復、審計和通知僅僅是需要管理的長長列表中的一小部分。特定于行業的管理方法，如HIPAA和Sarbanes-Oxley（SOX）可能需要用于控制更改、審計、監視關鍵系統的附加基礎設施。其他需要注意的事情包括：循環負載處理、版本管理、服務的生命周期管理和伸縮性等。

　　您應為服務的健康增長和發展制定規劃。因此，應具備良好的變更管理策略。如果您需要遵照HIPAA和SOX等，則這可能是強制性的要求。

　　4. 技能
　　優秀的技能分類對于任何軟件項目的成功都是必要的，這一分類包括深入理解領域、垂直技術和過程、業界和技術標準、新興技術和趨勢、編譯要求、開發平臺的專門知識、模式、最佳實踐、項目管理和測試。

　　為了能夠提供強有力的指導和領導，企業架構團隊應該是熟知這些核心技術的一個精干的小組，。而在那些垂直團隊中，其成員應深刻理解業務流程并應能夠協助EA團隊確定和設計良好的服務。

　　5. 交付模型
　　交付模型包括三個主要方面：團隊組成和規模、項目持續時間和開發方法。由于項目、技術方案、對技術的滿意度和專業知識的不同，每個組織的交付模型都不相同。該模型應在各個工作組和項目中保持一致，這樣當開發人員跨項目進行轉移時，會有相似的經驗和最低限度地減少學習彎路。

　　交付模型的示例包括對于中型項目的6 x 12（6個開發人員12周），以及對于小型項目的4 x 6（4個開發人員6周）。該團隊一般包括諸如項目經理、質量控制（QA）人員或業務分析人員的附加支持成員。支持團隊成員理解總體SOA目標很重要。他們需要和企業架構團隊緊密合作，并幫助確保工作具有策略意義。公司還已經嘗試了不同的SOA常用方法，如敏捷建模（Agile Modeling）和極限編程（Extreme Programming）。

　　6. 管理
　　擁有健全的管理模型能夠確保服務的結構化、成熟和健康增長。諸如組織中的驅動因素、文化、技術和信心等因素都顯著地影響著這一模型。管理對于確保沒有重復勞動和項目不偏離SOA都非常重要。

　　誰應對這一策略負責呢？無法得出直接答案。SOA確實是全體人員的責任。個人和垂直工作組自己均應確保他們總是符合服務方向。用戶不應屈從于走捷徑的誘惑，除非業務壓力而必須這樣做。企業架構團隊可以發起制訂策略，并在一定程度上對其進行監視。然而，即使在一個中型組織中，企業架構團隊也不能為每個項目制定策略。

　　企業架構團隊和項目管理辦公室（PMO）負責項目的優先級制定和排序。所有的業務要求（共享的或企業范圍內的）都應經過企業架構團隊。與使用單位人員、PMO和垂直團隊緊密合作，制定項目的優先級。一旦實施，企業架構團隊確保應用程序是符合SOA的。隨著服務發展到下一代，企業架構團隊為垂直工作組提供技術指導。

　　與第三方開發商和外部合作伙伴一起承擔SOA一致性的專門檢查。有時候，如果SOA一致性的級別不能令人滿意，則企業架構團隊成員應與開發商合作，并確保其滿足一致性。應制定方法來確保開發商為產品的后繼版本提供持續的SOA一致性。

　　管理組織應確定誰擁有給定服務（并因此對此負責）。責權的結合能夠減少模糊性，并且在出現問題時能夠確認哪個團隊對此負責。這對于共享的或企業范圍的服務（如編寫日志和安全）特別重要。在組合式服務的情況下，服務的總體質量取決于每一個組成服務。適當的責權結合有助于系統的平穩運行。

　　7. 戰略安排
　　新技術的刺激有時候會妨礙基本的業務因素。IT業在這方面有許多實際例子。有了SOA，這可能更容易發生。

　　因此，企業架構團隊的重要任務之一是進行持續的現實性檢查。企業架構團隊和業務專家需要確保SOA的步伐總是跟隨戰略性業務目標。如果短期的商業目標與長期目標沖突，那么該團隊應和高級管理層協商并找出最佳解決途徑。

　　這一點說起來容易做起來難。由于總會有異常發生，必須具有一個基于其問題的緊急程度進行改正的程序，這一點很重要。否則，這些異?？赡軙闹朴咺T項目優先級的業務流程中被孤立出來。
無論技術解決方案多么優秀，不著眼于業務價值的解決方案都是毫無用處的。

　　8. 溝通
　　SOA是整個企業范圍的工作。在大多數公司中，企業架構團隊創建其他垂直開發組能夠利用的可重用服務。即使在一個中型的IT團隊中，協調工作也是一項巨大的任務。其他工作組如何才能知道有什么服務可供使用？哪些組件可以忽視？正確使用服務的方法是什么？

　　提供服務的目錄清單是一種可能的方法，但是在大多數實際情況中，這一點并不能確保人們理解它。應該利用過程和最佳實踐來發布和消費有關可用服務的信息。一些公司為此目的而使用門戶，而另一些公司則使用通知媒介，如blogs和wikis。無論您喜歡什么媒介，在正確的時間對正確的人發布正確的信息都十分重要。

　　SOA涉及重大的重新設計，而每個人都對變化持有抵觸情緒。在任何一個組織中，特別是在實施的初始階段，預計會有一些抵觸。懷疑對于組織有利有弊。它是有利的，因為懷疑可平衡激進。它們有助于確保SOA支持者不會過于有野心。但是懷疑也是有弊的，因為它為說服懷疑者和推動正確的變化帶來了額外的工作。

　　Web服務技術的缺陷之一是，如果沒有良好的溝通渠道，架構可能變得更糟。采用XML計劃。當團隊獨立工作時，他們總是創建定制的但未必基于標準的模式?！白詈笠环昼姟钡膲毫蛧栏竦臅r間期限成為這一現象的催化劑。這一方法在短期內是有效的，但是這種“臨時”計劃很快就累積起來，并導致系統過于相互依賴和脆弱。

　　持續的溝通十分重要。公司通過定期舉行全體會議找到了成功之門。也可以通過這些會議來交流項目如何帶來良好的ROI，以及其他工作組如何使用現有的服務來使其流程更加高效。這將有助于更快的采納。

　　9. 高級管理層的支持
　　高級管理層的支持不僅對控制抵觸力量很重要，而且對其他方面如資金籌集等也很重要。SOA包括先期的投資。除非IT具有高層的支持，否則推動它向前是很困難的。如果我們看看業界主要的SOA實施，一個共同的模式就是CEO強烈信任該范例和技術的價值體現。

　　高級管理層還應確保，SOA實施符合業務需求并提供了所承諾的ROI。管理指導對于確保長期的業務目標和IT方向之間沒有偏離極為重要。

　　10. 持續進行重新設計
　　SOA不是一次性的模型。它包括持續的發展和重新設計。在初始幾個階段，它主要涉及到構建新服務以及將遺留的應用程序（使用適配器）部署在SOA上。水平服務（或共享服務）通常也是初始階段的一部分。一旦基礎服務就位，服務的下一代通常包括抽象化和精化業務流程。沿著這一路徑我們需要經過多次迭代。對于每一次迭代，反饋信息傳回到服務并進一步精化。

　　全程實現SOA的目的在于，在不斷變化的市場條件下促進靈活性和適應性。隨著業務的不斷發展，支持它的服務也將不斷發展。

　　SOA投資
　　走上SOA之路就像是進行退休儲蓄——這是一種長期的投資。用戶可能會經歷一些短期的痛苦，但是最終將得到回報。靈活、堅定、紀律和執著是先決條件。拋棄不良習慣而采用更好的習慣，真誠地反省和堅定不移的恒心。SOA并非萬能藥，但是它確實能夠幫助集成業務關鍵型軟件。SOA既是技術也是業務流程的重構。透徹地理解這兩者有助于確保長期的成功。

　　致謝：感謝Mike McCoy、Vasavi Nemani、Madhusudan Nori和Srinivasa Nemani，感謝他們的反饋意見和建議。