《InfoWorld》在追蹤這些神話的源頭后發現，事實上幾乎所有這些神話都沒有什么依據。例如，有神話認為服務器升級很重要，事實上根本不是這樣。另一個神話相信：業務能力是成為一名成功CTO的關鍵。事實上也不是這樣。還有一種神話認為80%的企業數據保存在大型機上。是否如此，不妨親自檢驗一下。我們執著的記者發現很多歷史悠久的神話需要揭穿，這再一次證明，盡管一些至理名言廣為人知，但并不總是合理。
神話之一：服務器升級很重要
真相：不要為可升級花費額外的錢；你將永遠不需要它
你最后一次更換服務器上的處理器是什么時候？你拆過運營系統的RAID控制器，用更大的緩存更換它嗎？你卸下過機器的鏡像18GB Ultra160 SCSI引導硬盤，代之以36GB Ultra360硬盤嗎？
盡管頂級服務器制造商吹噓它們的服務器平臺的現場升級能力，但是用戶會不斷地擺弄生產系統是一種荒誕的說法，除非迫不得已需要更換毀壞的零件。如果服務器使用時間不足1年，它很可能在訂購時就配備了合適的部件，不需要去改動；如果服務器使用時間超過了1年，任何思維正常的人都不會去拆開它升級CPU。
為了調查這個神話，我接觸了所有頂級服務器制造商。當問及有關升級服務器的統計數據時，沒有一家廠商愿意正式合作。一些廠商說沒有這類數據，另一些廠商說這是內部信息，出于競爭原因不能公布。所有廠商都聲稱發現這個問題令人驚訝，并且都對調查結果很感興趣。
所幸的是，一家不愿透露名稱的廠商轉交了一位營銷經理的非正式評論。這位經理的思索引起了我的共鳴：“我認為大多數顧客從一開始就購買了配置滿足未來發展需要的RAM和CPU的服務器。”
這位經理補充說：“許多顧客拿到購買硬件的款項后，更容易用這筆錢購買硬件，而不是把錢花在未來升級硬件上。”
不升級系統的另一個原因當然包括害怕把事件搞糟：遭遇操作系統、驅動程序或應用程序上的困難。由于只有很小的性能改進(比如說，從2.0G升級2.6G處理器)，而服務器其余部分仍和原來一樣，有什么必要冒這種風險嗎？
很難想像對雙處理器1U或2U服務器或服務器刀片上的硬件做很多改動，除了根據需要添加內存外。如果低檔服務器不能處理工作負載，解決辦法是用功能更強大的服務器更換它，或向負載平衡群集添加更多的服務器。把有限的資金花在老服務器上帶來不了ROI(投資回報)。當你考慮新服務器的規格時，要保證系統滿足你現有的需要，并在購買時留出這臺機器的預期壽命期可能需要的余量。除非你具有IT專業知識并實際進行過服務器升級，否則不要進行任何升級，不要為能夠適應未來處理器平臺的可升級CPU卡花冤枉錢。你將永遠不會用到它們的。
IT神話之二：80%的企業數據保存在大型機上
真相：50%，或更少
是終結大型機仍保存著80%的企業數據的神話的時候了。大型機自50年代問世后，基本上一直是管理所有關鍵任務企業數據的無可爭議的看門人。IBM因大型機而成為藍色巨人，因為藍色正是它們早期大型機的顏色。然而，70和80年代，IBM在大型機市場上的壟斷地位遭到了攻擊。隨著第一批小型計算機以及隨后的微型計算機的到來，Fortune 1000公司開始減少了對大型機的依賴。小型和微型計算機帶來了將集中保存的數據更靠近用戶分散存放的希望。
但是，Internet的誕生和由此引發的非結構化數據(如電子郵件、網頁、Word文檔)的洪水以及各種管理與保存這類數據的技術，讓許多人得到了這樣的結論：大型機對企業數據的束縛已經逐漸松綁。
RedMonk公司高級分析師O Grady說，許多大型機構的財務數據是用幾個Excel電子報表管理的，此外再加上各種不經過大型機的網志、即時消息、電子郵件，目前保存在大型機上的數據量在40%到50%之間。Yankee Group高級分析師Gardner說，現在已經有大量的關鍵財務數據是在大型機之外生成、共享和管理的。Gardner說：“一些企業用戶現在擁有Spreadmarts，即用于管理許多業務流程的、以真正分散方式保存的大型扁平的電子表報文件。”
另一個削弱大型機統治地位的趨勢是SAN和NAS專用設備的出現。盡管這類設備大多直接連到大型機上，數據在大型機中可以被共享，但越來越多的企業用戶傾向于將數據保存在SAN和NAS設備上。
IT神話之三：所有大機構都使用多種平臺
真相：這個“神話”比小說更接近事實
正如New Wave樂隊的Devo所說的那樣：“自由選擇是你的權利。來自選擇的自由是你的希望。”別無選擇難道不是比必須自由做出決定更容易嗎？這項原則適應于IT嗎？企業是在尋求多樣性而不是單一廠商解決方案嗎？
專家們認為這不是神話。Forrester Research副總裁Gilpin說，一些較小的公司為單一化的公司，而較大的公司由于兼并和收購而不可避免地變為多樣化的公司。此外，多樣性起到了杠桿作用。Gilpin說：“擁有其他一些廠商總是有用的，你可以將他們當做一種威脅來使用。”Oblix公司官員對此表示贊同，他說：“IT人員喜歡這種他們通過保持多樣化環境獲得的杠桿。”
IBM自治計算部官員Bartlett說：“絕大多數的企業成為多樣化企業。”他說，以前，單一化環境與多樣化環境之比約為八二開，而現在這個比例至少已經倒了過來。Bartlett說，公司希望全球化、全天候運營以及在Internet上運營的要求導致了多樣性。
多樣化和單一化各有各的優缺點。單廠商解決方案，即所謂的專有解決方案，避免了必須使不同系統一起工作的困難。但專有解決方案讓用戶受制于一家或很少幾家廠商，并且只提供有限的選擇。所謂的開放解決方案為用戶提供了多種技術選擇，從而在理論上降低了費用。但是，IT管理人員可能需要忙于在開放環境中集成各種東西、開發各種標準。
盡管大多數機構需要多樣性，但一些用戶至少在它們的部分IT基礎設施上更喜歡單廠商方式。例如，加州San Jose市最近受到人們批評，原因就是它選擇本地網絡廠商Cisco作為其正在建設的新市政廳的網絡設備供應商。
IT神話之四：與精通技術專業知識相比，CIO和CTO更需要精通業務
真相：技術資質比以往更重要
對于大約20年前出現在企業中的首批CIO來說，他們的首要工作是確保IT部門部署的技術為偏遠辦事處的業務目標提供服務。他們那時必須成為兩種差異很大的文化之間的橋梁。
但是在過去的20年中，當技術變得與公司的核心業務戰略密不可分時，許多CIO以及大型公司中的CTO卻被迫將過多的時間用在業務方面。
而且隨著技術項目數量的增加，許多CIO和CTO將單個技術采購和部署方式的更多決定權交給下級。那些做出產品購買決定的人常常單純關注技術，因此在做出戰術決定時，沒有充分考慮這些決定如何使整體業務目標受益。一家大型銀行的LAN管理員說：“我認為一些IT項目在技術上偏離方向或超出預算的主要原因之一是，缺少來自高級管理層在技術方面做出的指導。”事實上，一些業界觀察人士似乎擔心CIO和CTO必須花更多的時間來深入了解技術和產品，尤其是新出現的產品和技術。
CIO和CTO被迫將更多的精力放在業務而非技術決定上的主要原因之一是“.com”泡沫的破裂。由于90年代中后期盲目花在技術上的大量資金帶來很少的ROI，許多CEO要求任何有一定規模的技術設備都取得即使不是立即的也是短期的回報。
然而，僅僅關注短期的財務收益，迫使大多數CIO和CTO將長期的技術部署推遲到經濟復蘇之后進行。與那些在ROI與高科技投資之間取得更合理的平衡的人相比，這種延期只會讓保守的CIO和CTO處于競爭劣勢。
一位業內人士說，那些只希望得到短期ROI的CEO和CIO在IT技術發展方向這個問題上是近視的。他說，真正了解IT技術，知道采取什么措施使這些技術變化有利于加強競爭優勢的企業，才能夠占據非常有利的位置。
IT神話之五：大多數IT項目遭受失敗
真相：取決于你如何定義失敗
大多數IT項目失敗了嗎？在回答這個問題時，一些人會引用IBM Global Services、Capgemini和Sapient等大型咨詢公司提供的數字，而這些公司正是靠企業遭遇的可悲經歷而生存的。
另一些人則反駁說失敗是相對的。的確，許多項目都存在系統問題或預算超支，但它們沒有達到嚴重損害用戶業務的“失敗”狀態。
AMR Research副總裁Shepherd說：“如果某一項目晚了3個月，或預算超支5%，這可能令人失望，但這不是失敗。大多數IT項目都屬于這種情況。”Shepherd認為，雖然項目遇到五花八門的問題，但實際的部署通常都是成功的。
專業從事跟蹤IT成功或失敗的Standish Group規定了非常嚴格的成功標準。Standish Group去年調查了13,522個項目，證明絕對成功項目大大低于50%，僅為34%。徹底失敗的項目，即中途夭折的項目，為15%。介于兩者之間是完成了的、但“受到質疑的”項目。Standish說，受到質疑的項目占所有IT項目的51%，這些項目被定義為存在費用超支、超出工期的項目。Standish說，成功的水平依次與用戶參與、管理層支持的程度和擁有有經驗的項目經理相關。
對于IT項目咨詢機構Sapient來說，成功或失敗的關鍵因素取決于公司采取的控制風險的流程。換句話說，必須在故障點影響到整個項目前確定它。Sapient公司CTO Gaucherin說：“項目越大，失敗的可能就越大，因此你需要在控制風險上下更大的力氣。”他補充說，潛在的問題可以通過“暴露風險”法來控制。暴露風險法是一種在事情失控之前就確定它們的方法。
Standish Group官員說，也許對于IT項目最具破壞性含意的消息，不是被放棄的IT項目的數量，而是那些完成但沒有提供最初規定的特性和功能的項目。她說：“內容缺少50%以上最有可能被認為是一次失敗。”
不過，AMR的Shepherd則持另一種觀點，他說：“失敗是這樣一種情況：訂單被停止接收，或者賬目不能完成，或者項目本身被放棄。而這種情況很少發生。”
IT神話之六：IT不能伸縮
真相：幾乎任何技術都是可伸縮的，只要你混合正確的成分，并有效地實現它們。
幾乎每種信息技術曾經都被判斷為不符合要求。失敗常常用最惡毒的話來總結：“它不能伸縮。”理由當然是曾經由于這樣或那樣的原因，每種信息技術都不能伸縮。
不幸的是，對于這方面的犧牲者來說，可伸縮性是一個非常不準確的術語。人們可能希望應用擴展到大型服務器或縮小到手持機上。然而，尺寸只是可伸縮性的一個方面。其它方面包括帶寬、交易密度、服務可用性、查詢性能以及源代碼的可理解性或最終用戶的信息顯示，等等。
不存在包治所有這些病癥的靈丹妙藥，但這并不妨礙我們努力去尋找它。舉個例子：當社區網絡服務公司Friendster由J2EE切換到PHP，并大大改進了響應時間時，一場騷亂因此而起。作為對長期以來“腳本語言不能伸縮”的論斷的反應，PHP支持者現在可以開心地聲稱：“Java不能伸縮。”
這場爭論不僅制造了激情，而且還讓人們注意到了PHP發明者Rasmus Lerdorf是如何稱呼PHP“什么都不共享”架構的。他解釋說，由于PHP是無狀態的，潛在的瓶頸被從Web層排擠到數據庫層中。Lerdorf說，如果你使用Oracle產品，可伸縮性的大小取決“你每年給Oracle開出多大的支票”；如果你使用MySQL或PostgreSQL，“可伸縮性取決于你是否正確配置復制，是否有一顆精心設計的數據庫機器樹。”
當然，Java可以以類似方式使用。當eBay進行引起廣泛關注的J2EE遷移時，新架構的無狀態性被列為一個關鍵的成功因素。
可伸縮性不是程序語言、應用服務器或數據庫的固有屬性。它源于巧妙地將各種成分組合到一個有效的解決方案中。這里沒有單一的配方。例如，無論你的數據庫功能多么強大，在使用不恰當時，它都可能變為瓶頸。許多“.com”時代的Web出版商在付出慘痛的代價后學到了這一教訓，他們的數據庫驅動的網站在黑客的攻擊下而崩潰。
當前的網志革命代表著兩種協作方法之間的更好平衡：從數據庫和服務器緩存提供動態內容服務，從文件系統提供靜態內容。
得出分散的、松散聯系的Web架構本質上可伸縮的結論十分誘人。但事實上并不是這樣。我們學習了(并仍在學習)如何正確地混合這些成分。人們可以讀寫的格式和協議加強了人類一方的可伸縮性。緩存和負載平衡技術在帶寬和可用性上給予我們幫助。
然而一些問題將始終需要各種成分的不同混合。例如，Microsoft已經將內部業務應用整合到SAP的單一實例上。在這個例子中，成功的架構是集中的和緊密聯系的架構。
對于任何技術來說，“X不能伸縮”的論斷都是荒誕之說。真實情況是總有辦法讓X可以伸縮。了解這些可能性并避免隱藏的危險，需要書本上沒有的經驗。
