【技術e專欄】從亞馬遜成功談SOA 價值

以下談了一些關於SOA 的想法，主要想傳達幾個訊息。

1. 企業在思考SOA 的導入時，必須站在一個戰略的制高點，採取全方位的觀 點來看待SOA 對企業的衝擊與效益，而不能僅視為IT 部門技術升級的一 個專案而已。此外，也不應該在內部流程與上下游夥伴協同作業尚未檢視 與評估前，就貿然要導入。
2. SOA 的核心在於以「服務」作為企業流程與IT 系統的架構基礎，服務的設 計必須要有詳細而縝密的歸納與分析為基礎，才能發掘出具共用與可重用 的基礎服務；而且這些工作必須是企業內部跨部門，甚至是跨夥伴間的成 員，一起投入才能順利完成的。
3. 企業IT 開發人員不能只是想透過導入新產品，就可以來實現SOA，必 須同時在API 的使用與設計上有所精進，才能順利邁向以服務為導向的 系統設計與開發。

有人說資訊科技（Information technology, IT）產業像是流行產業，每隔幾年就有 一些新的技術名詞出來，像這兩年流行的大概 就是「雲端運算」與「Big Data」。那筆者怎 麼會在這時候還來談早已過時的「SOA」（服 務導向架構 Service-Oriented Architecture）呢？

SOA is not Dead 仍有參考學習價值

原因有二， 首先， 就像2009 年金融海嘯期 間，一篇傳閱甚廣的部落格文章「SOA is Dead; Long Live Services」所言，雖然SOA 這個名詞 已經成為過去式，但以「services」為核心概念 所發展出來的各種架構手法與軟體技術，還是 會延續下去的，這中間也包含了「雲端運算」， 知名的雲端服務「Amazon Web Services(AWS)」 的名字中，就反應出「 Web Services」在它整個 服務中是扮演了一個重要的角色。其次，一般 說來，台灣對於歐美先進IT 技術的引進還是有 時間上的落差，所以圍繞在SOA 概念下的許多 有用的技術與手法，對很多的台灣企業IT 而 言，還是有參考與學習的價值。

SOA核心 共用且可重用的服務

先從SOA 的定位談起，雖然它含有「架構」 （architecture） 的字眼， 但其實SOA 談的 不是一種具體的架構，而是一些關於架構的 指導原則。這些原則的核心是「服務」： 共用且可重用的服務（shared and reusable services），而且這裡談的服務是廣義的，不 是只從IT 技術的角度來看，也要拉高層次， 連結到業務層面，從企業的營運角度來思考 服務的設計。簡言之，企業的營運通常是透 過許多業務流程來體現，這些業務流程中的工作步驟由個別的部門提供，SOA 則提倡以 服務的角度來實現流程所需的工作步驟，並 要求以共用且可重用的服務來架構與組裝出業務流程，讓流程具有較高的彈性，方便企 業在因應內外部營運之需求時，得以快速調 整流程以提升競爭力。

舉個客戶服務的例子，過去可能只有顧客臨櫃 或客戶電話兩個管道，網際網路興起後，增加 了網路的管道，現在行動裝置盛行，又要有行 動平台這一管道，如果客服系統有採用SOA 方式建置，因為有可共用與重用服務的設計， 在增加像行動平台的新管道時，客服系統的擴 充可以沿用一些既有的服務，開發與建置將比 較容易且快速。反之，則可能會是好幾套並 行，拉高了建置成本。

SOA 關鍵 企業流程是否明確

