BizTalk 之我思我見

完成連續四天的課程後，昨天從恆逸拿到我這輩子第一張電腦技能的修業證書，沒想到既不是 .NET ，也不是 Java，竟然是做夢也沒想到的 BizTalk 2006。 　　雖然上面印著 Certificate 的 Title ，但這只是個無足輕重的修業證明，並不是證照。然而岳父卻非常看重這個證照橫行的時代，每每面對我這個除了駕照以外一無所有的軟體工程師，總是碎碎念，認為我技不如人、遲早被社會淘汰。 　　Anyway，這張假證照或許日後可以幫我唬弄過去，反正他甚麼也搞不懂。 　　對於有程式開發背景的人來說， BizTalk 大體上並不難理解與入手，一本我目測約三百多頁的原文教材，包含上機實做練習，四個全天就講完了。但是我極度懷疑沒有程式開發背景的人員能夠理解 BizTalk 這套軟體的操作，所以基本上，我看待這個產品並不是取代程式開發人員的工具，但「或許」是節省開發人員時間與負擔的工具。 　　強調「或許」，是對於開發老手，他早以手邊累積不少現成的套件或是函式庫，熟悉 OpenSource 的開發資源與現成的 Class，旁徵博引的開發效率未必會比滑鼠設定 BizTalk 內的各個 Pipeline / Adapter / Schema 來得慢，甚至可能還快上許多。但是對於新進的開發人員，BizTalk 提供許多現成的基礎環境設施與視覺化設定，應該可以幫助菜鳥進入實戰階段，所以充其量，BizTalk 是個拉近新手和老手之間差距的工具。 　　也許有人會說，產品的設定與視覺化開發比起程式碼來得好維護，這應該是 BizTalk 該勝出的地方，但事實卻不然。 　　我承認菜鳥工程師的程式碼解讀時會冒出無名火，但現在比較的狀況是，[ 經驗老道的工程師  vs ( 菜鳥工程師 + BizTalk ) ] ，如果常常去看 OpenSource 的開發人員會知道，有經驗的開發人員寫出的程式碼其實不難端倪，而且可修改的彈性高出甚多，逐步除錯也容易。但是，BizTalk 的除錯非常困難，且修改不易。整個上課過程中，我就飽受「一步錯，整個重來」的痛苦，一個 Schema 建錯，可能牽涉到的 Flow、Mapper、Pipeline、Ports...全部都得跟著調整或是重建，而且如果漏掉任何一個環節沒修正，非常不容易發覺，只知道訊息有進無回。 　　說到日後維護容易嘛...，因為圖型介面使得一張圖勝過千言萬語，交接與理解較為容易，這些論點因為我缺乏真正的實務經驗，不作評論 ( 依我所聽到的前人經驗，他人接手前人的專案，其實並沒有比較容易交接或是理解 ) ，但我要強調，即使真的有這個好處也是應該的，公司並不會因為維護容易而降低維護成本增加獲利，因為你帶入產品進去做，每年的維護費用收入本來就會有部分被產品的原廠 ( ex. 微軟** ) 拿走，公司真正能從每年維護營利的金額本來就比完全自己做來得低許多。但如果帶了 BizTalk 進去做，維護成本沒降低多少，那開發廠商豈不是虧到沒衛生紙擦屁股？ 　　目前我參觀過的幾個 BPM Solution - TIBCO、IBM WebLogic 和 BizTalk，微軟的 BizTalk 是最為技術人員導向的產品，也是商務功能最弱的。 　　這幾天上課，我嘗試分析 BizTalk 的成本效應。以它標準版 ( Standard Edition ) 的售價每顆 CPU 索價台幣 30 萬，中小型標案帶入不划算，價錢也無競爭力，但是大型案子要到多大的規模帶入，才能發揮效益產生競爭力呢？ 　　我的評估方式如下，如果某 SI 廠商的人日報價單價為 NT$10,000 / 人日，引進一顆 CPU 的 BizTalk 標準版授權，就必須至少縮短專案 30 個人日的開發成本才剛好打平。 　　如果，客戶使用一台兩顆 CPU 的機器當伺服器，BizTalk Standard 就要額外開銷 60 萬，這還是在不需要買測試機授權的狀況下。然後，假設引進 BizTalk 可以節省 1 / 3 的人日成本，使專案上線時程縮短，如果要剛好達到平衡，BizTalk 的 60 萬開銷就至少必須與這 1 / 3 的人日的成本節省等價。 　　剛提到一個人日一萬，60 萬就等於 60 個人日，也就是當總專案預估時程為 180 個人日的規模，引進 BizTalk Standard 版會剛好達成「開發階段」的成本平衡。這只是單論開發階段，也就是前期需求訪談、系統分析 (SA )、系統設計 ( SD )，與後期上線前測試階段系統整合測試 ( SIT )、使用者接受度測試 (UAT )、驗收流程 ( 文件 ) 都無法節省的狀況，專案規模至少要 235 個人日，也就是 235 萬以上的案子帶入 BizTalk 才有獲利的可能。 　　以上的試算的情境 Scenario 純屬初估，而且是以單一案子導入為前提 ( 不考慮同一個客戶日後有第二案或是第三案在同一台伺服器上利用 BizTalk 額外建置的狀況，所以說做生意要看遠、做遠就是這個意思 ^_^ )。以下提供簡易的公式僅供導入的評估參考： 　　適合導入 BizTalk 的專案規模 = [BizTalk 版本單價] * [CPU 數量] / [導入後預計節省的人日比例 ( 上例中為 1 / 3 ) ] * [130% ( 依比例計算前期與後期-非開發時期的人日成本 )] 　　要提醒幾點，導入後能節省 1 / 3 的開發人力是非常非常樂觀的估計，聽有實務經驗的人說能節省 1 / 5 ~ 1 / 10 就偷笑了。其次，懂 BizTalk 的設計師人員的薪資一定比只會  Coding 的菜鳥工程師來的高出不少，就算不影響廠商給客戶的專案報價，也一定會墊高成本侵蝕利潤，這些都是必須再斟酌的。 ** 微軟的維護費用不是採取一般廠商所使用的按產品售價比例收取維護費用的方式，而是採取買問題點數的做法。 *** 老師張 x 源其實教的還算有水準，雖然有些小錯誤，但還算用心。我現在都不太敢打別人的全名，因為發現大家都喜歡上 Google 查詢自己的名字。之前在中央聽了一場演講，我把對方講者的全名寫在部落格上，沒隔幾天，該篇文章就出現該演講者的回應跟我打招呼...