首先，何谓系统架构师？

 IBM工程师的说明是：
  架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他们负责让业务规则及需求与工程实践及限制相适应，以确保成功

 中文Wiki上的说明是：
  系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单

 这两个解释，加起来基本说明了系统架构师的定义。

JAVA系统架构师应该看的几本书

Thinking in Java
Effective Java

UML基础、案例与应用
UML入门提高

软件工匠
设计模式——可复用面向对象软件的基础

重构-改善既有代码的设计
敏捷软件开发-原则、模式、实践

企业应用架构模式
Expert One-on-One J2EE Development without EJB
 
软件工程——实践者的研究方法
软件领导－－成功开发软件的指导准则

后面的两本书，其实已经有点属于项目经理的范畴了，不过还不是很深入，看看对做成功的系统架构师是很有好处。

企业应用的系统架构师应该关注的几个方面

数据持久层的设计
 在Spring和Hibernate，ibatis出来以前，几乎每家公司都有自己的一套方法和架构，而架构师的50％的精力也会集中到这上面，EJB只是增加架构师的负担。在Spring出来以后，基本上，大多数的架构师都从重复设计这个轮子的无用功中解脱出来了。Rod的轮子太好用了，基本上，大家只要套上去就行了，或者，剩下最重要的事情，是选择一个合适的数据库连接池的开源项目吧

MVC架构的具体设计
 MVC只是个概要的概念，具体如何实现的具体技术很多，根据项目设计最恰当的架构

大并发性访问
 使用缓存，在数据量达到一定程度时，使用集群技术，优先考虑利用服务器的集群，其次是硬件集群，最后才是应用本身加入集群功能

超大数据量返回结果
 尽量使用分页，优化SQL语句，循环处理数据时尽可能共用对象，只保留关键数据，及时释放内存占用

超大文件的读取和生成
 尽可能快的读取大文件，并进行分析。写入大文件时，如何及时释放内存。学会适当利用操作系统的命令行资源来更快完成任务。
 
多线程的应用和管理
 线程池的管理和监控，线程的启动（包括定时启动），结束，回收，线程资源的释放
 
用户界面可用性设计
 平衡速度和可用性，恰当的使用异步和同步技术，展现关键数据为重点

分布式的数据交流和集成
 选择恰当的数据交互方式，从最泛滥低效的Web Service到最实用的文件共享

群集系统的管理
 如何确保缓存的同步？如何确保对象唯一性？如何保证各台机器的同步？
 是否采用EJB?如何利用J2EE的特性（例如JNDI)

复杂的业务规则
 规则引擎和工作流引擎场景和应用
 
其实，作为一个真正的系统架构师，不应该局限于企业应用的系统，这种系统往往有数据库的局限性，有时候，应该考虑是否可以横向跨越，直接对其它系统做一些架构考虑，在没有丰富的实战经验的前提下，而只是看了其它人的系统和代码，就能够给出有效的设计指导。

例如对于一个下载软件，可以有如下考虑：

 1. 未明和非法url的检验，已经下载失败的容许，信息记录
 2. 多线程下载一个文件,文件的切分和拼合，部分切片丢失的拼合可能性
 3. 下载线程管理
 4. 服务器或者P2P的机器之间的通讯协议
 5. 速度监控和限制
 6. 下载进度的监控和显示

作为一个在线播放软件,可以做如下考虑

 1. 播放速度的保证
   机器的问题基本不存在了，关键是网络问题。如何在检测网络速度，根据影片的质量，并缓冲足够多的内容，保证播放一直尽可能顺利的完成。

 2. 播放质量的保证
   如何利用DirectX等技术,最快的进行渲染,是自己写底层,还是利用已有的API

由于没做过类似的项目，可以写的东西还是少很多了。

系统架构师应该有的素质：

1、 实际的编程经验
  最少2年吧，多了就不说了，其实从大学就开始钻研的话，

