软件架构师

定义

软件架构师是软件行业中一种新兴职业，其含义通常指负责一个大型软件系统整体设计、规划和管理的人员。工作是理解并管理系统的非功能性需求，例如可维护性、性能、复用性、可靠性、有效性和可测试性等，并把客户需求转换为规范的开发计划与文本，制定项目的总体架构，指导开发团队完成计划。^[1]

架构师的角色不能简单等同于经验丰富的程序员。通常架构师是全职岗位，因为修改说明、检查已编写的代码是冗长但必要的工作，他们几乎没有时间编程。架构师的目标也并非找到唯一最优解，而是在一个可能很大的设计方案和决策空间里，搜索出一个可以被接受的方案。

在英文中，软件架构师与建筑师共用 Architect 一词，早期软件架构理论也常借用建筑学的术语和方法，例如“蓝图”。软件系统本身越来越复杂，涉及的功能和既有系统越来越多，软件外包、第三方实施等现实又要求有人对整个项目的规划和设计负责，架构师这一角色由此变得举足轻重。^[3]

原理

架构师的工作可拆成架构定义与架构交付两个阶段。定义阶段先捕捉非功能性需求，再思考如何在兼顾需求与限制的前提下确定系统结构、方针与原则，随后进行技术选型与架构评估。技术选型需要综合成本、许可、供应商关系、兼容性、部署升级政策以及最终用户环境等因素，本质上是一种风险管理：不确定性和复杂性过高时要减轻风险，存在机会或收益时则引入风险。^[4]

在技术手段上，架构设计常借助解耦降低复杂度。以高速公路网作类比，并非在所有目的地之间都修一条路，而是建立主干道与分支道路，把复杂度从 M×N 降到 M+N。早期电商网站常把会员、交易、库存等模块放在一个系统里实现，随着业务发展再将会员模块独立为会员系统、交易模块独立为交易系统，这种服务化拆分是分布式架构中常见的做法。^[5]

系统结构通常表示为组件与连接器构成的图：节点代表过程、模块、进程、工具或数据库，边代表过程调用、事件广播、数据库查询或管道等连接方式。由此形成若干可复用的架构风格，例如管道—过滤器风格中，过滤器读取输入数据流并产生输出数据流，管道负责把这些输出传给下一个过滤器，编译器各阶段和 Unix 管道命令都采用了这一风格。^[6]

面对复杂问题时，架构设计常采用分而治之的策略，通过纵深拆解把任务分解为故障发现、故障应急恢复等能力，再对各项能力做架构设计；也可以做横向解剖，逐层区分业务需求问题、产品设计问题和技术架构方案。解耦还可以针对角色之间的依赖，使各方按服务水平协议进行协作。^[5]

发展历程

软件架构作为概念，其源头可追溯到 Edsger Dijkstra 1968 年的研究工作以及 David Parnas 在 1970 年代初的论述，两人都强调软件系统的结构具有重要意义，把结构做对是关键。20 世纪 90 年代初起，围绕架构风格、架构描述语言、架构文档和形式化方法的研究逐渐增多。^[7]

20 世纪 70 年代中期，系统规模扩大使理解大型程序的模块交互变得必要，相关研究提出了模块互连语言。1980 年代，程序模块复用的需求上升，软件工程开始纳入提高代码复用的方法；1990 年代初出现的统一建模语言，为架构师表达高层系统决策提供了工具。1990 年代，软件架构逐渐被承认为一门独立的学科。^[8]

2000 年发布的标准 IEEE 1471:2000 给出了关于架构表示的规范，将软件架构描述为由软件元素、元素之间的关系以及元素与关系的属性构成的基本结构，以及创建这类结构和系统的学科。1998 年出版的《软件架构实践》一书提出了架构的分类法，并介绍了软件架构分析方法等内容。^[9][10]

在中国，软件架构师的培养长期被视为制约产业发展的环节之一。2005 年中国基础软件和应用软件销售额分别达 151 亿元和 477 亿元，增长率分别为 25.3% 和 23.5%，但业内分析认为，软件架构师培养不足是中小型软件企业难以做大的瓶颈之一。2006 年在南京举办的软件产业国际化高级研讨会暨微软大中华区架构师论坛，即为国内高级管理和技术人员提供了解软件架构与技术趋势的交流平台。^[2]

