軟 件 之 死

1999年，計算機科學家布魯克斯（Frederick Phillips Brooks,Jr.）以近70歲的“高齡”獲得了圖靈獎——這位數十年來蜚聲世界的軟硬件專家、教育家曾在其《沒有銀彈》（1986）一文中提出了一個迄今為止尚未被打破的著名論斷：“沒有一種單純的技術或管理上的進步，能夠獨立地承諾在10年內大幅度地提高軟件的生產率、可靠性和簡潔性”。布魯克斯用形象的譬喻來論述軟件工程中存在的“陷阱”——“在所有恐怖民間傳說的妖怪中，最可怕的是人狼，因為它們可以完全出乎意料地從熟悉的面孔變成可怕的怪物”，而“大家熟悉的軟件項目具有一些人狼的特性（至少在非技術經理看來），常?？此坪唵蚊髁说臇|西，卻有可能變成一個落后進度、超出預算、存在大量缺陷的怪物”。驚悚故事里，人們只有用銀彈（銀質子彈）才能消滅人狼，而布魯克斯認為，在軟件工程中，“沒有銀彈”，沒有一種能夠遏制軟件向“怪物”變異、同時還可大幅提升開發效率和產品質量的武器。
某種意義上，布魯克斯的觀點（抑或預言）是正確的——如果不能對基于代碼的軟件體系進行徹底的革新，那么在今后10年（甚至更久）的時間里，我們仍會在繁復迂曲的代碼迷宮中遭遇“怪物”。
一、大型企業級應用軟件已經死亡
2003年8月底，一年一度的DCI CRM展會在紐約Javitz中心舉行，參加展會的有21%是來自全球性企業（平均有6600多名員工）的CxO，60%是這些企業的中層管理人員。作為CRM市場的預言家和領頭羊，Siebel總裁Tom Siebel每年的主題演講都是大家翹首以待的。但是，這一年Tom Siebel的演講標題卻讓與會的所有人震驚：“CRM之死”。
“CRM產品已經沒有市場了?！备鶕iebel的預計：IT部門將不再購買通用的CRM軟件，然后再按照自己內部的業務流程對軟件進行調整了。如果Siebel的預見是正確的，那么CRM市場的終結也意味著企業關系管理市場、供應鏈、人力資源管理市場，以及其他大型應用軟件市場的終結。通過市場調查，我們發現，國際主流的幾家企業管理軟件廠商，包括SAP、PeopleSoft、Siebel等，近幾年來的營收一直在容與徘徊，而利潤更有下降之勢。當前，幾乎每一種大型的企業級應用軟件都在遭遇著深重的危機，以至于出現瀕危甚至垂死的癥狀。美國國家標準和技術研究院的一份研究報告顯示：“占據世界軟件銷售額85%的是大型的專用軟件，而其開發的失敗率卻高達70%！”
大型企業級應用軟件正在走向死亡，它表現在各個方面。
首先，以傳統方式開發的大型企業級應用軟件難以突破布魯克斯的“沒有銀彈論”，找不到軟件工程或者項目管理的方法，能夠大幅度提高應用軟件的開發效率——開發周期長、開發費用高，實施費用超支和工期延長，已經司空見慣。更加可怕的是，隨著企業的環境和需求的不斷變化，“建成即成閑置”，形成軟件工程的災難。
其次，客戶對大型企業級應用軟件的諸多期望幾乎無法得到完全滿足。例如，客戶期望實現業務集成和協作，在協作基礎上構建出高效的企業應用體系；客戶期望對供應鏈上的信息進行及時傳遞與處理，以實現更快捷的市場響應能力；客戶期望能夠快速實施和低成本部署滿足個性化需求的軟件系統，并適應未來商業環境的變遷……一句話，客戶對軟件功能和性能的要求越來越高。在這種市場需求下，要實現企業各個層次的集成，必然會導致軟件在規模、復雜度、功能上的空前擴張。
不僅如此，企業級應用的危機還表現為系統部署運行和維護的“危機”。應用環境
從單機應用，過渡到客戶機/服務器的環境，再過渡到瀏覽器/服務器的環境，并進一
步向多層式（N-tier）分布式系統的網絡環境遷徙。今天，基于互聯網的企業級應用要求軟件實現跨空間、跨時間、跨設備、跨用戶的協同，軟件處于極度復雜的異構環境中，這種情形下，以傳統的軟件開發思路應對當前的危機就只能是刻舟求劍、緣木求魚。
類似的危機，在中國表現得尤為突出。中國是一個迅速發展和不斷轉型的國家，中國企業的形態因此而更復雜，中國企業的改革變化空間因此而更大。正因如此，中國企業級應用開發和運營的危機也就更為嚴重，企業信息化的風險更多，失敗率更高。
我認為，正是傳統的軟件體系醞釀和加重了企業級應用的危機。
軟件體系主要包括軟件結構和生產方式。傳統的大型企業級應用軟件的主要特點是：編碼式的開發方式和一次開發持續運行的應用軟件——編碼式的開發方式，使得快速開發企業級應用軟件的愿望難以實現；一次開發持續運行的方式，則導致了軟件的僵化和瀕?！苊黠@，這種軟件不但難以適應客戶需求的變化，而且每次修改都必須在代碼層上推倒重來，因此造成了效率的降低和資源的糜費。
傳統的軟件體系正在內外交困的重重危機之下走向死亡！
 
