這輩子怕是沒機會當CTO了，只能假如一下了。CTO的主要職責是了解當前流行的技術并有前瞻性地設定技術戰略；預先感知未來的技術發展方向，保持市場競爭中技術較為領先的地位，這種領先應該是可以轉化為商業價值的。CTO可以很大程度上左右技術型公司的命運，如果作出正確的技術決策，就能在競爭中牽著對手鼻子走，成為游戲規則的制定者；一旦做錯決策，可能接下來幾年公司在技術上的投入都要化為泡影，浪費大量人力財力。
商業公司追求最大化商業利潤，CTO應該能夠感知公司所處的業務市場的前景，如果整個市場處于萎縮狀態，公司難保獨善其身，所以CTO”最怕入錯行"，CTO有責任勾畫公司未來的技術藍圖，并且他還應該懂市場. 我假想IBM當初從軟件轉向服務，背后的推手應該是CTO, 即使很多操作是由CEO來做，有前瞻性地提出轉型的人應該是CTO，因為他了解技術前景，或者說，他了解某些方面的技術是否在未來有市場。
整個軟件行業都在流行收購，但最初堅定走收購道路的先驅并不能得到廣泛的理解和認可。多年以前，oracle開始展現收購戰略的時候，他的對手SAP有些揶揄意味地，針鋒相對提出“organic grow”, 依靠自身成長。結果“成長”了幾年發現還是對手依靠收購擴張得更快，才開始跟著花錢收購，從這個角度說，SAP在戰略上已經先輸一招兒了。收購戰略或許是Larry Ellison的靈光一現，具體擴充哪些方面的市場，選擇哪些技術領先的對手進行收購，收購之后的整合規劃，這些應該都屬于CTO的職責范圍。不過就Oracle這個例子，Larry的技術嗅覺可能已經達到獵狗水準了。
隨著開源越來越盛行，技術也越來越傾向于開放。在開源盛行之前，每個公司，無論大小，都有自己的技術框架。發布的各個產品都架構在這個框架之上。后來出現了不同方面的開源技術框架，比如spring, hibernate, 各種MVC框架，CTO應該直接領導團隊對潛在可能吸收的新技術進行評估。這些開源的技術往往更優秀，因為新技術往往吸收了已有技術的精華并加以改進，另外，開源技術有廣泛的用戶群驗證并幫助優化。但同時，技術優秀不表示成熟，公司里需要有專門的團隊評估哪種技術可以在什么時候可以替代公司已有的技術。 這種選擇應該傾向于保守，寧可略微慢一點，也不能冒進做錯技術選型。比如flex和html5在三年之前比較，不太容易看出哪種技術有更好的前景。我個人覺得現在比較這兩種技術的話，html5的優勢明顯更大一些了。開放的技術吸引更多的技術狂熱者推動并完善它，html5似乎越來越好用了。技術選型的決策需要審慎地慢慢做，但一旦決策完成，就要雷厲風行執行決策。如果公司已經有十個產品基于老框架開發，那么不急于用新框架替代老框架重新修改老產品，畢竟商業產品最終目的是為了賣錢，而不是追求完美技術。更替已有產品框架無謂地引入風險。但是對于新產品，就要堅定不移地使用經過評估的新技術，如果公司范圍里，有不同的新老技術框架，維護起來的確有格外的成本，但死守老技術肯定是死路一條。CTO做技術決定的時候，需要把各個方面的考慮寫成文檔，讓一線技術人員了解技術決策的背景。上面用flex和html5舉例，并認為CTO應該讓一線技術人員了解技術決策背景，原因就在于我所在的公司一直在推行flex，而我一直疑惑這個決定是怎么做出來的，背后的依據是什么。
搞創新性的技術，申請專利當然好，這個沒啥可說的。 沒有一直追蹤新技術，況且最近幾個月在學數學，統計，sas之類跟java沒啥關系的技術. 只是亂談一下對技術的看法，java方面個人看好的技術包括，
Spring —— 它的對手是JBoss seam, seam當然也值得關注。在之前的博客討論Domain Driven Design的時候說過，并不喜歡Spring所有方面，尤其它跟DDD的思路有相悖的地方。但Spring已經成為一個流行平臺，它太流行了，所以各路專家好手都會在它的基礎上幫助改進Spring. 連DDD理論的創建者Eric Evans都說要把DDD的思想帶入Spring中，這就是龍頭的優勢。公司跟進Spring的技術風險小。Spring Roo是個格外值得關注的項目。
AspectJ —— AspectJ可以支撐技術框架，但是不適合大量用在應用層面的程序里。
OSGI —— 其實不太了解OSGI，但他看起來比較容易成為標準
Groovy —— 很多人在討論誰可以替代java， ruby, scala, phython還是groovy。我個人不覺得什么能替代java。橫向比較這幾個技術，比較看好groovy, 因為它是java的親戚， 能自然地復用java成熟的產品應用，所以它天生就有“成熟”的因子。人們往往看重快速開發的特性，而我覺得，支持底層開發和易維護性才更適合企業級開發應用。