企業應用開發和開放原始碼專案 (轉)

企業應用開發和開放原始碼專案 (轉)[@more@]

北京奧捷特通訊技術有限公司技術總監 劉天北

1
開放原始碼運動是家中的不速之客。只是當它已經在業的門庭內安家落戶，成為一股難以驅遣而又不可低估的力量時，傳統軟體企業才如夢初醒，開始認真地體味這位難以測度的來客給整個行業的帶來的變革。
而這位來客自身也在變化之中。隨著開放原始碼運動的不斷深入，它在的各個特定領域都投下了意味深長的身影。目前一個可見的趨勢是，開放原始碼的潮流已經越出了操作、管理系統、等系統開發領域，開始在企業應用開發這塊新的領地尋找它的市場份額。像在其他地方一樣，人們的神經再一次受到攪動。應該怎樣面對這股潮流？它會這個領域的生態鏈造成怎樣的影響？企業應用的開發者和最終都在暗自思忖這個問題。

我們首先勾勒出企業應用開發行業的現狀。什麼是企業應用？這個問題甚至連Martin Fowler本人都覺得難以回答。在經典之作《Patterns of Enterprise Application Architecture》中，他只是滿足於舉出若干常見的企業應用系統作為例子，並沒有提供更一般的概念。如果容忍一個模糊的定義，也許我們可以把企業應用考慮為“服務於商業目的，處理企業業務資訊、資料的軟體系統”。企業應用區別於系統平臺、控制系統、個人桌面應用、嵌入式應用等軟體系統。常見的訂單/預訂處理、供應鏈管理（SCM）、財務/資產管理是企業應用的明顯例子。
現代企業隨著自身發展，不少業務流程需要專門的資訊系統處理，藉以提高自動化程度、資訊傳遞速度、資訊性以及資訊處理/分析能力。這是企業應用得以產生的緣由。因此，從需求角度說，企業應用的核心在於企業業務的電算化。能否透過軟體系統，成功地實現企業需要的業務流程，就成為企業應用開發成敗的關鍵。

企業要建設自己的業務應用系統，可選擇方式主要有：
1. 購買現成產品
2. 自行開發
3. 委託開發商專項開發
其中2需要企業內部具備較強的開發團隊，這對於多數企業來說並不現實。而1則要求現成產品直接完全地滿足企業業務需要。由於不同的企業各具面目，同一企業在不同的發展時期需求也不一致，因此不加變化的現成產品也很難符合企業需求。所以目前企業開發的一般做法，是介乎1和3之間的折衷方案：軟體產品供應商提供“業務平臺”產品，再由開發商做“定製”開發。所謂“業務平臺”，是指獨立於特定業務流程，但封裝了該領域、該行業的一般業務模型的軟體系統。所謂“定製開發”，是指基於上述業務平臺，透過從資料到開發的繁簡不同的形式，實現符合特定企業需要的應用系統。目前我們熟悉的電子商務、企業網站內容管理、ERP、SCM、企業管理資訊系統（MIS）等領域都有大量軟體產品供應商提供平臺產品。根據企業現狀和經營戰略，諮詢公司給出目標業務流程和實施規劃，由系統整合商和軟體開發商完成系統搭建和實際實施。

2
上面談的是企業應用開發的一般形式。這種形式究竟有何弊端？開放原始碼軟體能為此帶來多大的變革？不少人只是把開放原始碼軟體作為降低總體擁有成本（TCO）的一種廉價選擇，而我將在下面論證：開放原始碼軟體在企業應用開發中的具有更重要的作用，即降低專案的風險，提高客戶對專案的控制能力。
企業應用開發具有相當高的複雜度和風險。據資料顯示，1998年美國企業應用專案不成功的比率高達75％，其中28%的專案最終被撤銷，40%導致專案週期被無限拖長或資金超出預算。目前國內軟體業中，企業應用開發的失敗率也居高不下，最近的幾次大型ERP專案的可悲失敗就是明證。
為什麼失敗在這個領域特別盛產？我認為，這往往和參與者對企業應用開發的認識有關。一方面，在初始規劃階段，企業客戶對於系統需求常常只具有模糊的一知半解，比如說，客戶會要求開發一套“電子商務系統”，卻無法給出具體的業務細節；而在系統開發成型、投入使用一段時間之後，隨著使用者對系統的熟悉，許多需求變更和全新的業務需求才會浮現出來。另一方面，平臺供應商為了推介產品，往往誇大其靈活性和可擴充套件性，給客戶一種只需簡單、配置就能實現業務需要的錯覺；而負責具體實施的開發商為了縮短實施週期，又傾向於儘量限制客戶的需求變更，力圖達到“徹底設計（up-front design）”，即，一勞永逸地完成整個系統的分析、設計，以最短的時間獲得最理想的系統。
由此，供應商和開發商向客戶許諾的永遠是一個完美的系統和快捷的實施計劃，而實際的實施過程卻肯定是漫長的、不斷被客戶反饋和需求變更打亂的。這種樂觀估計和悲觀實際之間的反差，我認為，是造成企業應用開發的一個重要因素。

