「變」才是自動化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角色職權的衝擊。
3.Fiona Lan 於 2008/03/31 22:23 回應
我同意Pan.tc328對於「專案時間分配」的觀點。我並非IT人員,但在我們藝術領域也一樣,不管是平面設計、網站、動畫、還是拍電影,越大型的案子,花在「企劃、前製」的時間就越重,從50%到80%都有。在我們業界,也是許多人拿到case就直接做,沒有事先做分析跟維護的規劃。然後,必定發生的事情,就是客戶覺得成品「不合身」,不斷的改稿、改稿、改稿。在改稿的過程中,因為沒有事先規劃工作檔案的架構,散落各處的檔案、各組稿件的新舊版本,越來越混亂,滿頭大汗的到處補破洞,能結案就阿彌陀佛了。
設計,原本就是客戶企業營運的一環,因此,從客戶的策略面著想,是天經地義的事,也是設計師能夠被尊為專業人士的原因。
2.匿名 於 2007/07/21 17:04 回應
好文章…推…很多人在談SOA……但想賣產品的居多……
天馬行空,講了一堆,除了建架出更多「技術的象牙塔」外,
我看不出SOA 到底對企業有什麼樣的幫助……
作者點出了point......
「變」應該才是SOA 主要要去面對與解決的……
1.Pan.tc328 於 2007/02/15 14:55 回應
我的想法跟你們有些出入三個月時間的系統分析以及六個月的程式撰寫,最後逐一的測試
我會 六個月分析,三個月實作. 風險在分析要排除7 成,所有變的不變的要抽出, 企業很多是變的,但也有許多不變,你要能預測使用者決策的想法,他可能去動那邊.
很多人都是拿到 Case 就直接實作,可能他們做好,我還在想,但我的Case 出去就一定ok 的