2、 书面表达能力和口头交流能力
   综合利用架构图，UML图，文字和代码片断，表达自己设计思想，至于是Word还是ppt，应该通吃

  在开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

3、 自觉主动;积极解决设计问题
  架构师的日常工作目标经常并不明确。很多开发人员直接参考功能规范来列出任务清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

4、 抽象思维能力和总结能力
  架构师，顾名思义，在系统未搭建好之前，就要能够有一个草图在心。而如果是对现有系统的改造，那么能在看过系统的文档（如果有的话）和代码后，就能总结出系统的架构特点。
  架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

  开发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

5、 全面的技术资讯吸收能力和选择鉴别能力
  作为开发人员出身，对于某一个具体问题的研究能力（虽然很多人总结为google能力），已经相当具备了。但是对技术资讯的全面接受和选择性深入了解能力，并且做出正确的判断，那些技术无非是厂家的噱头，而那些技术是真正可以用到项目，提高项目质量的好技术，这种能力确实至关重要的。

   2005年即将成为历史，看到很多人都开始写年终总结，我也忍不住了。"温故而知新"有点不敢当，不过在总结的过程中，我发现了自己取得的进步，也发现了许多不足之处，倒是让我感觉到有些意外。 OK，废话不说，正式开始了。

一、项目

1)        广州市XXXXXX数据交换系统

这是一个比较复杂的数据交换系统，提供本地数据库和XML的双向数据交换功能。其中Xml的格式在XSD（Schema）文件中定义，Schema文件的数量非常之多，，格式非常复杂。我们借助了一些自定义的配置文件（根据XSD生成、格式类似于目标Xml格式），才完成了这一过程，并又一次将巨大的工作量转移到配置人员那里去了。

在编码过程中，我编制了很多巨大的Class（2000行以上）和Method（400行）。幸运的是，在项目尾期，我对它们进行了一定程度的肢解（那个时候不知道啥叫重构）。

2)        广东省XXXXXX管理系统

负责了详细设计和数据库设计。元旦前成功的收到了项目开发阶段款，cheers!不过，目前仍在由其他同事进行尾期的开发。

• 项目中大胆使用了Nhibernate（version0.8）作为ORM工具，开发效率和运行效率都不错，唯一的遗憾是蹦出来的Exception的Message是E文的
• 自设计了非常简单的工作流，配置也很简单
• 项目采用了迭代式开发，效果非常不错
• 在进行性能优化以前，如果数据量大，查询效率非常低，经常查到超时（30万行数据）。后来对数据库增加了必要的索引，改造了聚簇索引，SQL Server的表现就非常强劲了，即使复杂的业务也基本感觉不到延迟。
  

二、书

今年确实看了很多书
 

书名	进度
UML基础、案例与应用	一遍完
.net本质论 第一卷	一遍完
敏捷软件开发-原则、模式、实践	正在第二遍
重构-改善既有代码的设计	一遍完
J2EE Development without EJB	第一遍即将结束
企业应用架构模式	一遍完
Struts in Action（电子书）	一遍完
Spring in Action（电子书）	一遍完
UML入门提高（电子书）	正在第二遍

三、积累

1)        学到了很多关于架构方面的知识，努力争取成为一名架构师是我的近期目标。

2)        《敏捷软件开发》和《重构》两本书对我的编码风格造成了很大的影响。现在，我不再编写巨大的类和冗长的方法。这本书，让我对优雅代码产生了崇拜心理，这种崇拜在我目睹了Entprise Library时达到了顶峰。

3)        XXXXXX管理系统是我在设计上的处女作，幸运的是，这不是一个很复杂的系统，虽然我的设计后来被证实存在一些缺陷，但是其他同事的极度的容忍和超强纠错让我蒙混过关了。

