SOA實作案例浮上檯面

目前已著手導入的企業，例如：華南銀行、臺大醫院、聯華電子、彰化銀行、國泰世華等都認為已到了可以開始嘗試的階段；其他包括台灣大哥大、臺灣固網也都在進行評估中；而尚未導入的企業，雖然認同SOA的觀念，但卻選擇觀望並等待成功案例的出現。

實作SOA的關鍵
SOA並非萬靈丹，也並非所有的應用系統都適合，企業本身必須先釐清自己的系統架構，並且掌握每一個系統與業務流程，究竟在處理哪些事情，然後才能進一步評估SOA是不是符合需求。

醫療業的SOA應用
臺大醫院系統架構全面轉向SOA
從SOA先導測試到正式上線的2年期間，臺大醫院全部自己一手包辦，堪稱是目前臺灣SOA實作規模最大的案例。

金融業的SOA應用
華南銀從銷售自動化系統開始SOA
以金控旗下各子公司的跨售產品與流程，完成SOA的概念驗證後，就積極建立共用業務模組的基礎，預計接續的銷售自動化系統開發，將能因此節省70％的開發時間。

半導體業的SOA應用
聯電順勢而為展開SOA先導測試
基於客服系統MyUMC的再造需求，聯電展開SOA的先導測試，驗證是否可以實作SOA所訴求的共用業務模組，經過3個多月的概念驗證之後，聯電決定進一步擴大規模實作SOA。

進化中的SOA
除了顧問養成還需要時間外，SOA成效難以評估以及方法論還在演變都是影響市場發展的關鍵因素。實作SOA的關鍵

一家遠洋船運公司，在美國911事件之後，突然接到海關的通知，要求所有貨運抵達港口前就必須完成報關作業，為了因應這突如其來的作業流程變更，這家遠洋船運公司開始找尋新的方法，來節省應用系統開發時間，因為如果沿用過去的方法來調整報關系統，一般估計至少需要3個月時間才能完成，在時間壓力的迫使下，該公司決定著手嘗試SOA的做法，最後只用了1個月時間就完成了新的報關系統。

有了共用業務模組作為基礎，SOA將能大幅縮短系統開發時間
類似這樣想要縮短系統開發時間的需求，近來也發生在臺灣的大型企業，而華南銀行就是其中一個例子。「華南銀行為了解決重複開發的問題，一年前正式啟動的企業入口網站建置專案，開始嘗試把系統架構轉向SOA」，華南銀行規畫開發部倪大為表示，在這個過程中，最難的就是如何找出可以讓各個應用系統共用的元件，該公司為了驗證SOA的可行性，首先針對銷售自動化系統的需求，逐一檢視每一個業務流程，然後經過一個多月的努力，總共切割出40多個共用元件，他預計「後續的銷售自動化系統開發，將能因此節省70％的開發時間，主要關鍵就是因為有了這些共用元件作為基礎。」

對於大型企業來說，IT的應用程度雖然較高，但是，經年累月一點一滴所累積的應用，早已超出當初所設計的系統架構。然而，為了因應新的需求，企業並沒有太多其他選擇，只能不斷持續擴充，最後不免形成疊床架屋的情況，同時並增加了系統整合的難度。近來，隨著SOA的發展逐漸成熟，部分企業已經迫不及待地決定透過SOA鬆綁既有系統，然而，SOA真的能夠解決所有問題嗎？

比起2年前，只有觀念沒有方法，SOA已經到了可以實作階段
「聯電認為SOA的難度不低，不論是技術面、開發面，甚至方法論都有不同的門檻」，聯華電子資訊工程部部長張順德說，目前在臺灣還沒有聽說過真正的成功案例，根據聯電的先導測試（pilot）結果來看，SOA的概念要真正實作，現階段還未盡成熟。

