服務科學課程回顧: 服務導向資訊系統架構(Introduction to Service Oriented Architecture)

回顧這個緊湊的學期,筆記真的非常重要,很多簡寫還必須想一陣子才能回憶起來。

來到服科所的第一堂課: SOA ,服務導向資訊系統架構( Service Oriented Architecture )。

跨領域的 Culture Shock

還沒深入之前只覺得教課的 Soumya 很有趣,沒想到就成了我後來的老闆,這是我在第一學期裡覺得最有趣的一門課了。老師這堂課非常希望把管理方面的知識,與用來實現其概念的資訊技術結合,所以總是上半場談管理,下半場講資訊。

雖然如此,這種實驗性的上課方法也並不是每次都會成功,往往深入討論管理理論的內容時, IT 背景的學生很常不自主地打瞌睡,下半場換教 IT ,換成本來非 IT 背景的其他學生頻頻半睡半醒地點頭…,這也無可厚非,因為剛開始真的完全聽不懂,連想像都有困難!

譬如,對不會寫程式的人(像我),教科書的說明雖然擺在那,想破頭也不會懂為什麼「 Ruby 」語言產生的 Code 比「 Java 」簡潔、「資料驅動的物件導向設計( Data-driven Object Orientation )」相對於傳統的程式語言邏輯有何優勢、什麼叫做用程式去管理程式、為什麼敏捷開發( Agile Development ) 需要談 SOA ? 這些跟發展 SaaS ( Software as a Service ) 有什麼關係?

隨著 IT 在學期專案中的角色逐漸吃重,更加明白為什麼本位主義不只是人力資源書裡的文化、心態、政治或利益上的問題,因為當你完全無法理解合作夥伴在做些什麼、能做些什麼,綜效( Synergy )就別想了,連解釋一個本來視為常識的基本道理也變得格外艱辛,這是跨領域的第一道天然障礙。

但是說這麼多,到底什麼是服務導向架構 SOA ?

服務導向系統架構 SOA 的基本理念

不鑽牛角尖,不妨想像傳統架構下的企業 IT 是燒玻璃,燒製的過程還有調整的空間,一旦冷卻定型,改變的代價就變得很高,某個部分破碎了,也代表這個瓶子完了( Crash )。

假使別人想使用這個瓶子,只能接受原本的形狀,頂多改改圖案花樣。 SOA 要做的事,是把企業 IT 用樂高積木的想法來設計,每個定義完整的組織功能單位都是一個獨立的 IT 系統,誰來用這堆積木、愛怎麼改流程、拼拼湊湊都無所謂,任何部分出了問題,隨時抽換就好,積木不會因此散落一地。

在 Amazon 的例子中,甚至把企業 IT 變成可以對外販售的「服務」,於是 Amazon 更能放手追求設備上的規模經濟,再用來進一步強化服務的內容。

其中一套 Amazon 的服務叫做 S3 ,專門提供儲存空間,原先是自己內部使用的,後來才轉為對外商轉。

沒聽過的話很正常,因為 S3 是 B2B 為主的服務,但是有套給一般人使用的軟體叫 Dropbox 可就大大有名了,前陣子才剛辦完一場極為成功的行銷活動「 Great Space Race 」- 一個針對各大學學生認證數量的贈送免費空間競賽,相信很多人手邊都有帳號吧?

Dropbox 就是租 S3 的空間起家的。意外嗎?提供線上儲存空間服務的公司竟然自己沒有儲存空間!在服務導向架構下這樣的例子還會越來越多。依照 IT 的層級,有各種名字用來分類這些 SOA 下的雲端架構產物:

SaaS(Service as a Service)

PaaS(Platform as a Service)

IaaS(Infrastructure as a Service)

它們共同構成了時下很夯但是人們其實不見得理解其內涵的「 雲端服務 」。

下方截圖取自維基百科

SOA-cloud-computing-layers

SOA 作為新典範一個最明顯的影響是資訊與網路基礎的創業(例如 App )和以前比起來簡單、快速、靈活得難以想像,只需要發展一個核心功能就夠了,其他的通通可以租到…,而且會越來越接近隨插即用!

不過,多少人能夠從中取得成功? CIO 雜誌做過一篇專題來探討 SOA 之於企業的策略意義,台大計資中心也曾在文章中提到許多大企業早在 XML 與 Web Services 出現之前的時代就已經有過運用 SOA 取得成功的案例。

然而這些討論似乎永遠都不夠,新世代的網路創業家們談論到這些技術應用時總是說他們還在努力尋找更好的答案…,一個比過去更好的 Business model 。

SOA 與營運模式 Business Model

在管理的課題方面主要以營運模式為主題,老師最初幾週花了一些時間重複討論它的意義與用途,再依照上課案例的描述來繪圖,每次都費了不少功夫討論及修正大家的營運模式。

為了不使營運模式流於胡亂作畫,老師介紹了Detmar Straub《 Foundations of Net-enhanced Organizations 》第八章中,引用 Peter Weill 與 Michael Vitale 所提出 E-business 的「 Atomic Business Model 」作為參考基準。

SOA-atomic-business-model

