SOA在業務與IT兩個世界中暢行

　　SOA是一種思想？一種軟體產品？還是一種軟體服務？儘管越來越流行的SOA已經充斥到幾乎所有的IT經理腦中，但SOA究竟是什麼？仍然讓人迷茫。面向服務的IT架構到底在業務與IT兩個世界中扮演了怎樣的角色？你眼中的SOA到底是什麼？

　　在今天，競爭激烈、變化越來越快的全球化商業環境中，傳統企業觀受到嚴重挑戰，如何靈活快速適應變化、創新求變，成為企業生存和發展的頭等大事。在業務敏捷性的實踐中，SOA正成長為IT促進業務提高的轉移正規化，從設計原則、架構正規化以及技術、標準和產品中實踐著它面向服務架構的偉大使命。

　　業務敏捷性向業務與IT兩個世界發起挑戰

　　事實上，許多企業都無法實現“業務敏捷”。他們的工作人員各自行動，計算機系統又相互隔離，不能協同工作：一方面是由IT部門負責的資訊系統，另外一方面則是調整IT系統所需要必要時間和成本。受這二者的制約，企業變化要麼時機已逝，要麼得不償失。因此，業務方作為利潤中心，總是抱怨IT每年都要花很多錢，不僅不能獲得良好的投資回報，也不能幫助建立戰略性的競爭優勢。而IT方作為成本中心，往往怨恨自己沒有得到應有的重視，資金不夠、加班加點。這種現象的出現也就不足為奇。

　　到底應如何看待IT與業務之間的關係？

　　首先，業務活動是由業務人員和資訊系統共同完成的，業務人員執行人工活動，比如拜訪客戶、輸入訂單和客戶資料、做出商務決策等等，而資訊系統執行各種自動化活動，包括商業邏輯、業務規則、管理業務資料，提供介面連線人員和資訊系統。所以IT是業務的一個重要組成部分。

　　其次，業務方決定人工活動和自動化活動的需求，管理人工活動，但是他們往往不具備必要的技術能力來建立、維護和運營那些支援自動化活動的資訊系統，這些工作被委託給自己的IT部門或者外包。所以IT要服務於企業戰略，為業務建立競爭優勢，幫助業務快速應變和創新求變。

　　可見，業務敏捷性首先需要的是一個靈活的業務模式（Business Model），業務自身不靈活，想改變卻心有餘而力不足，IT再能幹也是乾著急。其次，需要IT的敏捷性，也就是說一個當業務改變的時候，那些自動化活動說變就變，隨業務的變化而變化，花的時間少，花的人力物力也少。這種IT的靈活性，對IT的所有方面都提出了挑戰，從架構、方法論、技術、產品，到過程、成熟度和管控。最後，還需要IT與業務這對“冤家”之間的有效溝通與親密合作。

　　這很不容易，業務與IT來自兩個不同的世界，看世界的方式不同，所使用的“語言”也不同。大多數時候，業務不願意花足夠的時間在IT上，反過來，IT也不願意花足夠的時間去理解業務。他們把更多的心思放在技術上，有時候甚至為技術而技術，忘了IT是為業務和戰略服務的。 因此，業務敏捷性同時向業務和IT兩個世界發起挑戰，溝通和協調成為必然。

　　SOA暢行業務與IT兩個世界業務架構描述業務世界：從業務領域、業務元件、業務物件，到業務服務、業務流程、業務規則……IT架構描述IT世界：從應用、資料、整合、安全、基礎設施（包括伺服器、儲存、網路），到IT運營，全面覆蓋……兩個“世界”共同服務於企業，而如何實現兩個世界協作則成為企業戰略目標實現的關鍵！

　　SOA正是溝通兩個“世界”使命的承擔者，它提出了架構管控的概念，從角色、活動、職責，到協作、審批和監管的框架，保證有一個遊戲規則來讓這些東西真正地服務於企業的戰略和目標。

　　然而，大多數企業對自己的業務模型仍停留在自發狀態，缺乏業務方面的嚴謹企業架構實踐，更談不上業務與IT的溝通，這直接帶來兩個問題：

