前几天看到一篇架构师已死的文章，颇为有趣，仔细想想，架构师之所以兴盛和之所以必死，多半是因为太多的人对软件架构师的工作存在诸多误解的缘故。而诸多媒体和原厂商出于自身利益在国内行业进行的过度吹捧，给予了架构和软件架构师太多的光芒，程序员们自然而让的就把个人的职业规划扔到了聚焦点上。
写一些自己对架构设计和架构师的一些不是很成熟的看法，写到哪算那，全当口水了。
架构的概念非常广泛，解决的问题域空间也各有差距， 不能从一而论， 此处单指企业应用的范围而已，和互联网应用等其他范畴有较大差距。
1. 架构是设计出来。
这是很多人对软件架构的一个最大误解。
传统的瀑布模型里，人为的划分设计和编码实现过程，也划出了设计和验证过程的鸿沟，整体设计（概要设计）的可验证性，要在项目的中后期才能得到体现，这时候为时已晚。而为了保证设计的质量，回避中后期风险，又往往会强调加强设计粒度和评审粒度，这样一来，无形中又继续加大了设计和验证的鸿沟，拖长了问题反馈周期，规模越大的项目，问题越为突出。
据我的印象，业界中最早的最有影响的关于架构和架构师的界定其实来源于RUP.有别于传统的瀑布模型的中的概要设计，软件架构很难再说是按流水线方式设计出来。架构设计和概要设计的最大差别在于架构设计更看重反馈和验证过程，更看重架构师在整个软件开发过程中的由始而终的参与。在rup中，项目早期的关键迭代都和架构设计有直接关系。
架构设计应该强调通过更好的反馈-沟通-验证机制， 能在项目的较早期就得到技术和业务上的验证，为整个项目打下稳定的基础。 在某些敏捷开发过程中，架构设计并不会作为一个显著的KPI提出，更多是作为一种隐喻。通过使用迭代和其他更好的反馈交流机制，让项目的架构设计在在项目的前期以验证和演进的方式完成。可以说一个真正的架构设计，必须是可以有效验证的。
而现在很多公司和组织流行的先让大拿组织做设计，设计做完再评审，然后丢给小兵去干活的架构设计流程，实际是对瀑布模型的继续，我个人认为是完全背道而驰的。我多次参加过这样的架构设计评审，基本上可以说没有什么有真正营养的东西，只是一些流行概念的堆砌，昨天EJB,今天SSH，明天又是OSGI，这样的架构设计作出来也有可能会大幅度修改，或者坚决不修改让下面的人痛苦不堪，所谓的评审和存档过程只是自欺欺人而已。再考虑现在各大公司流行的CMM/CMMI，过程改进管理，这些paper的工作还可能会因为引入复杂的审批修改流程把人拖入泥潭。
这种做法，在java圈子里面，因为早期sun和一些大公司对架构和模式概念的极力鼓吹，大为盛行。某些人甚至只是看完了blueprint，做了几个tutorial，就摇身一变架构师，开始了架构设计生涯。
这样的架构师也往往很少编写代码（我们可以理解，一个人写完300页的设计文档以后，还有多少意愿再去写实现代码？），很少参与项目的开发工作，只满足做一些试验性质的代码工作（对呀，现在开源东西这么多，流行的东西组装一下架构设计就算over了么，还实现什么设计）和指导工作，甚至有些paper的架构师，完全就是靠粗读各种pattern和x宝典来做设计，设计的可行性和高风险性，可想而知，早期大量EJB的滥用导致的项目失败，其实根本原因在于甚少有架构师以验证演进的手段来决定是否应该使用EJB，怎样合理的使用EJB，将架构设计草率的外包给各大原厂商鼓吹的概念或者各种blueprint。而小兵们在面对架构+模式两顶大帽的时候也只会怯懦的怀疑自己的个人能力，然后坚持不懈的向架构师这一伟大位置继续奋斗。
而另一方面项目管理者也往往会误以为有了正规的架构设计就可以更好的保证软件项目质量，可以将项目的重心放置在需求和非技术工作之外，可以不用再考虑一般程序员的技术能力问题， 可以大幅度的xxx，xxx， 最后一堆苦水，然后再把责任归咎于架构师不成熟。
我早年经历过的几个项目就有此方面沉痛的教训，事后我个人复审设计，发现基本上整个方向都是错误的，个别项目设计者甚至连EJB的一些基本概念都没有了解，自己重头实现了一遍。过长的验证周期导致后期已经无法再做任何修改，只能咬牙吞下。
真正实用的架构是以逐步严谨的方式验证出来的，即便是自称中国java NO.1的袁红岗告诉你EJB非常好，没有EJB的架构就不是真正的J2EE架构，你也要验证以后再说，在此顺便bs一下csdn。
在那篇架构师之死的小品里，boss问小兵，你如何说服大家要使用hibernate？ 其实答案很简单，架构又不是设计出来的， 为什么要说服？