架构师核心技能养成计划

 作者：江南白衣，原文出处： 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都分不清，一句"这里搞个异步调用的middleware，有commercial support的"，同样是层次太高了。架构师对各大公司的完整产品线和著名的开源项目应该有宏观上的了解，最好在Wiki里编个索引。
     但同时也要抵制成为某项技术专家如Oracle启动参数优化专家的诱惑，技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能带来天大好处。

与业务域开发域人员沟通的能力及其他领导能力
 
   IT 架构师处在客户和开发人员之间，必须能够使用各种媒体（代码、模型、文档、PowerPoint以及谈话和讲座），与技术和非技术的干系人进行沟通。另外，架构师好歹也是个半大不小的官，其他领导必要的能力就不列了。
   
    参考了IBM DW中国上的两篇文章：

• 软件构架师的特点
• 观点与展望，第 3 部分: 什么是最有价值的 IT 体系结构技能，如何学习？

   

三、镜子做好了，自己先照一下

• 要把书单啃完；
• 要熟悉NGOSS、3G、IMS这些业务知识；
• 要把公司几百个项目的设计文档抽好的看一遍；
• 要跟随公司最新一波RUP+CMMI3行情；
• 要重修C++；
• 要完整了解一遍IBM、BEA们的产品线；
• 要从那些写得好的架构PPT中偷师...

评论

17 楼 zqrain 2007-07-16  

个人观点：软件项目或者产品复杂到一定程度，架构师还是非常有必要的。

江南白衣所提到的项目就是我认为的复杂到了一定程度的项目。

引用

将Architecture无限放大将压缩下层技术人员的技术决策权利

客观来说，过分的民主还不如集中有效率。（当然，我非常赞成软件开发过程中，民主的正面作用）。我觉得Architect的职责在很多大型项目里面的作用和必要性还是很显著的。至少，不可能指望所有的工程师对项目都有全局认识，对于大项目，这个对很多普通工程师来说，要求太高了。

16 楼 mzrj 2007-03-26  

                   

15 楼 lawever 2007-02-26  

那么引子中的那个问题该怎么回答？

14 楼 ozzzzzz 2007-02-20  

江南白衣 写道

hehe，那就是战术层面的吧。战略层面的的确是CTO和总工了。

但书单的书，应该对战术层面的架构师也适合吧。IBM DW的文章里还有架构师组的提法，一些大的项目，由一组架构师互补长短的进行共同设计，应该也是指战术层面的架构师。

DW是默认RUP为官方方法了，所以他们提出这样的概念我一点也不奇怪。
然而古话说“名不正，言不顺”。将Architecture无限放大将压缩下层技术人员的技术决策权利，同时造成对Architecture为核心构建程序的组织以臃肿组织结构和庞杂的管理系统。在我看来Architecture更多的是被提炼出来的设计规则，而不应该去被设计。

13 楼 adamzhao 2007-02-19  

江南白衣 写道

隐藏票又长了....看来讲开发人员或者项目经理的事情大家心里都有同感，而架构和架构师，在大家在不同的组织，面对不同的项目时都有不同的定义，而且这些定义在自己的范围内都是对的，所以就难说到一块了，怪不得这个领域也没什么大卖的书了....

白衣其实也不必太关注隐藏票的增减。
从文章上看，白衣很努力， 不过如果跟我们现在大多数人的理解差不多，而表述又不够清楚精炼的话，难免受到打击。 继续努力哦...

12 楼 江南白衣 2007-02-19  

隐藏票又长了....看来讲开发人员或者项目经理的事情大家心里都有同感，而架构和架构师，在大家在不同的组织，面对不同的项目时都有不同的定义，而且这些定义在自己的范围内都是对的，所以就难说到一块了，怪不得这个领域也没什么大卖的书了....

11 楼 江南白衣 2007-02-19  

hehe，那就是战术层面的吧。战略层面的的确是CTO和总工了。

但书单的书，应该对战术层面的架构师也适合吧。IBM DW的文章里还有架构师组的提法，一些大的项目，由一组架构师互补长短的进行共同设计，应该也是指战术层面的架构师。

