在今天,競爭激烈、變化越來越快的全球化商業環境中,傳統企業觀受到嚴重挑戰,如何靈活快速適應變化、創新求變,成為企業生存和發展的頭等大事。在業務敏捷性的實踐中,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技術和標準,比如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提供了分布式環境下卓越的互操作能力。
文章來源:CIO時代網