假如我是CTO

这辈子怕是没机会当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成熟的产品应用，所以它天生就有“成熟”的因子。人们往往看重快速开发的特性，而我觉得，支持底层开发和易维护性才更适合企业级开发应用。