不過多數時候一個 Business Model 可能結合了好幾種基本型的特徵,稱為 Hybrid Model ,例如知名旅遊網站 Lonely Planet 的例子:

SOA-hybrid-business-model-lonely-platnet

後來我找到這篇 Peter Weill 與 Vitale 在 MIT Sloan 管理學院資訊系統研究中心 2001 年 3 月刊登在 CISR Research Briefing 的文章,兩位學者另外列出了各種 Atomic Models 之間的綜效與衝突關係,非常有意思,值得一看。

SOA-atomic-business-model-2

SOA-atomic-business-model-3

由於雲端服務建立在網路的基礎上, SOA 課程教的 business model 引用了電子商務方面的研究,但是商學背景較深的學生應該會開始想,一般化的商業模式又是如何?

Peter Weill 另外還有一篇 2005 年的 working paper 《 Do Some Business Models Perform Better than Others? A Study of the 1000 Largest US Firms 》,裡頭列出 4 種 basic business model archetypes 與 16 種 detailed business model archetypes 如下:

SOA-business-model-archetypes

SOA-business-model-archetypes-2

正好去年有一本書在創業社群當中很火紅,也談 Business Model ,書名是《獲利世代( Business Model Generation )》,裡面用一張稱為「 Business Model Canvas 」的工具圖表來描述營運模式,一時眾多部落客爭相撰文推薦,各位不妨比較一下這些營運模式的邏輯有什麼不一樣?

SOA-business-model-canvas

從流程管理 BPM ,流程改造 BPR 到兼容並蓄的 BPMN( Business Process Modeling Notation )

對營運模式的有基本了解之後,接下來的課題是營運模式內部究竟是如何運作的?

解答在於流程。老師同時也用流程作為結合資訊與管理的橋梁,但為什麼是流程?從管理面出發,任何單一工作(Task)都不應該「沒有目的而存在」,有次序的各種工作組成了流程。

內部流程的總和能夠有意義地描述企業的整體運作而不至於太過複雜,單獨分析個別流程則有助發現那些「目的不具價值」的工作,並進行調整。從資訊面出發,所有需要被管理的行為都會留下紀錄,而資訊科技可以讓繁複的紀錄變得容易被管理。

更重要的是,在流程分析中找出的那些「重覆被執行的」以及其他由人力進行的許多工作都可以用資訊科技更有效率地取代,競爭力因為更快速的處理、更少的出錯以及更少的人力需求而提高,這正是企業流程再造( BPR,Business Process Re-engineering )的主要論點以及為何資訊系統的導入在 BPR 實務中如此重要的原因。

BPR 的濫觴, Hammer 與 Champy 合著的《企業再造( Reengineering the Corporation )》發表後頓成管理叢書中的經典之作,然而 BPR 的發展卻不像大師的書一樣熱賣長紅,原因是 BPR 經常以慘烈的失敗收場。

Griffith 等人 1999 年刊登在 Industrial Management 的研究《 Why new Technologies Fail 》點出 75 % 的 ERP 專案效果不彰甚至悲慘,即使 13 年之後這種詛咒式的失敗也沒有顯著改善,顧問公司麥肯錫去年 10 月發刊的 McKinsey Quarterly 也引用與牛津合作的研究指出,在初始預算 1500 萬美金以上的 IT 專案中,有一半的公司花費超過預算的 45 % 、時程延遲 7 % ,但卻有 56 % 的企業表示專案的價值比想像中還低。

BPR 蔚為風潮卻無法獲致普遍的成功,包括 Hammer 與 Champy 兩位始作俑者在內,許多專家陸續提出不同的意見來解釋企業失敗的原因,像是跨部門的溝通、企業文化、變革理論、領導階層的決心與組織執行力等等,也各自提出了一些建議。

老師沒有引用名著中的長篇大論,關於為何 BPR 不會受到組織內部的支持的這個問題, Soumya 說,「 IT的導入是用來取代多餘的人力,但是誰想被裁員呢?不如看著它失敗」。於是我恍然大悟。

想想,其實道理挺簡單的,不是嗎?

但是即使撇開因為擔心裁員而導致的不合作,「溝通」這件事情仍然十分困難,而妥善地處理它就是許多專案經理與產品經理的首要工作。意義上,用來描述工作與流程的視覺圖像都是「流程圖」,不同領域的表示方法卻大相逕庭。

Deployment Chart 用在工程與品管方面,習慣使用較多規範過的符號,圖形的邊邊角角都意味著某種細節,但在行政部門, Flow Chart 則非常的簡化,有些圖裡的方塊與圓圈甚至看不出有什麼不同,而資訊部門的 Activity Diagram 又用另一種風格來描述資訊流。

即使在特定領域,也不見得有產業一致的規範,每間企業都有自己的版本,經常同一公司內的不同部門間也無法藉由流程圖來溝通,連自己在做什麼都不知道,怎能妄想得利於流程分析呢?

SOA-Process-Modeling

斷斷續續的流程陳述加上無法彼此溝通的功能部門,負責寫出資訊系統的程式設計師只能憑自己的想像作畫,研發的過程效率不彰、成果所費不貲之外, IT 系統難以使用甚至無用,失敗似乎不難預見。