恰恰也是在這裡，開放原始碼軟體能戲劇性地改變原有的商業動力學和開發，從而給這一領域帶來革命性的變化。請考慮這樣一個隱喻：父母為發育期的小孩兒置辦衣服，假設這個小孩兒的身材特殊，沒有成衣能夠妥帖合適，只能定做；如果衣料足夠便宜的話，這裡的問題也容易解決，只需找到手藝合格的裁縫常年服務就是了——但是，假設當地的衣料又非常稀缺，只有專門店鋪才能買到，甚至這些店鋪還要強調，必須一次購買這個小孩兒一生的所有衣料。這樣，付清昂貴衣料費用之後，父母就很難再為裁縫撥出合理的預算——甚至會動念頭：乾脆“一步到位”地做一套大衣服，讓孩子穿一輩子！
透過這個荒誕而辛酸的故事，我們能發現企業應用開發困境的癥結：付給平臺供應商的過高的初期投資（initial investment）蠶食了後續開發的預算，但一個企業應用系統又是一個“身材特殊”又處在發育期的孩子，不可能用現成軟體（“成衣”）簡單的打發掉，更不可能透過一次實施的系統就完全解決今後遇到的所有問題。但是，如果不依靠可重用的平臺產品（“衣料”），每次都從頭開始開發，也會大大降低開發，延長交付時間。是的，答案已經呼之欲出：開放原始碼軟體正是這裡急需的廉價衣料。
由於採用開放原始碼軟體無需在專案初期就支付高額的平臺軟體費用，在這種開發模式下，“軟體”與“服務”之間就真正實現了等同。工作的重心轉移到客戶與軟體開發商之間頻繁的互動、反饋上。企業客戶可以把一個軟體專案考慮為一種常年的服務，其中包括週期性釋出（release）和迭代（iteration）過程，每次釋出可以短至幾周，集中於解決企業當前面對的最緊迫問題。受益於低廉的初期投資和的釋出週期，企業客戶能最大程度的避開前面談到的風險，並最大程度地更改原先的決策和設計。具體地說，在專案進行的任何時刻，客戶都能夠以很小的代價選擇：
* 更改業務需求。現代企業自身的業務模式處在不斷變化之中；系統的使用者由於認識的深入，也會提出與原先設計不同的業務流程和業務模型。這裡，原有的開放好比是形成珍珠的那個沙粒，透過在專案中不斷的塑造、發展，形成最符合需要的系統。與此相比，封閉原始碼的平臺軟體只能按照設計時開放的介面加以開發，其靈活性遠遜於前者。
* 擴充套件業務領域。企業應用的邊界往往是模糊的。比如說，很多客戶要求開發“電子商務系統”，但其功能需求卻遠不限於網上購物、產品管理、訂單處理等內容，還會包括供應鏈管理、財務/資產管理、網站內容管理甚至客戶關係管理的模組，其中每一個模組都有專門的領域軟體完成。開放原始碼軟體的自由特性，能允許客戶在最適合的時候，選用多個不同的開放原始碼軟體，實現“原始碼級別上”的應用整合。與此相比，封閉原始碼產品或者選擇“大而全”的“企業套件”（同時又暗示了更高的初期投資），或者透過專門的企業應用整合方案完成基於介面的整合（效果再一次遠遜於開放原始碼軟體）。
* 推遲專案開發或放棄專案。由於初期投資遠為低廉，客戶同樣可以在自己認為最恰當的時候做出推遲或放棄專案的選擇，同時仍然享用至此為止開發的成果。