不過比起2年前，只有觀念沒有方法的階段，現在已經有相當足夠的條件開始嘗試實作。事實上，對於企業來說，現在並不敢要求SOA達到100分的水準，但是只要有50～60分的幫助，就已經可以為企業帶來很大的改善，這樣的前提下，聯電在先導測試結束後，決定把客戶關係管理系統轉向SOA，目前正在著手進行系統再造的專案規畫。

除了聯電以及華南銀行，其實還有更多大型企業已經開始嘗試實作。腳步快一點的企業單位，例如：臺大醫院，就是目前SOA實作範圍最大的一個案例，整體應用擴及門診系統、住院系統以及急診系統等最核心的3大部分。臺大醫院副院長賴飛羆認為，「即便一開始投入SOA需要一段時間摸索，甚至也擔心Web Services會帶來執行效能上的問題，但是隨著門診系統、住院系統逐步上線的情況來看，SOA帶來的效益不僅可以預期也相當值得。」

缺乏成功案例驗證，大多數企業選擇憑藉自己的經驗摸索
因為大多數企業都面臨了一個共同的難題，就是系統需求永不停歇，而系統開發所需要的時間卻沒有辦法縮短。對於部分企業來說，SOA帶來了改變的機會，所以躍躍欲試，即便現階段缺乏step by step的最佳實作方法，企業必須靠自己的技術經驗與產業經驗慢慢摸索，但是在風險與效益的評估之後，沒有企業願意錯過，即便現在沒有具體的計畫，未來也要伺機而動。

「彰化銀行甚至提早了SOA的專案規畫，」彰化銀行資訊處處長曾芳明表示，在經過整體評估之後，發現即使SOA的實作過程，遇到難以突破的瓶頸，最慘的情況不過是回過頭來用傳統的開發方式，並不會造成整個開發專案的失敗，因此，彰化銀行決定以財富管理系統作為起點，他強調「SOA帶來的風險並不高。」

然而，以臺灣的整體現況來說，企業對於SOA的認知，雖然普遍認為是未來趨勢，但要從何做起，乃至於要做到什麼程度，才能把系統架構轉向SOA，卻是相當模糊。目前已經著手嘗試的企業，也大多選擇依靠自己的經驗慢慢摸索，主要是因為SOA在臺灣的發展，才剛剛邁入實作階段，相關的資訊服務廠商也缺乏導入經驗，因此不容易說服企業，而企業也不想成為資訊服務廠商的白老鼠。市場調查機構IDC認為，在顧問經驗還需要時間養成的情況下，SOA的發展最快還要2年時間才會邁入大規模導入階段。

如何找出可共用的業務模組，是企業面臨最大的難題
目前已經開始嘗試SOA實作的企業，大多會先進行概念驗證（POC ，Proof of Concept）。這個過程中，各個企業亟欲驗證的就是「SOA是否真的可行」、「該如何找出可共用的業務模組」以及「共用模組切割能否達到最佳化」。根據臺大醫院以及華南銀行的實作經驗來看，重新檢視應用系統與業務活動之間的關連性，是一個根本而且必要的做法，唯有如此才能按圖索驥，找出之間的關連性，進而判斷哪些應該成為共用業務模組。

台灣大哥大技術暨用戶管理處副處長劉致中不諱言地指出：「實作SOA真正的關鍵，就是企業本身必須先釐清自己的系統架構，並且掌握每一個系統與業務流程，究竟在處理哪些事情，然後才能進一步評估SOA是不是符合需求。」事實上，SOA並非萬靈丹，也並非所有的應用系統都適合，例如：系統本身的屬性就很封閉，只有少數人使用的系統可能就不需要SOA。

雖然說SOA只是一個概念，並不是新的技術，也不是一個新的產品，但實作SOA的過程，卻真的會改變系統架構。根據臺大醫院以及華南銀行的實作經驗來看，顯而易見的改變，就是系統架構中，會多出一層以往所沒有的共用業務模組層，主要可以因應前端不同的需求，進而透過可以共用的業務模組重新組合，並且成為一個新的應用服務，過程中因為有了共用業務模組的基礎，因此大幅減少了系統開發的時間。