10 楼 ozzzzzz 2007-02-19  

江南白衣 写道

我觉得如果一个系统，并不只由一个单体的程序组成(即使是这个单体程序可能分布成一个负载均衡的群集)，而是由几个程序运行在不同的服务器上共同组成的时候(比如仅一个接入系统就需要radius server,认证server,在线server，实时计费sever,详丹与帐务server，业务管理server，对外接口server，数据库，数据仓库等等),这时就需要架构师了。我们单位目前的很多软件都属于这个类型，所以还是需要架构师啊：）

ozzzzzz 写道

我觉得江南白衣对于framework和architecture的区别还是有所混淆，至少不比rup中说的清楚。包括他列举的那些书单和所说的方法，都只是给类似公司总工的人的，而不是给类似Gates这样的构架师的。
可以说构架师80%的成分是管理和企业组织以及市场方面的，只有20%才是技术方面的。当然这20%的重要程度是50%。然而一个小型的软件公司（基本上国内所有的软件公司都包括在内），他们没有复杂的产品线，也没有很多历史用户负担，更没有那么多的细分市场，搞一个构架是不核算的，更不用说搞一个构架师了。

NO!
这个时候你的工作最多的依然是framework层面的。Architecture最大的用途，是治理公司的经营和生成结构，和人员结构，以及销售策略，更多的是战略层面的，而不是战术层面的。

9 楼 wolfsquare 2007-02-19  

白衣说的是软件架构师，其实还有一种叫做系统架构师。。。

8 楼 江南白衣 2007-02-19  

我觉得如果一个系统，并不只由一个单体的程序组成(即使是这个单体程序可能分布成一个负载均衡的群集)，而是由几个程序运行在不同的服务器上共同组成的时候(比如仅一个接入系统就需要radius server,认证server,在线server，实时计费sever,详丹与帐务server，业务管理server，对外接口server，数据库，数据仓库等等),这时就需要架构师了。我们单位目前的很多软件都属于这个类型，所以还是需要架构师啊：）

ozzzzzz 写道

我觉得江南白衣对于framework和architecture的区别还是有所混淆，至少不比rup中说的清楚。包括他列举的那些书单和所说的方法，都只是给类似公司总工的人的，而不是给类似Gates这样的构架师的。
可以说构架师80%的成分是管理和企业组织以及市场方面的，只有20%才是技术方面的。当然这20%的重要程度是50%。然而一个小型的软件公司（基本上国内所有的软件公司都包括在内），他们没有复杂的产品线，也没有很多历史用户负担，更没有那么多的细分市场，搞一个构架是不核算的，更不用说搞一个构架师了。

7 楼 lordhong 2007-02-19  

好文,怎么会有人投"隐藏"? 过分了点吧... 难道是嫉妒? 嘿嘿...

6 楼 ozzzzzz 2007-02-19  

不过我声明，隐藏不是我投的。

5 楼 ozzzzzz 2007-02-19  

我觉得江南白衣对于framework和architecture的区别还是有所混淆，至少不比rup中说的清楚。包括他列举的那些书单和所说的方法，都只是给类似公司总工的人的，而不是给类似Gates这样的构架师的。
可以说构架师80%的成分是管理和企业组织以及市场方面的，只有20%才是技术方面的。当然这20%的重要程度是50%。然而一个小型的软件公司（基本上国内所有的软件公司都包括在内），他们没有复杂的产品线，也没有很多历史用户负担，更没有那么多的细分市场，搞一个构架是不核算的，更不用说搞一个构架师了。

4 楼 downpour 2007-02-19  

一个构架师比较重要的是能够根据业务的不同选择使用不同的技术选型来满足客户的要求吧。

可惜现在这样的人不多。

3 楼 江南白衣 2007-02-19  

呵呵，好像有位老大砸了19票隐藏阿，看在俺年初一凌晨还在码技术帖子的份上，别砸得这么狠嘛:)

2 楼 有思想的芦苇 2007-02-18  

"自行编制一个wiki "真的那末重要吗?

1 楼 抛出异常的爱 2007-02-18  

算不算新春第一礼？