作者:江南白衣,原文出处: http://blog.csdn.net/calvinxiu/archive/2007/02/18/1511545.aspx,转载请保留。
引子:
"这个项目的架构是什么?"
对方爽快的回答:"Spring+Struts+Hibernate。"
嗯,这位很可能不是架构师......
一、核心竞争力
架构设计的原理、模式与技术
未经培训的架构师们从试验与挫折中获得架构设计的技能,但其中大量的原理、知识、模式和技巧,都经历了一个重复发现的过程。
其实,各路神仙在这个领域虽则没有捣鼓出大热的畅销书来,但前篇的架构师书单,也足够为我们作一个系统的知识整理。
悲哀的发现,自己的再发现式积累还是太慢、太片面,大多局限于GOF23、Java EE架构模式、RUP 4+1视图等方面。
满足架构质量属性所需的软硬件知识
如何满足性能,伸缩性,扩展性、可靠性,容灾,可恢复性,可管理性这些质量属性,是架构师的饭碗级知识,如构件分布式通信的知识。
有序的以方法为驱动源的任务执行
匠级的架构师多有一套自己的方法论、过程论,每回设计都是熟练而有序的执行。
架构师在软件开发中的过程,以RUP为基础的剪裁被描述得最为详细,可执行度最高的。
而核心的架构过程,直觉与模式,有序与混沌的平衡,就只有反复试验,独家秘制。
领域知识与业务分析能力
技术人员一般抗拒学习软件开发以外的东西,但架构师却非如此不可。
BTW.G9写过一篇很有意思的〈商业软件编程很无聊?〉
大型项目的经验
中国有多少架构师,不在于有多少人通过了什么考试培训,而在于中国大型项目的数量。
问:你这个项目的架构是什么?一口回答:Spring+Struts+Hibernate。这位很可能就不是架构师了,因为这仅仅是技术Stack,项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。
除了亲自担任这些项目的架构师,如果明了它设计与决策的思路也是一样的。所以,尽量多读一下公司项目的设计文档,也愉快的接受其他项目组架构评审会的邀请。
二、基本能力
完整的软件开发生命周期经验
这个不用说了,幸好中国的架构师什么脏活累活都做过,甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了,差别只在于基本生命周期理论--RUP + CMMI3 + 敏捷原则的细节掌握。
精通一两种主流开发语言、保持当下架构的开发体验
国内的架构师到了三十岁以后很多就往理论上跑,而国外的架构师则在往上发展的同时保持下面的编程体验,所以国内多水王,而国外则多大师。
水王总会设计层次过高,与实现有断层,与开发人员难沟通,也没法自己哗啦啦编个验证原型。而且,人过三十之后学习能力下降,手艺放下了想重新上手还很难
但是,也不必要挽起袖子每月编码若干行,很可能你的"亲自出手"因为时间安排不来反而拖了大家的进度,但一定要保持一个体验。
宏观了解当前的技术与产品,追逐最新的技术潮流
架构师如果连Tuxedo与IBM MQ都分不清,一句"这里搞个异步调用的middleware,有commercial support的",同样是层次太高了。架构师对各大公司的完整产品线和著名的开源项目应该有宏观上的了解。
但也要抵制成为某项技术专家,如Oracle启动参数优化专家的诱惑,技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能有天大好处。
同时,架构师的知识结构必须是亘古真理+最新技术的结合,盲目追逐最in技术的不是架构师,但倚老卖老,张口就说你们年轻人就知道追逐新技术的同样也讨人嫌。
与业务域开发域人员沟通的能力、决策能力和权威和其他的领导能力
IT 架构师处在客户和开发人员之间,必须能够使用各种媒体(代码、模型、文档、PowerPoint以及谈话和讲座),与技术和非技术的干系人进行沟通。
另外,架构师必须注意培养自己的技术决策能力和决策权威。
最后,架构师好歹也是个半大不小的官,其他领导必要的能力就不列了。
参考了IBM DW中国上的两篇文章:
软件构架师的特点
观点与展望,第 3 部分: 什么是最有价值的 IT 体系结构技能,如何学习?
三、镜子做好了,自己先照一下
要把书单啃完;
要熟悉电信的业务知识;
要重点学习满足架构质量属性的软硬件知识;
要把公司几百个项目的设计文档挑好的看一遍;
要跟随公司最新一波RUP+CMMI3行情;
要重修C++;
要完整了解一遍IBM、BEA们的产品线;
要从那些写得好的架构PPT中偷师... |
|