http://dev.csdn.net/article/28/28508.shtm
http://dev.csdn.net/article/28/28734.shtm
http://dev.csdn.net/article/28/28737.shtm
軟件的涅磐<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
作者：黃柳青
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產品已經沒有市場了。”根據Siebel的預計：IT部門將不再購買通用的CRM軟件，然後再按照自己內部的業務流程對軟件進行調整了。如果Siebel的預見是正確的，那麼CRM市場的終結也意味着企業關係管理市場、供應鏈、人力資源管理市場，以及其他大型應用軟件市場的終結。通過市場調查，我們發現，國際主流的幾家企業管理軟件廠商，包括SAP、PeopleSoft、Siebel等，近幾年來的營收一直在容與徘徊，而利潤更有下降之勢。當前，幾乎每一種大型的企業級應用軟件都在遭遇着深重的危機，以至於出現瀕危甚至垂死的症狀。美國國家標準和技術研究院的一份研究報告顯示：“佔據世界軟件銷售額85%的是大型的專用軟件，而其開發的失敗率卻高達70%！”
大型企業級應用軟件正在走向死亡，它表現在各個方面。
首先，以傳統方式開發的大型企業級應用軟件難以突破布魯克斯的“沒有銀彈論”，找不到軟件工程或者項目管理的方法，能夠大幅度提高應用軟件的開發效率——開發週期長、開發費用高，實施費用超支和工期延長，已經司空見慣。更加可怕的是，隨着企業的環境和需求的不斷變化，“建成即成閒置”，形成軟件工程的災難。
其次，客戶對大型企業級應用軟件的諸多期望幾乎無法得到完全滿足。例如，客戶期望實現業務集成和協作，在協作基礎上構建出高效的企業應用體系；客戶期望對供應鏈上的信息進行及時傳遞與處理，以實現更快捷的市場響應能力；客戶期望能夠快速實施和低成本部署滿足個性化需求的軟件系統，並適應未來商業環境的變遷……一句話，客戶對軟件功能和性能的要求越來越高。在這種市場需求下，要實現企業各個層次的集成，必然會導致軟件在規模、複雜度、功能上的空前擴張。
不僅如此，企業級應用的危機還表現爲系統部署運行和維護的“危機”。應用環境從單機應用，過渡到客戶機/服務器的環境，再過渡到瀏覽器/服務器的環境，並進一步向多層式（N-tier）分佈式系統的網絡環境遷徙。今天，基於互聯網的企業級應用要求軟件實現跨空間、跨時間、跨設備、跨用戶的協同，軟件處於極度複雜的異構環境中，這種情形下，以傳統的軟件開發思路應對當前的危機就只能是刻舟求劍、緣木求魚。
類似的危機，在中國表現得尤爲突出。中國是一個迅速發展和不斷轉型的國家，中國企業的形態因此而更復雜，中國企業的改革變化空間因此而更大。正因如此，中國企業級應用開發和運營的危機也就更爲嚴重，企業信息化的風險更多，失敗率更高。
我認爲，正是傳統的軟件體系醞釀和加重了企業級應用的危機。
軟件體系主要包括軟件結構和生產方式。傳統的大型企業級應用軟件的主要特點是：編碼式的開發方式和一次開發持續運行的應用軟件——編碼式的開發方式，使得快速開發企業級應用軟件的願望難以實現；一次開發持續運行的方式，則導致了軟件的僵化和瀕危——很明顯，這種軟件不但難以適應客戶需求的變化，而且每次修改都必須在代碼層上推倒重來，因此造成了效率的降低和資源的糜費。
傳統的軟件體系正在內外交困的重重危機之下走向死亡！
二、探究軟件死亡之因
互聯網時代給企業帶來了無限的想象空間。企業的營銷模型由傳統的4P（產品、定價、地點、促銷），引領出基於互聯網的ABC模型（任何時間任何地點、基於網絡、溝通營銷）。企業系統已經從部門級、企業級，發展到社會級的實時在線的應用，應用的範圍在深度、廣度上都發生了質的變化。
世易時移，變“法”宜矣——當應用需求已從部門、企業上升到社會的層次，我們必須重新考察企業級應用的需求。
一方面，用戶需要個性的軟件。市場經濟條件下，成功的企業，一定是個性化的，有獨特的管理方式和企業文化，以此區別於競爭對手，以贏得市場空間。企業的價值一定是個性化的，企業信息化必須從個性出發：企業級應用軟件的實施應該充分體現和放大企業的與核心競爭力相關聯的個性價值，從而使企業的價值得以提升，這才應該是信息化對企業的核心貢獻。如果一個信息化項目不僅不能凸顯出企業的個性——反而加劇了企業與同行的“價值同質化”，那就可以判定，這個信息化項目未能獲得成功。
另一方面，企業需要靈活的軟件。企業的生命週期是一個動態變化的過程。在每個成長階段，企業都需要有所區別的政策和管理；隨着環境的變化，企業的業務和管理方式要相應地發生變化；再加上隨着企業概念的外延擴展，如今已變成了一個涵蓋供應商、客戶以及各種合作伙伴的虛擬組織。因此，企業對靈活性或者彈性的需求變得十分重要，相應的，企業級應用軟件也需要更高的彈性。
目前，傳統的企業級應用軟件產品往往採用兩種典型的交付模式。
其一，以套裝軟件加上二次開發交付客戶。此種方式主體上固化了軟件的功能結構，只留一小部分參數配置。這樣的軟件在具體應過過程中還需要大量的二次開發，即使這樣，仍然時常不能滿足企業的需求。應用軟件廠商通常會大肆宣揚自己的產品包含“行業最佳業務實踐”，並以“管理專家”的身份對客戶的管理模式強行變革，以適應這種標準化的“行業最佳業務實踐”。然而每個企業所處的競爭環境千差萬別，企業的戰略、核心競爭力亦有所不同，企業只有保持自己鮮明的個性，並對環境的變化保持高度的柔性，隨時準備調整管理策略，纔是生存和發展的關鍵。試問哪裏有這種“放之四海而皆準”的管理真理能解決所有企業的問題？由此可見，所謂的“行業最佳實踐”必然是以抹煞企業特徵和不適應未來發展需要爲代價而實現的。“開盒即用”的方式往往具有良好的系統架構和穩定的系統性能，能夠適應一定領域的市場需求，但很難滿足不同用戶的個性化需求。
其二，爲客戶從代碼級開發定製的軟件系統。這種定製開發方式，基本上是從客戶的個性化需求出發，進行軟件定製。誠然，這種定製開發的軟件系統能夠滿足特定用戶的大部分需求，但開發者總是很難全面考慮軟件的擴展性、穩定性等架構因素，產品因此而不能快速適應客戶的需求變化，同時也很難提高開發的效率。許多軟件公司，陷身於在軟件定製開發的泥潭中無法自拔——軟件知識得不到有效的積累，成本又居高不下，這構成軟件公司或者是系統集成公司的發展瓶頸，同時也在一定程度上妨害了軟件產業的發展。
顯而易見的，上述兩種軟件開發方式，都不能解決軟件隨需應變的問題——軟件開發方式效率低下，軟件結構死板僵化。在這個企業形態不斷變化、企業外延不斷擴展、企業的環境不斷變遷、企業的業務不斷調整的時代，這種以一次開發持續使用爲特徵的軟件已日顯陳腐和落伍。
三、尋找銀彈
“沒有銀彈！”布魯克斯如是說——真的就沒有任何一種技術或管理上的進步，能夠獨立承諾大幅度提高軟件開發的生產率、可靠性和簡潔性嗎？
確實，直到上個世紀末，20多年以來，軟件行業的生產效率依然沒有數量級的提高，軟件在幫助傳統行業提高效率的同時，自身卻成爲最原始意義上的“手工行業”。雖然，許多大型的企業級應用軟件採取了大規模的生產和協作，但是這種軟件往往開發時間長，效率低，無法動態調整，無法由僵硬變得靈活和敏捷。軟件業也需要脫離手工作坊時代和工業時代，而走進敏捷定製的後工業時代。
軟件生產方式的落後，加之需求和環境的進一步複雜，使得傳統軟件的生產方式，不但不能緩解軟件工程的危機，而是處於不斷加深的危機之中。互聯網應用時代，企業期望的是以更低的成本，更快的速度，獲得高質量、高靈活性的隨處可得的軟件。顯然，依靠傳統軟件業落後的生產方式和僵化的軟件結構，無法面對互聯網應用的挑戰。矛盾在不斷加劇，危機在不斷加深。
我的看法是，傳統的軟件工程的方法無法解決“軟件危機”的問題；換言之，不要期望從傳統的軟件體系中找到真正的“銀彈”。
僵化的軟件結構無法產生銀彈——從代碼級做起的軟件，強調功能實現，天生具有龐大、僵化、無法適應變化的缺點。編碼式的軟件，無論是採取何種方式，都無法真正實現“敏捷定製”。代碼級的編程、代碼級的維護使得效率不可能真正地提高。
落後的生產方式無法產生銀彈——從代碼級做起的軟件，經歷了大量重複性的需求分析、設計、編碼、測試、維護工作，生產週期長、軟件複用性差。依靠這樣的生產方式，生產效率如何提高？又如何能保證軟件的高質量？
既然傳統的軟件體系是導致軟件危機的根本原因，固守這種軟件體系，軟件業將永遠無法擺脫“軟件危機”的噩夢，更無法實現軟件大規模敏捷定製的夢想，那麼，那顆用以制服“軟件人狼”的銀彈究竟在何方？
軟件之變
史前史中，沒有別的場景比巨獸在焦油坑中垂死掙扎的場面更令人震撼。上帝見證着恐龍、猛獁象、劍齒虎在焦油中掙扎。它們掙扎得越是猛烈，焦油糾纏得越緊，沒有任何猛獸足夠強壯或具有足夠的技巧，能夠掙脫束縛。它們最後都沉到了坑底……過去幾十年的大型系統開發就猶如這樣一個焦油坑，很多大型和強壯的動物在其中劇烈地掙扎。他們中大多數開發出了可運行的系統——不過，其中只有非常少數的項目滿足了目標、時間進度和預算的要求。各種團隊，大型的和小型的，龐雜的和精幹的，一個接一個淹沒在了焦油坑中……
布魯克斯《人月神話》
結構之變
我們來解剖一個死亡的大型應用軟件系統。在一個有幾千員工的企業，在投入了千萬級的資金和兩年時間之後，一個企業級的業務支撐系統剛剛上線運行。可是企業的組織結構、流程、人員在軟件開發的過程中已經發生變化，而且還在變化！軟件開發商必須修改軟件。軟件有一千多頁的設計文檔，上百萬行的代碼。“有經驗”的程序員跳過了設計思路而直接編寫程序源代碼。久而久之，軟件的設計文檔還“刻舟求劍”的停在原地，源代碼已經與當初的圖示思路大相徑庭。實際上，任何事物有了“百萬級”的因子之後，都是沒有辦法直接管理的。上百萬行軟件源代碼幾乎無人能懂，並且極難改動和維護，軟件因此變成了掙扎於焦油坑中的巨大怪獸。
要解決大型應用軟件的難題，必須首先解決軟件的結構問題。彙編語言的出現，使軟件告別了“0”與“1”組成的“天書”。其後軟件的車輪走過高級語言、面向對象、面向服務等不同階段。直至面向構件的軟件技術出現，軟件技術人員將掙脫面對大段冗長代碼的泥潭。在面向構件的軟件中，一個應用系統不是由上百萬行的代碼組成的，而是由幾千個構件經過可視化組裝而成的。系統的複雜度有了數量級的下降，而圖形化的組裝使軟件跟應用設計合二爲一。
作爲對代碼式軟件體系的顛覆和革新，面向構件的軟件體系首先從表達層面填平了代碼表達與圖形化知識表達兩者間的鴻溝，徹底消除了軟件源代碼與軟件設計思路之間的斷層。主要優勢在於：用戶的需求改變可以直接通過構件裝配式的圖形化設計思路得以體現；永久的屏蔽軟件代碼層，可以讓軟件架構師和程序員跳出傳統開發模式的侷限，只需和圖形化的構件打交道，在徹底進化軟件表達的同時，也使其改動與維護易如反掌。
在面向構件的軟件思路下，簡潔表達帶來了簡潔的軟件更新——“隨需應變”不再只是一句口號。面向構件的軟件體系，鬆散耦合的構件組裝方式，系統不同部件之間的低關聯度。重複使用經過考驗的構件，可視化的知識表達，系統複雜指數的數量級下降，也使得企業應用更爲成熟更爲穩定。
面向構件的趨勢正爲軟件行業的預言家所看好。在《軟件成功的奧祕》一書中，麥肯錫四位資深專家Detlev Hoch、Cyriac Roeding、Gert Purkert、Sandro Lindner經過對全球一百家最成功的軟件公司、450位頂尖領導人物的訪談之後，認爲面向構件技術是軟件行業未來前景中的核心部分，軟件行業提高生產率的主要來源。引用軟件專家Brad Cox的話說，面向構件的技術是軟件行業的銀彈！
追溯歷史，面向構件的技術理念淵源已久。Mcllroy在1968年提交NATO軟件工程會議的論文《大量生產的軟件構件》中，首次提出了“軟件組裝生產線”的思想。早在20世紀九十年代初，中國科學院的楊芙清院士就提出了構件化軟件體系的設想。那以後，採用構件技術實現軟件複用，採用“搭積木”方式生產軟件，就成爲軟件開發人員長期以來未能實現的夢想。海內外學者不謀而合對面向構件技術展開的大量探索，歸根結底是爲了解決軟件開發過程中“重複發明輪子”的問題，如何能讓同一個輪子也可以用於不同的車。這恰恰印證了中國的一句老話：殊途同歸。
生產方式之變
中國正在製造一切。在美國人、歐洲人、日本人看來，的確如此。從打火機、兒童玩具、服裝鞋帽到鋼琴、計算機主板、飛機配件，我們的政府從不諱言製造業已成爲中國經濟發展的支柱產業。試想一下，如果能充分借鑑並汲取製造業的發展經驗，軟件產業會不會在不久的將來成爲驅動中國經濟增長的又一“強力引擎”？
其實，就如同製造汽車，軟件的開發完全可以構築在“構件組裝”的模式之上；這樣，軟件技術人員可以擺脫“一行行寫代碼”的低效環節，直接進入“一塊塊搭配構件”的更高階段。不僅如此，面向構件的技術徹底打破了原有軟件基於代碼層開發的固有模式。“構件”取代了“代碼”成爲了軟件的“信息原子”（基本結構單元）。隨着構件庫的不斷充實和完善，靈活的構件、集成式的軟件結構將把搭積木式的“組裝軟件”從夢想變爲現實。
面向構件的產品不僅在客戶需求吻合度、上線時間、軟件質量上領先於同類產品，大大提高了項目的成功率。而且，軟件的開發和維護變得空前簡單，客戶可以隨時隨地獲取應對商業環境變化和IT技術變化的最新信息化方案，真正實現“敏捷定製”。
再從軟件應用的角度看——互聯網時代的企業應用定義，正在發生革命性的變化。軟件在傳統的企業應用模式中，是爲某一個部門服務的，也是以其所完成的功能表述的，從主觀上可以把企業應用分割爲人事、財務、行政、ERP、CRM、SCM、BI等等；而在互聯網的應用中，橫向的部門互動、實時的企業間互動、多樣的交互渠道、靈活的業務規則，使得原先意義上的“獨立應用”不復存在。客戶應用模式的變化，從根本上對軟件企業及其產品提出了更高的要求。
綜前所述，面向構件不失爲軟件企業的優選方案——作爲軟件代碼的集合，構件可以完成一個或多個功能的特定服務，也爲用戶提供了多個接口。通過構件組裝，實現契合互聯網時代應用需求的全部軟件功能，這種解決思路必將爲當前的大型企業應用產品畫上一個歷史性的圓滿句號。不久我們看到的企業解決方案 會面目一新，不再單一固化；它是一組或多組面向構件的模塊，按照企業自身需要靈活組裝，並隨着企業的變化不斷重組重構、動態匹配。
面向構件的思想，第一次給了軟件騰飛的翅膀，可以]快速實現像硬件那樣的任意裝配定製。過去，有人將軟件定義爲“編碼的知識”，而今，新體系下的軟件成爲了“構件的知識”——即使說成“構件技術改寫軟件定義”也絲毫不爲過。
產業之變
開發效率是企業生產力。全球範圍內的軟件從業者都在探尋着“提高軟件開發效率”的可行途徑。概括說，提高軟件開發效率的關鍵在於提高軟件的複用能力和複用程度。
研究報告顯示：“一個軟件的60％－70％的功能是可以被複用的。”然而現實情況則是，不同的企業總是不斷在爲其客戶開發着幾近相同的“輪子”——某種意義上，“不斷地重複發明輪子”正是對當前軟件生產模式的最恰當的描述。毫無疑問，只有面向構件才能讓企業這駕戰車（包括軟件公司和客戶在內）在“軟件複用之路”奔馳得更加迅疾、更加平穩。
在長期籠罩着陰霾的軟件天空裏，面向構件的思想彷彿一道曙光，撕裂了陳腐的舊軟件體系——相信進化論吧，最終，舊的一切會被拋棄，取而代之的將會是嶄新的面向構件的軟件結構。這是一個靈活的軟件取代僵化的軟件的過程，也是一個新的體系開始產業化的過程。據不完全統計，目前國內外已經有相當一部分前瞻性廠商，開始嘗試新的軟件體系。
圖表：面向構件的軟件體系下的軟件產業結構
那麼，新的軟件體系、軟件結構將會給軟件產業以及應用模式帶來哪些變化呢？主要有以下兩方面：
一方面，面向構件的互聯網應用基礎平臺將備受矚目——該平臺將成爲應用軟件構件化的“金字塔基”，爲應用軟件向面向構件的技術遷徙，提供開發運行的環境和基礎設施。
另一方面，分層級的應用構件將取代應用軟件編碼——複雜、僵化的應用軟件的編碼時代將會結束，取而代之的是“敏捷的構件集成時代”的到來。
此外，面向構件的技術還將會極大地促進應用市場的發展。未來以面向構件技術爲基礎的軟件產業必將催生出衆多的應用構件廠商，從而形成社會化的分工和交換。這種分工協作帶來的明顯好處是，面向構件的應用軟件在成本、質量、交貨期等方面的競爭力將遠遠超越傳統的軟件體系結構下的應用軟件。
分析面向構件的軟件產業的生命週期，大致可劃分爲五個階段：創新期、接受期、成熟期早期、成熟期晚期和衰退期。如今，面向構件的軟件生產已經跨過了接受期，其標誌是面向構件的軟件生產思想開始商業化，單個廠商開始採用面向構件的軟件生產方式。然而，接受期和成熟期早期之間的產業鴻溝依舊存在。構件理念由接受期向成熟期早期進化，單點突破很多，但尚未形成生態鏈。可以預見，一旦跨越產業鴻溝，整體產業發展將經歷鉅變，我們將面臨一個雪崩式的發展階段——根據Gartner Group的預測：“到2005年至少70%的新應用將主要建立在如軟件構件和應用框架這類‘構造塊’之上。”——我國在構件化軟件的探索方面也已悄然前行，國務院信息化工作辦公室在《振興軟件產業行動綱要（2002年至2005年）》中，多次提到推廣應用軟件構件和複用技術，加快構件技術發展的目標要求。國內已經有一些廠商開始通過聯盟的方式推動面向構件的軟件體系的發展。毋庸置疑，新體系將爲中國軟件產業提供“後發先至”的寶貴機遇！
軟件業變革的帷幕已然拉開，面向構件的軟件技術被越來越多的國內外業界專家推崇爲軟件產業的The One。可以深信，在未來的十年裏，我們將有幸目睹軟件在面向構件的思想指導下不斷髮展、日臻成熟。代碼式的軟件最終會成爲歷史，軟件將以更優美的形式被表達、更優美的方式在生產，並在使用過程中獲得更加完美的體驗。
請關注《軟件的涅磐》三部曲下篇《軟件之美》。
軟件之美
軟件建築之美
新春伊始，北京的氣溫略有回升。週末，頤和園裏到處熙熙攘攘，遊人如織。昆明湖畔，萬壽山邊，有氣勢宏偉、層疊綿延的重廊復殿，有自然綺麗、神韻似水鄉江南的園林；飽覽湖光山色之餘，不禁大爲慨嘆中國古建築之美。實際上，頤和園的衆多建築，大都是由標準化的構件組合搭建而成。
古建築之美在《營造法式》中大抵可以尋根溯源。該書成於北宋時期（約公元1103年），凡三十六卷，乃中國古代建築學集大成之寶典。書中提出了一整套木構架建築的設計方法，概括了當時的各種構件詳圖、規格、尺寸，以及生產各種材料構件的標準，和磚、瓦、琉璃的燒製方法等等——此書可說是頤和園建築風格與建築方法的淵源——通過建築構件的分解和標準化，《營造法式》爲中國古建築的結構設計、工程管理奠定了基礎。中國建築之美，肇始於此。
感嘆建築之美的同時，我也在思考：能否找到屬於軟件體系的《營造法式》？
研究現在的軟件體系，不難發現：現在的軟件專家們仍需要與大量的需求、設計、代碼的細節打交道。出於項目實施時間、投入資源等方面的限制，大型軟件往往以實現若干個具體的用戶功能需求爲目標。專家們沒有時間，也沒有精力去追求軟件的美學目標。日復一日，隨着用戶功能要求的變化，大型軟件項目成爲大量代碼的隨機而無序的堆積，奇醜無比。許多工程師一旦完成項目，就恐避之不及，不願再去碰自己幾個月來夜以繼日的勞動成果。
而在面向構件的軟件思想中，軟件專家們則要幸運得多。他們不再需要不斷重複具體的軟件實現的技術細節；他們的工作更像一個軟件建築師；他們的思緒又重新集中到用戶的切身業務需求上，圍繞用戶，如何用簡潔的結構，搭建出一個個有個性、有美感的軟件。
正如看風景。設想在昆明湖邊，忽然下起雨來，你仍可沿着長廊繞湖徜徉，品味雨帶來的幾絲清韻；抑或尋一個八角亭，邀三五好友喝茶對弈。但說回到現今的軟件，美感頓失；似有刀耕火種時期爲一棲身之所而知足之嫌。也許終有一日，軟件也會如昆明湖畔的風景，無論何時何地，都能讓用戶隨心所欲體驗互聯網時代的萬般精彩。
軟件結構之美
從心理學角度說，人類對事物的認知大致經歷了感覺、知覺，再到思維的漸進過程，這也是一個從具體到抽象的過程。一開始我們會根據物質的外延特性（如軟硬、冷熱、黑白）來“表達”物質，其後根據它的功能來“表達”，最終我們明白了所有物質的結構。
早在公元前五世紀，德謨克里特就提出了物質永遠存在。他認爲世界是由一個巨大的虛空和無數的原子組成。
1803年英國化學家道爾頓創立的原子學說，則從物理學的層面向世人揭示：“一切元素都是由不能再分割和不能毀滅的微粒所組成，這種微粒稱爲原子”；從此我們對事物的認識從原子、分子逐漸過渡到宏觀層面。
這種對事物本質認識的進化，奠定了整個科學進步的基礎。不管從哲學領域的原子論，還是物理學領域的原子論，我們都能清晰發現，西方表達事物的方式是個進化的過程，貫穿始終的仍是從本質出發，用分析的眼光關注物質的基本結構——那麼，假如我們不再像以往那樣功能化地審視軟件，而是去關注其本質，關注其結構，是否會找到一條提升軟件生產效率的新途徑呢？答案是肯定的。
在不斷變化、日新月異的業務知識範疇，面向構件的軟件體系找到了一個可以固化軟件知識的結構，即通過構件爲人類建立有效積累和複用知識資源的途徑——實質上，構件就是各種通用知識和業務知識的封裝和複用。面向構件才能改善軟件知識的生產和管理的質量，實現軟件財富的有效積累，實現知識的管理與創新。
以構件形式“裝配”而成的軟件更契合軟件企業及其客戶的需求，同時也更具“美”的特徵。評審軟件的美醜妍媸，關鍵要考量軟件的結構簡潔與否，軟件設計與實現可否快速應對業務需求的變化。基於這個標準，可以得出：代碼式軟件受制於開發方式和軟件結構，因而不大可能呈現出“美”的特徵；而面向構件的軟件體系是依靠變化來獲取活力，能儘可能保持乾淨、簡潔的設計——這當然更接近我們對“美”的定義。
美的軟件結構需要具備很好的複用性、可維護性以及可移植性。複用性好，能保證爲開發者節省大量的資源；並擺脫基於代碼的傳統軟件結構的晦澀難懂，建立方便維護的基礎。較之傳統代碼式軟件維護難、修改難的缺陷，面向構件的軟件則清晰明朗，容易理解，還具有很強的可維護性。可移植性，在傳統的軟件體系中根本無從提及，軟件體系自身與系統應用環境之間存在千絲萬縷的關聯，軟件企業也無力解開繁複的關聯糾結，剪不斷理還亂；而採用面向構件的軟件結構，構件已擺脫了對底層應用環境和技術的依賴，使得構件在異構環境中也能實現複用，得以實現良好的可移植性。
隨需應變的體驗之美
在《敏捷軟件開發》一書的序言中，羅伯特·馬丁（Robert C Martin）曾這樣形容美的軟件：“（軟件之美）在於它的功能，在於它的內部結構，在於團隊創建它的過程。”然而美的價值最終在於體驗，正像博爾赫斯所說的那樣：風景在旁人看不到它的時候，便不能算是“風景”——因此我們有必要對羅伯特·馬丁的看法作適度的修正：軟件之美體現在結構與功能的協調之美，開發者與應用者的體驗之美，團隊協力創建的過程之美。
美的軟件是軟件企業和軟件開發者的終極目標。
先來看看傳統代碼式軟件。傳統代碼式軟件，難以適應未來IT技術和商業環境的變化；基於代碼的定製開發與客戶需求的經常變動中間常常存在難以逾越的鴻溝，客戶的抱怨、軟件廠商的無奈往往宣告了大型軟件項目的徹底失敗。只能以“破而後立”的方式進行軟件的升級——客戶在支付了昂貴的信息化成本後，得到的卻是一個有時空限制的、缺乏靈活性的軟件：不用多久，客戶便會發現，當業務需求激烈變化時，原有的軟件系統是那樣孱弱無力。客戶固然不願意兩次踏入同一條河流（在同一個軟件項目上重複投資），軟件企業也未必喜歡推倒重來的“二次開發”。
在看面向構件的軟件，它將具有足夠的能力、足夠的靈活性來管理變化、滿足市場和客戶的要求。“變化”不會給面向構件的軟件帶來挑戰和危機，恰恰相反，“變化”能夠充分展示面向構件軟件的優勢。通過“變化”，客戶可以充分展示面向構件的IT系統的核心競爭能力。
誰說大象不能跳舞？誰說企業信息化只能千人一面？無論企業規模如何，面向構件的軟件都能夠支持敏捷的功能延展和豐富的“個性選擇”。目前，傳統的通用型企業級軟件之所以頻頻出現僵化、狹仄和無法響應客戶需求等許多問題，正是因爲基於代碼的應用軟件在擴展性和個性化方面“能力有限”。面向構件的軟件必然會令軟件企業與客戶雙方獲取到更其豐富美妙的開發及應用體驗。
軟件過程之美
軟件過程之美，對於軟件開發人員以及客戶的意義是多重的：對軟件設計者來說，能直觀地分割、並具有最小內部耦合的軟件結構是“簡約之美”。對開發人員和管理者來說，生產無缺陷代碼、並取得每週重大進展是“精緻之美”。對用戶來說，通過直觀、簡單的界面、準確呈現所選程序是“清晰之美”。
只有通過面向構件的軟件開發方式，軟件企業才能從產品開發過程中捕捉到美感——明確的分工將把一個巨大的軟件項目分解成爲若干個可控制、可管理的子項目；在大大降低項目風險的同時，提高了項目管理的可見度和可控度。
具體說軟件的過程之美，主要體現在從時間到空間、從內涵到外延的不同側面：
從時間控制看，傳統流程由於分工不清楚，或者不同的分工間存在瑣碎而複雜的關聯，導致需求變化時，項目的時間進度和工程質量很容易像脫繮野馬般失控。而面向構件的工程管理卻不會如此，因爲有大量的複用軟件存在，分工也相對明確，項目的時間和質量自然就比較容易控制。
對軟件的空間部署而言，傳統軟件項目部署管理往往只能在一些參數設置和有限的二次開發接口上完成，變化較大的業務需求無法得以滿足；而面向構件的軟件體系中，複雜的業務需求還可以在基礎構件和行業構件上可視化組裝完成，有較好的服務工程管理能力。
從產品內涵來看，在面向構件的軟件體系中，產品由很多構件組成；只需要重組小部分構件，或添加小部分構件就能實現產品創新。
由內及外，個性化就是面向構件的軟件產品的外在表現：在面向構件的軟件工程管理中，由構件實現通用功能，由構件的選擇、組裝和配置實現個性化，輕而易舉實現了軟件的個性化需求的工程管理；傳統軟件產品則相反，連對單一個性化的用戶需求變化進行有效表達，都無法實現，個性化功能和通用功能經常混雜在一起。
面向構件的軟件是美的。通過面向構件的互聯網應用基礎平臺，業務專家可以更專注去設想軟件的功能，結構專家可以分離出通用的構件搭建美的軟件，而面向構件的軟件開發過程也更爲和諧，更趨高效。 在今天，面向構件的軟件體系和這個新體系中的基礎平臺帶給我們的不僅僅是個性化的企業級互聯網應用軟件開發的效率，更重要的是其內涵，是其表現出來的軟件美學。
“橫看成嶺側成峯”，如果我們站在一個更高的角度審視軟件，就會發現軟件在面向構件之後，與知識存在許多相似之處：知識無限，組成軟件的基本元素——構件同樣無窮無盡。但只要掌握一定的知識，就可以進行無窮的探索；軟件亦然，只要有一定數量的基礎構件，就可以產生出不同的應用。比爾·蓋茨有句話說得很對：軟件的發展不存在所謂“極限”，其發展速度只會受到人的智力、想象力和創造力的制約。但我想，如果是基於過去那樣一種成功率低、動輒令項目墮入焦油坑的軟件研發思路，那麼軟件（尤其是大型行業應用軟件）的發展其實早已遭遇到了“極限”——好在今天，面向構件的軟件可以讓我們輕鬆地超越極限，充分釋放自己的智力、想象力和創造力。
應該慶幸傳統軟件體系的“基因”缺陷已被及時發現。應該欣喜面向構件的思想體系，能夠將軟件開發知識、行業業務知識整合到構件中進行管理。應該相信通過面向構件的軟件的思想的實踐，我們能夠構建新的企業——知識企業，我們能夠構建新的社會——知識社會。
當軟件革命吹響涅磐的號角，讓我們期待變革的風暴來得更加猛烈，讓我們期待軟件爲信息化列車高速飛馳提供無盡動力，也讓我們期待軟件之美能夠沁人心脾吧！