二、探究軟件死亡之因
互聯網時代給企業帶來了無限的想象空間。企業的營銷模型由傳統的4P（產品、定價、地點、促銷），引領出基于互聯網的ABC模型（任何時間任何地點、基于網絡、溝通營銷）。企業系統已經從部門級、企業級，發展到社會級的實時在線的應用，應用的范圍在深度、廣度上都發生了質的變化。
世易時移，變“法”宜矣——當應用需求已從部門、企業上升到社會的層次，我們必須重新考察企業級應用的需求。
一方面，用戶需要個性的軟件。市場經濟條件下，成功的企業，一定是個性化的，有獨特的管理方式和企業文化，以此區別于競爭對手，以贏得市場空間。企業的價值一定是個性化的，企業信息化必須從個性出發：企業級應用軟件的實施應該充分體現和放大企業的與核心競爭力相關聯的個性價值，從而使企業的價值得以提升，這才應該是信息化對企業的核心貢獻。如果一個信息化項目不僅不能凸顯出企業的個性——反而加劇了企業與同行的“價值同質化”，那就可以判定，這個信息化項目未能獲得成功。
另一方面，企業需要靈活的軟件。企業的生命周期是一個動態變化的過程。在每個成長階段，企業都需要有所區別的政策和管理；隨著環境的變化，企業的業務和管理方式要相應地發生變化；再加上隨著企業概念的外延擴展，如今已變成了一個涵蓋供應商、客戶以及各種合作伙伴的虛擬組織。因此，企業對靈活性或者彈性的需求變得十分重要，相應的，企業級應用軟件也需要更高的彈性。
目前，傳統的企業級應用軟件產品往往采用兩種典型的交付模式。
其一，以套裝軟件加上二次開發交付客戶。此種方式主體上固化了軟件的功能結構，只留一小部分參數配置。這樣的軟件在具體應過過程中還需要大量的二次開發，即使這樣，仍然時常不能滿足企業的需求。應用軟件廠商通常會大肆宣揚自己的產品包含“行業最佳業務實踐”，并以“管理專家”的身份對客戶的管理模式強行變革，以適應這種標準化的“行業最佳業務實踐”。然而每個企業所處的競爭環境千差萬別，企業的戰略、核心競爭力亦有所不同，企業只有保持自己鮮明的個性，并對環境的變化保持高度的柔性，隨時準備調整管理策略，才是生存和發展的關鍵。試問哪里有這種“放之四海而皆準”的管理真理能解決所有企業的問題？由此可見，所謂的“行業最佳實踐”必然是以抹煞企業特征和不適應未來發展需要為代價而實現的?！伴_盒即用”的方式往往具有良好的系統架構和穩定的系統性能，能夠適應一定領域的市場需求，但很難滿足不同用戶的個性化需求。
其二，為客戶從代碼級開發定制的軟件系統。這種定制開發方式，基本上是從客戶的個性化需求出發，進行軟件定制。誠然，這種定制開發的軟件系統能夠滿足特定用戶的大部分需求，但開發者總是很難全面考慮軟件的擴展性、穩定性等架構因素，產品因此而不能快速適應客戶的需求變化，同時也很難提高開發的效率。許多軟件公司，陷身于在軟件定制開發的泥潭中無法自拔——軟件知識得不到有效的積累，成本又居高不下，這構成軟件公司或者是系統集成公司的發展瓶頸，同時也在一定程度上妨害了軟件產業的發展。
顯而易見的，上述兩種軟件開發方式，都不能解決軟件隨需應變的問題——軟件開發方式效率低下，軟件結構死板僵化。在這個企業形態不斷變化、企業外延不斷擴展、企業的環境不斷變遷、企業的業務不斷調整的時代，這種以一次開發持續使用為特征的軟件已日顯陳腐和落伍。
 
三、尋找銀彈
“沒有銀彈！”布魯克斯如是說——真的就沒有任何一種技術或管理上的進步，能夠獨立承諾大幅度提高軟件開發的生產率、可靠性和簡潔性嗎？
確實，直到上個世紀末，20多年以來，軟件行業的生產效率依然沒有數量級的提高，軟件在幫助傳統行業提高效率的同時，自身卻成為最原始意義上的“手工行業”。雖然，許多大型的企業級應用軟件采取了大規模的生產和協作，但是這種軟件往往開發時間長，效率低，無法動態調整，無法由僵硬變得靈活和敏捷。軟件業也需要脫離手工作坊時代和工業時代，而走進敏捷定制的后工業時代。
軟件生產方式的落后，加之需求和環境的進一步復雜，使得傳統軟件的生產方式，不但不能緩解軟件工程的危機，而是處于不斷加深的危機之中?；ヂ摼W應用時代，企業期望的是以更低的成本，更快的速度，獲得高質量、高靈活性的隨處可得的軟件。顯然，依靠傳統軟件業落后的生產方式和僵化的軟件結構，無法面對互聯網應用的挑戰。矛盾在不斷加劇，危機在不斷加深。
我的看法是，傳統的軟件工程的方法無法解決“軟件危機”的問題；換言之，不要期望從傳統的軟件體系中找到真正的“銀彈”。
僵化的軟件結構無法產生銀彈——從代碼級做起的軟件，強調功能實現，天生具有龐大、僵化、無法適應變化的缺點。編碼式的軟件，無論是采取何種方式，都無法真正實現“敏捷定制”。代碼級的編程、代碼級的維護使得效率不可能真正地提高。
落后的生產方式無法產生銀彈——從代碼級做起的軟件，經歷了大量重復性的需求分析、設計、編碼、測試、維護工作，生產周期長、軟件復用性差。依靠這樣的生產方式，生產效率如何提高？又如何能保證軟件的高質量？
既然傳統的軟件體系是導致軟件危機的根本原因，固守這種軟件體系，軟件業將永遠無法擺脫“軟件危機”的噩夢，更無法實現軟件大規模敏捷定制的夢想，那么，那顆用以制服“軟件人狼”的銀彈究竟在何方？

原文轉自：http://www.anti-gravitydesign.com