整合各種流程邏輯於一身的 BPMN ( Business Process Modeling Notation ),就是學者與業界專家們為了改善流程溝通所做的努力之一。

荷蘭 Eindhoven University of Technology 與澳洲 Queensland University of Technology 的教授們於 1999 年創立了這個超棒的網站「 Workflow Patterns 」,整理各種流程管理觀點與研究,附帶精美的例圖與說明,當然也包括了 BPMN 標準。

BPMN 這個工具還很年輕,仍然在發展當中, Visio 是 MS Office 家族中專門用來畫流程的軟體,在 2007 的版本裡,還看不到 BPMN 圖標的身影,到了 2010 版本, BPMN 已經成為內建的範本之一,可見得它的重要性持續增加中,不過當然了, BPMN 也不是完美的。

課程中我們使用過的一個 BPMN 教學範例:

內外流程的完美結合: BPMN + Service Blueprint

有人可能注意到,上面那張 BPMN 的 patient pool 是留白的,怎麼會這樣呢?

因為顧客的流程基本是我們無法控制的。由於 BPMN 中運用大量的邏輯符號,以及某些應用中會 直接轉成程式碼( BPEL ),為免流程分析不切實際, BPMN 最好是用在企業內部可控制、可改變的工作流程上。

在行銷裡,我們有另一個工具,同樣關心工作與流程,但不必要控制任何人也能提供一個服務整體的綜觀,而且提供了與流程相關事物的資訊,這是在 BPMN 中缺乏的。

那就是 Lynn Shostack 在 1984 年發表的服務藍圖 Service Blueprint 。在這篇文章中有關於服務藍圖的更完整解析

SOA-BPMN-Service-Blueprint-example

來對服務藍圖與 BPMN 做個簡單比較吧。服務藍圖中列出了各種 Customer Action ,雖然在排列上盡可能使其有順序意義,方便理解,但是顧客當然不必要按著牌理出牌,一千種顧客也許有一千種臨場行為,服務藍圖關心的是哪一些最重要?誰會接觸到這些顧客?需要誰的協助以及現場的環境是如何?

而 BPMN 的特色則是非常清楚描繪了內部作業。顯然, BPMN 是作業導向的流程邏輯,而服務藍圖是顧客導向的流程邏輯。

我們有幾種方式,可以把兩者的優點結合在一起,讓流程既能充分管理,也保有顧客導向的優點:

第一,將 Customer Action 等元素加入到 BPMN 當中

第二,將 BPMN 的符號邏輯加入服務藍圖當中

第三,仍然分別繪製兩張圖,但是 BPMN 的流程將對應到服務藍圖裡的行為/工作所引發的後續流程。

我比較喜歡第三種,分開畫。例如以下的範例:

SOA-BPMN-Service-Blueprint-example-2

SOA-BPMN-Service-Blueprint-example-3

要驗證第三種是不是比較好…,我的想法很簡單,就算沒有很仔細觀察兩張圖,甚至不熟悉它們,也應該很快能發現,其實下面的 BPMN 畫的內容就是上面的服務藍圖用紅線標記的流程!

而這張 BPMN 其實還可以與前端網頁開發的 Model-View-Controller 架構進一步結合,把網站與使用者互動的 Views 也標記上去。

SOA-BPMN-Service-Blueprint-MVC-example

跨領域,就是應該這麼玩!

這學期 Seminar 正好也有兩位網路創業家來分享故事,Gogolook 的 CEO Jeff 以及 Plurk 亞太區的負責人 Danny ,兩間公司最讓我驚訝的是,雖然 Gogolook 開發的 App — WhosCall 擁有頗大的流量,而 Plurk 全球會員數則有 600 萬,但是他們的總員工人數則僅僅只有個位數…,還不一定在台灣。

網路與程式技術的進步的確很大程度上改變了創業的可能性,相較之下,SOA 的課程講義裡有一張圖我覺得很有意思,鮮明地指出傳統 IT 設計的缺陷,稱為「Spaghetti Architecture」。

SOA-Spaghetti-Architecture

最後列上幾個這學期運用到的實用網路服務:

1. Github for Version Control

2. Heroku for Cloud Deployment

3. Amazon EC2 for Cloud Virtual Machine

4. Mock Up Builder for Interface Design

5. Balsamiq for Interface Design

學海博大精深,只看一篇怎麼夠:

* 服務科學課程回顧: 應用商業分析(APPLIED BUSINESS ANALYTICS)

* 服務科學課程回顧: 服務行銷與管理

* 服務科學課程回顧: 服務科學實務(SERVICE IN PRACTICE)

* 自我效能(SELF-EFFICACY)觀點:解析自我感覺良好

* 誰說態度決定一切? 態度三元論(ABC MODEL OF ATTITUDE)與計畫行為理論(THEORY OF PLANNED BEHAVIOR MODEL)

(Visited 2,992 times, 1 visits today)

Wendell.Huang

科技公司嫌棄太活潑,消費品牌挑剔太沉悶..., 經常必須解釋自己在學什麼, 不小心就摔破對方眼鏡的跨領域玩家。

3 Comments

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *