软件架构师的定义乃至所需要的特质历来众说纷纭。下面从一些另类的角度来做点分析。
从产生根源来看，程序规模越大，参与人员越多，越需要架构师；
程序越小，参与人员越精英化，架构师存在价值越小。
这不难理解，大军团作战，总不好一窝蜂就上去了，总要有些规则，总要有人把我全局。
架构师就是在比较高的层面上把握全局的这个人。
从这个角度来看，对架构师而言选择最重要，因为站的高，所以选择具有非常大的价值。
注意不是UML，也不是对业务的理解，不是编码能力而是做出正确选择的能力。
当下的开发环境下，考虑解决方案时，所面临的选择不是太少，而是太多。
举个最简单的例子，我们要开发一个基于Web的项目管理程序，那么你面临的选择是：
- 自己从头造，还是用现成的做二次开发？
- 用现成的，是用开源产品还是微软的？
- 用微软的话，是用MS Project还是基于SharePoint?
- 用开源产品，有这么多选项究竟导入那一个?
- 如果自己从头造，那么是基于微软的技术，还是基于Linux?
- 使用什么框架么?
- 如果要做，用什么语言?
每一个这类选择的背后都是赤裸裸的利益---在商业环境下永远不要忘了这个。
做选择其实可以很容易，所以是个人就可以干这活，并不具备很高的门槛。
关键差异是有无根据和正确程度。
如果说程序员的生产效能可以差10倍的话，架构师的价值可以差无数倍。
想选择正确，最关键的前提是理解待选择的选项和外部的切实要求。
前一点很难，这往往要求一个人涉猎广泛，在很多的领域中具有经验。
不只要知道LAMP，还要知道asp，不只要知道软件还是知道些硬件，不只要了解Java，可能还要了解C#。
理解程度倒未必一定要很精通，关键是要抓住差异以及其适用场景。
但这恰恰与这个时代的特征相反，在这个时代里，技术日趋繁杂，专家越来越多，通才越来越少，诸神陨落啊。
走极端的人可能会说，那么多人，没懂什么，去做网站也成功了。
这也可能，运气很好的话，什么也不懂，一样可以做很对的选择。
但能力这种事，本来最主要的就是尽可能去除运气成分。
从编码的角度看，架构师不懂编码是不行，但却不需要是最精通编码的人。
一者谋的一隅，一者谋的是全局，因此也就导致对技能的要求不同。
原文链接：http://www.cnblogs.com/daoshi/archive/2012/08/13/2635664.html
