架构师的启蒙战歌
下面几个What的问题是架构师的入门Question。
1.什么是架构？
如果自问自答，这是个相当鸡肋的问题。看看书里的答案可能有点收获。
架构定义了系统元素的结构与行为，关注最重要的元素，记录决策原理，受涉众利益与环境的影响。
架构不仅是结构，也不是企业架构，系统架构，信息架构，硬件架构.....
架构设计也不是面向对象分析/设计，虽然架构设计基于面向对象设计，但补充了面向对象设计里没有关注的视点。
2.架构有什么用途？
人类所有行为都是目的驱动的，不同目的下架构的过程也会不同，继续看书里的答案，经常的用途有：
- 培训与沟通
- 满足系统的质量属性，与涉众沟通达成一致的目标
- 有效管理复杂性
- 支持开发日程安排、工作分配、成本分析
3.各个流派用什么视图来表达架构？
最经典的RUP 4+1，ISO/ITU-T联合制定的RM-ODP，Hofmeister在《Applied Software Architecture》中使用的西门子视图，《Documenting Software Architectures》使用的方法等。
RUP4+1架构方法采用用例驱动
需求阶段：用例视图（Use Cases View）,最初称为场景视图,关注最终用户需求,为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
架构设计：逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署,通常在UML中用类图,交互图, 时序图来表述,类似与我们采用OOA的对象模型
静态结构：开发视图(Development View), 描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统,也叫做实现视图(implementation view).开发视图 关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图,包图来表述. 开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
处理视图（Process view）处理视图关注系统动态运行时,主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题,在UML中通常用活动图表述。
物理视图（Physical view ）物理视图通常也叫做部署视图(deployment view),是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
运用RUP 4+1视图方法进行软件架构设计 ：http://blog.csdn.net/ajian005/article/details/6924804
4.架构师在软件生命周期中的工作和角色？
架构师的工作不只是设计(虽然最重要的的确如是），在分析、设计、实现、测试、维护、技术风险管理、问题域分析、团队技术领导与沟通者等流程里架构师都有自己的角色要担当。
5..架构师的技能？
自己总结了一篇《架构师核心技能养成计划》
答案：
1.IBM DW 中文站上有四篇不错的入门文章：
一、什么是软件架构？
二、软件构架师的特点
三、软件架构的过程
四、进行软件架构设计的益处
2.《Large-Scale Software Architecture》的前50页也回答了同样的问题。
3. 另外所有和架构沾点边的书都会忍不住浪费篇幅去讨论这些问题。
不过这些答案从字面上看都是大家熟悉的东西，很容易泛泛的看完了，过一阵子脑子里又十室九空，最好是能够看进去产出化学作用，再辛苦一点把它们总结成自己的文档。
And then? 可以开始一些How的问题了.....
=================================
架构师核心技能养成计划
作者： 江南白衣，原文出处： http://blog.csdn.net/calvinxiu/archive/2007/02/18/1511545.aspx，转载请保留。--last update 2007.3.25引子：
"这个项目的架构是什么？"
对方爽快的回答："Spring+Struts+Hibernate。"
嗯，这位很可能不是架构师......
一、核心竞争力
架构设计的原理、模式与技术
未经培训的架构师们从试验与挫折中获得架构设计的技能，但其中大量的原理、知识、模式和技巧，都经历了一个重复发现的过程。
其实，各路神仙在这个领域虽则没有捣鼓出大热的畅销书来，但前篇的架构师书单，也足够为我们作一个系统的知识整理。
悲哀的发现，自己的再发现式积累还是太慢、太片面，大多局限于GOF23、Java EE架构模式、RUP 等方面。
满足架构质量属性所需的软硬件知识
如何满足性能，伸缩性，扩展性、可靠性，容灾，可恢复性，可管理性这些架构质量属性，是架构师的饭碗级知识。
有序的以方法为驱动源的任务执行
匠级的架构师多有一套自己的方法论、过程论，每回设计都是熟练而有序的执行。
架构师在软件开发中的过程，以RUP为基础的剪裁被描述得最为详细，可执行度最高的。
而核心的架构过程，直觉与模式，有序与混沌的平衡，就只有反复试验，独家秘制。
领域知识与业务分析能力
技术人员一般抗拒学习软件开发以外的东西，但架构师却非如此不可。
BTW.G9写过一篇很有意思的〈商业软件编程很无聊？〉
大型项目的经验
中国有多少架构师，不在于有多少人通过了什么考试培训，而在于中国大型项目的数量。
问：你这个项目的架构是什么？一口回答：Spring+Struts+Hibernate。这位很可能就不是架构师了，因为这仅仅是技术Stack，项目规模不大时Spring+Struts+Hibernate才会成为架构的重点。
除了亲自担任这些项目的架构师，如果明了别人架构设计与决策的思路也是一样能拿经验。所以，尽量多读一下公司项目的设计文档，也愉快的接受其他项目组架构评审会的邀请。
二、基本能力
完整的软件开发生命周期经验
这个不用说了，幸好中国的架构师什么脏活累活都做过，甚至跟着市场人员跑去做演示这些国外架构师不一定有的经验我们都有了，差别只在于基本开发生命周期理论--RUP 、CMMI3、 敏捷原则的细节掌握。
精通一两种主流开发语言、保持当下架构的开发体验
国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。水王的设计多与实现有很大断层。而且人过三十学习能力下降，手艺放下了就别想捡起来了:(
但是，保持一个体验就好了，也不必要苦行僧似的要求自己每日编码若干行，很可能因为你的时间安排不来反而拖了大家的进度。
宏观了解当前的技术与产品，追逐最新的技术潮流
架构师的知识结构必须是亘古真理+最新技术的结合，盲目追逐最in技术的不是架构师，但倚老卖老，张口就说你们年轻人就知道追逐新技术的同样也讨人嫌。
架构师对各大公司的完整产品线和著名的开源项目应该都有个宏观上的了解。
但也要抵制成为某项技术专家，如Oracle启动参数优化专家的诱惑，技术细节掌握到业务职责需要的程度就刚好了。除非如Spring Framework进一步了解能有天大好处。
与业务域开发域人员沟通的能力、决策能力和权威和其他的领导能力
IT 架构师处在客户和开发人员之间，必须能够使用各种媒体（代码、模型、文档、PowerPoint以及谈话和讲座），与技术和非技术的干系人进行沟通。
另外，架构师必须注意培养自己的技术决策能力和决策权威。
最后，架构师好歹也是个半大不小的官，其他领导必要的能力就不列了。
参考了IBM DW中国上的两篇文章：
三、镜子做好了，自己先照一下
- 要把书单啃完；
- 要熟悉电信的业务知识；
- 要重点学习满足架构质量属性的软硬件知识；
- 要把公司几百个项目的设计文档挑好的看一遍；
- 要跟随公司最新一波RUP+CMMI3行情；
- 要重修C++；
- 要完整了解一遍IBM、BEA们的产品线。
=================================
架构师书单 2nd Edition
作者：江南白衣，原文出处： http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx，转载请保留。
为了2007年的目标，列了下面待读或重读的书单。
"其实中国程序员，现在最需要的是一张安静的书桌。"，的确，中国架构师大多缺乏系统的基础知识，与其自欺欺人的宣扬"读书无用，重在实践变通，修身立命哲学书更重要"，把大好时间用来追逐互联网上的片言只语，不如直面缺陷，系统的学习一次。
书单越读越薄，好书真的不多哇。
一、Software Architecture篇
这个领域没有什么"畅销书"，可能读者中本来就是开发设计人员与项目经理占了多数，真正定位为架构师而且做的也是架构师工作的不多吧，你懂的尽是偏僻的人生。
《Software Architecture in Practice,2nd Edition--软件构架实践(第2版)》
第一版是第九届JOLT作品，一本被引用很多的架构书。
《Documenting Software Architectures --软件构架编档》
第13届JOLT大奖作品，捕获架构的过程，徐昊推荐。
《Applied Software Architecture --实用软件体系结构》
另一本被引用很多的架构之书。
二、UML 篇
UML、4+1视图始终是架构师界最通用的东西，寻找一种向世界妥协的方式。
1. 《UML Distilled 3rd》
没什么特别想推荐的UML工具书，选本最薄的吧。
2.《The Elements of UML 2.0 Style》
胜在没有同类书。
3.《UML和模式应用(第3版)--Applying UML and Patterns 3rd》
UML+RUP作的OOAD过程。
三、特定领域篇
开发人员有GOF23 Pattern，架构师同样也有架构师的Pattern。不同领域的架构师需要不同的知识。
1. 公共领域
《Domain-Specific Application Frameworks --特定领域应用框架：行业的框架体验》
ozzzzzz推荐，介绍了30个特定领域特定框架的设计。
《Head First Design Patterns》
最好的GOF23经典设计模式阐释，适合被[GAMMA95]折磨的架构师拿来复习，中文版即将发行。
2. Java EE领域
《Patterns of Enterprise Application Architecture --企业应用架构模式》
Martin Fowler老书，企业应用各层上的模式。
《Effective Enterprise Java--中文版》
Neward, Ted作品，作者学贯东西(.Net与Java)，像写Blog一样，每一页里面都有大量的信息。
可惜两本都比较旧了，没有新版。
3. EAI/SOA领域
《Enterprise Integration Patterns --企业集成模式：设计、构建及部署消息传递解决方案》
4. 网络与后台服务编程领域
《Pattern-Oriented Software Architecture, Volume 2 --面向模式的软件体系结构 卷2:用于并发和网络化对象的模式》
《Pattern-Oriented Software Architecture, Volume 3 --面向模式的软件体系结构卷3：资源管理模式》
著名的POSA2与POSA3。
四、闲书篇
《Code Complete 2 --代码大全2》
一本你教育小弟时的代言人。
《The Pragmatic Programmer --程序员修炼之道：从小工到专家》
一本你启发小弟的代言人。
《The Art of Unix Programming --UNIX编程艺术》
五、高效读书心得
刚好Head First系列开头都有一段教人如何读书的话，再加工整理如下：
1.尽量阅读中文版
虽然有人英文很强，有的翻译很差，但AnyWay 中文阅读与理解的时间，略读与快速定位的速度还是要快一些。
2.即时批注、总结笔记与交流
虽然爱书，但发现最有效的读书方式还是不断的制造脂批本，读书时在重要的文字下划线，把自己的心得写在页旁。
在明天复习一次批注，最好可以有空重新整理笔记，或者拿来与人讨论。
3.大量思考或重复记忆
看书最郁闷的事情就是看完之后脑袋空空了。技术书还好点，虽然看的时候可能很辛苦，但就像学会了骑单车，之后再骑的时候总是会的；而偏设计与管理的书，最容易的事情就是看的时候很快，看完没什么留下到实践中。
所以，我们不能以看小说的速度来看设计书，要寻找思考的机会，思考是最好的记忆。
又或者，大量的重复记忆，重复多遍直到无意识的记忆。
4.人体工学
那些见缝插针的时间与地点不是看这个书单的好地方。
环境不要有电视，音乐等强输入源，而微风阳光鸟语等弱输入源则有助活跃大脑。
看书时大量的喝水。
如果发现自己的大脑已经疲累，已经在浮光掠影的翻看，就要休息。
留给大脑消化的时间，看完书不要接着看其他有难度的书或事情。
江南白衣架构师三版书单：
http://calvin.javaeye.com/blog/351007
http://calvin.javaeye.com/blog/57670
http://blog.csdn.net/calvinxiu/archive/2007/03/06/1522032.aspx