值得注意的是，企業對於SOA是否已經成熟的想法，目前仍舊呈現兩極的情況。有的企業因為適逢系統架構翻新階段，因此決定把系統架構全面轉向SOA，有的企業則是選擇從單一系統開始，更多的企業則還在驗證SOA，相較之下，尚未投入SOA的企業，對於SOA的認知也相對模糊，並且期待成功案例的出現。

臺大醫院系統架構全面轉向SOA

在臺灣，SOA雖然才剛剛邁入實作階段，但是大範圍的應用案例已經浮上檯面，目前除了臺大醫院的系統架構已經全面轉向SOA，其他包括台灣大哥大也正在進行全面性的系統架構檢視，並且把這項評估程視為2007年的重點；台灣固網則是因為既有系統疊床架屋，現在的系統與業務模式，早已超出原本的規畫，因此，調整系統架構是遲早的事情。

沒有時間等100分的成功案例出現，覺得SOA可行就用了
一般來說，企業對於新興技術或是方法論的採用，都會採取循序漸進的做法，SOA的發展自然也是如此，企業一開始通常都會用一段時間進行概念驗證，然後才會決定專案範圍，臺大醫院同樣也經歷了這個過程。

「2年多前，臺大醫院的主機轉換專案再度啟動，並且大刀闊斧地決定把系統架構轉向SOA，在當時甚至當今都是一個非常領先的做法，」臺大醫院副院長賴飛羆表示，決定把系統架構轉換成SOA之前，臺灣沒有任何一個成功案例可以參考，但是「對於臺大醫院來說，也沒有時間等100分的案例出現，然後才來做這件事情，因此，在經過概念驗證之後，覺得SOA可行就用了。」

臺大醫院的系統架構轉換，將會涉及的應用範圍，同時包括了門診系統、住院系統與急診系統等3大核心領域，賴飛羆說，過去的系統雖然穩定，但是延展性差，任何一個需求產生都是痛苦，舉凡健保局需要醫院提供的一些醫令資料，往往都需要半天一天的時間，才能完成資料轉換，系統架構轉換成SOA之後，因為同時遵循HL7以及Web Services兩個開放標準，因此，就可以直接與外部系統介接，進而達到快速回應需求的目的。

目前臺大醫院的系統架構，由上至下可以區分成Web Application（應用層）、HL7 over SOAP（網路協定層）、Web Services（共用業務模組層）以及資料庫等4層，賴飛羆表示，這樣的分層切割出來之後，事實上也改變系統開發人員的工作模式。過去一個新的需求產生之後，往往會挑選出適當的人選，然後就交由這些人從無到有逐步開發完成，現在系統架構轉換成SOA之後，只要明確定義出每一層應該遵循的標準，例如：共用業務模組層的溝通，就是採用Web Services標準，就可以做到垂直分層分工，而不用理會其中的程式碼或是商業邏輯。

遵循HL7醫療標準，逐步切割出10個共用業務模組
然而，當初光要定義這些標準，臺大醫院就花費了半年時間進行相關的規畫，其中共用業務模組部分，主要是遵循醫療界的HL7標準進行切割，相較於其他企業必須慢慢摸索的情況，臺大醫院在這方面幸運許多。臺大醫院資訊室系統組組長楊子翔進一步表示，HL7雖然是內容訊息傳輸標準，但是由於標準制定範圍涵蓋了每一個醫療流程，因此臺大醫院決定依循HL7，並且依序在共用業務模組層，切割出查詢、病人基本資料管理以及財務管理等10個共用模組。

目前臺大醫院的共用模組，主要是透過Web Services溝通，楊子翔表示，當初雖然也有考慮過使用MQ，不過後來因為考量到與其他醫療單位等外部系統介接的需求，因此還是決定採用Web Services作為跨平臺標準。臺大醫院歷時1年半開發的系統，總算從去年開始陸續上線，預計今年4月要完成所有系統的轉換。

