隨著媒體與IT大廠的炒作，好像一談到「整合」就非SOA不可。很多技術詞彙（例如：BPEL、ESB、BAM…）也在這個過程中不斷地被創造出來，但這些一技術詞彙好像並不會幫助我們對於SOA在應用上的了解，甚至只會令人更懷疑這些名詞只是IT產業又拿出來行銷的噱頭而已。
事實上，技術出身的我不得不承認，SOA有一種架構性美很容易讓技術人員醉心。但在同事朋友們討論SOA的時候，總覺得少了什麼？這樣的美可以幫助我們解決什麼樣的問題呢？如果只是架構上的美，終究也只限於技術架構的美而已，有什麼資訊問題是無法用傳統EAI（Enterprise Application Integration）技術手法來解決而一定要採用SOA嗎？還是它的美只存在於IT學院的象牙塔之中呢？
面對業界許多（非IT領域）朋友的疑惑，我決定寫這一篇文章來重新為SOA「正名」，從IT在商業運作上應用的角度來闡述SOA主要所要解決的問題，讓大家再從另一個角度來看SOA。
定義：不只是技術，是IT架構
或許已經有讀者注意到了，我們通常談到IT，大部份都會說是XX「技術」，但為什麼沒有聽過有人說SOA「技術」呢？如果我們看SOA（Service- Oriented Architecture）這三個英文字母，會發現SOA中的「A」竟然是Architecture（架構）這個字。單就語句結構上來看，如果在「架構」這個字詞後面再扯上「技術」兩個字，還真有點奇怪。
嚴格說來，SOA這一個詞並不是指一種「技術」，而是指一種IT架構，當然，這樣架構下會有各種不同的技術，來解決企業在面對商業自動化的所面臨的各種不同的問題。
本文將先介紹SOA對企業的意義，主要在藉由商業自動化，以協助企業解決一個千古不變的難題：變。
自動化服務元件是商業自動化的第一步
SOA（Service-Oriented Architecture，服務導向架構）顧名思義，以「服務」做為導向來出發，以設計並建構我們的系統構架。簡單來說，我們可以說：「服務導向架構」目的是要達到一個自動化的商業行為。
首先，讓我們舉個例子說明。澳圖美德（Automated）科技是一個系統整合廠商，在他的商業行為中，他需要經常對他的供應商（例如SUN Microsystems）來進行詢料（特別是在庫存中並沒有足夠的備料時）。
早期這樣的一個行為，是由純人工的方式來處理，需要再透過SUN業務同仁處理（包括報價及答覆商品的Delivery Time），但在整個商業流程中，商品的報價與Delivery Time並不會有經常性的異動，因此這樣的做法是一種人力資源的浪費。
為了避免這樣的問題，我們可以將上下流兩個公司的系統做適當的調整，讓SUN公司在系統中建架一個服務元件來提供價格與Delivery Time 的資料查詢，直接利用在澳圖美德內部的系統來呼叫SUN公司所提供的服務元件，澳圖美德的同仁即可完成報價與Delivery Time（交期）的詢問。所以可以認知到的是，在商業自動化的前提下，SOA需提供一個「跨系統的資料交換與傳遞的規範與方法」，以便商業上的資訊交換。而在整個架構中，被實做出來以負責資訊的交換與傳遞的程式一個個的模組，我們可稱為服務元件。
或許有些讀者會發現，這樣的做法，不就是幾年前 Web Service的技術觀念下就已經提出來的做法嗎？這跟SOA 有什麼關係呢？
當然，如果只是上述的例子中所提到的需求，其實只要用 Web Service就可以做到了。那SOA可以再解決什麼樣的問題呢？藉由上面的例子，我們再來拉大企業的需求，以再進一步認識 SOA。
「服務元件」結合「流程」提供更多樣的自動化服務
由上述的例子，如果單純從資料流的角度來看，我們可以說：「澳圖美德公司與SUN公司在做資料交換的動作，讓澳圖美德員工可以很輕易得到他需要的資料。」但其實自動化的商業行為並不只是資料交換那麼單純；例如，以身份認証而言：是不是所有的廠商都不需經過認証就可以呼叫SUN公司所提供的元件來取得SUN的報價與 Delivery Time 呢？或者不同的協力廠商所取得報價會相同嗎（不同的協力廠商有可能會因不同的規範而有不同的報價）？再從流程的角度來看，整個商業行為並不是在取得報價後就結束了–是不是要有詢價記錄（以便未來的追蹤）？
或者，如果價格合理，那就會進入採購的程序。如果價格不被接受，那則有可能進行到議價的程序，如果該項商品還有多個供應商的話，那也有可能進入到詢價、比較的不同的程序。甚至不同供應商也有可能有不同的作業流程或程序，有些一定要先下單再出貨，有些關係好的則可以先出貨再下單。有的商品則有可能要先下樣品單，甚至樣品交貨的同時也要先付貨款等等。
因此很單純地由一個服務元件來進行資料交換，並無法滿足商業行為自動化的所有需求。在一個完整的商業自動化行為中，往往需要由一組（多個）可能由多個不同系統提供的服務元件來進行服務。
例如，系統應該先進行身份確認（這裏是一個身份確認的服務元件），再來才進行詢報價程序（這裏應該又是另外一個服務元件），最後，當買方確認要進行下單的時候，才會進入採購程序（進入採購流程應該又是另外一組服務元件，甚至有可能對應到另外一個獨立的系統中）。而組織、整合並決定所有的服務元件的使用順序地即是「流程」。因此商業自動化的目的下，如何進行跨程式語言、跨系統、跨組織、甚至跨企業的流程架構、規劃、設計與實作，也是SOA 要思考與規範的重點項目。
我一開始說SOA有種架構性的美，是指它作為一種IT架構，竟與哲學中的現象學具有同樣的世界觀 。現象學提到「存有」與「關係」。「存有」在OO（物件導向，Object-Oriented）中（註），可以視為是物件，而在SOA中，我們可以說它是服務元件。而關係，在OO中就是那個方法，而在SOA中，就是跟時間一起被定義在流程之中。SOA即是結合服務元件及流程的很嚴謹、很工整的架構（待續）。
註
Service-Oriented 與 Object-Oriented：
看到Service-Oriented，IT產業較熟悉的人應該就會直接覺得想到OO（Object-Oriented，物件導向）。確實，從觀念上來說，這兩個概念是雷同的，只不過它們所關切並要解決的問題是屬於不同層面的：SOA是從商業邏輯成層面來看，以減少系統中服務元件設計與開發的時間；而 OO則是關注程式設計與開發的層面，以減少程式元件重新開發的時間。
昨天談到SOA之所以不同，是因為它結合服務元件及流程，而形成嚴謹而具有美感架構的IT概念。但它是不是僅只是於「比較美」而已呢？它對企業運作，是不是真的發揮效益呢？讓我們再隨著昨天的例子繼續走下去。
「變」才是自動化IT最大挑戰
伴隨著澳圖美德跟Sun 原廠生意往來的增加，他們的合作關係越來越密切，也越來越有信任感，因此在兩邊老闆與業務同仁熱切期望與鼓吹下，在短短一個禮拜會議討論後，老闆們握手作出以下決議：「面對市場的快速反應，某些單期的商品，只要是澳圖美德業務人員確認後的訂單，Sun原廠這邊就可以直接出貨，澳圖美德的同仁只要事後在一個月內補上訂單及貨款即可，以縮短整體的交期。」
這樣的消息對兩個公司的業務同仁而言都是一個普天同慶的大好消息，特別在信任感足夠的前提下，交期縮短的做法會讓客戶滿意度增加，並相對地提升業績，特別對澳圖美德而言，這樣的做法會縮短貨品在途與減少庫存，可大大提升兩個公司在整體銷售上的執行力。
但獲得執行力是要付出代價的。
老闆又繼續說了下去：「為符合這樣的需求，請IT人員於半個月內修改系統…」一語未閉，資訊部門的同仁全都當場傻眼（並考慮要不要遞出辭呈）：天啊，當初為了達到整體的商業自動化，花了澳圖美德公司與Sun原廠的資訊同仁們三個月時間的系統分析以及六個月的程式撰寫，最後逐一的測試，直到上個月才剛算完全測試完成的系統，半個月要怎麼改啊？瘋了嗎？
IT主管們（特別是資訊長與技術長）所面臨的最大挑戰並不是一個固定的商業行為，其實大部份跨企業/組織的商業流程自動化需求都可以利用傳統EAI所使用的IT技術手法來完成；講白了，IT人員只要把商業的作業流程定義清楚，不管採用什麼技術（VB、JAVA、N-tier、 mainframe、有資料庫就用資料庫，沒有資料庫就用最笨的方式，像是TEXT file等），大部份商業上的需求都還是可以硬生生--不論用苦力技術或高級的方式（例如物件導向加XML）來實作出來，但最大的挑戰往往發生在商業流程改變的時候。
「規劃永遠趕不上商業變化。」這是所有IT人的痛，因此當我們談到商業自動化，「流程」只是故事的一半而已。也是SOA的切入點所在。
在瞬息萬變的經營環境中，SOA目的在更深一層去關切並預想商業流程的變異性，並思考、定義與切割一個個服務與流程，以強化企業商業自動化的靈活度。
是行銷名詞還是真的有用？
談到這邊，我想「為什麼要SOA？」或「SOA是不是一個行銷術語？」應該會得到較清楚的答案。在商業自動化為前提下，「服務元件」與「流程」可視為商業自動化的基本元素。面對商業行為的變異性，在「服務元件」與「流程」的設計與實作上，應該要達到彈性並且可以重複被使用的水準，以減少系統重複開發的時間，這樣子以商業服務為基本元素來做為的出發點，而設計出來的IT架構，我們就稱之為「服務導向架構」(SOA)。
而在這樣一個約定而成、公開規範的SOA架構下，企業便可藉由「服務元件」與「流程」靈活組合（就像玩樂高積木一般），因應瞬息萬變的商業行為需求。理解SOA的本質後，我們再來看SOA中各個資訊原廠或SI廠商所提出的各種五花八門資訊名詞時，應該就會比較清楚個中差異。例如：BPEL（Business Process Execution Language，商業流程執行語言），簡單說就是特定資訊語言可以用定義及規範各個服務元件的執行的先後順序與因果關係（也就是流程）。再如 ESB（Enterprise Service Bus，企業服務匯流排）則是服務被實踐的地方，ESB在系統與系統間、企業與企業間，負責整合的作業，讓「服務」的串連形成一個匯流排（Bus），如同巴士（Bus）一般地，傳遞跨系統、組織與企業的資訊服務。
面對企業資訊「整合」的需求，SOA並不是唯一的答案，但無疑地，隨著SOA技術逐漸發展成熟，新的概念與技術可以讓企業面對商業整合時可擁有更大的彈性與效率。而接下來的專欄文章中，我們將陸續探討SOA對企業內人事、流程、甚至CEO角色職權的衝擊。
沒有留言:
張貼留言