簡言之，將開放原始碼軟體引入企業應用開發的，遠不只是成本上的考慮，而更多地應該關注它與漸進式（emergent）開發模式之間的親和性。漸進式策略推崇最小的初期投資、透過多次釋出和反饋完善系統，推崇主動迎接“變化”而不是拒斥甚至否認變化的價值。與之相對的策略是，透過包羅永珍的平臺產品和一步到位的實施鎖定所有變化的可能性。這兩種策略在軟體開發的不同領域應該各有勝場，但針對企業應用系統來說，我認為前者對這裡湧動的風險具有更強的抵抗力。
在企業應用的各個專門領域，比如門戶/內容管理、電子商務、電子辦公、ERP、SCM、CRM等等方面，都已湧現出大量成熟的開放原始碼產品。對於渴求提高靈活度、避免風險的開發專案，採用開放原始碼企業應用產品已經不再只是幻想，而是正被很多企業成功實踐著的現實選擇。

3
那麼，對於一個規劃搭建企業應用系統的企業，一旦選擇使用開放原始碼產品，又怎樣才能確保專案成功呢？我認為至少有以下幾點重要考慮：
* 策略和態度
如上所述，對於企業應用開發，過分樂觀的、速勝的態度肯定是有害的。應該把企業應用專案視為一個長期的、謹慎的過程，不少時候甚至要應用到“退一步，進兩步”的策略。應該從特定問題尤其是業務瓶頸入手形成應用，而無需追求面面俱到，或者從“電子商務”或“ERP”的抽象概念出發確定系統功能。
* 開發商
開發商的和素質對於企業應用開發來說也是至關重要的。合格的開發商，應該對客戶所處的行業有較深的理解和開發經驗，對選用的開放原始碼產品非常熟悉——不少選用開放原始碼產品開發的廠商本身也參與了該產品的開發，或者是經過開放原始碼專案組織的特別，這些對於實際專案來說都是重要優勢。另外，開放商應該能認同軟體開發作為服務的觀念，能夠採取擁抱而不是拒斥變化的態度。
* 產品
面對日益豐富的產品，毫無疑問應該選擇其中最成熟的（而不是功能最多的）。一般開源軟體都有較完善的使用者社群，在考察過程中，應該關注這些社群中的使用者問題，尤其看對特定問題的回答速度。不同開源軟體形成的企業應用平臺之間也有明顯的水平差距。成熟的平臺往往已經包括了大量的可重用，對認證/、工作流、報表、資料快取等技術層面都形成了完整的解決方案。優先考慮類似的平臺產品能夠顯著地提高開發速度。
* 規劃
漸進式開發強調小型的、經常性的釋出。基於這一點，在專案規劃中，應該保持概要性的長期目標和明確的短期目標。短期目標由企業目前需求最緊迫的一組系統功能集構成。一般的做法是，每次釋出實現哪些功能，各個功能之間的優先度由客戶決定，開發商確定完成這些功能需要的時間。
* 反饋
漸進式開發需要開發商和客戶之間的緊密合作與反饋，藉此隨時調整開發方向，確定實現細節。因此在每一發布週期的初始階段，開發商無需花費太長時間過度設計（over-design），而是透過客戶的及時反饋確定開發結果是否合格。一個可考慮的做法是，一位客戶方代表長期與開發團隊共同辦公，由此能使客戶的反饋機制更加制度化。
* 許可問題
與很多人的設想不同，開放原始碼產品並不意味著完全免費——雖然價格往往是低廉的。不同的開源專案包含的許可方式各有差別，其中常見的如GPL（ General Public License），LGPL（GNU Lesser General Public License），MPL（ Public License）， License，Open Software License等，每一種都包含著較為嚴格的使用條款和特定的法律隱含。尤其是在專案開發時，不僅了開放原始碼元件庫，而且修改了原有程式碼的情況下，更應該徹底研究相關軟體的授權模式，以最終確定開發成果的版權歸屬。

最後，也許該談談什麼樣的企業應用專案不適合採用上面談到的開發模式。我能想到的大致有這樣幾種情形：
* 企業的需求非常簡單、固定，並且已經有現成產品恰好滿足這一需求。對於這種情形，採用現成產品並不會造成導致更大的風險。客戶可以完全依靠軟體供應商提供簡單的服務和維護。單純的財會系統是這方面的明顯例子。
* 要求專案在極短期內完成。這會使漸進式的開發策略變得完全不可能。
* 專案的初期預算過於充裕。當然，嚴格地說，預算永遠不應該“過於”充裕。但這卻是不少國內企業的實情：一筆一次性幷包含時限的撥款，如果數目過大，當然不適合選用廉價的方案——但我們可以料想，這樣的專案無論怎樣選型，實施的風險都不會降低。