4)        写文档比写代码要难。我为XXXXXX管理系统写的《详细设计说明书》没有人愿意看。到最近，我才感觉到我的文档能力有了长足的进步，我不再为了写文档而写文档，而是带着阐述问题和解决方法的目的。这一点跟我老大的帮助息息相关。老大亲自对我的文档用红色字体做了许多中肯的批注，老大也让我将一份简单的visio图重画了三次，一次是因为图形之间没有对齐，一次是因为图形在100%视图下面没有对其到网格线。，还有一次是因为动态连接线没有对齐到网格。

四、遗憾

1)        未能在Office System领域有任何作为

参加了广州几乎每一次的OTEC会议，每一次都是看别人谈天侃地。

2)        在不懂设计的时候做了设计、在不懂文档的时候写了文档

不过任何事都有第一次的嘛

五、信条

1)        只要有一台PC或者NB在50米之内，我永远都无法安心看书

2)        郁闷了一定要找个东西发泄，可以是陪你喝酒的酒友，也可以是一堵墙

3)        怀着一颗感恩的心看世界

4)        世界越复杂，我们就应该越简单

架构师 的专业发展方面也与此类似。越来越多的 IT 组织开始认识到良好软件体系结构的重要性，架构师职业正迅速发展为 IT 内一个独立的门类。由于要从相当小的候选范围内招募架构师，因此这就给管理带来了一些新挑战。即使人力资源部门找到了候选者，针对经验进行的筛选也比其他 门类更为严格。跨越这些障碍的最快方式是要认识到，大部分好的架构师同时也是好的开发人员，因此寻找架构师人才时可能首先应该从普通开发人员中找起。招聘 人员在对候选者(内部或外部)进行详细审查时，应该考虑这个观点。不过，对此资源进行挑选可能比较麻烦，因为只有极少的优秀开发人员具有成为架构师的特征 或愿望。

本文列出了开发人员成为架构师要进行的工作。我将从可能考虑进行此转型的开发人员和评估进行此转型的开发人员的经理这两个方面来探讨这一问题。我还将提供一系列在做出这些决策时要考虑的因素。

个人特征

软 件开发团队和管理层之间的联系始终是 IT 中的一个关键所在。二者都倾向于以完全不同的方式考虑给定的问题。大部分相关技术都是讨论项目经理应如何跟踪和解释开发人员的进度和问题。但沟通不足的情 况仍然非常普遍，而且这是项目失败的首要原因。好的架构师是解决这个问题的最有效办法。架构师的主要责任是提供开发人员和项目经理之间的共用沟通媒体。他 们负责让业务规则及需求与工程实践及限制相适应，以确保成功。以下是成功架构师的一些主要特征。

愿意并有能力进行沟通：在 开发人员中发现架构师的最有价值标准是有效的沟通。您需要技术娴熟、经验丰富的开 发人员，这样的人员需要有就项目中的业务相关问题进行沟通的经历。架构师经常必须对理解方面的差距进行预计，然后才能有所贡献。他们必须愿意克服困难来确 保技术和业务观点的融合。他们并不必对意见交换工作进行计划和协调;这仍然主要是项目经理的工作。他们的任务是确定表述系统设计时的最佳工具和构件，以促 进有效的意见交换。他们必须能够判断当前方法显得不足而需要采用新方法的情况。写作技能也非常重要，还需要具有制作草图的技能或使用制图软件的能力。

具有处理谈判细节方面的经验：架 构师经常需要负责讨论系统开发的技术折衷方案。优先级的冲突可能会带来实践 限制、风险规避或可能导致在各个不同业务组之间需求不同。优秀的架构师能够有效地评估技术可能性，并能在不损失项目的主要价值的前提下制订开发计划来处理 各种利害关系和限制。这与前面讨论的沟通技能紧密相关，但同时也要体现架构师的技术能力。好的架构师候选者应该是经常帮助对有争议的讨论进行引导的人，能 够使讨论得出新的想法，而不会使其在一个位置停滞不前。