在此同時，相關的管理工具也必須備妥，楊子翔表示，目前針對Web Services的系統效能監控，主要是用CA的管理工具，對於轉向SOA之後，延伸出來的模組重複使用性監控，則是經由應用系統呼叫共用業務模組的程式碼過程間接掌握，長期來說，臺大醫院仍舊需要透過工具進行共用模組的管理，不過礙於現階段正在進行系統轉換，因此，相關的管理工具評估，自然就成了第二順位。

這一次再度啟動系統轉換專案，臺大醫院只能成功不能失敗，賴飛羆決定自己操盤，在採用Sun Fire 12000主機之後，整體的系統架構也決定轉向SOA，應用系統的開發則是採用Microsoft Visual Studio 2003版，相較於過去使用Cobol開發的情況，一開始最難的就是如何找到.NET人才，進而建立一個開發團隊。

華南銀從銷售自動化系統開始SOA

當企業對於SOA的概念驗證結束之後，接下來的正式專案導入，大多會選擇從單一系統開始進行，而華南銀行就是一個最好的例子。目前在金融業的應用，除了華南銀行以外，包括彰化銀行、國泰世華都已經有具體的規畫，大家共同的目標就是為了解決重複開發的問題。

對於金融業者來說，資訊應用雖然相對較為成熟，不過，一個又一個的應用系統開發過程中，卻難以避免重複開發的問題，類似的功能不同的系統都需要，這樣的情況，不僅會形成重複開發的問題，更重要的是，開發成本也因此無法降低，SOA強調可以重複使用業務模組的概念，就成了金融業者想要解決重複開發問題的寄望所在。

目前華南銀行已經從銷售自動化系統（SFA）展開，彰化銀行則是鎖定從財富管理系統開始，國泰世華的決定是從聯貸系統著手。「國泰世華認為業務模組重複使用的意義，就是要企業別再發明新的輪胎」，這樣的前提下，國泰世華從去年第4季開始自己摸索SOA實作方法，並且陸續切割出100多個共用業務模組，現階段正要邁入聯貸系統開發，同時也是真正驗證SOA實作的開始。

至於華南銀行與彰化銀行，雖然同樣是從單一系統開始，但是華南銀行的銷售自動化系統已經邁入開發階段，彰化銀行則是最近才開始進行評估。「華南銀行開始關注SOA的過程，其實是無心插柳柳成蔭」華南銀行資訊開發部倪大為說，當初主要是基於企業入口網站（ICP專案）的需求，開始尋找適合的解決方案，後來仔細分析需求之後，卻發現在企業入口網站之下，集結了B2B、B2C、B2E以及Call Center等不同子系統的需求，而背後又有許多重複的地方，最後才決定從B2E之下的銷售自動化系統開始實作SOA。

SOA的觀念大家都有，但能否實作出來又是另一件事
然而，在此之前，華南銀行已經先驗證了SOA的可行性，倪大為說：「SOA的觀念大家都有，但相關的工具或解決方案成熟了嗎？則是一個問號，而實作更是最難的部分。」華南銀行決定著手嘗試之後，就先以金控旗下各子公司的跨售產品，作為SOA概念驗證的標的，如果SOA真的可行，不僅人與系統能橫向溝通，更將為華南銀行打造統一的系統架構。

倪大為說：「SOA只是一個概念，真正的方法論以及專業領域的know how還是要靠自己」，所以真正開始實作之前，必須先做概念驗證，這個過程中，華南銀行確實發現了其中的差異與效益，例如：跨售的保險產品，從交易到扣款總共需要4個流程，過去的做法是把這4個流程都寫在同一個應用系統中，現在的做法則是把這4個流程拆解出來，然後透過共用業務模組層的機制，提供給其他的應用系統使用，這樣的做法將能避免重複開發的問題。

用1個月時間建立4大類40個共用業務模組
目前華南銀行的共用業務模組層，主要區分為客戶資料、交易作業、帳務查詢以及事件通知等4大類，在此之下又有40多個共用業務模組，倪大為推估，接下來的銷售自動化系統開發，將能因此節省70％的開發時間，主要就是因為有了這些共用業務模組作為基礎，然而，在這之前，華南銀行為了找出適合作為共用的業務模組，就花費了將近1個月時間，預計未來還將會持續調整。

