- a knight’s tale - 乃特風雲錄 -

日昨, 在忙著陪老外之中, 某大前輩問了我一個問題: 既然 SOA 是 Concept, 那到底在軟體工程當中, 他在哪段有所調整? 是 Requirement 階段? SA 階段? SD 階段? 大前輩問這個問題是有用意的. 當各大社都在狂推 SOA 想要藉此搶市佔, 可是各家的解決方案好像都沒能改變現狀 — 賣平台. 講這種話我等於是得罪全世界各大社, 但是我的重點只放在, 某些 RFP 或需求規格書裡看到的事實.

回到 SOA 本身的定義, 某些狀況下是和 OOP 有重覆. 在各大網站上, 也確實是有相關討論. 沒錯, 在執行細節上, SOA 有更明確的規範, 包括 XML, SOAP 等等, 但是如果把這些額外的定義, 從 Requirement 當中 (暫時) bypass, 而當作是開發工具的附加特性, 整個 SOA 和 OOD 的相似度當然就更高了, 除了 Software as Service 這個 concept 例外.

在 OOA/D 裡, 對物件的規畫方式, 可以透過各種各樣的 Design Pattern 完成, 當然也會有 Anti-Pattern 的論點, 但總是一系列的方法. 在這些方法裡, 都是以物件的行為作為規劃的出發點. 而 SOA 則有所不同, 每個 software (or component) 都是一個單獨的 service (for business), 這與 OO 裡各物件的用途稍有不同. 如果從這樣的角度來說, SOA 又或許可以被當成是另一種 “不成文的 Pattern” 來討論.

那麼, 姑且把 SOA 當作一種特殊定義的 OOD 好了. 那, 某大前輩又問了我一個問題, 目前台灣有哪些廠商能『真正』 deliver SOA? 長輩說, 那些 software provider 不要講, 那些除了賣軟體出張嘴 consult 之外, 都不能搞什麼鬼的. (正如我碰到過的某 ERP 案, 該世界知名大廠也有 SOA Solution. 電車 2.0 和彩券 2.0 姑且不算好了, 因為那些 software 好像沒特別標榜 SOA) 我想了半天, 在上述這些系統都出過錯之後, 我還真不知道哪家端出的這道菜真的能吃. (聽說吸摸妹唉哪一級也都差不多喔)

而在另一個標案裡, 某單位考慮要組織再造, 但是承辦人的想法卻是, 再造之後的組織需要用哪些軟硬體, 拼死命在那邊猜軟硬體的規格; 而完全沒有考慮新的組織架構長相, 功能, 介接等等. 會發生這類的狀況, 只有兩個可能性, 而且兩個同時發生: 1. 該單位不願意花錢做 2-stage bid, 或是 1st consulting stage 爛掉了. 2. 承辦人員所『熟悉』的廠商只從賣軟硬體的角度去思考問題解法, 而不是從組織實際需求來思考. 這讓我想起了之前曾在某單位看到的狀況: 沒錢換 Web Server (用 Pentium2 的主機, WinNT4, IIS 版本舊到不行), mail server 掉信掉到亂七八糟, 卻有錢把每個 user 的桌機換到多新多新的等級, 同時每個 desktop 都直接 2 port 上 C 牌 L2 Switch, 甚至還考慮往 GB 升. 這種狀況之下, 資訊化只是花錢的好理由.

所以…品質問題…hmmm…我什麼都沒說…:)