SOA的實施之『道』—中間相遇

　　SOA推進策略的問題，是我們最近被問到最多的問題。有個管理專家用『道』，『法』，』術』,來比喻SOA幾個方面，很有意思。『道』的層次可以認為是業務敏捷，IT靈活性等管理目標，』法』是指，SOA的管理與控制規則，『術』，是指各種具體的標准與技術規范。

　　看到今年以來，媒體上無數技術廠商，應用軟件公司，甚至硬件公司都把SOA當作時髦的標簽做市場宣傳，我不得不自嘲的認為，自己也是學屠龍，賣豬肉。一種技術潮流剛剛興起的時候，發生炒作和形式大於內容的事，在IT領域已經成為一種傳統。從興趣進入真正的項目推進，纔是真正有價值的事。然而認真思考了SOA架構理念的人，很快就會發現，想要把它認真落地，一大堆問題就浮現在腦子中：

　　·如果企業的業務戰略都在不斷變化，傳統的IT規劃是否還有應有的價值?

　　·如何一面開發應用系統，一面建立企業級的服務管控規則?

　　·現有的生產系統都十分陳舊，如何將他們納入新的SOA架構?

　　·如何在開發新的跨業務應用融入SOA的實施方法?

　　·SOA好像是比EAI更好的一種集成『術』，到底有什麼不同?

　　下面我試著用中間相遇的策略作為一種可行的辦法，來回答一些問題。有些企業在推進SOA實施時采取的是『自頂向下』的方式，即從企業的戰略開始，逐步向下展開;另一些企業則采用了另一種途徑，就是『自底向上』的方式。這裡所說的『自底向上』，並不是說由底層的技術推動業務，而是說，從小的項目開始做起，積累經驗，然後做大項目，最後上昇到戰略層面。

　　然而，無論是『自頂向下』還是『自底向上』，這兩種SOA實施策略都各有利弊，很難達到理想的效果。

　　『自頂向下』是企業實施SOA戰略性的策略，其核心思想就是從企業層面做SOA實施的整體規劃。它的好處是從企業整體進行考慮，面向業務，企業可以根據其業務的發展情況以及現有的IT情況做一個SOA實施的整體規劃。這樣可以推動整個企業的標准化，所有的服務模塊都基於相同的標准，方便今後的重用。但是它的風險也不小：一方面是范疇涵蓋大，周期長，初期的投資大;另一方面是它要求整個企業要有比較高的紀律和技能，有一套完整的組織架構和管理流程。

　　『自底向上』的實施辦法則是戰術性的，它強調從小處著手，從一個部門級應用開始實施SOA。這種方法的好處是見效快，風險小，初期的投資也不大。不過這種實施方式的彈性相對比較差，特別是當企業需要在更大層面實施SOA時，可能會產生一些銜接問題。

　　結合多年來幫助客戶成功實施SOA的經驗，一種更加切合實際的SOA實施策略，這就是『中間相遇』(meet in the middle)的實施策略。在SOA的實施中結合『自頂向下』和『自底向上』的方法，尋求兩者之間的結合點，纔能最有效和成功地實施SOA。因為對絕大多數企業或組織機構來說，在業務系統實施的初期，存在很多不確定性，包括業務需求和項目所選擇的開發技術、平臺等都存在不確定性。遵循『中間相遇』的原則，業務人員和開發者都各自循序漸進地做事，在過程中不斷溝通，這樣就能夠使得業務的改變得到最快的響應，並且不會影響開發效率，最終兩者能夠在某一點相遇，從而搭建起符合需求的系統。通俗地說，『中間相遇』的原則就是我們常說的『大處著眼，小處著手』，在做一個一個項目時，並不僅僅把眼光局限在正在進行的項目，同時也兼顧企業IT系統和業務發展的整體規劃。

　　那麼，采用何種軟件工程學作為指導推進中間相遇的實施策略呢?

　　許多傳統軟件工程學的都是在SOA之前發明的，這裡面的大多數方法沒辦法通過簡單的拿來主義，直接用於指導SOA的軟件開發。項目群的整體規劃，可以采用PMO的辦法。但針對SOA應用開發的推進，我們需要一種方式，既能針對SOA實施的特點，又能兼顧特定企業的管理模式和軟件開發習慣。