對於華南銀行來說，系統架構轉換成SOA之後，固然可以大幅節省相關系統的開發時間，不過也不能為了達到這個目的，然後又增加IT人員的負擔，因此，「華南銀行決定實作SOA之後，首先要解決的問題，就是不讓IT人員寫Web Services，否則為了要SOA，大家又必須學習新的技術，也是一件頭大的事情。」

對此，華南銀行的做法，是在應用系統端以及共用業務模組這一端，都分別寫好可以自動編譯Web Services的程式，換句話說，當應用系統端要呼叫Web Services時，就可以透過這個程式自動編譯成Web Services。除此之外，華南銀行在實作SOA的過程中，其實也很擔心Web Services會影響到系統的回應速度，但是後來發現可以透過硬體改善，所以這個疑慮就煙消雲散了。

華南銀行在實作SOA的過程中，參考了IBM的SOMA方法論，但是自始至終並沒有引進外部資源，主要也是因為資訊服務廠商缺乏導入經驗，因此，不如憑藉華南銀行內部的系統分析師以及業務分析慢慢累積經驗。

聯電順勢而為展開SOA先導測試

為了因應客服系統MyUMC的再造需求，半導體製造業者聯華電子決定展開SOA的先導測試，驗證是否可以實作SOA所訴求的共用業務模組，經過3個多月的概念驗證後，聯華電子決定擴大規模，並且計畫把客服系統轉換成SOA架構，不過由於現階段還在進行相關的專案規畫，因此，不論是專案範圍或是即將導入哪些工具、方法論一切仍未拍板定案。

SOA的門檻不低，沒有資訊服務廠商說的簡單
事實上，面對一個新興科技的崛起，概念驗證仍舊是發展初期必經的過程。對於絕大多數的企業來說，SOA的觀念雖然已經相當熟稔，但要如何實作仍是第一次，聯華電子資訊工程部部長張順德有感而發地說：「實作SOA其實是有門檻的，不論是技術面、開發面或是方法論都有不同的挑戰，並不像資訊廠商說的那樣簡單。」

不過，對於聯電來說，SOA如果真的可以實作出來，也將為聯電帶來更高的價值，因為過去傳統的開發方式，是比較技術導向的做法，SOA則是從更寬廣的角度切入，這個變化將使得管理者、開發人員以及使用者等不同層的人，能有更完整的想法。

張順德表示，聯電其實從很久以前就開始關注SOA的發展，但是2年前SOA才正在萌芽，資訊服務廠商雖然可以把SOA的觀念講得天花亂墜，但就是看不出來實作的方法在哪裡，近來，則慢慢有了改善，各個資訊服務廠商似乎也都可以說出一套方法。

「對於聯電而言，這個時候開始實作SOA，其實是順勢而為。」張順德說，聯電本來就有一套自己的方法論－SDP（Solution Developer Platform），是開發應用系統必須遵循的標準流程，但是與SOA著重的面向與思維邏輯不同，SDP比較偏重技術面，IT只是一個支援的角色，SOA則是強調業務服務流程，如果兩者之間可以結合，對於聯電會是一件好事。

以聯電的先導專案來說，雖然是基於客服系統MyUMC的再造需求，但是在過去幾個月的概念驗證階段，只有專注在工廠生產資訊提供這個環節。「概念驗證階段的評估關鍵，主要是想知道共用業務模組的做法是否真的具有可行性」，張順德表示，過去2、3個人就能負責一個應用系統開發，一個公司裡面可能同時有很多不同的開發團隊在開發類似的功能，重複開發除了造成資源浪費以外，也很容易導致系統應用複雜化的問題。