　　一是業務優化、應變和創新缺乏形式化和數字化的基礎，很容易靠感覺辦事。這種“拍腦袋”應變策略，往往帶來很多問題，有些時候，這些問題的原因被強加到IT的頭上，而使IT承擔了不應承擔的責任。

　　二是業務和IT之間缺乏“可追溯性”（Tracability）。在將業務的需求對映到IT的時候，使用模糊的自然語言，容易造成翻譯後的失真和變形。同時，細粒度的操作層次所定義的需求，受到變化的衝擊大而快。這最終導致業務和IT在進行需求對映，尤其是在需求發生變化時，很難保證好的可追溯性，從而導致業務的需求無法準確地對映到IT，業務需求的變化很難被快速地定位到IT。

　　傳統模式需要引入新的IT架構正規化和抽象層次，從而為企業的業務活動和流程提供多系統相互協作的IT支援，SOA則恰好扮演了這個角色。

　　SOA為業務與IT兩個世界帶來什麼？

　　SOA究竟在實現業務和IT兩個世界的溝通中體現了怎樣的價值？筆者認為：

　　① SOA在業務與IT之間增加了一個新的抽象層次，就是“業務層次上的契約”，用來描述不同的業務元件（或者業務物件）之間互動的介面。這就是SOA通常所說的“服務”。

　　其中包括功能介面、服務質量約定（Service Level Agreement）和業務策略等。它們是用於元件化地對業務建模，通常其粒度比技術層次上的物件或者元件介面要粗，而業務流程就是通過將這些服務編排在一起得到的。當業務流程發生變化時，有些變化通過改變服務的配置（如業務策略）來完成，有些變化通過重新組裝已有服務來完成，有些變化要用到現有服務之外的業務功能，則需要外購或者開發少量新服務，然後重新組裝。

　　業務元件化建模所得到的服務模型，解耦了業務架構和IT架構，提供了業務架構和IT架構之間良好的對映能力和變化的可追溯性，即在服務定義不變的情況下，業務和IT可以獨立地演變，帶來很好的靈活性。

② SOA建立了一個新的整合架構，負責將遺留系統和新建的系統連通起來，讓不同技術世界的服務元件可以相互以Web服務介面為中介來鬆散耦合地互動。

　　這牽涉到各種協議、API、訊息格式的轉換、服務端點的發現和繫結、訊息的路由、服務質量的保證、服務策略的實施等等。SOA繼承了過去EAI（Enterprise Application Integration）和MOM（Message Oriented middleware）的最佳實踐，比如“企業服務匯流排”（Enterprise Service Bus，ESB）作為一種架構風格元素，用於在分散式環境下提供鬆散耦合的整合基礎，但是SOA使用了Web服務，建立在標準和開放技術的基礎上，而不是私有的技術、標準和方式。新的整合架構還引入Service Registry，ESB與之合作提供服務的動態發現和繫結。ESB的實現通常會利用已有的訊息中介軟體。

　　③ SOA通常會建立一個資料服務層，整合EII（Enterprise Information Integration）的技術和最佳實踐。

　　這個整合架構，要確保所有服務和應用在開發之時，能夠跟其他的應用和服務整合，不管它們今天是否存在，互聯互通、相互整合、“開發即整合”是SOA對技術層面的基本要求。

　　值得提醒的是，SOA一個很重要的設計原則ESB是基於“服務”的分散式整合，很多基於“細粒度”的介面和訊息整合，並不符合SOA的設計原則，也將導致可能的效能問題。

　　④ 在應用架構方面，新的SOA技術和標準，比如SCA/SDO允許你採用平臺和語言相關的方式實現，但是元件實現的服務介面則是標準化的。

　　複合應用（Composite Application）建立在其他應用的基礎上，通過將來自Portal應用的人工活動、B2B的合作伙伴應用、資料服務和本地業務服務來快速形成新應用。基於BPEL等標準的流程引擎，使用“宣告式”的方式來將服務編排在一起，在複合應用中起著重要的作用。這些都是在已有的應用平臺上增加而來，比如IBM的WebSphere Process Server支援SCA/SDO和BPEL，它是在IBM的J2EE伺服器WebSphere Application Server的基礎上實現的。