再舉個涵蓋跨企業協同合作的例子，幾年前 PCHome 線上購物推出的「24h 到貨」服務， 就是一種創新的客戶服務。PCHome 要落實 對客戶的這項服務，它的組織內部以及它與外 部業務夥伴之間，就必須要有許多流程上的 改變與配合，並搭配IT 系統的快速修改，才有可能在短時間實現這項創新的服務。如果 PCHome 的內部流程缺乏彈性，IT 系統也是 鐵板一塊，那即使PCHome 有創新的業務策略，也未必能快速地實現策略，獲致市場競爭力。所以，業務服務雖然需要透過IT 技術與 系統的服務來落實，但SOA 絕不是僅僅從IT 的角度來談服務的。企業需要透過很多的改變 與調整才能邁像SOA 的境界，絕不是導入一 些IT 技術與買一些特定的產品就可以輕鬆實現的。例如，企業在業務流程都還沒有建立標 準化與文件化的情況下，貿然要去導入SOA， 一定會事倍功半，困難重重的。

以宏觀來看，SOA 也是隨者企業營運環境變 化的需求，以及IT 技術如何有效支援這些 需求所逐步演化 出來出來一些原 則， 是有其脈絡 可循的。這些需 求可以概括性的 歸納為「敏捷性 （agility）」與 「降低成本（cost down）」。敏捷 性要求企業面對 外部營運環境的 變化與競爭， 必 須要有彈性， 能做出快速的應變 與調整。此外， 不僅要快而有效， 還要盡可能的降 低完成調整所需的成本。

系統間的整合議題 「牽一髮而動全身」

這其中IT 系統的調整與整合，往往就占了成 本的一大部分。雖然感覺上軟體應該是很有彈 性，容易修改的，但實際上卻往往不是如此。 相信很多人都有經歷過，「牽一髮而動全身」 才是修改大型系統時常會面臨到的現象，若還 有不同系統間的整合議題，那更是雪上加霜， 延宕費時。所以軟體工程的研究中，一直將軟 體的模組化與重用化視為「聖杯」，期盼能找 出可有效共用與重用的軟體模組單元。回顧軟 體發展史， 從「procedure」、「module」、 「object」到「component」，都還未獲致滿意 的結果，所以才會演化出現在以「service」的 軟體模組單元。簡單說，這個方向的演進是朝 「粒度」（granularity）較大的軟體模組單元 發展，在兼顧重用性的需求下，提高模組的自 主性與降低模組間的相依性。

但是SOA 裡談的「服務」不只是IT 或軟 體層次的服務， 前面已經提過，SOA 也要 從企業的業務流程的層次來看服務。實際 上， 這就是說討論服務的設計時， 也要有 「粒度」（granularity） 與階層（hierarchy） 的概念， 有比較高層次， 屬於業務層次的 服務，也有比較具體而細緻的IT 層次的服 務。例如， 就有學者提出多層級、不同粒 度的服務模型， 包含了「process service」、 「business service」、「composite service」、 「informational service」、「data service」、 「utility service」與「infrastructure service」 等不同粒度類型的服務 1。其中process service 以及business services 直接對應到企業的業務流程，與 IT 無關，其他的就比較屬於IT 層次的 服務。這就意味著SOA 的導入絕不只是IT 部 門的工作，必須也有業務分析人員（business analyst）一起投入，從事業務流程的服務設計 規劃工作，辨識出具共用性與重用性的服務， 從而帶出所需要的IT 層次的各種服務。

1N. Kulkarni and V. Dwivedi, "The Role of Service Granularity in A Successful SOA Realization – A Case Study", IEEE Congress on Services 2008.

Amazon系統以標準化 「服務介面」來溝通

這樣看來，SOA 的導入是一項所費不貲的大工 程，不僅要投入許多人力，也要採買不少軟體 工具與平台。視企業的規模而定，的確有可能 是一項大投資。但如果成功導入，也會帶來明 顯的效益，一個最知名的SOA 成功案例就是 亞馬遜（Amazon）。十多年前，亞馬遜的資 訊系統也是龐大而紛亂，在2002 年左右，亞 馬遜總裁Je Bezos 下達了一項命令，要求公 司內部所有的資訊系統都必須調整，不管用的 是什麼技術與平台，系統之間都必須以標準化 的「服務介面」來溝通合作，不能做到的團隊 就請走人。這項改革自然在亞馬遜內部造成及大的震撼，但結果是非常正面的，它讓亞馬遜 的購物平台與雲端服務平台能快速因應客戶需 求，成為市場領導者。

