所有的 IT 組織都需要 Oracle 。但我說的不是那個 Oracle 。

我在工作上所扮演的其中一種角色可以稱為System Architect。和建築師有點類似，這個工作是設計資訊系統架構，從現有系統架構開始，根據組織目標找出不足之處，再找出能補其不足的資訊系統或是元件，以及能和現有系統整合運行的方法，來完成目標系統架構設計。這個工作是一種有機演化的過程，很少有人是從零開始，因為你大概很難有機會碰到有人突然決定要開一家一千人的公司，或是要成立一個幾百人的政府部門，找上你來從無到有設計出整套能支援這一千人的IT架構。絕大多數的情況是要遷就現狀，新舊科技混合。對我們這種人來說，我們最關心的是一個系統的組成元件能不能被乾淨切割，是不是有明確定義的界面。我希望看到像汽車設計一樣，零件能夠被輕易替換，只要界面規格符合，也能用最新升級的零件取代舊零件，提升整體系統的性能而不需要更換整個系統。

可惜這始終只是夢想，因為完全不符合以Oracle為代表的現代ERP/CRM系統的競爭策略。更糟的是因為Oracle併購了太多家公司，我根本懷疑他們沒有時間做好整合，而只是把不同系統硬湊在一起。何況Oracle自己從90年代以來的系統架構，實在也上不了台面。我不否認Oracle的Database的強處，但他們的企業應用軟體實在像科學怪人。

你如果誠心誠意地問，Oracle也會大發慈悲給你看他們11i或R12 EBS的整套系統架構，裏頭也真的有分割出各個元件，像web server, application server, process manager, form engine, authentication / SSO, application business logic, database engine等等。如果真的那麼純淨，那麼理論上你應該可以要求Oracle說：我的機構已經用Microsoft IIS當做web server，用Informix當資料庫系統，並且已經有足夠甚至多餘的硬軟體與人力支援，為了不浪費既有投資，能不能我用IIS和Informix來整合進你們的11i/R12 EBS，既然你們有這麼獨立的系統架構？

用個不算貼切但是容易了解的例子來解釋。就好像有人肚子痛找醫生檢查，醫生說是盲腸炎，但是不能只割盲腸，因為是整套消化系統共同運作，所以要把整套消化系統的所有器官一起換新移植。我們的文明社會雖然不盡理想，但幸好的是醫學發展與電腦軟體業走了完全不同的方向，否則的話現代醫院會和殯葬業結合成為互利共生的聯盟。一旦被診斷是盲腸炎而付不出以百萬美元為單位的費用做器官移植，就只好躺家裏等死了。

當然這個狀況可能是有點強人所難也稍嫌吹毛求疵。換個比較尋常的要求：兩個以上獨立運作的資訊系統間的資料整合。當然我知道會聽到ESB和SOA，我自己也常用這些術語唬人。雖然我自己曾經實際implement過web service也看到過小規模資料交換實作成功的例子，但是兩個以上大型enterprise系統的全面資料整合的成功例子我還真沒看到過。當然我孤陋寡聞，這檔子事就像中樂透，每個人都聽說過有人中獎，但是沒有人直接認識或親眼見到任何一位得主。也很像皇后的貞操，是不是真的只有當事人自己明白，連皇帝都搞不清楚。

我懷疑Oracle不了解自己的系統架構是有根據的。一般在implement一個disaster recovery site的時候，最簡單直接的方法是準備好一組一模一樣的servers環境，然後一台一台從production site把每個硬碟裏的東西copy到相對應的DR server上，然後再configure每台DR server。如果系統設計得夠乾淨，理論上這個configuration的工作只需要更改每台server的IP address與virtual address，也許再加上一些不應該太複雜的修改調整。如果一共有50台server加上不到20 TB的資料庫，整個clone和configure的工作應該能在兩天到一星期內完成。我最近看到的一個計畫，複製一個DR site的估計時間是三到六個月。我覺得不可思議，研究之後才發現原來Oracle 11i的整套環境沒辦法被直接clone，因為Oracle自己沒有能力找出哪些configuration在clone之後要被修改。說得難聽點，他們不知道自己的產品是如何運作的。所以Oracle提出的方法是一台一台server重新安裝所有軟體，依序安裝所有的patch，然後測試。雖然說我還是不能了解為什麼安裝軟體patch在區區不到50台server會要花半年的時間，這個謎也還沒解開。

理想中的商業軟體架構應該要清楚分割成至少三個部分：邏輯控制（business logic），使用者界面，以及資料存取。但是自從有現代資料庫系統以來，所有人都把這三部分混在一起。這樣做的好處是軟體工程師設計程式比較容易，開發與維護的成本都比較低。從廠商的觀點，這也增加了客戶對特定產品的依賴性與更改產品平台的困難性。雖然說這也並不能全怪到Oracle的頭上，因為所有資料庫系統都有自己的trigger, stored procedure以及獨有的程式語言，這些功能也廣泛被程式師用來implement邏輯控制。但Oracle更進一步發揚光大的是導入了form（表格）的概念，讓偷懶的程式師可以直接拿來implement使用者界面。也為了相容性的包袱，Oracle一直到11i還維持了對form的支援。因為這些醜陋的架構，Oracle系統有一大堆他們明說了的或是偷偷放進去的server processes。一個整套的11i EBS要能運作，有幾十個 IP ports 要被開放。我如果夠閒夠無聊的話說不定能找到一些資訊安全的漏洞。

前一兩年的一個project裏我們訪談一位IT部門經理了解她的組織最近進行的主要工作，她提到最大的一件工程是要把一個系統的資料庫部分從Informix換成Oracle，估計要用四五個人做三四個月。這件事有點像見山是山，又不是山，又再是山的不同境界：如果是對IT沒感覺也沒經驗的人，聽了這估計大概毫無反應，因為無從比較。如果是對IT有些經驗的人聽了應該會覺得驚訝，因為理論上只是換掉底層的資料管理存取部分，不應該要那麼大的人力。但是真正實作過這些資料系統的人聽了，也是不會有驚訝的反應，因為更換資料庫是動搖國本的舉動，基本上幾乎是整套系統都要被重寫。那位部門經理在告訴我們人力需求與時間的估計後看我們沒特別反應，一臉挑戰的神情，於是我把那番動搖國本論的說法講給她聽，被引為知己，所以後來的interview才沒被擺臉色看。

因為在IT領域裏有太多說不清也弄不懂，近乎怪力亂神的非理性真實事件，所以我說 IT 管理需要 Oracle ，這個Oracle比那個Oracle便宜得多，而實用性說不定也差不了多少。