對于大型公司項目平臺選擇J2EE的幾層認識

>>>  技術話題—商業文明的嶄新時代  >>> 簡體     傳統

好久不在這里寫文章了。

  我是一個從野路子上一路走來的程序員,現在主要用.net做方案。選.net不選java并沒有什么特別的原因,只不過是因為我自己從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的東西是個“玩具”,“低檔平臺”,他們在背道而馳,最后的失敗也是當然的了。

  這是就是我的第一層認識。

 如前面所述的,由于很多人已經被洗過腦,還有其他很多操作上的考慮,大家都會很自覺地配合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規劃,oracle實施,運行在一個oracle cluster上,數據庫的存儲用的是HP的11000,應用服務器用兩臺單獨的590,全部資源都劃為一個分區來跑。在每個月初會有幾百人在里面干活,系統要把上千萬條數據做轉換、抽取和導入(ETL),每到這個時候,系統就會慢得幾乎不能干活,登錄頁都需要十幾秒才會響應。聽說硬件組的人為了加快效率,都把這個數據庫的存儲移到最快的硬盤條帶上了,還是很慢。每次登錄這個系統,我都能感覺到IBM和Oracle的龐大重量全部壓在我的鼠標上。

  這個例子并不是為了證明j2ee很慢。相反,我認為這個系統的慢一定出現在軟件的設計上,那種級別的慢法,一定是要有數量級上的性能提升才會有用,java與C++相比,也不過是10倍以內的效率之差,不會慢到二十秒出現登錄頁,再過二十秒才能登錄進去。因此,一定是與軟件、數據庫的設計很有關系,也就是與開發者的水平有關系,只有那樣才會導致幾百上千倍的效率區別。

  因此,用什么技術效率高什么的,只是一個說法。就是嚴格證明過的數據說什么技術比另一個什么技術快,也不能保證“這個項目”就一定會“吞吐量大”。這就是一個營銷手法,它在我們面對問題時,提供心理安慰。

  說到了這個項目,我就用這個項目做例子,繼續說我的第二層認識。

  公平地講,這個項目有很大的技術風險,開發的難度也很大。一開始是個燙手項目,倒不是因為有政治方面的問題,高層都肯定是下了決心來做的,但大家都已經算計過了,這個項目的技術難度這么大,有50%的可能性是會做爛掉的,公司里沒有多少人敢接手負責。但是這個項目又必須做,最后就會指定一個項目負責人來強迫他來做這個項目。

  其實這個項目雖然難,但都是技術方面的難度,最少50%可能性是會很成功的。于是負責人就會硬著頭皮上馬,開始招標什么的。然后,各種廠商也都立即擁過來,各種營銷手法來來往往的,也不用多說了,只說這個負責人在最后定標時的心理。

  前面說了,這個項目有一定的風險的,雖然只有50%,但這50%對于項目責任人來說就是100%的風險。因為這樣重要的項目,負責人也都會是很高層的領導,他們對政治方面非常敏感,一般情況下是會給自己留足后路的。資金不成問題,請廠商不要節省,節省你就輸了。在這個投資的范圍之內,如何保證自己的政治風險最小?

  很明顯,就一定是要選擇一個最大牌的廠商,選擇最高檔的技術。最好為了分散政治風險,把幾個大廠商都拉進來一起做才好,比如我說的這個項目,數據庫用最貴的Oracle, 一個CPU的授權都在30萬,打折?不用了,你要給我最好的服務!軟件的實施請BEA來做,BEA連應用服務器都能做,做這個不是小菜?IBM做咨詢與規劃,還有硬件當然也是IBM,最好的機器給我來兩臺做熱備!

  有懂技術的說了,慢著,這不是加大了風險么?這么多大廠商來一起做,不是增加了溝通的難度嗎?最少也增加了集成的難度呀!從技術角度上來看,是這樣的,這樣一來,技術風險從50%成了75%,做爛掉的風險加大了!

  你說的沒錯。但是我一直說的是政治風險,沒說技術風險的事情。這個項目的政治風險是對項目負責人能力評價的影響。如果做成了當然最好,但是還有一半情況下做不成,那影響就很負面了。

  對于一個項目負責人,他的決策思想一定是這樣的:如果選擇了一個小廠商,項目做壞了時,他就有決策方面的失誤的嫌疑了。因此一定要選擇最好最貴的廠商,這樣的話,就是做爛了項目,他也可以向領導匯報:您看,我們選擇了最好的產品,最好的硬件最好的服務,最好的軟件開發者,這都是業界一級棒的乙方,他們聯手都做這事情做成這個樣子。言下之意就是:這不是我的決策問題,是這個項目真得真得太難了。

  當然,最后項目也不會一無是處,對付著還是能用的,這就叫成功了。但項目做得很差是人人都看得出來的,于是這個后者就用上了,政治責任就推走了。

  這就是我對這個選擇的第二層認識:從政治上講,選擇最大牌的廠商是最安全的。

  IBM這些廠商深知這個秘訣,于是他們把自己包裝成很高明、很抽象、很High Level的樣子,這就與很多大項目的責任人的心理就切合上了。而MS因為后起,就有心理定勢,以為自己的技術比別人來得晚,生怕甲方對他們的技術能力有懷疑,于是總是在技術上努力。

   這就叫“市場定位”。

  最后,我再聊聊我新近觀察的一個項目的運行,來分享一下我的第三層認識。

  在達到了第二層關于政治風險的認識水平之后,我保持了這個認識水平有一段時間。當然我也無法左右公司高層的選擇,反正有錢就花吧!只是有些系統自己要用的,難用成那樣實在不爽,有時候也不免發發牢騷。

  我有一個哥兒們混得挺好,他新近做著一個項目,當然項目也是由一IBM指導實施的,聽說最初決定這個項目由誰來做時,也是某個領導一番沉思之后決定的,但那位領導不說什么理由, 只是思考之后做了這個決定而已。

  這個項目沒有什么大的技術難題,技術實施的成功率是很高的,按道理不需要什么政治保險。一開始我那哥兒們在做方案時,也的確沒有選擇IBM,而是以他們的評估,選擇了資質不錯,但是價格是IBM五分之一的一個廠商做為給領導決策的推薦。

  有一點我們都沒有多想,就是這個項目雖然沒有技術風險,但整體上有一個政治風險。這個系統所要支持的一個業務模式很創新,公司里有很多人出于各種原因,對這個項目比較抵觸。在項目立項時,這種反彈還沒有表現出來,大家估計也都沒有反應過來這個項目是在做什么。等做到一半時,很多人開始明白過來了,回過味來了,發現這個項目再做下去,可能會出一些對自己“不利”的情況。

  這個說是“不利”,其實也沒有什么“不利”,無非是高層的注意力會有一些轉移、政策優惠會有一些轉移、資源的傾斜會有一些轉移什么的,業務上的競爭與沖擊還遠遠說不上,其實對于很多中國人來講,只要自己不得益就算是吃了虧了。

  于是這個項目就受到了沖擊,一會兒停下了,一會兒繼續了,一會兒又被人重新設計目標了,反正搖搖欲墜,挺危險的。

  最后,這個項目還是挺住了,繼續!為什么?因為有IBM在!

  當項目因為上述問題出現方向爭論、資源爭搶時,這個項目自然就延期了。項目一延期,而且看勁頭甲方一幫人還要繼續這么亂下去,IBM不干了,第一、他們的工程師、咨詢師天天白瞎在這里,那工錢是按小時出的,流水一樣。第二、IBM做的項目,怎么能做爛掉?以后讓業界說起來,“某某某公司的某某平臺是IBM做的,做爛了!”這IBM的臉往哪里放?IBM也是個官老爺公司,能力固然是很強的,但是內部政治也很復雜,說不定比我們更復雜,他們可丟不起這人。第三,IBM已經在財務計劃里把每期工錢的應收預算做好了,你又延誤了,不交支票了,這可不行!

  于是,IBM通過自己長期已經建立的人脈對甲方開展了攻勢,上上下下都有IBM的營銷團隊在活動,這個項目的那位責任人正好得到助力,項目目標很快確定,爭論平息,項目繼續。

  后來我們聊天時,對這位項目負責人的高明手法佩服無比,他早看到這個項目未來的風險所在,于是就采用了與大廠商綁在一條船上的策略,在危機出現時,借力向公司的決策層加壓,最后險勝。如果一開始就決定另一個較小的公司來做,出現這種事情時,小乙方只能閉嘴苦等,聽人發配的份兒。多支付的那部分項目費用,就算是“管理成本”好了。

  最后總結第三層認識:

  * 如果一個項目有技術風險而無政治風險,那么從領導角度上出發,一定要用看起來最HIGH的配置,因為技術困難導致的政治風險,可以通過不等式的傳遞性而推脫:“乙方如此強大,還沒有辦法, 因此此項目確實超出我們的,以及現在業界的技術能力”。

  * 如果一個項目有政治風險而無技術風險,而自己又沒有信心獨自搞定這些問題的話,不妨拉上大廠商,借用他們的力量來在關鍵時候做推動。

  * 只在有項目即沒有技術風險,又沒有政治風險的情況下,才可以考慮采用一家務實進取的小公司來做,快速低成本地搞定。

  說到最后,大家應該明白我說的意思了:在很多大型的企業里,項目技術的選擇已經基本上與J2EE和.net技術本身沒有什么關系了。這兩個技術是兩大陣營碰巧選擇的武器而已,可能有一些小小的優劣差異,但是根本不重要。這兩大陣營由于定位的不同,各自占據市場的兩端,誰是高端誰是低端,并不能說明這兩種技術哪種就是“高級”的技術,而哪種就是“低端”技術。

  客觀上,為了迎合兩端不同客戶的需要,這兩類平臺都發明了相應的附加品。比如Java,就發明了J2EE這種陽春白雪的東西,還有很多無比抽象復雜的實現模式,而.net則發明服務器控件、viewstat和數據綁定這類速成工具。

  這篇的目的,一方面是為了把自己的想法和大家交流,另一方面,也是想勸勸大家,不必太介意技術那點小小的差異,目前大家遇上的項目,大多都沒有什么技術限制,迫使得你必須選用什么平臺,或是不能選擇什么平臺。因此,技術平臺的選擇往嚴重了說是一個政治問題,往說得好聽一些講,是策略問題。選擇的原則,我也在“第三層認識”里總結過了,只要選擇得當,就可以使項目更容易成功——那才是我們這些人的目標。

  -- the end --


HAL9000 2013-07-10 15:35:53

[新一篇] Mac OS X 背后的故事

[舊一篇] 計算機編程簡史(圖)
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表