我對於大型公司項目平台選擇J2EE的第一層認識
我是一個從野路子上一路走來的程序員，現在主要用.net做方案。選.Net不選jave並沒有什麼特別的原因，只不過是因為我自己從C開始學起，一直學到C#, 很熟悉這個平台罷了，從業15年了，C#是最方便的一個語言，而VS是最方便的一個工具，因此就很自然地用C#來解決我的一切問題，而這個工具也沒有讓我失望過，基本上還沒有遇上過解決不了的問題。
但是在現在的這家公司裡，我卻發現了一個很明顯的選擇傾向，就是90%的項目，都會選擇J2EE的平台，.net平台基本上沒有什麼機會被引入。更有一段時間，公司裡甚至規定了：禁止使用.Net技術！
這是一家金融公司，一直以來都是以甲方的身份出現的，不知道為什麼居然會出現這樣的規定，甲方應該關心需求，不知道為什麼還會做技術平台的這種要求，而且用上了“禁止使用”這樣的字眼，無論如何，都是一種很不客觀的做法。
前幾年我還有些單純，看問題總是從技術角度出發。這個規定讓我相當不滿，於是我做了一些測試和調查，證明了幾件事情：
1. 無論在小負載和大負載的情況下，.Net都比J2EE的效率要高。
2. 由於第一條，對於相同的應用程序 .Net比J2EE的所需要的硬件投入小得多。
3. .Net與J2EE相比，前者學習的成本低得多，開發用的人力成本也更低。開發周期也短得多。
4. 收費的.Net與“免費的”J2EE相比，產品許可證成本要低廉得多。這是花了我最多時間來扭轉人們看法的一條。
5. 以公司裡的大多數項目的規模來看，.Net比J2EE更合適於我們公司的情況——你真得不必為每一個項目都購買Oracle和weblogic，大多數系統每天只有幾個用戶，登錄不到1個小時。
我拿著這些得到的事實，去找一些參與了此規定制定工作的人理論，在討論過程中，我又發現了以下幾個事實：
1. 這些人沒有一個人熟悉.Net平台。
2. 這些人中，絕大多數人也不熟悉J2EE平台。
3. 這些人懂具體技術的人也不多，但有一些高層，是IBM的忠實信仰者。
大型企業的決策者們的心理是這樣的——我們金融公司基本上資金充足，明白嗎？我們不需要節省費用，上市之後，有幾十億的定向募集的資金要用於IT建設，這筆錢必要花出去的。如果不花干花淨，投資人是不答應的。因此最小的項目，也常有幾百萬的預算，這其中一半是開發費用和數據庫、中間件等服務器產品費用，另一半是幾台IBM的小型機硬件（這也是被認死了的東西），用於支持每天個位數的訪問量。
如果項目太省錢，是沒有辦法操作的。
既然錢不是問題，那麼我們公司在項目投入方面的心理訴求是什麼？是做一個“高檔的”項目，一個標桿項目！誰能抓到這個點，誰就能得到項目。
IBM的營銷人員非常強大。他們向人們暗示：只有J2EE才是“高檔”的，而微軟的平台是“小孩子玩的”東西。後來，我有機會參加一些項目的工作，於是親眼看到IBM的營銷能力在公司裡造成的影響：如果在項目規劃的會議上有人提出是否考慮一下MS的平台，他們會通過輕蔑的笑容讓提議者無地自容。請注意，技術決策者基本上都是一些對技術一知半解，或是完全不了解的人，人都有下意識，都有虛榮心，不願意讓人認為自己在技術上很低檔，沒有見識，於是一個個就很羞愧地住了口。有些情況下，即使一個心存懷疑的人，也會自動加入鄙視MS的行列，與之劃清界限。
另一方面，MS卻一直不知道為什麼自己總是在營銷上失敗，他們的營銷人員很單純地向我們說明，.Net平台的優越的性能、便宜的開發成本、低廉的產品費用……，但是他們不知道我們的心理訴求，他們所講的一切，都是在證明MS的東西是個“玩具”，“低檔平台”，他們在背道而馳，最後的失敗也是當然的了。
我對於大型公司項目平台選擇J2EE的第二層認識
如前面所述的，由於很多人已經被洗過腦，還有其他很多操作上的考慮，大家都會很自覺地配合IBM的營銷攻勢，而且我們也衷心相信：在IBM等軟件和硬件的支持下，我們的一個個系統步入了“高檔系統”的行列。把.Net平台留給了孩子們玩去吧。
其實，IBM，以及其他一些高端廠商(Oracle, BEA等)做承接的項目，大部分的活計是直接再轉包給其他國內的小廠商的，他們自己所需要做的，基本只限於“規劃、咨詢、建議、項目管理方法論”等一些又高端又陽春白雪的工作。
不過說實話，這些大廠商的總結能力真不是蓋的，你聽了他們的咨詢師的課之後，大部分會感覺自己醍醐灌頂，狠不得把自己的所有的系統都推倒了重來！甚至狠不得把自己的業務方式都來個大變革。不過另一方面，這些高瞻遠矚的規劃，一般也會與現實社會有很大的距離，要麼是客戶不接受，要麼是監管不接受，要麼是現實不接受。無論如何，聽聽絕對有好處，就當開闊了思路了。
既然遠景做不到，那麼近景能做一些就做一些也是好的。首先就要聽這些大廠的話，選擇SOA, 或是SAAS, 或是別的什麼概念來做這些項目, 當然，聽IBM他們說，這些項目的都需要J2ee來支持，而最好的J2EE應用中間件，當然是IBM自己的websphere什麼的。其實都沒所謂.Net好還是Java好，無關乎技術。對於廠商來說，這都無非是一件武器，用來對抗微軟的武器罷了，因為MS真得太令人害怕了，需要這麼多廠商來一起對抗它。
為什麼MS令人害怕？因為以下的幾個原因：
1. MS是一個程序員的公司，而IBM是一個營銷員的公司。MS有實實在在的技術，但是明顯在市場頭腦方面差人一等，因此總是在戰略上慢幾拍，但是後發的產品很強大。
2. MS一直不停地研發。相信學MS技術的人都有感覺，就是他的主導技術基本上不到三年就要整個推掉重來一次，比如從ado到linq，再到現在的那個什麼Ado.Net entity framework的東西。每一代技術都更強大，但是翻新得讓人追不上。這種技術創新的能力，是十年不變的Java陣營很害怕的。而且下一代的WPF、WCF等平台的高度和技術能力是其他廠商難以達到的。
3. MS有著令人難以置信的軟件產品線，從操作系統到游戲，甚至是機器人仿真和開發包！在每一個戰線上，他都有產品（可能是原型級的）可以用來對抗全世界廠商。
4. MS正在蠶食下一代程序員。
因此，java聯盟必須努力抗擊MS, 他們其實對java的低效率心知肚明，但是他們已經選擇了這個武器和這個招牌，因此只好做足文章，把數據庫、應用服務器全部用Java寫成——當然可以用。這就夠了。
但是效率太低，無論懂不懂技術都能看出來系統慢。那麼也沒問題的，只要幾台P590上線，也就快多了。
技術上也對此准備了解釋：是的，J2EE是用於對付大批量用戶的應用平台，在少用戶的情況下，效率上不明顯。但是當用戶量上升到海量級別時，這個系統的響應曲線一定是平緩的。而“.Net一類”的響應曲線必然是陡峭的。這叫做“吞吐量”。
我們得到了安慰，為我們的預算支出找到了解釋。每個人都滿意了。至於什麼時候我們會用上百萬並發的吞吐量？也許永遠也不會，不過備著這個能力也好。
一度我也很相信這個含義不明的“吞吐量”指標，實際上的情況如何？有個例子可以參考：公司裡有一個系統很關鍵，用戶並不是很多,這個系統由IBM規劃，orcale實施，運行在一個Oracle cluster上，數據庫的存儲用的是HP的11000，應用服務器用兩台單獨的590，全部資源都劃為一個分區來跑。在每個月初會有幾百人在裡面干活，系統要把上千萬條數據做轉換、抽取和導入（ETL)，每到這個時候，系統就會慢得幾乎不能干活，登錄頁都需要十幾秒才會響應。聽說硬件組的人為了加快效率，都把這個數據庫的存儲移到最快的硬盤條帶上了，還是很慢。每次登錄這個系統，我都能感覺到IBM和Oracle的龐大重量全部壓在我的鼠標上。
這個例子並不是為了證明J2EE很慢。相反，我認為這個系統的慢一定出現在軟件的設計上，那種級別的慢法，一定是要有數量級上的性能提升才會有用，Java與C++相比，也不過是10倍以內的效率之差，不會慢到二十秒出現登錄頁，再過二十秒才能登錄進去。因此，一定是與軟件、數據庫的設計很有關系，也就是與開發者的水平有關系，只有那樣才會導致幾百上千倍的效率區別。
因此，用什麼技術效率高什麼的，只是一個建立在“完全相等條件下進行比較”這個前提下的一種說法而已，現實中，你沒有辦法忽略具體設計人員的個人水平造成的影響。就算是有嚴格的數據證明說什麼技術比另一個什麼技術快，也不能保證“這個項目”就一定會“吞吐量大”。其實這就是一個營銷手法，它在我們遇上巨額費用支出是否合理的問題時，提供自我心理安慰的理由。
既然說到了這個項目，我就用這個項目做例子，繼續說我的第二層認識吧。
公平地講，這個項目有很大的技術難度，開發的風險很大。一開始是個燙手項目，倒不是因為有政治方面的問題，高層都肯定是下了決心來做的，但大家都已經算計過了，這個項目的技術難度這麼大，有50%的可能性是會做爛掉的，公司裡沒有多少人敢接手負責。但是這個項目又必須做，最後就指定一個項目負責人來強迫他來做這個項目。
其實這個項目雖然難，但都是技術方面的難度，最少50%可能性是會很成功的。於是負責人就會硬著頭皮上馬，開始招標什麼的。然後，各種廠商也都立即擁過來，各種營銷手法來來往往的，也不用多說了，只說這個負責人在最後定標時的心理。
前面說了，這個項目有一定的風險，雖然只有50%，但這50%對於項目責任人來說就是100%的風險。這樣重要的項目，負責人也都會是很高層的領導，他們對政治方面非常敏感，一般情況下是會給自己留足後路的。資金不成問題，請廠商不要節省，節省你就輸了。在這個投資的范圍之內，如何保證自己的政治風險最小？
很明顯，就一定是要選擇一個最大牌的廠商，選擇最高檔的技術。最好為了分散政治風險，把幾個大廠商都拉進來一起做才好，比如我說的這個項目，數據庫用最貴的orcale, 一個cpu的授權都在30萬人民幣。打折？不用了，你只要給我最好的服務就行！軟件的實施請BEA來做，BEA連應用服務器都能做，做這個還不是小菜？IBM做咨詢與規劃，還有硬件當然也是IBM，最好的機器給我來兩台做熱備！
有懂技術的說了，慢著，這不是加大了技術風險麼？這麼多大廠商來一起做，誰會聽誰的？那不是增加了溝通的難度嗎？最少也增加了集成的難度呀！這樣一來，技術風險從50%成了75%，做爛掉的風險加大了！
你說的沒錯。從技術角度上來看，是這樣的。但是我一直說的是政治風險，沒說技術風險的事情。這個項目的政治風險是對項目負責人能力評價的影響。如果做成了當然最好，但是還有一半可能性做不成，這種情況下影響就很負面了。
因此，對於一個項目負責人，他的決策思想一定是這樣的：如果選擇了一個小廠商，項目做壞了時，他就有決策失誤的嫌疑了。因此一定要選擇最好最貴的廠商，這樣的話，就是做爛了項目，他也可以向領導匯報：您看，我們選擇了最好的產品，最好的硬件最好的服務，最好的軟件開發者，這都是業界一級棒的乙方，他們聯手做這事情，但是還是做成這個樣子。言下之意就是：這不是我的決策問題，是這個項目真得真得太難了，換了誰也不行。
當然，最後項目也不會一無是處，對付著還是能用的，這就叫成功了。但項目做得很差是人人都看得出來的，於是這個後著就用上了，政治責任就推走了。
這就是我對這個選擇的第二層認識：從政治上講，選擇最大牌的廠商是最“政治安全”的策略。
IBM這些廠商深知這個秘訣，於是他們把自己包裝成很高明、很抽象、很High Level的樣子，這就與很多大項目的責任人的心理就切合上了。而MS因為後起，就有心理定勢，以為自己的技術比別人來得晚，生怕甲方對他們的技術能力有懷疑，於是總是在技術的可用性、成本的節約性上努力, 很有南轅北轍的意思。
這就叫“市場定位”。
我對於大型公司項目平台選擇J2EE的第三層認識
剛剛第三篇的發布時，cnblog告訴我一個小時裡不能發兩次精華。可是我寫一千來字都花不了一個小時。今天思路比較快一些，呵呵。
最後，我再聊聊我新近觀察的一個項目的運作，來分享一下我的第三層認識。
在達到了第二層關於政治風險的認識水平之後，我保持了這個認識水平有一段時間。當然我也無法左右公司高層的選擇，反正有錢就花吧！只是有些系統自己要用的，難用成那樣實在不爽，有時候也不免發發牢騷。
我有一個哥兒們混得挺好，他新近管著一個項目，這個項目也是由IBM指導實施的，但聽說最初決定這個項目由誰來做時，也是某個領導一番沉思之後決定的，但那位領導不說什麼理由, 只是思考之後做了這個決定而已。
這個項目沒有什麼大的技術難題，技術實施的成功率是很高的，按道理不需要什麼政治保險。一開始我那哥兒們在做方案時，也的確沒有選擇IBM，而是以他們的評估，選擇了資質不錯，但是價格是IBM五分之一的一個廠商做為給領導決策的推薦。
有一點我們都沒有多想，就是這個項目雖然沒有技術風險，但整體上有一個政治風險。這個系統所要支持的一個業務模式很創新，公司裡有很多人出於各種原因，對這個項目比較抵觸。在項目立項時，這種反彈還沒有表現出來，大家估計也都沒有反應過來這個項目是在做什麼。等做到一半時，很多人開始明白過來了，回過味來了，發現這個項目再做下去，可能會出一些對自己“不利”的情況。
這個說是“不利”，其實也沒有什麼“不利”，無非是高層的注意力會有一些轉移、政策優惠會有一些轉移、資源的傾斜會有一些轉移什麼的，業務上的競爭與沖擊還遠遠說不上，但如同郭德綱的那句話一樣，對於很多中國人來講，只要自己不得益就算是吃了虧了。
於是這個項目就受到了沖擊，一會兒停下了，一會兒繼續了，一會兒又被人重新設計目標了，反正搖搖欲墜，挺危險的。
最後，這個項目還是挺住了，繼續！為什麼？因為有IBM在！
當項目因為上述問題出現方向爭論、資源爭搶時，這個項目自然就延期了。項目一延期，而且看勁頭甲方一幫人還要繼續這麼亂下去，IBM不干了，第一、他們的工程師、咨詢師天天白瞎在這裡，那工錢是按小時出的，流水一樣。第二、IBM做的項目，怎麼能做爛掉？以後讓業界說起來，“某某某公司的某某平台是IBM做的，做爛了！”這IBM的臉往哪裡放？IBM也是個官老爺公司，能力固然是很強的，但是內部政治也很復雜，說不定比我們更復雜，他們可丟不起這人。第三，IBM已經在財務計劃裡把每期工錢的應收預算做好了，你又延誤了，不交支票了，這可不行！
於是，IBM通過自己長期已經建立的人脈對甲方開展了攻勢，突然之間，上上下下都有IBM的營銷團隊在活動，這個項目的責任人正好得到助力，項目目標很快確定，爭論平息，項目繼續。
後來我們聊天時，都對這位項目負責人的高明手法佩服無比，他早看到這個項目未來的風險所在，於是就采用了與大廠商綁在一條船上的策略，在危機出現時，借力向公司的決策層加壓，最後才得險勝。而如果一開始就決定另一個較小的公司來做，出現這種事情時，小乙方只能閉嘴苦等，聽人發配的份兒了。
雖然請IBM而支付了5倍的費用，但項目畢竟可以繼續，多出的那部分，就算是“管理成本”好了。
總 結
◆ 如果一個項目有技術風險而無政治風險，那麼從項目決策都角度上出發，一定要用看起來最HIGH的配置，因為技術實施困難導致的政治風險，可以通過不等式的傳遞性而推脫：“乙方如此強大，還沒有辦法, 因此此項目確實超出我們的、以及現在業界的技術能力”。
◆ 如果一個項目有政治風險而無技術風險，而自己又沒有信心獨自搞定這些問題的話，不妨拉上大廠商，接用他們的力量來在關鍵時候做推動。
◆ 只在有項目即沒有技術風險，又沒有政治風險的情況下，才可以考慮采用一家務實進取的小公司來做，快速小成本地用“低端方案”搞定。
說到最後，大家應該明白我說的意思了：在很多企業裡，項目技術的選擇已經基本上與J2EE和.Net技術本身沒有什麼關系了。這兩個技術只是兩大陣營碰巧選擇的武器而已，可能會有一些小小的優劣差異，但是根本不重要。MS和反MS這兩大陣營各自采用不不同定位，因而各自占據了市場的兩端，誰是高端誰是低端，並不能說明這兩種技術本身哪種就“高級”了，而哪種就是“低級”技術。
當然，客觀上為了迎合兩端不同客戶的需要，這兩類平台都發明了相應的附加品。比如Java，就發明了J2EE這種相當有點陽春白雪的東西，還有很多無比抽象復雜的實現模式，而.Net則發明了服務器控件、vIEwstat和數據綁定這類速成工具。
這篇的目的，一方面是為了把自己的想法和大家交流，另一方面，也是想勸勸大家，不必太介意技術那點小小的差異，目前大家遇上的項目，大多都沒有什麼技術困難迫使得你必須要選用什麼平台，或是不能選擇什麼平台。因此，技術平台的選擇往俗了說是一個政治問題，往好聽了講，是策略問題。策略選擇的原則，我也在“第三層認識”裡總結過了，只要選擇得當，就可以使項目更容易成功——那才是我們這些人的目標。
原文鏈接：http://www.cnblogs.com/haoxiaobo/archive/2010/06/01/1748966.Html
