软件企业中的架构师职责探讨.docVIP

软件企业中的架构师职责探讨 　　摘要：软件架构是设计一切系统的基础和核心。许多软件架构师中盲目追求业务通用框架，会导致项目结束时，听到用户这样那样的抱怨。正是由于当今业界存在着这样或那样的误区，我们需要重新考虑并探讨软件企业中的架构师的职责是什么，如何成为一个真正意义上的软件架构师，该文就对此提出了自己的看法，同时对架构师自身存在的一些问题进行了分析。 　　关键词：软件；架构师 　　中图分类号：TP311文献标识码：A文章编号：1009-3044(2011)29-7295-02 　　随着软件工程行业对“软件架构师”的工作职责的认识愈来愈清晰，人们也逐步认识到具备优秀素质的软件架构师的资源稀缺的问题。但软件工程领域基本上没有一致的有关“软件架构师”的定义。 　　“软件系统架构是根据具有参考意义的实践而定义出来的。主要表述了一个系统的基本组织结构、基本组成构件和相互的关系，以及构件于外部环境间的关系。同时，软件系统架构为后续的设计和架构演化提供了指导性原则”――出自IEEE在2004年4月公布的“IEEE Standard 1471”。 　　“软件架构代表了一个系统的组织结构。这包括将系统分解为不同的部分、界定它们之间的连接、确定它们之间的交换机制、并且为后续的设计提供指导性的原则”――出自UML的原创者。 　　可以看出，一个软件企业中的架构师，应该具备怎样的素质和技能？也就是说，软件架构师的职责到底是什么？只有明确了软件架构师的工作职责，才能构建出满意的高品质架构及设计。 　　1 软件架构师应具备的素质 　　架构存在一个生命周期的概念。它包括从架构初步构建阶段、架构逐步优化阶段、架构成熟阶段、架构老化阶段到架构消亡阶段。为了延长软件架构的生命周期，对架构师所需经验和知识的要求也越来越高。 　　1.1 架构师的成长模型 　　作为架构师的预备阶段，在有限的时间和精力下，他们都是对某个单一技术方向进行了深入细致的研究和应用，成为这项技术方面的专家。而随着涉足的专业技术领域日渐扩展，开发人员开始在多个领域进行深入的研究，从而成为多个方向的技术专家。这样的日积月累，开发人员就会成为软件生产和开发方面的“全方位专家”。Chuck Kilmer在2006年提出的架构师成长模型（图1），就是典型的事例。 　　随着架构师在各个经验领域的拓展，他们的工作也会进一步的提升，所负责的软件产品及开发也更加广泛。他们会接触到更为复杂的商业环境及业务流程，同时也会接触到更多的相关角色。最终也会成长为一名合格的软件架构师。 　　1.2 架构师的工作能力 　　从2005年Keith Frampton教授发表了《架构师需要的能力》中我们能够清楚的看到，一个理想的架构师要具备人际关系、技术经验、推理分析、执行技能、流程技能、项目管理、商业技能、人员管理等8个维度的工作能力。 　　2 软件架构师的工作职责 　　软件架构师的应该具有以下几个方面的工作职责。 　　2.1 解决商业问题 　　架构师的重要责任就是挖掘隐藏在合同要求背后的真实需求，这不但可以最大满足客户，也可以帮助我们避开技术壁垒，能用更为简单的替代方案满足客户。这就要求我们引入“商业概念模型”这种有效分析和建模手段。一个有效的商业分析模型，有助于理解整个商业问题，建立一个软件系统存活的最高层面的大背景，并且详细记录和分析模型中各个元素及元素间的关系。 　　2.2 解决架构问题 　　架构师要具有面对功能方面、质量方面、系统灵活性、系统演化等诸多问题的解决能力。 　　简化根本复杂性：常常为了解决某一局部复杂性引入了更为复杂的框架或产品，使得复杂性不减反增。往往正确的方式是做减法而不是加法，把最根本的复杂源找到，把根铲除。 　　架构决定性能：最好提升性能的方法不是痛苦地做一次次对即将上线的产品做性能测试和提升，而是在架构设计的时候就把性能作为重要因素，从架构底层考虑分布式、缓存、系统交互划分等影响性能的重点。提前关注性能，是解决性能问题代价最小的方式。 　　不要为预防故障引入更多的故障：架构师常常会为识别出的可能故障点加入监控措施，但往往会忽略做些监控措施也是会有故障的，不要试图让你的系统天衣无缝，这往往是使系统更为复杂和脆弱的来源。先承认是系统总会有缺陷的，只是把这些缺陷设定为容易察觉和维护的点。 　　量化非功能性需求：作为架构师要有意识地去定义和量化性能、可扩展性等这些非功能性需求，只有这样才能更好地和其他部门更好沟通，谋求更多资源，也便于系统更有效地验收。 　　2.3 解决设计问题 　　从Gang of Four的经典设计模式的实质就可以看出，具有丰富工程经验的设计人员已经在很多方面的系统设计中进行了总结。当然，作为一个合格的设计人员，掌握设计模式这样的设计