時間：4月12日 15：00-15：45
主講人：毛新生
主持人：各位來賓，大家下午好，非常感謝大家能夠一直堅持聽我們的演講，相信大家聽了毛先生的演講肯定會覺得不虛此行，為什么呢？因為SOA談了幾年，其實在各種場合中在各個領域里也有很多的交流，我得到反饋毛先生是講的最好的人，希望大家多多問他一些問題，讓他把演講講得更加生動和精彩。
毛新生：SOA確實是在太多的場合講過同樣這樣一個題目，所以我深知講大家聽過的題目講出一些名堂，是非常辛苦的，所以今天還是需要大家嘴下留情。
今天我希望給大家報告的主要有這么幾個部分內容，第一部分，SOA究竟希望解決什么問題。第二部分，應該怎么樣去看待SOA，當我們考慮SOA應該從哪些方面來考慮。第三部分，談論IBM在SOA方面的方法、技術和服務。最后，做了兩年多，我們也一些經驗希望能夠分享給大家。
現在的業務環境對于這些老板來說，他們關心的重點當然永遠都是“錢”，是利潤，是他整個部門和整個企業員工的生產效率，以及對各種各樣的變化快速的響應能力，不管是客戶的需求還是市場上的變化，這就需要他們做各種各樣的創新。IBM有一些市場調查，像今年我們剛剛對全球的CEO做完調查，要做到這一點非常不容易，我們需要持續地創新，也就是說我們要改我們的業務模型等等。這樣一個創新或者說這樣業務上的轉變，主要有這么三點：一，怎么樣讓我們的人在整個企業范圍內部或者在企業外部，也就是跟我們的合作伙伴，跟我們重要的客戶很好地協作。二，我們的業務模型、業務流程能夠怎么樣做一些改動，使得它的自動化的東西更多一些，效率更高一些，然后使得我們的業務模型的成本結構更加優化等等。所以，我們需要創新我們的業務模型、優化我們的業務流程。三，我們怎么樣對我們的信息有更好的利用，這在我們日常生活當中是非常多的。
我接觸過亞洲的好幾個銀行，這些銀行都非常強調，跟我抱怨說他們現在沒有辦法，業務人員沒有辦法拿到一個單一的對客戶的信息，其實在中國是非常普遍的，前不久我就面臨自己的一個問題，我到中行給我信用卡交錢，我就跟他說，我現在在你銀行有一個賬號存了多少錢，我有一個信用卡，麻煩你從這個賬號劃一筆錢交到這個信用卡上去。這個柜臺的小姐說對不起，我不知道你的信用卡花了多少錢，需要你打電話。然后我就打電話，那邊打電話查詢你花了多少錢，每一筆是多少錢，合成美金是多少錢，然后告訴我需要到網上查，在中國銀行事實上它不同的客戶渠道看到的客戶信息是不一樣的，毛新生這個人在中行不同的渠道那兒是個不同的人，就不是一個人。我就很不爽，我在這里所有的業務都在這個地方，怎么是不同的人，還得我做這個做那個，這是一個典型的情況，造成的IT每個渠道就是一個單獨的系統，建立的模型不一樣，處理的過程也是不一樣的。我在招行有一張卡，這些問題就可以解決。
信息看起來不是那么容易，我們要把這個信息自由地在整個企業范圍內流動，讓我們的員工在需要得到信息的時候就可以得到，就是信息唾手可得。談論這個問題引出的一個結論，我們今天是一個強調速度的時代，有越來越快的變化，有越來越多的變化，這些東西還要變得正確，我們要做一個正確的變化，來使得我們的業務能夠持續地去創新，在業務上、在市場上能夠獲得一個很好的業務結果。做到這一點，大家都希望企業的IT信息系統能夠幫這個忙，但是這個好象不是那么令人滿意。首先，看看企業的企業架構就有點問題，結構非常亂，而且也非常復雜，我們做一些項目周期很長，在某個地方做一些小的改動，將一些系統連接起來，花的代價都非常大。非常有趣的是，在過去兩年多來，我在亞洲所有國家的客戶那兒，我跟客戶要整個架構，每個幾個企業不能夠給出來，這是普遍的情況，韓國、日本、東南亞一些國家都是這樣，拿不出整個企業范圍內的整體企業架構，如果要拿出來，畫出來的東西就是這個樣（見圖）。從花錢的角度來講，整個IT現在花的錢，每年拿到的預算超過70%的錢都是用在IT的維護方面，IT運營當中出的一些問題的解決方面，而不是用來開發新的系統，或者是加強已有的系統來滿足我們客戶的需求，這樣一個狀況也非常的普遍，比如我們在上海的中國遠洋集團，他們的情況就是這樣，他們EDI系統大概有十來個人做工作，差不多八九個人解決各種各樣的問題，一會兒三星來一個抱怨說我這個海關報關怎么沒有做，有什么問題，一會兒又是沃爾瑪來一個電腦，弄得他們天天加班還很不高興。IT部門一直處于不太好的狀況，非常努力地做事情，可是業務部門經常在質問IT部門你們花了我們很多錢，你們能不能做得更加快一點，做這些事情花的錢更少一些，然后做的事情出問題少一些，質量更加高一些。甚至說在幾年前華爾街有一個分析師說IT已經不重要了，這個東西沒有辦法說，用IT的東西就讓我獲得戰略性的優勢，這就需要IT去思考，我們該做什么樣不同的事情，或者我們換一種不同的做法，來使得我們重新回到十多年前沃爾瑪有一個小小的零售鏈，利用IT、利用整合擴展的價值鏈上的供應鏈管理系統，從而使得它逐漸從一個美國偏僻地方的小倉庫逐步發展到今天全球零售業的老大，在它的號令之下，無數的垂直的價值鏈聽命于他，他給你一分錢的利潤就是一分錢的利潤，這是IT所成就的。到今天，沃爾瑪的IT系統依然是非常具有特色。
我們IT需做些什么東西改變安全狀況，改變IT企業架構的混亂，大家非常努力做事情，還是非常委屈地受業務部門的抱怨。事實上它意味著我們構建軟件的新的趨勢和要求，這就需要我們認真想。首先我們來看看過去的IT系統，過去的IT系統無論是美國，美國大概有四十多年的IT建設的歷史，其他的國家有三十多年，如果要看中國大陸，應該是十幾年的IT建設的歷史，這么多年的建設歷史，實際上過去我們都是這樣一種哲學來做的，就是由部門驅動的，我們過去的業務模式也是這個樣子。一個部門提高效率，就能夠在市場上單打獨斗，就可以生存下去，還可以賺到很多錢，現在IT環境比過去復雜的多。我們需要從過去以部門為導向開始轉移到企業內部各個部門要努力去很好的相互協作，非常動態的，根據外面客戶的要求動態的協作。而且我們還要想辦法把自己不太擅長的東西交給我們的合作伙伴去做，在一個動態的價值鏈上怎么樣去利用別人的能力，大家以一個雙贏的心態、雙贏的合作來為我們的客戶提供最有競爭能力、最適應、最讓他覺得值得的、需要的服務，這樣就導致我們的業務模式發生一個很大的變化，放在整個全球化的狀況之下，其實每一個企業、每一個行業都面臨這樣一個狀況。
比如前不久我參加了一個汽車IT論壇，大家都在說現在中國要怎么樣利用我們的自有優勢，參與到全球汽車的零部件采購當中去，我要在這個價值體系當中來發揮我的優勢，賺到我的錢，這對他意味著什么？意味著他的業務模式轉移成這種方式，而不是過去那種方式。這種業務上的變化，對IT意味著非常非常多的東西，我們可以看到在過去我們IT系統建設的原則就是我們以一個部門為導向、為中心，提出它的業務需求，然后我們給它建造一個系統，這個系統完成這個部門所需要的東西，我們看到不同的部門在做自己的事情，在過去若干年當中建立了一堆系統，但是很不幸的是，每一個部門其實建這些系統的時候他們的哲學都不太一樣，請的人也不太一樣。由于在不同的時間點上建的這些系統，因為IT的技術都是逐步發展的，所以他們使用的技術也不太一樣，從而使這個整個企業范圍內的系統不僅僅是一個孤島，大家沒有連在一起，大家對數據的看法，大家對業務邏輯的看法、對技術方面的看法不太一樣之外，還有一個非常有趣的問題，就是整個這些高度異構、高度分布、高度異制系統的就像一個破碎的系統，這種做CE的方式，業務上這種變化并不是一天一夜發生的，它是逐漸發生的，很多企業的IT系統建設也反映了這樣一個業務模式的變化過程，也就是說在過去我們力圖在采用一些私有的或者是業界比較那么不通用的方式做了很多的闡釋，就是我們過去一直做的企業應用整合。我們采用各種各樣的方法，有的人有文件共享的目錄，有的用STP，有的用RPC，有的人做得好一點會提供數據總線，采用類似于中心、輻射這種所謂集成范式，來形成有線的連接，大多是點對點的連接，這種集成到今天為止，因為其私有的技術，因其在探索過程當中形成整合的范式并不是最佳的做法，從而帶來了相當多的問題，一方面是這種整合沒有帶來一種靈活性，缺乏這種靈活性，使得整個架構非常脆弱。也就是說我希望在某一個地方希望發生變化，這個變化將會沿著整個集成的架構擴散到很多跟它打交道的地方去，從而使得一個小小的變化需要非常大的變化才能將這個變化所滿足。
另外一個問題，相當多的點到點的連接，使得系統當中的邏輯和系統要重用的時候，付出的代價是相當高的。不管我們過去做了多少，我們還是在一個非常技術、非常細節性的層面看待IT系統，在IT系統里面表現出來的是對象、過程等等東西它們富有的只是技術的含義，我們為了表達非常業務模型的東西，比如業務的過程、業務的活動、業務的流程，我們是用代碼將它們拼起來的，從而使得這樣硬編碼的方式改起來相當難受。為了配合這樣一個普遍的業務模式，我們需要我們IT做些什么，首先我們需要從部門導向這樣一種方式逐漸開始轉移到在整個企業范圍內的整體規劃著手的方式來轉移。這樣一個轉移最重要的目標為了確保我們的移動邏輯和數據的資源確實是能夠共享的，因為要共享首先意味著他們在講同樣的話，在采用同樣的標準、指導原則等等，而不是說你做你的，我做我的。這背后意味著你的IT管控能力，意味著你整個企業范圍內應該有架構師的委員會，甚至通過你的高管所形成的推進委員會，由他們在決策層面、在戰略層面和技術執行層面制定種種規范，使得整個企業范圍內每個解決方案的執行都應該有整個企業范圍內考慮的參考架構以及相關的設計原則等等。從而保證你的數據模型、你的業務邏輯等等具有一致性，這種一致性是最后在實現級別，大家能夠相互共享最重要的基礎。
其次，我們開始要從過去比較私有的或者是局限于某一個提供商的技術和方法，逐漸地轉向到一種開放的、通用的標準所基于的運行環境、開發方法、工具等等，并且要確保所有的系統都能夠非常自由地、通用的方式整合在一起。通過這樣一個方式，我們還需要整個系統能夠去限制這樣一個變化，也就是說當某一個地方發生一個變化的時候，我們要讓這個變化只是局限在這個地方，而不會擴散到企業的其他系統當中去，我們稱之為防止企業架構的脆弱性。我們終于要將IT系統從簡單的技術元素要上升到業務的元素，也就是說我們需要將業務活動、業務的流程，以及相關的評價的性能指標等等，作為一個直接的元素開始為它建模，實現它，然后把它部署在系統里運行它，然后要管理、監控它。這個東西就不同于我們過去用代碼的級別，我們需要有清楚的語義描述，在這樣的基礎之上，這些東西對業務人員來說變得非常直觀和自然，而且具有完整的業務理念，當你對這些東西進行建模的時候，跟業務人員溝通就有很好的基礎，當我們將這樣級別的東西是現在IT系統并且管理的時候，我們直接自然地支持業務活動和業務流程的管理。通過這樣一種實現，我們期望著直接是現在IT業務系統的元素都是可以用的，而且可以用它在不同情況下組裝，來滿足業務模型本身的變化。這樣一個變化就是我們所談論的業務創新所帶來的。為了要做到這件事情，實際上有若干個關鍵問題需要回答，這幾個關鍵的問題是SOA所期望去回答的。
第一個問題，我們開始要動身為這個業務本身來建模，我們要將業務流程表述為一系列業務活動，而且我們要將那些可重復的業務活動標識出來、定義出來，描述清楚，我們稱它為所謂的業務服務。我們通過這樣一個方式期望有一種方法使得我們將業務模型變成一個非常靈活的模型，在這樣一個模型當中，當業務發生變化的時候，實質上主要是用來將那些可重復的業務活動，也就是所謂的業務服務進行不同的組裝，形成你新的業務活動。這樣一種重新的組裝可能包括了業務服務的插入到已有的業務活動和業務流程當中去，或者去掉某一個業務服務，或者是這些業務服務之間的組裝順序進行調整，或者是某一個同一語義的業務服務的替代，這個替代是插入、順序的調整，大家都是如此自然。后來同一語義服務的替代，比如我們幫華為做的那個事情，華為在歐洲有很多提供商幫他運交換機，這是當地很多服務的提供商幫他提供的服務，華為不能綁死在一個人身上，在這個地方等于有若干個人，我們只需要根據提供的業務服務，根據SOA服務級別的數據來調整，誰的成本低，誰的響應快，我們根據客戶的需求，根據業務的規則去選擇適合我們不同的服務提供商，這樣我們業務模型非常清楚，這個地方根據業務規則去動態調整，使得我們業務變得非常靈活。
我們要做業務模型，這件事情是我們過去做得非常少的，我在過去這幾年里為客戶做事情的時候，客戶說給你業務用意就好了，沒有這些事情了，說明我們的業務人員實際上他的腦袋里面沒有想我應該對我自己的業務有一個非常清楚的認識和定義，我要把它變成一個非常清楚的結構，通過對這個結構的分析，對這個結構當中每一個要素也就是業務活動或者業務服務去進行分析，去看它每一個活動應該要滿足什么樣的要求，評價的指標，它會有一定的開銷，時間上的開銷或者是成本上的開銷，它會帶來一定收益。所有這些東西怎么樣跟我整體業務談論的利潤問題、成本結構問題，以及我哪一部分應該外包給別人，哪一部分應該自己留下來，哪一部分應該作為核心部分留下來，我的業務人員在這個地方沒有清晰，大部分客戶都說我給你一個業務用意，他看到的是操作的層面，甚至這個業務人員上來跟你講做這個做那個，這離靈活的業務模型太遙遠了，沒有這樣一個靈活的業務模型，不可能真正、很好地業務創新當中各種各樣的調整。
第二個問題，是IT要做得事情，IT要非常能干地支持這樣的業務建模，要做這件事情并不容易，要有一套方法和過程，幫助IT人員和業務人員坐下來一起，用業務人員的語言，用業務人員腦袋中比較自然的想法和描述，去一步一步地推導出來一個比較靈活的業務模型。第二件事，IT系統要有一系列的設施幫助我們對這些業務模型當中的各種要素以及要素之間的相互關系去進行描述，去進行建模，要能夠有一系列的技術幫助構造部署運行和管理業務模型當中的內容。這就意味著IT從過去比較低級的技術模型轉向高級的業務模型。第三件事，可追溯性，在業務和IT模型當中，在于整個SOA方法論當中最重要的事情，我們業務模型搞清楚了，IT也有這個能力去支持這樣的東西，試問當我的業務模型發生變化的時候，我怎么樣能夠比較順利地去使得這樣一個變化傳遞到IT所實現的模型當中去。IT自身要滿足怎么樣在高度分布、異構的計算環境當中提供無縫的集成能力，在人、數據、應用和流程不同方面都要能夠很好的支持集成。其次，整個架構需要采用過去所謂的最佳實踐來使得我們的架構能夠變得非常的柔性，這樣一個有柔性的架構可以很好地支持IT系統自身可持續的演進，這樣一種演進需要應付什么樣的挑戰，整個企業范圍內事實上有很多的應用，你有可能增加一個應用，可能減少一個應用，某一個應用技術因為太老了需要淘汰，我很多的應用需要打個補丁，所有這些東西不能因為我要做新的做法來約束這些行為，這些問題沒有辦法避免。像過去一樣，我們在很多客戶看到打補丁是最常見的做法，我們有一個新的業務需求來了，我要把已有的系統做拷貝，然后改寫代碼，怕它影響中間的數據庫，在中間建立一個運作時的數據庫，然后進行拷貝等等，這樣的事情我們在某種程度上因為局限于現有的IT環境，我們還是沒有辦法避免這樣的事情，我們也不應該過多地去限制它在已有的應用上去做調整，或者增加減少這些應用，這些東西都是非常必要的，因為部門級的東西我們還需要很好的支持。
最關鍵的是我們需要避免的是這樣一些演進、這樣一些演變、這樣一些改變不至于使得我們所實現的業務模型受到沖擊，要做到這一點，最關鍵的兩件事情，一個我們要做到技術實現的獨立性，所謂技術實現的獨立性，是指某一個IT系統指支持了哪些業務活動，支持了哪些業務模型當中的業務要素、業務服務，只要他的業務語義不變，只要它的接口不變，你今天用J2EE做，你今天是用主機做，我們需要幫忙做到這些事情，就使得你擁有了一個很好的手段，這個架構提供了一個很好的柔性，使得你可以根據你自己的人員、根據你自己的錢的問題，根據你自己的時間上方方面面綜合考慮，我怎么樣去調整我現有的應用系統，使得你擁有很大的靈活性。其次要做到位置透明性，也是進一步地給你帶來靈活性，位置透明性有幾種情況，一是我要在動態的價值鏈上去工作，我們希望服務本身、業務流程不應該假定這個服務就在哪里，或者在這個應用，或者在那個應用，我們是根據業務規則動態看它在這里，在那里，只要是業務的語義，只要是業務的接口是一樣的，就好了。另外一個可能性，你要調整應用的時候，需要這種位置透明性，舉個例子，比如我現在幫一個銀行做事情，他們在主機有非常多的核心業務，實際上對銀行來說絕大部分的核心應用都是在3900，或者類似于主機系統上面來做，這些主機上所做得事情通常來講現在由于主機的技能越來越少，他們會面臨非常大的壓力。現在有一些小銀行希望把主機上的東西開始轉移到J2EE，要做這件事情沒有辦法一下子把主機上所有的事情都轉移出來，我們需要一點一點轉移，我們將原來的服務由主機實現，現在需要一個一個拿到開放的J2EE平臺上來，這個時候位置透明性就可以幫助我們，使得你IT本身實現上的變化不至于影響業務上的模型。
有了IT方面的好處，從而就使得業務的部分和IT部分就有一個結合，使得業務模型的變化可以比較容易、順暢達到IT系統，同時IT又擁有自己非常好的柔性，任意地去改變我實現的時候所用的技術、應用，從而使得IT方面自由演變不至于理想而影響高層的業務模型。我們要解決這幾個關鍵的問題，我們有一個非常簡單的哲學，在業務層面上，我們希望能夠從建立起所有組建化的業務視圖，通過這個業務視圖，我們將我們的業務逐漸變成一個擁有非常清晰的結構，在這個清晰的結構里面，每一個業務部分都有非常清楚的范圍，哪些東西是可重用的，這樣我們得到一個業務模型，怎么樣利用一套方法去將它預設到一個基于SOA的比較柔性的IT架構里面。我們來理解SOA，從業務的角度，什么是服務？服務就是那些可重復的業務活動。在這樣一個視圖之下，我們的服務開始逐漸地從過去不清楚的想法來看的方式開始轉向以服務為中心的方式來看待你的業務。什么是以服務為中心，也就是我們通過服務來組裝來實現你的業務，以及由此派生出來的各種各樣的概念和技術。
什么是SOA？SOA就是以服務為中心，來組織IT系統當中的架構風格，它的通過松散耦合和隔離關注等設計原則實現架構靈活性，這種架構靈活性加上可以重用、可以組裝的服務，可以使得你企業的IT系統在動態、不確定、變化的環境下可以自由持續地演進。我們還需要一些方法論來幫助達成業務視圖的過渡，這樣的方法論重要的是，我們需要解決業務和IT之間的結合，其次我們要解決IT和業務之間模型的可追溯性。
SOA作為所謂的新的軟件構造方法要包含哪些關鍵要素，通常我們談論的軟件構造方法，在軟件構造方法里，我們應該從這么幾個方面來判斷，首先我們拿到一個問題，應該有一套抽象的概念和手段來幫助你去思考你的問題域，然后去建模。這些抽象手段都是基本要素，比如我們過去為了解決一個問題，就是用一個過程，現在處理的問題越來越復雜，有一個對象幫助你建模，將一些數據封裝在一起，它是一個類聚非常好的元素。慢慢我們開始將功能組合在一起，用來簡化對我們問題域的視圖，這樣我們擁有一個管理復雜度的能力。你會持續地看到在過去我們構造一個問題域，我們怎么為這些問題域去建模，到今天我們為它增加了另外一個東西，那就是從業務的角度出發來考慮所謂的服務，這個服務本身有一個接口，并且有附著于這個接口的業務語義。其次，你有要有一套方法，怎么樣將這些抽象元素很好地組織在一起，過去我們在OO里有所謂的設計模型，通過這樣一些模型，有各種各樣的模式，將這些基本的抽象元素組織在一起，這種組織本身其實背后所做的決定包含了很多設計方面的設計原則和設計的風格與理念，比如說我們希望這樣的元素目的都是為了使得對象之間的變化或者是組件之間的變化相互之間存在很好的結耦，可以做各種各樣的變化，但是我那個部分不會受到很多的影響，或者為了簡化整個過程的復雜性。
這些很好的設計實踐，就逐漸出來很多設計范式，將那些比較簡單的、基本的抽象元素，按照一定的設計風格和理念組裝在一起的方式方法，這個就是我們在CBD看到的很多設計方式，在SOA領域里，我們將會出現業務范式，在你業務流程里，有一個從得到訂單以后怎么樣得到錢，這些范式有一些主要的業務過程。
我們對我們的業務過程，對我們拿到的問題域，我們要解決的業務部門帶來的問題，我們就有了一個邏輯上的東西，我們開始要考慮實踐的細節，從而將它變成是一個物理上的架構，所以我們要考慮到部署模型，考慮到實踐的細節。再往下到物理的運作環境，物理運作環境我們稱之為計算環境，這個計算環境可以是J2EE，今天我們談論的是以服務為中心的計算環境，所有這些活動都應該很有序地組織起來，讓它發生，有很多人做不同的決策，不同的人有不同的活動，這些活動之間有相互協作的順序，他們還要滿足企業開發的要求，所以我們有開發的過程。所有這些東西跟IT上面的活動，跟業務的活動銜接在一起，我們怎么樣跟業務有很好的配合。作為這樣一個IT部門的活動，我們要為業務部門提供服務，所以你要滿足整個公司的政策，比如ROI的問題等等。在SOA的角度來講，其實是A、B、C、D的事情，我們有服務的計算環境，有以服務為中心的業務與相關的業務驅動業務模型，有以服務為中心的分析和設計模式，或者IBM在金融行業里也有相關的業務模型和范式。我們在韓國航空公司， 參考國際航空協會的過程，那些東西有很多范式在里面。面向以服務為中心的開發過程，我們非常強調敏捷開發過程，在IBM各個部分都有非常清晰的支持，從開發過程當中來講，我們有RUP，XP，在運作環境中有SOA Foundation，在設計部分有業務組件模型，還有跨越這兩部分的建模分析與設計、架構決策等等，有SOA的成熟度模型，服務建模與架構方法，參考架構，設計模型，行業SOA模型。與此同時，我們還提供了SOA的管控，是在IT監管模型之上，它主要是側重從業務的驅動方式來定義我們的業務模型，然后實現到我們的IT系統里面，這些業務服務都是可重用的，大家都是共享的。為什么創建這個服務，別的部門應用這個服務，需要負擔成本上的東西，出了問題，誰來負責，需要做改變的時候，誰來做改變，做這樣的改變對我們業務模型意味著什么，做這個改變，對我們的利潤、對我們的業務、對我們的用戶滿意度帶來什么影響，所有這些東西需要有一個嚴謹的有業務人員介入，并且有IT人員支持的審查、批準的過程。這個過程還要跟原來的IT管控模型結合起來，使得我們SOA比較側重在業務以及業務和IT互動這個層次上的決策，具體實施到IT所負責的完全底層的技術，以及日常運行的活動當中去。這樣一個過程我們稱之為SOA的管控，使得我們通過SOA的方法論所定義的業務模型以及這個業務模型在IT的世界里面實現之后，真正能夠產生和帶來價值的重要的依據和手段。
現在我們來看看IBM的SOA方法、技術和服務。我們今天非常簡化地來講這些，從SOA的實施步驟來講，我們有五個大的步驟，第一步，應該看看自己的業務成熟度，一個非常詳盡的問題集，我們大概有一千多個問題，到目前為止，我在韓國做過最復雜的是200多個問題，我們從不同的角度去問你的問題，從商務的角度，從技術架構，從應用的角度，從開發方法的角度等等，不同的角度，每一個角度都有很多的問題，我們會得到一個成熟度，你看看你處在哪個成熟度模型之上。第一個級別就是完全與部門驅動是一個個孤島。第二個級別就是已經有一些點對點的整合，有一些傳統的EI方式帶來局部的整合。第三個級別，我們開始已經對某些應用做了所謂的組建化，也就是說我們根據業務的建模指導，將一個應用所實現的業務處理，以及相關的數據資源以一個業務服務的方式表達出來，使大家共享，實現IT靈活性和柔性。第四個級別，整個公司范圍內所有的應用都已經陸陸續續地變成了以Web Server作為自己的擁有的資源。通過這些符合的應用，將原來不同的應用所實現的能力轉化為更加復雜的業務服務拿出來。第六個級別，我們所有這樣一些服務，如果從第一級別到第五級別，我們有可能還是存在一些服務之間是一些硬連接的方式，到了第六個級別，這些服務全部都是動態的綁定，這些服務幫助你在語義方面的選擇，本身在企業范圍內開始往外拓展，拓展到你的合作伙伴或者客戶，這樣形成一個動態虛擬的企業。
因此企業需要識別我們現在處在哪個級別？然后我們開始制定一個轉型的路線，讓我們怎么樣從現有的狀態轉移到我們期望的目標狀態，在這個方面來講，比如方法論。第二個級別，我們開始需要用業務組件的方式，來幫助在業務這一部分幫你創建一個比較靈活的業務模型，我們在這一步非常需要業務人員的介入，大家一起來看怎么樣子合理地將你的業務進行劃分，劃分完了之后，我們需要看哪些東西給你帶來差異化的或者帶來核心競爭能力，或者你不得不有的一些東西，哪些東西是給你在投資上會影響你的成本結構，哪些東西是屬于你開始需要考慮在未來需要發生的，可能某些東西需要我們外部的人員來做，意味著在未來它有可能轉移到我們的合作伙伴，有些東西可能需要內部挖掘更好的潛力，意味著不同的部門需要更好的協作，或者是有些部分現在做得太差。所有這一切其實都是我們從業務的角度來進行指導的。通過有一個業務模型之后，我們開始將高層的業務模型分解，利用我們服務建模、架構方法學，逐漸轉向到向技術方面的模型轉移。我們有相當多的步驟來幫助將一個高層的業務組件模型轉化為比較細的業務組件模型，利用服務建模和架構設計方法去轉化為一個服務模型，這個服務除了服務的列表，我們還需要看這些服務之間相互的組裝的關系，以及服務相互之間的依賴關系，和我們怎么樣去利用這些服務組裝我們現有的業務流程，以及怎么樣去在考慮我們前面分析的各種各樣的變化，比如我們要把某個部分要進行合并，哪個部分要去除等等，在業務模型方面的變化，對單個的業務服務或者業務服務組裝所形成的變化都需要在流程方面有很好的考慮。使得可能的變化以及長遠可能發生的變化都能夠被我們做出來的服務模型所覆蓋。
其次我們要為每一個服務提供一個實現的決策，這個實現的決策包括兩個層次，一個層次是這個服務是我們從外面買，因為外面有可能做了相關的服務，比如有些公司可能對于地圖的服務不做了，還是我們自己建，我們自己建開始要牽扯到IP方面的決策，這樣一個服務我們要建是用全新的系統來建，還是利用已有的系統，如果利用已有的系統，我怎么樣重用已有的系統，我怎么樣用一個設施將已有的系統連接起來，在這個基礎上我們要考慮一些安全、性能等等方面的問題，可能我們還需要考慮數據的重新建模和重組的問題，因為有的時候我們有很多數據分布在不同的系統當中，它們格式不一樣，它們業務語義不一樣，我們要做這樣一個服務，要做用到這些過程，我們要使用一些方法，要一些源數據，讓這些聯系起來。還有一些比較工程上的考慮，我們期望這些服務都是單獨，都是相互獨立的，也就是說每一個服務自身的存在并不依賴與另外一個服務而存在。這就意味著我們每一個服務在另一個服務看起來是無狀態的，我們每一個服務發送一個請求到另外一個服務當中去，不需要顧及他現在是一個什么樣的狀態，這對于在服務當中的我們強調的靈活性和結耦能力是非常重要的。通過這個服務模型，通過前面的架構決策，開始逐漸地推進到組件模型，實現這些服務所需要各種各樣的組件，就回到我們前面已經很熟悉的所謂基于組件開發的方法。
我們做完這些建模事情之后，我們逐漸將這些東西映射到參考架構上來，在做這些參考架構上我們面臨著一系列的實現架構，這樣以服務為中心的參考架構，我們用什么樣的產品，為什么用這樣的產品？我們建一個什么樣的企業服務總線，建什么樣的集成設施，為什么建這樣的集成設施，還有安全的問題、性能的問題等等。我們來做各種各樣的相關的架構決策，IBM有一個參考架構的模型，它考慮到方方面面，可以供大家參考使用。所有這一切我們應該有一個管控的組織，以及相關的流程，我想這個東西對于SOA在業務部分的價值是非常重要的，當然我們在國內實施的經驗來看，要一步到位實施這些管控是相當困難的，所以需要我們在做項目的時候需要主動積極地跟業務部門互動，來爭取業務部分的價值更多、更好的展示。IT技術方面，架構對技術的適應能力等等都是比較容易得到的。
IBM的建模方法，還有一些服務，我們有SOA相關的業務咨詢服務，包括前面我們提到的成熟度評估等等，我們也有一些設計的服務，包括實施的服務。我們前面提到SOA Foundation系列產品，服務的整個生命周期，我怎么樣根據你的業務去標識業務服務，怎么樣創建，部署到系統里來，怎么樣管理，在管理這些業務流程和業務服務基礎之上，我們了解到我們的業務服務和業務流程有哪些地方需要優化，然后我們跟業務人員重新建模，所有這些我們都有很好的產品去支持。
從工具的角度來講，我們前面提到了高層業務模型怎么樣去轉化到技術級別的模型，從技術級別模型轉化到技術級別的轉化模型，這樣的過程是模型驅動，使得代碼可追溯性，以及生產效率都有大幅度的提高。重要的是模型驅動的開發方法，能夠將你各種各樣的經驗和所做的事情轉化為可重用的資產，如果我們看過去在對象、在組件的級別，我們看到有非常多的設計范式，根據這些設計范式，可以在支持模型驅動的工具里，將這些流程具體化，具體化你自己可重用的資產。然后可以在業務層面來做這些事情。
我們在亞洲做了一些客戶，我們有一些經驗，這是一個實例，前面我們提到了一些做法，這個例子是中遠集運的例子，有20多個，相互分立的，完成中遠集運，基于文件的平面為基礎的消息格式，來跟全球的港口它的重要合作伙伴，比如三星、沃爾瑪，以及當地的政府、港口打交道等等這方面的業務流程。他們效率非常低，因為他們沒有很好的集成在一起，當三星抱怨我的報告沒有完成的時候，事實上他都不知道他相關的數據在哪里，這些數據也都沒有一個明確的業務語義元素，他要處理這些問題，要找到這些問題，定義這些問題在哪里，去解決這些問題，要花很多的力氣。最后用SOA的方式，得到他的業務組件，分析他的業務流程，出來他的業務模型。這個業務模型應用參考的架構實現起來，這在各個級別有很好的整合。假定你需要發生業務變化，這些業務變化有可能是我要增加一個新的港口，流程沒有變化，這個非常容易，我們只需要重新部署一個新的業務實力就可以，如果新的港口、流程沒有變化，但是需要支持的業務受到變化的時候，我們只是需要在企業服務的總線上做一些調整和處理，這個部分增加相關的處理就可以了（見圖）。如果你的新的港口不需要支持，當流程上有一些變化的時候，我們只需要在流程的部分對于已有的信息或者是業務處理的服務做一個重新的組合就可以了。如果這個新港口又要支持信號的流程，又要支持新的報文，我們能夠自由地以非常小的代價在高度重用的級別之上來滿足我們新的業務需求，并且這些變化都是非常清楚的被局限在一個一個自己該有的地方，而不會進行擴散。
企業范圍因為做了這個事情之后，他們開始考慮我怎么樣以EDI為基礎，建立整個企業范圍的總線，怎么樣將各種各樣已有的系統把它們的業務處理和數據轉化為可重用的服務，然后重用它整體的業務模型。
服務模型創建和架構設計中的經驗分享，SOA的實施還是要以價值為導向，而不要盲從，不能過于技術驅動的方式，還應該看到SOA結合我實際要做得事情，看看在業務技術上給我帶來一些什么樣的好處，然后我們再來看SOA的設計原則，怎么樣來做，我們要建設新的架構元素，比如ESB等等，會給我們帶來什么樣的附加的東西，比如我們整個架構會花很多錢。我們還要對變化有足夠的重視，我們要在業務的級別，在技術實現的級別，對各種各樣的可能變化用意拿過來，很好地去測度你的業務模型是否適合。我們在組織和流程成熟度都會影響到服務模型質量，假定你的業務流程今天和明天完全不是一回事，我想再怎么樣做，這個業務模型本身以及將基本的要素組織成一個靈活的要素都是非常困難的和富有挑戰的。所以我們在選擇某個部分進行SOA實施的時候要有所側重和考慮。我們非常希望強調業務人員能夠有高度的參與度，已有的系統要去重用，并且將它們的能力轉化為服務，實際上并不是那么輕松的事情，還是需要做很多事情，還是需要一個系統一個系統做一些事情，有相當多的系統，尤其是現在市面上比較流行的系統都已經有標準的適配器，這樣大部分都能解決。做SOA，尤其是剛開始推動SOA其實非常需要整個企業范圍內對SOA有好的認識，需要高層領導對SOA要了解，并且重視，我覺得國內各種各樣的客戶在IT管控方面都需要提升了。
我覺得性能的事情并不是一個問題，SOA并沒有帶來額外的性能問題。服務的包裝有各種各樣的方式。
影響SOA實施工程中工作量的因素，這取決于成熟度的要求，要求要達到什么樣的級別，整個團隊對于SOA相關的方法、技術產品掌握的程度，還有一個常識就是你現有的產品本身是不是夠復雜，以及這種地域的分布或者業務流程、數據和技術環境的易用性怎么樣，包括你的系統相當難以改造等等，這些都不會有影響。
主持人：把博大精深的SOA講的這么細其實挺難的，大家會后再跟毛先生交流。