自觉主动;积极解决设计问题：架构师的日常工 作目标经常并不明确。很多开发人员直接参考功能规范来列出任务 清单。架构师通常则是向这些开发人员提供所需结构的人员，以便尽可能提高工作效率。好的候选者不仅进行沟通方面的工作，而且也会预计各种设计问题并加以解 决——通常在没有任何具体指示的情况下自觉进行。无论所分配的职责如何，积极参与项目的开发人员都有机会从一起工作的人员中脱颖而出。

抽象思维和分析：架构师必须能够理解表述模糊的概念并将其变成相关各方能够理解的项目构件。他们必须能够理解抽象概念，并以具体的语言对其进行沟通。开发人员中好的候选者经常要求或自己主动解释开发生命周期中容易混淆的问题。他们能迅速评估各种想法并将其纳入后续工作的操作建议中。

开 发人员经常具有很强的数学能力，而好的架构师则倾向于表现出更强的口头表达能力。管理人员经常说开发人员具有“工程意识”，而这是一个用于评 估架构师的非常有意义的方面。架构师应该具有很强的解决技术问题的能力，但还必须能够准确获知更为全面的人员如何与技术交互的信息。这要求具有某种形式的 抽象思维(而不再是代码的细节)，这种思维能力可能较难形成。

有些人认为，某种级别的正式教育是成为优秀开发人员的必备条件之一，我并不同意这种精英论。我遇到了很多高中就辍学的优秀开发人员。不过，对于体系结构设计工作，我的个人经验以及我对所需能力的认识都让我相信，好的架构师通常至少获得了一个有挑战性的学士学位。

跟踪生命周期

好 的架构师通常有在具备定义良好的软件开发生命周期(Software Development Life Cycle，SDLC)的组织工作的经验。架构师必须理解在其所属专业内最重要的操作过程。这并不意味着需要有其他前提，例如，并不需要高能力成熟度模型 (Capability Maturity Model，CMM)级别的工作经验。好的架构师可能来自使用 SDLC 的多个小型迭代的极限编程(Extreme Programming，XP)方法的组织。务必注意各种传统软件开发操作，如 Michael A. Jackson 的方法：Jackson 结构编程(Jackson Structured Programming，JSP)和 Jackson 系统开发(Jackson System Development，JSD)。Jackson 的研究对架构师职业发展的意义就像 Donald Knuth 的研究对程序员一样重要。架构师可以偏爱任何经典的、经过时间考验的软件系统开发方法。

SDLC 也可以成为评估架构师合适人选的有用机制。每个 SDLC 阶段都具有能提供相关线索的特征。SDLC 包含很多小的变体，但在此部分，我将使用几乎所有方法的公共基础部分。下面的列表详细说明了 SDLC 的各个阶段，并列出了好的架构师候选者在每个阶段表现出来的特征。

• 　　分析：在分析期间， 好的架构师会考虑非技术影响，以便了解需求和将在其中进行开发的 环境。架构师可为风险评估任务带来广泛的软件经验供参考。寻找具有丰富经验的开发人员，以帮助业务部门理解技术人员正确解释需求所需的信息。寻找在开发的 早期阶段能够预计可能遇到的问题的开发人员。
• 　　设计：在高级设计期间，好的架构 师会收集问题空间的各个抽象元素，并就其进行沟通，以便开发团队草拟将要开发的系统的相关图表。架构师负责将需求谨慎地映射到所得到的系统体系结构的功 能。在详细设计期间，他们所扮演的角色并不是核心角色，但为了根据整个系统的规则对特定模块的元素进行审查，仍然需要他们。寻找善于让团队能够预计设计决 策对最终系统的影响的开发人员。寻找善于确定一些最佳构件来促进与技术和非技术受众沟通设计问题的开发人员。
• 　　实现：在 实现期间，架构师对项目进行引导，以确保其符合系统体系结构。他们在一线评估技术更改请求，并确定如何对设计进行调整，以最好地处理此类请求。架构师还要 密切了解开发人员的进度，特别要跟踪系统中模块间的集成点的状态。寻找经常对讨论进行引导来连接多个子系统的开发人员。寻找项目经理可以依赖其快速地进行 与更改和出现的问题相关的风险评估的开发人员。
• 　　测试：架构师对系统集成和用户接受度测试进行指导，并负责评估进度的正确沟通的持续测试结果。寻找理解错误模式且善于将测试复查结果转换为行动计划的开发人员。
• 　　维护：在 维护期间，架构师将发起关于系统集成的讨论。无论处理 IT 基础设施问题，还是确保部门之间的技术合作，架构师都必须完全理解应用程序，必须快速学习姊妹应用程序的体系结构，而且必须就集成点和风险进行有效沟通。 寻找具有系统集成经验且表现出快速掌握全貌的能力的开发人员。系统集成是一项独特的任务。