　　我們前面所設計的服務，實現它們的IT元件就表現為一些SCA元件，或者EJB、POJO元件，而業務流程則在IT層次上實現為BPEL或者一些SCA元件。這些服務和流程都有自己基於標準的形式化描述，儲存在服務註冊庫（Service Registry）中。

　　⑤ SOA Governance被用來在整個服務的生命中期中，將來自業務和IT的人協調起來，讓他們各司其職，有章可循，相互協作。

　　在實現層面，這通常需要藉助於Service Registry來管理服務的生命週期，同時，我們需要擴充套件現有的管理產品，從基礎設施、應用和元件的管理，延伸到服務、流程和業務活動和業務績效的管理。在這個基礎上，建立數字化的服務和流程優化策略，從而使得IT可以主動地向業務提供業務優化和調整的支援。

　　辨明SOA認識的四個誤區

　　簡單的說，SOA的產生遵循了這樣的邏輯主線：業務敏捷性需要一個靈活的業務模型，業務模型需要一個靈活的IT來支援。同時，良好的業務建模，IT與業務之間的對齊和互動變得很重要，所以基於企業架構的實踐，橫貫業務和技術的SOA管控被用來保證SOA轉型的成功。

　　一個靈活的IT需要遵循必要的設計原則，比如關注點分離、鬆散耦合，而這些設計原則結合具體技術形式體現在IT架構中，將會形成自己的架構風格，這當然也由一些架構元素支撐，比如ESB，服務註冊庫等。這些架構元素多多少少都能夠從過去的IT當中找到些影子，但是，它們使用新技術，建構在開放標準和技術的基礎上，融合和繼承了過去的實踐成果，也同時容易產生誤解：

　　誤解一：SOA=ESB

　　ESB只是SOA架構中的一個元素，負責轉換、路由和服務質量等。看待SOA，應該從業務、技術、管控等不同的角度來看待。

　　誤解二：SOA=Web Service

　　Web Service通常指基於SOAP/HTTP的Web服務，這些服務是實現SOA中所定義服務的一種技術形式。Web Service提供了分散式環境下卓越的互操作能力。

　　誤解三：我的系統都是新系統，SOA沒有用武之地

　　答案應該是“有”，如果你希望得到業務敏捷性的話。SOA通過更好地讓IT和業務融合在一起，藉助於企業架構、業務建模、SOA監管和一些新的設計原則，架構風格，支援這些原則和風格的最新技術來達成IT的靈活性，以支援業務敏捷性。

　　誤解四：SOA與BPM是一回事

　　BPM與SOA關係緊密，但並非一件事。BPM的目的是業務優化，這種優化需要IT的支援，SOA提供很好的支援。另外，BPM在業務建模和業務規則方面為SOA提供很好的支援，為SOA達成業務敏捷性帶來良好的基礎。

　　你的SOA是什麼？

　　SOA作為一種架構方式的變革，充分體現了業務驅動的價值訴求。通過總結和繼承過去IT實踐的成敗得失，SOA將其首要目標定位為業務敏捷性，即通過建設一個靈活的IT來幫助業務快速應變，引領創新。因此SOA對業務人員、管理階層是一個值得注意並且很有吸引力的事，但SOA對不同角色的人意義也自然不同。

　　① 對於IT主管

　　SOA是一個好機會，建立IT的戰略地位，通過IT幫助企業建立戰略性競爭優勢是IT人員馬上就可以去做的，但是如何實踐企業架構，如何建立SOA管控，如何通過SOA Center of Excellence來組織人員，培養種子力量將是IT主管要面臨的挑戰。

　　② 對於架構師

　　需要了解SOA的設計原則、架構風格、架構元素和相關技術和產品。他們需要配合IT主管，推動企業架構實踐和SOA管控，跟業務人員共同合作，推動SOA專案。

　　③ 對於開發人員

　　學習和使用SOA，是趨勢使然，即需要學習新技術，也需要增加一點架構的意識，還需要培養自己的業務建模能力。

　　④ 對於ISV

　　SOA可能意味著一個好機會，就是如何將自己對一個行業的理解轉化為一個比較通用的業務模型和服務模型，通過可重用的軟體資產，建立面向行業的解決方案模板與複合應用。

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