在企業級的應用系統開發領域，J2EE架構現在已經被普遍接受了。雖然它並未完全兌現剛剛出現時的種種美好許諾，跨平臺，分佈式，易於開發維護等等，但J2EE的廣泛普及，已經是一個不爭的事實。雖然J2EE已經非常普及，但從技術上來講，它本身還是存在很多缺陷的，比較突出的缺點，就是開發效率低，維護更加複雜，許多項目組都陷入其中不可自拔。
自互聯網出現以來，企業應用系統的架構發生了很大的變化，C/S架構被廢棄，B/S成爲絕對的主流。但B/S架構本身，要比C/S複雜的多，加上新技術層出不窮，整個行業都處於巨大的困境之中。Web應用系統的開發，就像一座大山一樣，把所有的人，無論是甲方還是乙方，無論是開發人員，維護人員還是系統用戶，都被累垮了。
B/S系統本身的架構設計，要比C/S系統複雜很多，在C/S架構中，一般是兩層結構（Client/Server）。一般在這種架構中，服務器是一個數據庫服務器，只負責數據的存儲和讀取訪問支持；前臺程序採用VB，PB，Delphi等圖形開發工具來開發，通過網絡直接連接到後臺的數據庫服務器，通過發送SQL命令來實現數據庫的訪問。這種開發環境下可以使用圖形化的控件來搭建用戶界面，用戶的交互性比較好。缺點在於應用程序發佈在客戶端，如果客戶機數量很多的話，客戶機程序的安裝，升級都比較困難。而在B/S結構中，涉及到了多種服務器類型，Web服務器，App服務器，DB服務器。在B/S系統中，用戶通過客戶機上的瀏覽器來訪問後臺的Web服務器，Web服務器再把相應的請求轉發給應用服務器來處理，應用服務器再將其中的數據訪問請求轉發給數據庫服務器進行處理。
與C/S開發的一種語言包打天下不同，B/S系統的開發需要在多個層次上進行編程開發。在Web開發中，人們爲了簡化開發過程，提高效率，陸續發明了很多新技術，在頁面開發上，基於JavaScript本身，發明瞭如prototype, jQuery, Ajax等框架；基於java技術，發明了J2EE架構，基於J2EE架構，又發明了Struts, WebWork, Spring, Hibernate ,Itabtis等無數的框架產品。結果在試圖解決問題的同時，這些產品本身又造成了新的問題。
相對於C/S開發的單一開發工具開發，B/S開發要涉及到很多工具，語言和框架，這些工具，語言和框架，都是爲了解決某一問題而設計的，而開發人員必須把這些目的不同的東西整合起來，才能搭建出一個整體的系統。
B/S的複雜度，很大程度上是由於涉及的技術面太多，太多的產品，太多的技術，太多的框架，這樣不僅增加了學習的難度，增加了學習技術的成本，而且也增加了系統運行維護的成本，最終提高了整個系統的開發，運營成本。
這種高昂的成本讓開發人員，維護人員，開發公司，和甲方都陷入了困境之中，大家在這一困境中掙扎，不能自拔。
開發人員的困境
在B/S系統的開發中，開發人員是最辛苦的一類人。用戶的所有需求，都需要一行一行編寫代碼來實現，項目時間緊，加班加點幹，最苦惱的是，要完成一個基本的功能，需要學習一大堆東西才能實現。HTML, JavaScript, Ajax, Jquery, Jsp, Servlet, EJB, Jdbc, Struts,Spring ,Hibernate,光是技術名詞，恐怕一張紙都列不完。
開發人員面臨的困境，就是技術本身在快速演化發展，不時有新名詞，新概念出現，同時現有的技術也在快速演化之中，真是生也有涯，而知也無涯，感覺象夸父追日一樣，每日不停的奔跑追趕，何日纔是盡頭啊。另外一個頭疼的事情，就是技術架構的變化性，今天一個語言，明天一個語言，一旦底層的平臺變了，自己費勁力氣學會的東西就一文不值了，年齡一天一天大了，那裏有那麼多的精力老追趕新技術呢，於是很多人轉行離開了。
但仔細想一想，所有這些架構，這些技術，真的那麼必要嗎？
爲什麼一定要忙於學習新的技術，而不是把精力用在用好現有的技術上呢？
爲什麼一定要受限於某種具體的語言和技術，而不是採用跨語言的解決方案呢？
爲什麼一出現新的技術，就把原來的代碼全部推翻重寫呢？
爲什麼要整天跟着新技術的腳步跑，而不沉思程序設計的哲學思想，厚積而薄發呢？
從某種程度上講，Java世界裏面這麼多框架，產品，語言，很多都是這樣的思路，試圖解決問題，但同時創造出新的問題出來（大家可以回顧一下Struts1糟糕的設計，痛苦的調試，艱難的維護）。開發中用的產品，技術越多，系統就越複雜，光是學習這些技術，框架怎麼使用，就把開發人員的時間和精力耗去大半，而究竟應該怎樣來設計實現系統，已經沒有人考慮了。時間和精力被無謂的消耗掉了。這纔是開發人員最大的悲哀所在。
Web開發壓垮的第一批人，是開發人員。壓垮他們的，是系統的複雜性。
維護人員的困境
終於，在多次延期，多次修改，無數次補丁以後，系統終於上線了。現在輪到維護人員來面對這個龐然大物的系統了。
系統維護人員，對自己的工作，有一個形象的，不太雅觀的比喻：擦屁股。
系統本身開發起來就複雜，使用起來也複雜，再加上開發過程中隱藏的錯誤，行業術語叫Bug，維護人員的電話一直沒有停過，除了操作指導，就是錯誤報告，再加上誤操作以後直接在後臺數據庫裏面改數據，反正事情又多又雜，整天忙得不亦樂乎。
如果是開發人員自己來做維護，相對還好一點，至少裏面是怎麼回事情，大概知道個差不多，有了問題，小修小補打打補丁，雖然累點，總還是有希望的；如果不是自己開發的，要來做維護，那就要了老命了，要文檔沒文檔，要註釋沒註釋，還要面對同樣多的技術架構，語言和技術平臺，用維護人員的話說，就是如履薄冰，如臨深淵，每天都在祈禱，這個系統別出問題。
從表面上看，是開發人員和維護人員之間的矛盾；從本質上看，是系統複雜度的矛盾。如果一個系統開發的很複雜，那麼它本身就很難維護，即使勉強維護，維護的成本也很高。
如果你在系統裏面用了10項技術，那麼維護人員就必須學習10項技術才能進行維護；如果你在系統了寫了10萬行代碼，那麼維護人員就必須面對10萬行代碼。
當維護人員覺得系統已經無法支持下去時，他們會一走了之。而新來的人對於這個系統，工作的難度只有更高，更加難以勝任。
當一個系統無法維持正常的維護時，它的壽命也就到了。這時就會把它推掉，重新開始一個新的系統開發。不幸的是，新的系統一般來說會重複舊系統已經走過的路線，開發的更加複雜，更加難以維護，最後再次陷入無法維護的境界。
爲什麼系統變得難以維護，因爲系統太複雜；
爲什麼維護人員無能爲力，因爲系統太複雜；
爲什麼維護成本居高不下，因爲系統太複雜；
Web系統壓垮的第二批人，是系統的維護人員，壓垮他們的，還是系統的複雜性。
科技公司（乙方）的困境
和對個人的收益不同，系統複雜性，帶給科技公司的，既有收益，也有風險。
系統複雜度的收益，就是客觀上的跑馬圈地，一件事情簡單了，能做的人就多，競爭就激烈，最後就不好賺錢。CPU不是誰都能設計的，所以Intel發了；OS不是誰都能開發的，所以MS發了。把Web系統搞得很複雜，就會人爲提高它的門檻，能做的公司少了，競爭就會少很多。早期的C/S階段，把整個MIS系統搞得很簡單，開發門檻太低，於是有一大堆的公司來做，最後大家都難以生存下去，現在的外包公司，也不需要公司有啥技術積累，於是有一大堆公司一起做，最後大家都掙不了錢。從這一方面來說，系統搞的複雜一些，對科技公司來說，客觀上是有一定好處的。
最大的好處，是提供這種複雜性的基礎設備的公司，例如Oracle, BEA, SUN, HP這些。以Oracle爲例，每升級一個版本，就可以訪問更快，存儲更多，也就能賣更多錢。但問題是：究竟有什麼必要在系統中存儲那麼多的信息呢？這些信息真的增長那麼快嗎？還是垃圾增長快呢？
基於這個原因，所有的基礎設備提供商，都在不遺餘力地推進系統的複雜性，今天一個標準，明天一個標準，如果有現成的標準，就把這個標準不斷升級，讓你跟着跑，整天疲於奔命，永遠處在追趕之中。
最典型的例子就是Microsoft了，無論操作系統也好，Office也好，IE也好，反正三年必升級，強制性讓你報廢現在的東西。這就是基礎設備提供商的生命所在，不斷增加系統的複雜性。
對於具體的開發公司來說，系統的複雜性就是可怕的敵人了。系統越複雜，開發的成本就越高，維護成本也越高，如果客戶不爲這些來買單的話，開發公司就會做一個項目，賠一個項目，最後把公司賠光，關門拉倒。
在人月神話中，講述了恐龍在泥沼中掙扎，掙扎的越厲害，險的越深；現在很多的開發公司也是一樣，險在項目之中不能自拔，活兒越幹越多，不知何日纔是頭，最後一算賬，還不能掙錢。對於公司來講，人力成本居高不下，所有人員被困在一個個項目中掙扎，公司永遠長不大，變不強。
很多人會講這個現象歸咎於大環境和客戶的不成熟。也許他們是對的。
但從深層次看，還是系統的複雜度問題，系統太複雜，以至於把開發公司的人力，物力，財力都消耗殆盡，根本無力發展。
在一個複雜度無法控制的狀態下，公司只能是疲於奔命，隨波逐流。
Web系統壓垮的第三批人，是一個個開發公司，壓垮他們的，還是系統的複雜性。
客戶(甲方)的困境
甲方的科技人員對於系統的複雜性，往往缺乏先見之明。所有的招標文件中，一律指出要保證技術的先進性，素不知，所謂的先進性，往往也意味着新技術，對於整個系統而言，往往是增加其複雜性，而不是減少其複雜性。
國內的甲方對於項目開發往往有個誤區，喜歡按照人員的工作量，通常是人月來估算項目的費用，預算和成本。其實這是很不取的。很多時候只是盲目的要求增加人手，卻不考慮到底有沒有這麼多工作需要人來做，或者做這件事情的時機是否成熟，是否合適。
在按人頭計算費用的模式下，開發公司傾向於增加人手來提高整個項目的費用計算，而且最好是增加低成本的新手來做項目，這樣做的結果就是整個項目陷入盲目運行的狀態，所有的人都在忙，但不知道在忙啥，整體作的是無用功。很多時候把甲方的人員也拉了進來，包括業務人員和科技人員，大家一起瞎忙，一起浪費時間做無用功。
項目開發的種種問題，最後的惡劣後果，實際上都是由甲方來承擔的。甲方既是項目的投資人，也是最終的使用者，如果項目不能達到目標，最終買單的是甲方。
項目的過程管理，時間管理這些都先不談，單獨談談項目的複雜性對甲方的長遠影響。
首先是開發成本的失控，項目越複雜，開發的成本也越高，這些不必要的成本，或者說資源的浪費，最終是由甲方來買單的，開發公司最多不幹了退出，甲方卻退無可退，硬着頭皮也要把項目做完。
其次是項目最終難以維護，正如上面所談到的，系統越複雜，以後的維護就越困難。而更加要命的是，一個企業內部會有多個系統，這些系統分別由不同的開發商在不同時間按照不同的技術來開發，有的甚至已經換手幾次。而甲方的科技部門要同時維護這樣並行的多個系統，再考慮各個系統之間的交互關係，最後的結果就是焦頭爛額，忙得不可開交。
從整體上來看，甲方對於信息技術可以說是又愛又恨，一方面，現在的企業運行離不開這些系統，另一方面，這些系統在帶來便利的同時，又帶來了無窮無盡的麻煩。每個系統的搭建費時費力，最後用不了幾年就漏洞百出，不得不推倒重來。整個系統的建設在不斷重複這一故事，直到下一個輪迴開始。
有的甲方是家大業大，浪費點沒啥，他們可能不太在乎系統建設時浪費的一點點資金，但對於系統運行帶來的煩惱也是無可奈何。而有的甲方本身的底子就比較薄一些，這些系統建設上的浪費和失敗就可能直接導致企業的巨大損失。行內有句名言，不上ERP是等死，上ERP是找死。說的就是這種現象。
甲方的困境，簡單來說在於成本的投入和收益不成比例，由於系統的複雜性不斷增加，甲方的投資被不斷消耗在調合系統的複雜性上，而不能用在更有效益的地方。
現在的項目開發現狀，使得很多甲方變成了一朝被蛇咬，十年怕井繩，對於後續項目的開發，早已失去了往日的激情和動力。
根本的矛盾，仍然在複雜度上，只有降低項目的複雜度，纔是解決問題的根本途徑。
原因分析
雖然在《人月神話》中，布魯克斯已經指出：軟件的複雜性是它的本質特性之一，但在實際工作中，人們往往容易忘記這一點。
軟件的複雜性來源很多，但B/S系統的複雜性，又對C/S時代更有進步，尤其是J2EE的項目開發，其複雜性在不斷增加。具體原因很多，但涉及的技術太多，是重要原因。
目前，B/S系統開發涉及的技術面太多，在界面展示，業務流程，數據操作等多方面，目前一般採用不同的技術方案，不同的框架，不同的產品來處理和實現。這些產品本身都是相對獨立的，都構成一個自己的知識體系，而要把這些不同範疇的技術整合起來，使之成爲一個統一的整體，光在技術層次上，就構成了一個非常複雜的系統。
一個系統涉及的內容越多，也就意味着出現錯誤的機率越大，這樣一個系統也就更加不穩定。
而系統的價值，就在於它的穩定性，一個沒有起碼穩定性的系統，是不會產生價值的。
在傳統的J2EE框架內，應用開發已經太過複雜，變得臃腫龐大，這一點業內已有定論。正是基於這個考慮，近年來出現了一些試圖簡化這一過程的產品和框架，例如Spring, Hibernate，都是這種思路的產物。
但不幸的是，諸如Spring, Hibernate這樣的產品，在解決某一問題的同時，又往往帶來更多的問題，只是用一個問題代替了另一個問題，從整個系統的角度來看，整體的複雜度不僅沒有減少，反而有逐步增加的勢頭。開發人員現在需要學習的東西，不是更少了，而是更多了；工作不僅變得輕鬆，反而更加複雜，更加混亂，也更加沒有生產力了。