SOA實作的關鍵，是能否建立共用業務模組
根據先導專案的結果來看，SOA確實是可行的，目前聯電的下一步仍在規畫中，其中包括與SOA相關的技術、工具、方法論以及商業流程檢視，都必須面面俱到的評估，張順德說：「目前聯電並沒有侷限SOA的應用範圍，也沒有明確的步驟或是時間表。」

不過，可以確定的是，聯電在做完先導專案後，內部的資訊人員都已經能夠認同SOA，而不像過去普遍存疑的態度，張順德說，這就是先導專案的效益之一，畢竟過去只是聽別人在說SOA，但是否真的可行，必須眼見為憑才能服氣，「真正關鍵在於共用業務模組的建立，因為有了共用模組的基礎，後續的應用系統開發才會快。」

進化中的SOA

對於部分企業來說，試著實作SOA已經是刻不容緩的事情，但是對於有的企業來說，仍有許多還要再等等的理由。一方面是因為還看不到成功案例，另一方面則是因為市場過於混亂，以致於有意願嘗試的企業，決定憑藉自己的經驗來實作SOA，而意願相對低落的企業則選擇持續觀望，除此之外，包括顧問還需要時間養成、SOA成效難以評估以及方法論還在演變都是影響市場發展的關鍵因素。

先期導入者必須對系統架構有充分的掌握度
事實上，SOA在臺灣市場的發展，過去幾年都還是處於市場教育階段，一直到去年下半才逐漸有概念驗證的專案出現，目前為止，仍舊沒有任何一家資訊服務廠商真正拿得出成功案例，這個關鍵在於先期導入者對於資訊服務廠商的不信賴，而資訊服務廠商的顧問又必須仰賴專案經驗養成。

對此，IBM、BEA、微軟以及甲骨文等都紛紛表示，顧問的養成固然需要依賴專案經驗累積，但是在此之前，各個公司內部都有一套養成的方法，其中，除了來自國外的專案經驗技術轉移之外，各個資訊服務廠商也會定期把顧問送到國外培訓。

然而，即便如此，市場調查機構IDC企業應用研究經理曹永暉不諱言地指出，「SOA顧問的養成會比ERP還要難」，因為SOA的複雜度不僅具有產業差異，甚至就連每一個公司的SOA都會有所不同，相關的顧問除了需要產業經驗以外，也必須經過多個專案的歷練，才能針對不同企業的系統與流程做出適當的判斷。

除此之外，SOA成效難以評估也是另一個讓企業遲疑的原因。根據目前已經投入SOA的企業來看，大多是因為已經有具體的目標想要改善，例如：縮短應用系統的開發時間，進而達到即時回應市場需求（Time to Market）的目的等，因此這些企業大多是亟欲驗證SOA可行性的一群，一般來說，驗證之後就會進入真正的實作階段，其中甚至很少看到企業具體評估SOA的效益。

從局部開始慢慢擴大導入範圍，才能快速展現SOA效益
企業為了快速掌握SOA的經驗與效益，現階段大多會採取局部導入的做法，這樣不僅可以降低風險，也可以快速展現SOA所帶來的效益。對於許多大型企業來說，即使非常認同SOA、也有實作經驗，都不可能因為要SOA就大幅翻新系統架構，除非正好有這個計畫。

值得一提的是，臺灣的大型企業，過去為了加速系統開發的時間，對於不熟悉的應用或是超過既有人力負擔的需求，都會透過委外開發的方式完成，長期下來，這些企業的IT人員可能會逐漸偏重業務分析，進而無法充分掌握系統架構，類似這樣的情況，也會影響到該企業對於SOA的實作能力，所需要的摸索時間也會變得更長，因為SOA不只是應用開發層面的問題，更深的意義在於系統架構的轉變。

如果企業本身無法充分掌握相關技術或是系統架構，不僅容易被資訊服務廠商牽著鼻子走，也容易陷入產品面的功能比較，然而，SOA並非一定要透過新的工具才能實作出來，重要的是，系統的溝通介面要遵循開放標準，才能真正達到SOA鬆散耦合的訴求。