近年来敏捷开发模式被广泛应用，其快速迭代的环境对软件架构师提出了新的要求，促使其构建能适应快速变化的职业能力体系。^[11]

应用

架构师的工作覆盖软件项目的多个环节，包括领导与协调项目中的分析、设计和实施等技术活动，推动关键技术决策并最终表达为软件架构，确定并文档化系统的需求、设计、实施和部署等视图，确定设计元素的分组及分组之间的接口，以及评价和确认软件架构的实现。

在系统现代化与迁移场景中，架构师帮助分析既有系统及其依赖关系，逐步对单体系统解耦，将接口标准化，使数据流更透明，评估迁移风险，并有针对性地偿还技术债务。在受监管或高速增长的环境中，架构工作还要兼顾安全、合规与扩展能力，使架构决策的理由以及安全、可用性、可维护性等要求的满足方式可以被追溯。^[12]

架构师的实践对象往往规模庞大。有从业者记述，2005 年美国一家航空快递公司需要每天交换 8.6 亿条邮件递送扫描消息，该平台的消息处理能力到 2010 年达到每天 50 亿条；2012 年美国一家玩具公司引入产品生命周期管理软件时，需要整合的既有外购和自研应用系统超过 50 个，且分散在北美、欧洲、中国、东南亚等多个地区。^[3]

从职业发展看，架构师通常需要具备计算机科学或软件工程知识，由程序员起步，经历软件设计师等阶段后再成长为架构师。相关材料指出，一名合格的软件架构师通常需要 8 年以上的软件项目开发实际经验，其大部分知识与经验来自实际开发工作，而非单纯的理论学习或厂商认证。

局限

架构师并非经验丰富程序员的等价物。资深程序员熟悉整个软件生命周期，可以经培训成为架构师，但不等同于架构师，也有的资深程序员对架构设计本身并不感兴趣。代码审查、确保设计模式被正确应用通常属于资深程序员的事务，而是否选用某种容器或服务器、是否引入负载均衡等属于架构事务。^[13]

架构职责在实践中容易出现偏差。常见问题之一是架构工作介入过晚，等到技术问题已经显现才引入架构师，此时关键决策早已形成、技术债务已经产生，调整成本高昂。另一种偏差是把软件架构仅仅理解为文档，架构师的工作被简化为绘制图表。此外，不少组织把资历等同于架构能力，把经验丰富的开发者直接转为架构师，如果架构工作只被当作附加任务，角色定位就会模糊，并在日常工作中被操作性事务挤占。^[12]

架构角色能否发挥作用，还取决于是否具备真正的决策能力。如果架构岗位只能以顾问身份处于项目之外，缺少清晰界定的决策空间以及与开发、产品、运维和安全之间的常态化沟通，就可能只产生建议，而无法形成一致的架构治理。缺少架构责任时往往同时出现多种症状：接口不清晰、依赖难以追踪、各团队自定标准，新功能耗时变长，架构知识集中在少数人手中且决策没有记录，技术债务不断累积。^[12]

架构决策本身也受现实约束。在资金底线与需求紧迫性面前，架构合理性在实际任务排序中往往不是优先级最高的要素，短期内可以妥协，长期则不能；过早追求完备也可能导致急功近利或建设脱离实际的方案。此外，架构师对全局的把控不等于可以任意左右项目结果，其判断仍取决于需求信息的完整程度和组织的协作方式。^[14]

参见

• 软件工程 —— 软件架构师这一角色所处的学科与工程实践领域。

• 软件架构 —— 软件架构师负责设计与决策的对象。

• 设计模式 —— 架构设计中用于组织组件与接口的常用经验总结。

• 统一建模语言 —— 架构师用来描述和表达高层系统结构的建模语言。

• 敏捷开发 —— 对软件架构师职业能力提出新要求的开发模式。

• 非功能性需求 —— 架构师在需求阶段重点管理的系统质量属性。