分类：
2011-12-20 23:57:03
既然已经了解架构的含义，那我们再来看看负责创建架构的责任人：架构师。
架构师这个角色在任何软件开发项目中都是最有挑战性的。
首先，架构师是一位技术领导，这意味着架构师除了拥有专门的技能外，还必须拥有领导能力，领导能力也要能体现在组织中的职位上。
从职位上来讲，架构师是项目中的技术领导，应该拥有进行技术决策的权威。不过，很多时候架构师和项目经理的职责很容易让人混淆，下面用电影行业的职位来打一个比方，帮助大家了解他们的不同：项目经理是制片人（确保事情完成），而架构师是导演（确保事情正确地完成）。架构师和项目经理代表了这个项目的公共角色，对于项目外的关注人员来说，他们是主要的联系点。架构师尤其应该是创建一个架构及给组织带来价值的投资倡导者。
在决策方面，架构师要综合考虑，果断下决定。例如，在某些情况不清楚或没有充足的时间探究所有的可能性及有交付压力的情况下，如果架构师不能进行决策，那是不行的。而且这样的环境会很常见，架构师要接受这个现实而不是设法改变它。
有些时候，架构师会在决策时咨询其他人并营造其他人共同参与决策的环境，但是进行适当的决策仍然是架构师的职责，即使有时候这些决策并不总是正确的（当然，是事后才发现这些决策不正确的）。因此，架构师必须是厚脸皮的，因为他们可能必须纠正他们的决策并原路返回。
没有决策能力的架构师会使项目慢慢被破坏。项目团队会对架构师失去信心，项目经理将会担心，因为这些等待架构师决策的事项没有进展。更加危险的是：如果架构师没有制定关于架构的决策并编写成文档，团队成员会开始制定他们自己的（可能是不正确的）决策。
角色和人之间是存在差异的。一个人可能会履行很多个角色，一个角色也可能会由许多人来履行。由于架构师需要非常广泛的技能，所以，架构师这个角色可能会由多个人来履行，这时，架构团队中的每个人都可以充分运用他自己的经验来履行此角色。特别是在理解业务领域和各方面技术所必需的技能时，往往需要多人合作才能达到相关要求。有一点很重要，就是最终的团队必须平衡。
如果架构师角色由一个团队来履行，拥有一个首席架构师就非常重要了，他是架构团队的协调人，经常会有先见之明。没有这个协调人，要让架构团队的成员创造出内聚的架构，或做出决策是很困难的。
对于一个不熟悉架构概念的团队来说，为了达成共同的目的，建议团队应该创建并颁布一个团队规章。
优秀的架构师知道他们的优势和弱势。最优秀的架构通常由一个团队而不是个人创建的，这都是因为“众人力量大”，人多则见识更广和更深。
大部分架构师曾经都做过开发人员（几乎是绝大部分架构师都是从开发人员走过来的），同时，架构师应该了解软件开发流程，因为这个流程能确保团队的所有成员协调的工作。
这种协调性可以通过定义涉及的角色、从事的任务、创建的工作产品、不同角色之间的移交点来获得。因为在日常工作中架构师会影响许多团队成员，所以理解团队成员的角色和职责，理解他们正在生产和使用的东西对于架构师来说很重要。实际上，团队成员也非常希望架构师能够指导他们的工作。
架构设计会涉及技术知识，所以，一个架构师应该拥有一定程度的技术技能。不过，架构师不必是一个技术专家，他要关注的是技术相关重要因素，而不是细节（其实很多时候，架构师也是技术专家，而且对细节理解得非常深入）。架构师需要理解像Java EE或.NET这样的平台上可用的关键框架，但是不必理解这些平台程序编程接口（API）的细节。
架构师必须与项目中的开发人员打交道，只有当架构师承认开发人员的工作价值时，在架构师和开发人员之间的沟通才是有效的。这也说明了，架构师应该具有一定的编程技能，即使他们在项目中不必编写代码，也必须跟上技术更新的脚步。
架构师应该有组织地参与开发，并且尽可能地参与代码的编写。如果架构师参与实现，开发团队会从架构师那儿获得见识。架构师还可以通过查看他们决策和设计的第一手结果来进行学习，从而对开发流程给出反馈。
大部分成功的软件架构师都曾经是核心的编程人员。某种程度上来说，他们就是通过这段经历了解到业务的某些情况的。如果没有这些知识，要实架构上的重要元素（如源代码的组织、采用的编程标准）时，架构师将无法进行决策，架构师和开发人员之间将会存在沟通障碍。
另外，设计是架构设计的核心。架构使关键设计决策具体化，因此，架构师应该拥有很强的设计技能。关键设计决策指的是关键结构的设计决策、特定模型的选择、指导规格说明书等。
一个人不可能在短时间内获得设计能力，这是多年经验累积的结果。某些设计专家在回顾他们早期的工作时都会惊讶他们原来的设计是如此的不好。在学习一项新技能时，想要对此精通则必须进行设计实践。
架构师除了掌握软件开发技术之外，还要理解业务领域相关知识（可以说是必须理解），以便担任利益相关者、用户（他们理解业务）及开发团队成员（他们更熟悉技术）之间的中间人。
业务领域的知识除了使架构师更好地理解系统的需求之外，还能够确保他们及时捕获恰当的需求。另外，一个特定领域通常与应用到这个解决方案中的特定架构模型组（和其他资源）相关，知道这个对照关系可以极大地帮助架构师。
因此，一个优秀的架构师通常会平衡掌握软件开发知识和业务领域知识。当架构师理解软件开发但不理解业务模型时，可能会开发出只反映出他所熟悉内容但无法满足需求的解决方案。
熟悉业务领域使架构师能够预见到架构中可能发生的改变。既然架构受其部署的环境（包括业务领域）影响很大，对业务领域的正确认识会使架构师在可能改变的区域和稳定性方面做出更全面的决策。举例来说，如果架构师认识到在将来的某点必须符合新的调整标准，他会在架构中考虑这个需求。
在架构师相关的所有软技能中，沟通最重要。有效沟通所涉及的各个方面架构师必须全部精通。架构师尤其要拥有较强的口头、书面表达能力同时，沟通是双向的，架构师应该既是优秀的聆听者，也是优秀的观察者。
有许多理由说明有效沟通是项目成功的基础。很明显，与利益相关者的沟通对于理解他们的需求，以及就架构相关问题与他们达成（并保持）一致来说非常重要。
与项目团队沟通也是十分重要的，因为架构师不能只是简单地把信息传达给团队，他还要激发团队，比如他必须要传达（并强调）系统的愿景，让大家都了解这个愿景，而不是只有他自己理解并相信。
同时，架构师也必须是一位比较好的谈判专家。对于架构设计的许多方面，架构师需要与众多利益相关者进行交流，其中的一些交流则需要谈判技巧。
另外，架构师应特别关注如何在项目中尽可能早地把风险降到最小，因为这会对稳定架构所花的时间有直接影响。风险与需求（及需求中的变化）有关，消除风险的一个途径是精炼需求，以便这种风险不再出现，那么这就需要回退需求并和利益相关者达成一致意见了。在这种情形下，如果架构师是一位谈判高手，能够清晰明白地表明不同折中的后果，相信一定会事半功倍。
成功的架构师并不只是关心技术，他们还要对政治足够敏感，并且知道组织中的权力所在。他们可利用这些知识与恰当的人沟通，确保在项目的适当周期中获得相应的支持。
政策包括大量的不确定性，这会使许多技术人员紧张，让他们感觉仿佛在“客场”比赛，他们正处于一个不利的位置，因为他们的技术不能发挥出多大的威力。
实际上，组织中起作用的许多强制约束位于项目交付的系统之外，并且这些约束是必须考虑的。为了解决不同的意见，一个政策性流程是不可避免的。因此，与其谴责它，倒不如把政策理解成是处理不同意见的必然需求。
京东地址：
卓越地址：
