2.架构有什么用途？
  继续看书里的答案。
 
3.各个流派用什么视图来表达架构？
  最经典的RUP 4+1，ISO/ITU-T联合制定的RM-ODP，Hofmeister在《Applied Software Architecture》中使用的西门子视图，《Documenting Software Architectures》使用的方法等等。

4.架构师在软件生命周期中的工作和角色？
   架构师在分析，设计，实现，测试，维护，技术风险管理，问题域分析，团队技术领导与沟通者等方面的工作。

5..架构师的技能？
  自己总结了一篇《架构师核心技能养成计划》

答案：
1.IBM DW 中文站上有四篇不错的入门文章：
一、什么是软件架构？
二、软件构架师的特点
三、软件架构的过程
四、进行软件架构设计的益处 

2.《Large-Scale Software Architecture》的前50页也回答了同样的问题。

不过这些答案从字面上看都是大家熟悉的东西，很容易泛泛的看完了，过一阵子脑子里又十室九空，最好是能够看进去产出化学作用，再辛苦一点把它们总结成自己的文档。

And then? 可以开始一些How的问题了.....

一、核心竞争力

架构设计的理论、模式与技术
    架构师们从试验与挫折中获得架构设计的技能，但其中大量的原理、模式和技巧，都经历了一个重复发现的过程。
    其实，各路神仙在这个领域虽则没有捣鼓出大热的畅销书来，但前篇的架构师书单，也足够为我们作一个系统的知识整理。
    痛苦回首，发现自己的再发现式积累还是太慢、太片面，大多局限于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中偷师...

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1511545

   一、Software Architecture篇

     这个领域没有什么"畅销书"，可能读者中本来就是开发设计人员与项目经理占了多数，真正定位为架构师而且做的也是架构师工作的不多吧。

   1.《Software Architect Bootcamp--软件架构师教程》

    架构师新手训练营，可惜常以Corba做例子。第2版国内还没有翻译，只好看完中文的第一版再去看电子版了。
   
  2. 《Large-Scale Software Architecture-A Practical Guide using UML--大型软件体系结构：使用UML实践指南》
   如果看不惯上一本，可以改以这本作为入行指南。

 

 3. 《The Art of Software Architecture: Design Methods and Techniques--软件体系结构的艺术》

    薄薄的一本，架构理论的抽象与提升。
 
 

4.《Documenting Software Architectures: Views and Beyond--软件构架编档》

     第13届JOLT大奖作品，市面上介绍UML描述架构的书很多，但捕获架构的过程，为什么这样捕获的书籍就少了，所以它拿JOLT。
 

   二、架构模式篇

    GOF23属于开发人员的Pattern，架构师同样也有架构师的Pattern。

1. 《Head First Design Patterns》

      最好的GOF23经典设计模式讲解。
 。

2. 《Patterns of Enterprise Application Architecture--企业应用架构模式》

    Martin Fowler经典。
 


3. 《Analysis Patterns: Reusable Object Models --分析模式》
    Martin Fowler作品，但需要刚好有那个经验的人才看得进去。


4. 《Domain-Specific Application Frameworks: Frameworks Experience by Industry--特定领域应用框架：行业的框架体验》
 介绍了特定领域特定框架的设计，我自己最喜欢看人家的设计与思考。

    


三、特定领域模式篇

1. Java EE领域
   《Effective Enterprise Java--中文版》    

    Neward, Ted作品。

   《Expert One-on-One J2EE Design and Development--J2EE设计开发编程指南》

     Rod Johnson作品，依然使用J2EE的倒霉架构师需读。



      


2. SOA/ESB领域 
《Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions--企业集成模式：设计、构建及部署消息传递解决方案》

 


3. 网络与后台服务编程领域
《Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects, Volume 2--面向模式的软件体系结构 卷2:用于并发和网络化对象的模式》

《Pattern-Oriented Software Architecture: Patterns for Resource Management, Volume 3--面向模式的软件体系结构卷3：资源管理模式》

    著名的POSA2与POSA3。

 

四、RUP/UML 篇

    除了RUP、UML、4+1视图，架构师们还可以遵循很多的设计方式，但UML仍然是架构师们的通用语言，RUP还是架构师职责最清晰的任务执行流程。

1. RUP最好的书其实是那份《RUP－软件开发团队的最佳实践》加上 RUP2003.6.15 中文版自带的架构师视角的文档，还有空可以看看《The Rational Unified Process:An.Introduction.第3版》


2. UML随便看一份电子书也能入门了，语法方面不需要专门买书。但教人如何画好UML的《The Elements of UML Style--UML风格》就很必要，可惜国内没有翻译第2版。

五、闲书篇

1.《Code Complete 2--代码大全2》

    一本你教育小弟时的代言人。
 

2.《The Pragmatic Programmer--程序员修炼之道：从小工到专家》

    一本你启发小弟的代言人。
 


3.《The Art of Unix Programming --UNIX编程艺术》

六、高效读书心得

   刚好Head First系列开头都有一段教人如何读书的话，结合自己的经验整理如下：

1.尽量阅读中文版
  虽然有人英文很强，有的翻译很差，但AnyWay 中文阅读与理解的时间，略读与快速定位感兴趣内容的速度还是要快一些。
 
2.即时批注、总结笔记与交流
  虽然爱书，但发现最有效的读书方式还是不断的制造脂批本，读书时在重要的文字下划线，把自己的心得写在页旁。
  读完后，把上面的划线与批注，用自己的语言重新整理表述。有人喜欢用MindManager，我还是习惯纯文本123。
  最好在明天复习一次，或者拿来与人讨论。
 
3.大量思考或重复记忆
  看书最郁闷的事情就是看完之后脑袋空空了。偏重技术的书还好点，虽然看的时候可能很辛苦，但就像学会了骑单车之后，再骑的时候总是会的；而偏重设计与管理的书，最容易的事情就是看的时候很快，看完没什么留下到项目实践中。
  所以，我们不能以看小说的速度来看设计书，要寻找思考的机会，思考是最好的记忆。
  如果实在没有思考的topic，就只有大量的重复记忆，重复多遍直到无意识的记忆。 
 
4.人体工学
  那些见缝插针的时间与地点不是看这个书单的好地方。
  环境不要有电视，音乐等强输入源，而微风阳光鸟语等弱输入源则有助活跃大脑。
  看书时大量的喝水。
  如果发现自己的大脑已经疲累，已经在浮光掠影的翻看，就要休息。
  留给大脑消化的时间，看完书不要接着看其他有难度的书或事情。