　　很多大型企業應用系統是一個規模宏大、業務復雜的系統，現在所有從事的架構師都在考慮基於SOA服務的軟件工程學。基於『中間相遇』的實施策略，在自上而下地規劃了IT戰略和參考架構後，企業需要找到一個有代表的應用項目。引入SOA服務工程學來開始此具體項目的實施，通過這個SOA服務工程學的推進方法，企業可以依靠如下三個方向建立自己獨有的SOA服務工程學框架：

　　建立符合企業管理模式的SOA管理架構：每個企業的組織架構，管理策略都不相同，通過SOA服務工程學的推進可以建立針對特定組織的管理原則，紀律，運營和管控

　　建立符合企業習慣的服務工程：SOA服務工程學可以看作是對企業原有軟件工程的一個擴充，它在利用SOA服務的重用，靈活性，業務敏捷，和投資回報等方面增加了一些針對企業級項目群管理服務工程，比如針對SOA開發的，SOA需求管理，服務識別與發現，版本規劃，服務定義，設計，實施，部署，管控等等。通過前一到兩個項目總結的這些方法和原則可以作為其他項目開發的基准。

　　SOA基礎架構的搭建，選擇前一到兩個有代表性，覆蓋技術架構比較廣的應用，同時也進行了針對特定應用的架構驗證，在此過程中，一些類似ESB，BPM ,數據服務，服務庫等SOA基礎設施也同時被建立起來。

　　以下我們舉一個例子：(在這裡，項目1、項目2和項目3也可以被看做3個典型業務場景)：

　　在開始具體項目實施之前，企業首先需要先為企業確定一個參考架構(Reference Architecture),相當於我們常說的頂層設計，後面實施的自底而上的項目都要瞄准這個參考架構。下面我們來分析項目1和項目2。雖然這兩個項目都是從底層編碼開始實施，但是項目參與者已經有意識地在用SOA的思想和參考架構去做，並且在遵循按服務契約設計的實施方式。在這裡，項目1和項目2的選擇是一個很重要的問題。由於是處於嘗試階段，前兩個項目通常會選擇比較緊迫、能體現一些用戶需求、並且能夠體現快速實現ROI的方式。項目1和項目2盡管都是從編碼做起，但不完全是自底向上地做，而是遵循一種『中間相遇』的思想，這也是通過實踐總結出來的比較安全的推進方法。從項目3開始，參與者就開始有意識地構建那些重要的服務層以及相關的管理控制策略，以形成企業資產。前兩個項目中的服務，在後期的項目中被重用的幾率可能有一些折扣，比如服務的重用率可能達到70-80%，而不是理想的100%。但是在實施的過程中，可能已經體現出了SOA的優勢，如此一來，很容易博得企業決策層的認同，進而支持項目3的推進。

　　項目3是非常關鍵的環節，在實施過程中，需要形成一些涉及到戰略層面的管理知識和規則。從項目3開始，就要抽象出一個服務層來：即需要在業務層和技術層之間增加一層服務層，以彌補業務與技術之間的鴻溝。也正是由於服務層的形成，能夠保證在技術的跳變時不會直接影響到業務需求。

　　開始做最初的SOA項目時，我們會先解決比較急迫的業務問題，然後根據這些業務問題用SOA方法，如分層的結構、ESB結構，實施一兩個項目。此時要盡量具體著眼於項目本身對具體業務的價值。實施完這兩個項目以後，就能給整個組織帶來信心，尤其是管理高層。隨後，就考慮引入一個管理SOA的規則，把前兩個項目總結的經驗和包裝的服務標准化，盡量在後面的建設中應用，即引入SOA管控。所以，這是一個循序漸進的過程。但我們在做第三個項目的時候就不再自底向上，而是開始從SOA實施小組管控中心的規則和最初的兩個項目達到磨合，而產生了服務的中間層，包括服務本身具體的架構。

　　在整個SOA推進的過程中，所有的東西都是在不斷迭代的，參考架構，服務定義，實現的技術都是可以不斷迭代的，正是因為SOA的松藕合設計，纔使得多重迭代成為可能。

　　回到文章開頭SOA的『道』, 『法』，『術』邏輯，以面向業務的企業架構『道』著眼，以具體實施項目的『術』入手，在SOA服務工程中的服務『法』相遇，就是中間相遇策略的基本理念。