软件架构师

出自 MBA智库百科(https://wiki.mbalib.com/)

软件架构师(Software Architect)

　　软件架构师是软件行业中一种新兴职业，是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。对一些大型软件产品或项目的开发，这一角色显得很关键，因为缺乏好的软件架构师而导致项目失败的例子不胜枚举，一个没有经验和能力的软件架构师也会使软件项目失败的速度加快。正因如此，MartinFowler指出：架构师是对所有重要事情作出决定的人。

　　软件架构师在整个软件开发过程中都起着重要作用，并随着开发进程的推进而其职责或关注点不断地变化。在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。此外，架构师还要经常审查客户和市场人员所提出的需求，确认开发团队所提出的设计；在需求越来越明确后，架构师的关注点开始转移到组织开发团队成员和开发过程的定义上；在软件设计阶段，架构师负责对整个软件架构、关键构件、接口的设计。在编码阶段，架构师则成为程序员的顾问，并且经常性地要举行一些技术研讨会、技术培训班等；随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点；在软件维护讦始时，软件架构师就要开始为下一版本的产品是否应该增加新的功能模块进行决策。

　　因此，软件架构师是软件项目的总体设计师，是软件组织新产品开发与集成、新技术体系的构建者，是从宏观上驾驭大型系统的战略家，是对软件项目中所有重要架构事情作出决策的人，是策略制定者、组织协调高手、称职的顾问与领导者。

　　好的软件架构师不只是一位受到尊敬的资深技术人员，通常也是策略制定和组织协调的高手，称职的顾问与领导者。这是因为软件架构规划与设计主要是以宏观的角度切入系统架构，一般所谓的设计则是以微观的角度切入。软件工程师和程序员所考虑的是单个构件的功能，而软件架构师必须从全局的角度理解软件项目的业务目的和期望结果，能够定义不同的构件是如何组装在一起的。软件架构师规划系统的角度主要是从自上而下的方式着手，而软件设计师则多半从自下而上的方式着手。这种从宏观／微观的角度进行划分，在其他学科也常看见，如宏观经济学与微观经济学等。这种宏观角度的本质，就是软件架构师专业领域与其他软件开发人员最根本的区别。

　　从宏观的角度，举凡架构规格与决策、排定架构审阅时程、解决所有架构相关的问题、所有主要技术决策的核准、维护架构规格等都是架构设计的主要工作。通常在项目一开始，需求与初始分析等工作流程会产生规划的企业流程与预期系统完成的功能。有了这些信息，软件架构师就能草拟最初的高层架构蓝图，并列出影响架构的可能的因素清单。另外，软件架构师也要担负估算项目成本的职责，评估项目计划对系统既有基础结构与架构的冲击，以及计算可能付出的成本与所带来的效益。

　　除了上述任务以外，检查初期架构规划设计、影响因素与成本，维持与组织架构决策的一致性也是架构设计师的重要职责之一。这通常要找出制定项目的架构决策与其优先级的判断基准、定义问题领域、决定可能解决方案的制约条件、确认有关可能解决方法的假设状况以及辨识模块重用的可能性。软件架构师也必须负责确保需求的达成，以及硬件、软件、基础结构、性能、安全性、容量、可用性和系统运行、管理与维护等属于系统层次相关技术之间的协调与平衡。在某些关键时刻，软件架构师也要做出系统与架构在协调、平衡上种种必须当机立断但又很难判断的决策。

　　软件架构师必须设法降低可能的技术风险对系统的冲击。在规划初期，技术风险对一般人来说通常都是不可知、不可验证也不可测的。风险大多与系统层次的需求有关，有时也会与组织需求有关。不论任何类型的风险，有经验的架构设计师都可在项目的先期也就是构建架构时期，预先列出这些可能的风险，然后在后续的开发时期配合开发人员予以适当地处理与解决。另外，架构设计师也必须领导开发团队，保持与其他成员的良好互动，确保开发人员是根据架构蓝图来构建系统。

　　总之，软件架构师的主要任务就是规划与系统架构层次相关的事务，评估可能的风险与成本，并有效运用有限的人力、物力资源满足系统层次的需求。优秀的软件架构师是保证软件系统强大生命力的核心人物。专业架构师能够帮助组织全面研究现有架构和设计模式、评估系统设计的优缺点和可能存在的风险，通过一系列的专题指导和具体案例帮助组织掌握先进的、成熟的设计模式，简化复杂的业务逻辑和需求，确定系统最佳方案。在必要的情况下，还可就特定领域或课题，为开发人员提供定制指导。

　　在一个较大规模的软件组织里，一般都有项目管理师、软件架构师、系统分析师、软件设计师、测试工程师、数据库工程师、程序员、过程改进、质量保证等不同的职位。在这些职位中，人们容易混淆的是系统分析师和软件架构师。对于系统分析师的角色，业界有两种观点，一种是把系统分析师当成既懂技术又懂管理的全能冠军，另一种是把系统分析师当作需求分析师，而架构师才是灵魂。那么，系统分析师与软件架构师在角色方面的分配究竟有什么区别呢?

　　当软件规模比较小时，系统分析师所完成的工作是把真正的业务需求(这个需求不是指客户简单所说的哪一个功能，而是需要去挖掘的，可能是潜在的但又是系统必需的，条例清楚、逻辑清晰的业务功能，而且需求不仅仅只是来自业务上的，系统所依赖的运行环境也会产生一些需求)转换成计算机可理解、可实现、可计算的模型。但由于现在的系统规模越来越大，复杂程度越来越高，而且应用领域也越来越广，所以很难由一个工种的人来全面完成这项艰巨的任务。

　　在具体的软件设计过程中，现在把它分解为由系统分析师与软件架构师合作共同来完成这一任务。其中系统分析师侧重的是前一部分的工作，软件架构师侧重的是后一部分的工作。系统分析师的主要工作内容包括业务需求分析、系统需求分析、可行性分析以及建模等，其特点是更多地与行业专家、用户沟通，再及时与项目经理(项目管理师)、软件架构师以及老板商讨，分析项目具备的特点、成本、风险等，考虑实现的模型。系统分析师所面临的往往是有许多不确定性的事件，需要对这些不确定的事件进行分析、总结，使之得出一个相对可靠的确定性结论或实施方案模型。

　　软件架构师的主要工作内容就是在系统需求比较清晰的条件下进行系统总体的架构设计，当然它也可能会涵盖一些系统分析师和软件设计师的工作内容，但其特点是确定性的东西会多一些，力求为系统找到或架构一·个最优的模型。这里面虽然可能有很多创新的成分，但更重要的是如何充分运用现有的各种模型、结构、方案，并根据项目．的特点，在各种方案中取长补短，找到一个最好的平衡点和结合点，使之最适合当前项目的解决方案。所以，软件架构师实际上是使系统细致化、完善化，为拥有更好的可靠性提供保障。

　　在实际的职责上，软件架构师比系统分析师所站的角度更高一些。在大规模的软件系统中，系统分析师可能就系统的某个子系统进行分析与设计，而软件架构师应该对整个系统的结构负责。

　　软件架构师一般都是具备计算机科学或软件工程的知识，由程序员做起，然后再慢慢发展为架构师的。在国内，很多大学目前还没有设立软件架构的学位课程，虽然IT业界对设计和架构的兴趣日渐高涨，但各学校还无法在课程中增加相应的内容来体现这一趋势。从这个方面来说，学校教育已经远远落后于产业发展。因此，促进和发展软件架构学课程的任务将落在现在的软件架构师身上。目前的软件架构师应该帮助各大院校建立相关课程体系，一旦教育课程建立起来，知识体将不仅通过新毕业生的工作成果来得到扩展，同时也会从适合软件架构的教育研究和出版物中得到扩展。虽然大学要加强软件架构学课程的建设，但是，软件架构师的成长应该有一个实践的教育过程，并不是简单的学校的理论学习或者通过大型软件公司的认汪就能成为合格的软件架构师。除了信息系统综合知识在学校学习外，软件架构师的大部分知识和经验将来自实际开发工作。一般来说，一名合格的软件架构师的成长应该经历8年以上的软件项目开发实际工作经验。一般需要经历程序员、软件设计师等阶段，然后再发展成为软件架构师。

　　当然，并不是每一位程序员经过8年后都可以成长为软件架构师的。一个软件工程师在充分掌握了软件架构师工作所必需的基本理论和技能后，如何得到和利用机会、如何利用所掌握的技能进行应用系统的合理架构、如何不断地抽象和总结自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才，这就在于机遇、个人的努力和天赋了。

　　就目前来看，国内软件架构师的培养途径主要有两种方式，一种是大学(软件学院)教育方式，另一种是个人自我培养然后再进行相应的培训和认证。但是，不管哪种方式都有其不足之处。

　　软件学院的培养方式能够系统地传授软件架构师必需的知识体系，但是，软件架构师不是简单的通过理论学习就能够培养出来的，软件学院的学生可能缺乏必要的设计、开发经验和相关的领域知识。尽管软件学院也强调给予学生实践的机会，但毕竟这种机会是有限的。有关“三分之一的师资来自企业”的规定，在部分软件学院中也没有得到真正落实，导致传授给学生的还是一些纯理论知识。

　　自我培养方式的主要对象是具有一定年限的软件开发和设计人员，如Microsoft、IBM、Sun等公司的软件架构师认证对学员的基．础并没有具体的要求，只要交纳规定的费用，然后进行几天的集中培训，通过考试就发给学员证书，甚至不需要考试就直接发放证书。这些开发人员在自我培养的过程中不一定能够系统地学习软件架构师的理论知识，他们只具有一定的开发和设计经验，仅仅经过几天的培训，是不太可能培养出合格的软件架构师的。而且，作为某个厂商的培训和认证，其最终目的是培育自己的市场，培养一批忠诚的用户，而不是为中国培养软件架构师。因此，也存在很大的问题和缺陷。

• 张友生,李雄.软件架构师的角色和培养(A).计算机教育.2006,11