架构师培养建议

有 些组织能比其他组织更有效地进行架构师培养。如果充分考虑到招聘此类新专业人才的困难，努力促成能鼓励开发人员发展为架构师的环境是非常明智 的策略。但务必避免对不愿意或不适合走这条路的开发人员进行处罚。组织应该为开发人员制订多条发展路线，包括那些愿意继续担任开发人员的人。对架构师而 言，资深开发人员不可或缺。他们可以实现系统中最关键的模块。通过对其他开发人员进行代码检查和测试支持，他们可帮助确保总体软件质量，而如果质量不能保 证，即使最好的体系结构也毫无用处。

组织应制订个人评估程序，以鼓励开发人员考虑其职业目标，其中要包含体系结构设计的选项。应该鼓励经 理在其下属中寻找体系结构设计人才。应该实 现指导计划，让架构师与希望成为架构师的开发人员协作工作。应该鼓励开发人员通过参加各种协会、撰写文章和参加会议，从而参与到专业领域中来。通过这样参 与进来，可帮助开发人员从新的角度理解系统，并帮助他们更好地就其认识进行沟通。这样还能培养可提高效率的重要创新想法。

结束语

1、  了解系统集成方面的知识

• 硬件基础知识
• 网络基础知识
• 行业的最新知识
• 软件工程基础知识

    我觉得一个架构师的知识面应该非常宽广，遇到难题，总能够想到最佳的解决方法，也即最合适的设计。所谓“复杂的系统，一流的设计”，一流的设计往往是最合适的设计，比如说分布式应用，可以使用WebService、Remoting、J2EE，架构师会方根据实际的情况做出最合理的选择。
 

2、  精通面向对象、设计原则、设计模式

        OO这是基础，OO的出现就是为了解决软件设计上的复杂性的。OO是很科学的东西，但并不是所有的地方都需要OO。个人认为OO的核心是多态，多态的核心是迟绑定。

    遵循设计原则是优雅设计的前提。过分遵循原则则是过度设计。

    架构师是直接参与设计的，设计模式解决的正是设计上的问题，所以，熟悉设计模式应该是必然的。有人说，36计就是模式。熟读36计的人并不一定都会使用36计。同样， 熟悉设计模式并不是靠看一两本诸如《C#设计模式》之类的书就够了的，必须经过很多项目的实践，做到收放自如。用最合适的模式解决问题，或者不用模式（并非每个地方都需要模式）。

3、  熟悉企业应用的特点、难题和解决方案
 

     企业应用架构同样有模式可循。Fowler在《企业应用架构模式》一书中给我们总结出了类似《设计模式》一书中的通用的模式供我们参考。 这本书读起来比较枯燥，但确实非常有用。
 

4、  2年以上的专职编码经验

    当然，如果你是天才的话，可能不需要两年。很多人认为架构师不应该参与编码，然而，很难相信，一个不会编码的人能够设计出优秀的系统。不断的了解编码过程中遇到的问题可以促使架构师改进设计。

5、  能够熟练的用代码、文档（birdshome、冬冬指出）和图形的形式表达自己的设计思想和设计理念