SOA的根本目的究竟是什麼？
SOA的根本目的就是業務的敏捷性。也就是說，我們如何藉助與SOA，讓這個業務本身想變就變。要做到這件事情不是太容易，當中有三個要點要理解:
首先是業務本身是非常靈活的。實質上是在談論我們不管下面有沒有IT系統，好比說，在國內實際上有非常多的企業，尤其是中小企業，沒有什麼特別的IT系統，都是靠人自己來做這件事情，他們也有一個業務敏捷性的問題、隨時應變的問題，不需要IT的東西，業務本身是獨立的。他自己怎麼樣才能做得很靈活呢？舉個例子，聯想很高興把IBM的PC部門買了，但是接下來麻煩就來了。IBM給他們N多人，從美國、日本到中國的研發中心，與此同時，這些人工作的習慣，IBM賣給他們的部門的相關工作流程、文化理念和支持他們的IT系統大概一併都得賣給他們。我在美國若干個實驗室包括日本的實驗室都看到非常有趣的現象，IBM的辦公室中間起了一道牆，建築物裏起一道牆很容易。IBM支持這些人的業務流程和業務系統中間砌一道牆怎麼砌呢？這對IBM和聯想來講都是一個很麻煩的問題，IBM怎麼把這一部分人和相關的業務系統和數據剝離出去，而聯想面臨一個很討厭的問題，我們怎麼把這些東西接到我的系統裏面來，這實際上就是一個非常典型的例子，你的業務在發生各種各樣的變化的時候，要怎麼樣去靈活的處理這件事情。
其次是業務自身建模的問題。我的業務是不是真的也可以組件化，我的業務的執行的過程是不是非常的富有柔性，我可以把我不同的業務活動變得什麼樣呢？就是內聚性非常高，外耦合性很低。如果你的業務面上已經組件化並且想好了組裝的問題的話，這個業務本身就很靈活，最終用戶的需求就比較容易的去滿足。
如果說我們在業務層面上做了非常靈活的處理和組裝的能力，可是IT系統相當一部分業務活動是由IT自動化並且支持的，如果不能很好的去配合這一點，也是非常苦惱的。我們一直都在努力的希望我們的IT系統越來越組件化、模塊化、並且有組裝的能力，但是有一件事情我們沒有做好，就是在IT系統中你會發現，那些項目不管是組件和對象做得怎麼好，或者是一些涉及的模式，可是抽象的級別比較低，它和業務的組件和剛剛講的可重用可組裝的業務的活動有着非常遙遠的距離。
所以我們講在這個地方就存在一個事情，我們能不能總結過去IT世界裏一直在嘗試和探索的，希望它有組裝的能力，希望它重用，希望能夠非常靈活的應付各種各樣的變化的能力，設計哲學和設計原則，能不能提升抽象的級別，使得我的IT系統能夠直接出現一個業務人員可以理解的抽象單元，而且這種抽象單元還可以像過去OO的世界裏面的組件的樣子，他們有着非常清晰簡潔的接口，同時按照各種各樣的模式可以比較靈活的組裝，應付各種各樣的變化。這個就是面向服務的架構SOA裏所談論的一個新的抽象級別：服務。
服務作爲一個更高級別的抽象，對在引用的IT系動，它繼承了過去我們在多年IT探索中所得到的設計哲學和理念，集成了他們並且將其進行延伸，增加業務抽象和業務支持的部分的東西進來，成爲一個新的IT人員應該掌握的抽象的手段。它可幫助我們非常靈活的將IT世界裏的東西進行分割，並且靈活的組合。
還有第三個問題，那就是一個已經切割好可以靈活重用和組裝的業務世界裏的單元，與IT世界裏的單元，它們之間的影射，或者我們用一個學術的詞“可追溯性”，這個參考的架構談論最多的一件事情就是“可追溯性”。
這個意思是雙向的。當業務活動發生變化，比如說業務的規則發生變化，或者業務流程對這些業務活動進行組裝層面上發生變化的時候，這種變化如何從業務的世界向IT的世界去進行傳遞？這是一件事情。其次，我在IT世界裏，當我要切換到一個新的平臺，我從過去老的主機的世界切換到J2EE或者相反的過程中，我形成的IT世界裏的衝擊帶來的一些變化，如何反饋或者在業務的級別上被阻斷，如果有什麼變化，怎麼影響業務層面上的東西，影響在哪裏，有沒有很好幫助你定位的地方，使參與這個事情的業務方與IT方所帶來的困擾儘量的減少。
SOA的本質
從它的本質上來講，SOA是一個構建IT組織、實現和整合業務流程的新的IT的趨勢，它的核心就是引入了新的抽象級別，就是服務。這個“服務”基本上可以理解成重複使用的，可以和別的服務進行組裝的業務單元或者業務活動、業務能力。
講到服務，更多的是談論的不是IT的概念而是業務的概念，也就是將公司可重用的業務單元組裝在一起，來形成你的業務流程，滿足你的業務需求的公司，我們稱之爲這個公司是面向服務的，它和今天經濟轉移到知識經濟、服務經濟是非常有關係的。爲了支持這樣一個業務，IT系統要具有自身的架構風格，這種架構的風格是以服務爲中心的，我們稱之爲面向服務的架構。在這個世界裏，各種各樣的業務方面的應用和流程其實就是一個又一個的複合應用。
這種面向服務的架構和過去是非常不同的。首先是標準化和組織的承諾，這兩件事情是非常重要的。第一你要做SOA的事情，標準化要在企業架構裏有非常好的貫徹。另外整個組織的承諾不是CIO的承諾，不是CTO的承諾，也不是一個技術人員和幾個技術人員的承諾，首先是CEO的承諾，然後就是各種各樣業務部門的承諾。要讓他們看到面向服務或者是以服務爲中心的業務模式對創新和業務的靈活性，對他們賺錢和關心的種種痛苦的問題的解決是如此之有效。所以他們說，OK，讓我們面向服務，接下來是IT部門需要去關心和承諾的東西。
整個SOA實質已經將IT系統的抽象級別從一個過去純粹的技術世界（對象、過程、函數、組件等）逐漸延伸進業務的領域。從技術人員的角度小節一下，SOA就是這樣子，我們將業務的功能和應用的數據變成可重用的模塊，它們可以連接起來，完成端到端的過程，這個模塊就是服務。SOA本身定義了業務和IT兩個層面上的東西，首先是你的業務本身、流程怎麼實現，IT怎麼樣實現這樣的哲學和業務層面的設計創建和交付。
SOA如何落地？
首先是業務層面上的建模，怎麼樣將業務進行組件化。然後是IT世界裏怎麼架構，怎麼去建設這些東西。一方面是說業務世界裏建模以後，藉助於服務建模的過程，這實質上就是將粗密度的業務組件和業務活動與過程怎麼樣遞次分解，映射到IT世界裏比較細密度的服務上去，藉助於SOA基本的架構風格根據你選擇的產品設計架構來實現。一方面是業務的結合，還有一個是粗細密度的結合。SOA沒有辦法一蹴而就，是一個需要業務和IT的世界攜手同行，相互理解，大家這樣合作才能達成目標，這是一個長期演變的過程。
實際實施的時候有很多問題，我們總結了十大頂尖問題：什麼時候開始一個服務、什麼是好的服務、可伸縮性標準等等。我只是簡單講一下，怎麼樣開始第一個SOA的項目。
通常應該有一個遠景圖，然後應該對自己做一個成熟度模型的分析，這裏是從方方面面來講的，可以類比CMM的角度去講它，從業務組織、IT的方法、應用的狀況、整個情形、架構是什麼樣子的，硬件和軟件的基礎設施。做完一個評價以後，可以確定自己的目標怎麼做，選擇其中的一個或者若干個作爲你的重點開始第一個項目。從切入點的角度來講，可以從不同的角度來想，一個是增強數據的重用能力，一個是把連通性解決好，把整合的基礎打下來，讓人的合作變得好一點。
治理也是一個非常有趣的話題。治理是使得SOA的作用真正發生的基礎。SOA的治理方法實際上是我們在實踐過程中總結出一套方法，這個方法是可供參考的。你可以從計劃的角度，先可以做一個計劃，實際上是從企業整體的角度出發，可先側重在某一個局部，做一個計劃，然後將相關的規矩定義出來。實施的過程中要遵循一些東西，最後有一個評審，之後要有一個修改，這樣去實施這件事情。因爲你整個SOA來講，服務是有生命週期的，從業務建模、定義出來，創建出來開始組裝，開始用，開始管理，這個過程中你都可以應用SOA治理的標準和要求。