不過這並不代表SOA 的導入投資一定可以回 收，相反地，就如本文一開始就提到SOA 一 詞某種程度已成為過去式，意味著SOA 失敗 案例一定也不少，所以企業在考慮導入SOA 前，一定要對自身的條件，包含業務面與IT 面，以及投資的成本效益（ROI）有一番仔細 的評估後，再決定導入的範圍與程度，因為如 果要全面性的導入，及可能要購買與建置基礎建設性的中介軟體平台，費用相當高的。

SOA的推動與導入 不宜由單一部門來推動與導入

關於業務面的評估，上面已簡要提過，筆者也非此方面之專家，所以以下僅就IT 面的評估 提出一些個人的看法。即使只談IT 面的評估， 也是有很多面向值得考慮，這裡筆者將聚焦於 企業IT 部門在服務開發方面的成熟度評估。 不過並不是要以像是CMMI 五個成熟度等級 那樣嚴謹繁瑣的來談，只是提供幾個可供快速 自我檢視的參考面向。首先，規模較大的企業 在IT 方面的運作與治理（governance）可能採 用中央集權制，也可能是比較鬆散的各自為政 制，或介於中間。一般說來，SOA 追求的是具共用性與重用性的服務，它的效益自然要從企業整體或 至少跨部門的角度來考量， 才能最大化，所以SOA 的推 動與導入不宜由單一部門來 推動與導入。企業IT 的運作 上，如果比較欠缺跨部門合 作與嚴謹的專案管理經驗， 在導入SOA 前，可能要格外 謹慎，經過一些宣導與試做 後評估後再進行。

其次，SOA 的技術內涵也不是全然都是新的， 有許多也是過去一些技術的延伸與再進化， 像是企業應用整合（EAI）與企業流程管理 （BPM）等。所以過去曾經導入過這些技術與平台工具的企業，在導入SOA 時，相對來說， 技術門檻會比較低，否則的話，可能要拉長導 入期，採漸進式導入為宜。

API的運用與設計 就是SOA的一個最重要的基礎

最後，也是最基本的評估，就是IT 系統分析 與開發人員對API（ Application Programming Interface）的運用與設計的成熟度。筆者認為， 從系統開發的角度來看，API 的運用與設計就 是SOA 的一個最重要的基礎。早期學校裡教 程式設計與系統開發，這方面的著墨並不多， 圖型人機介面（GUI） 流行後， 透過MVC （Model-View Controller）的架構樣式，大家 開始有了更多程式模組分離的概念，有了初步 的API 的概念。接著OOP 興起，Java/C# 的使 用中，必須大量運用語言所提供的函式庫，所 以開發人員都會有許多使用API 的經驗，但卻 不見得有設計與開發API 的經驗。 到底什麼是API ？我常用與GUI 對比的方式 來跟學生解說：GUI 是程式對使用者的介面， API 則是程式對程式的介面。打個比方，GUI 的程式設計像是B2C 電子商務，而API 則是 B2B 的電子商務。

一般說來，開發人員在設計程式的時候，是會 考量到從使用者端，也就是UI 端，如何使用 （呼叫）自己所寫的功能。但很少會去想到我 寫的這些模組，以後也可能需要被其他（並未 事先設想）的程式模組使用，更別提甚至是夥 伴企業的資訊系統透過遠方來呼叫使用，這就 是沒有從API、從服務的角度來設計自己的程 式模組。根據筆者的經驗，系統設計之初，若 沒有先設想到 API，日後要來增加，困難度高 很多，常常無法達到所預期的目標。因此，IT 系統的分析與開發人員必須先花點功夫探討一 下API 的運用與設計的原則，進而提昇至服務 介面的運用與設計，這樣在導入SOA 時就應該會比較順利。