在全球商用數據庫系統市場中，由IBM、Oracle和EMC組成的三駕馬車，構成了從軟件到硬件的企業數據庫系統，并且幾乎占領了全部的市場份額，其中IBM是服務器提供商，Oracle是數據庫軟件提供商，EMC則是存儲設備提供商，他們被合稱為IOE。
從2012年開始，阿里巴巴開始了一場“去IOE”運動，阿里用成本更低廉的MYSQL替代了Oracle，使用PC Server替代了EMC、IBM小型機等設備，并且到2013年5月，取得了圓滿的成功。在這場轟轟烈烈的運動中，阿里以開源系統架構為基礎，創造了適合阿里使用、成本低廉、可持續擴展的自主系統，一舉躋身同Google、亞馬遜等不依賴IOE的全球頂尖技術的互聯網公司行列。
至于“去IOE”的原因，主要來自兩方面：一是成本的問題，數據內容的幾何級增長，帶來向IBM、Oracle和EMC購買軟件、硬件與服務的費用出現幾何級增長，并且這種幾何級增長的趨勢仍將持續；二是安全性的問題，美國棱鏡門監控波及全球，而IBM、Oracle和EMC則均是美國公司，難免讓人懷疑其與美國政府有所瓜葛。
阿里巴巴如此，對于依賴于IOE的電信運營商而言，也同樣有必要考慮“去IOE”的發展模式。
電信運營商具有“去IOE”的訴求
目前，國內電信運營商基本是IOE陣營的一分子，前期在系統建設上進行了較大的投入，而后期則由于持續的擴建與維護的需要，繼續支付高昂的費用。在運營商財大氣粗且數據量較少的年代，依托IOE是毫無問題的，但是今時不同往日，電信運營商進入了過緊日子的時期。根據中國移動2013年Q3財報，前三季度利潤在公司成立16年后，首次出現了負增長；而數據則隨著用戶數的增多、業務數的雙重增加而出現幾何級的增長，而大數據應用的需求，使得數據處理變得更加復雜，這一切都意味著系統成本的快速增加。利潤減少的情況下，自然就需要向成本要收益，價格高昂的IOE建設與服務的費用，自然就成了值得考慮削減的范疇，更何況現在行業當匯總已經有成功案例的存在。
不僅僅是出于成本的考慮，安全因素同樣重要。電信運營商所掌握的數據，相當部分是同國計民生有密切關聯的，并且涉及到較多用戶個人隱私。這種類型的數據，自然是可接觸的主體越少越好，而采用IOE架構，一下子就有三家外部公司有機會接觸到這些保密性較高的數據，更何況他們還是來自于棱鏡門監控丑聞制造者的美國，或許他們真的在為美國政府提供一定的服務。
電信運營商實現“去IOE”困難重重
有了訴求，未必就是需要馬上執行的，電信運營商同樣具有一些困難，阻礙“去IOE”。
首先，內部技術實力缺乏?？梢钥吹桨⒗锇桶褪菗碛幸恢嵙^強的內部團隊，他們在開源系統的基礎上，重新進行了設計與開發，成為阿里巴巴獨有的系統，這才是“去IOE”的表現，否則找其他公司用開源的系統在阿里巴巴當中實施，就不是“去IOE”，而只能被稱為“替IOE”。對于電信運營商而言，現有的內部技術實力，不足以支撐整體化的“去IOE”，而選擇替代IOE的方案，則毫無意義，真要這樣做，只不過是向另一些公司采購系統、采購服務而言，然后同樣存在泄密的風險。
其次，電信運營商數據混亂。要想“去IOE”，就得更換系統，就得把現有的數據導入到新的系統當中，而現在運營商的數據多、復雜且混亂，每個省都有一大堆各自的系統，省內系統之間未貫通，省間系統之間更是毫無關聯。據了解，某個運營商的省公司計劃上大數據系統，但經過了9個月的努力，僅僅是完成了最近半年的寬帶上行數據的整合工作，數據多、雜、亂的特征可見一斑。因此，在這樣的數據基礎上，去完成“去IOE”，可以說是困難重重。
第三，電信級服務追求不出任何錯誤的穩定。阿里可以在“去IOE”的過程中出現一些錯誤，因為互聯網用戶早已習慣了互聯網站出現的一個又一個404錯誤。只要資金不受到損害，哪怕淘寶中斷服務半天，充其量也就是科技類的重大新聞而已。而電信運營商提供的電信級服務則完全不同，任何問題的出現，都可能引發一場災難，都可能是一次嚴肅的安全生產責任事故。
電信運營商需要走“農村包圍城市”
在需求與困難并存的背景下，電信運營商需要走“農村包圍城市”，“建設革命根據地”的道路，來實現“去IOE”。
具體而言，所謂“農村包圍城市”，就是指電信運營商在推進“去IOE”的過程中，一開始絕對不能涉及核心的系統，而需要從邊緣的、新建的，尤其是基于互聯網的業務系統開始做起，例如各個基地的系統、電子渠道的系統等。然后在這些系統“去IOE”取得成功的基礎上，逐步向核心系統進行滲透，最終全面實現“去IOE”。
所謂“建設革命根據地”，就是指需要培養內部的人才，來應用開源的系統，進行電信運營商“去IOE”的推進工作，形成擁有自主知識產權的體系架構，從而最終完成“去IOE”，而非“替IOE”的方向。而作為同時需要研發能力，與現網落地能力的“去IOE”工作而言，應由研究院與各個省份公司的IT部門共同推進，其中前者負責具體的研究工作，包括體系架構設計等方面；而后者，則是一方面結合實際情況，分析體系架構的可行性，另一方面，則需要實現“去IOE”的具體落地。
