鼎鼎大名的SpringSide项目发起者江南白衣关于构架师的文章，不知道他最近是咋的了对讨论构架师这么感兴趣了，呵呵。还是希望发理论性文章的同时多一些实质性技术的好文章，继续支持！
这篇文章虽然有些不痛不痒，但是也可以算的上了解在中国国情下的构架师的好文章。什么是构架？并不是"Spring+Struts+Hibernate"，到底什么是构架，构架师到底要做些什么？听白衣细细道来！
作者：江南白衣，原文出处： http://blog.csdn.net/calvinxiu/archive/2007/02/18/1511545.aspx，转载请保留。
引子：
"这个项目的架构是什么？"
对方爽快的回答："Spring+Struts+Hibernate。"
嗯，这位很可能不是架构师......
一、核心竞争力
架构设计的理论、模式与技术
苦命的架构师们从试验与挫折中获得架构设计的技能，但其中大量的原理、模式和技巧，都经历了一个重复发现的过程。
其实，各路神仙在这个领域虽则没有捣鼓出大热的畅销书来，但前篇的架构师书单，也已足够为我们作一个系统的知识整理。
顾影自怜，发现自己的再发现式积累还是太慢、太片面，大概只局限于GOF23、Java EE架构模式、RUP4+1视图等方面。
有序的以方法为驱动源的任务执行
匠级的架构师多有一套自己的方法论、过程论，每回设计都是熟练而有序的执行。
其中架构师自己的架构设计小过程可以参考书单反复试验，独家秘制。
而与开发团队配合的大过程，以RUP为基础的剪裁被描述得最为详细，是可执行度最高的。
领域知识
技术人员一般抗拒学习软件开发以外的东西，但架构师却非如此不可。
架构师的职责就是将业务需求转化为系统设计，良好的领域知识才能保证转化的质量，与客户的沟通，以及有意识的让架构支持业务系统可能出现的变化。
那又如何快速成为新领域的专家呢？精通快速业务建模吗？BTW.G9写过一篇很有意思的〈商业软件编程很无聊？〉
大型项目的经验
中国有多少架构师，不在于有多少人通过了什么考试培训，而在于中国大型项目的数量。
问：你这个项目的架构是什么？一口回答：Spring+Struts+Hibernate。这位很可能就不是架构师了，因为这仅仅是技术Stack，项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。
除了亲自担任大型项目的架构师，如果了解这些项目的架构为了满足怎样的功能与非功能性需求而设计成这个样子也一样能增加经验值。所以，我们可以尽量多读一下公司以往项目的设计文档，愉快的接受其他项目组的架构评审会的邀请。
二、基本能力
完整的软件开发生命周期经验
这个不用说了，幸好中国的架构师什么脏活累活都做过，甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了，差别只在于一些理论知识--RUP + CMMI3 + 敏捷原则的掌握程度。
精通一两种主流开发语言、保持当下架构的开发体验
国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师则在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。
水王的设计一般会层次过高，与实现之间有断层，设计质量缺乏保证，与开发人员产生沟通障碍, 自己哗啦啦编一个验证原型的日子更是一去不返。
更痛苦的是，人过三十之后学习能力下降，手艺一旦放下了想重新上手还很难:(
但是，也不必要挽起袖子每月编码若干行，亲自出手编写某个模块，很可能你的"亲自出手"因为时间安排不来反而拖了大家的进度，但一定要保持一个体验。
宏观上的，广度优先的了解当前主流的技术与产品
架构师如果连Tuxedo与IBM MQ都分不清，一句"这里搞个异步调用的中间件，要有商业支持的"，同样是层次太高了。架构师对各大公司的产品线和著名的开源项目应该有宏观上的了解，最好在公司Wiki里编一个索引备忘。
但同时也要抵制成为某项技术专家如Oracle启动参数优化专家的诱惑，技术细节掌握到业务职责需要的程度就刚好了。除非进一步了解能带来天大好处，如Spring Framework。
与业务域开发域人员沟通的能力及其他领导能力
IT 架构师处在客户和开发人员之间，必须能够使用各种媒体（包括代码、模型、文档、PowerPoint以及谈话和讲座），与技术和非技术的干系人进行沟通，清楚、简洁地对体系结构决策进行描述、演绎和申辩。
另外，架构师好歹也是个半大不小的官，其他领导必要的能力就不列了。
参考了IBM DW中国上的两篇文章：
posted on 2007-02-20 16:43
cresposhi 阅读(997)
评论(2) 编辑 收藏