架构师的角色定位
曾经有个段子:新人入职,CEO、CTO 甚至司机都来迎接,结果发现是误会。这反映了创业公司一人多职的常态。确实,很多初创团队里,一个人包办开发、测试甚至运维,这种'一条龙'模式虽然高效,但也容易踩坑。记得早年有一次,因疏忽导致发出的光盘母盘含有病毒,被迫召回两万张,那次经历让我明白,角色分工明确的重要性。
架构师并非凭空产生的称呼,ISO/IEC 42010 国际标准中有明确定义。它可能是个人、小组或团队。微软将其分为四类:企业架构师(EA)、基础结构架构师(IA)、特定技术架构师(TSA)和解决方案架构师(SA)。
- EA:决定公司整体技术路线,如盖茨曾担任的首席软件架构师。
- IA:提炼和优化基础性、可复用的框架组件,这是技术公司的核心资产。
- TSA:专注安全、存储等专项技术的规划。
- SA:负责解决方案的设计,将产品与技术组合以满足用户需求。
大公司分工细致,小公司则往往一人身兼 IA+TSA+SA。实际工作中,也常简单分为软件架构师和系统架构师。软件架构师偏向 TSA+IA,是程序员晋升的常见路径;系统架构师则是 SA+TSA,需通晓软硬件知识,更侧重综合运用现有产品实现需求。
核心职责
架构师需参与项目全生命周期,从需求分析到部署,对技术活动进行指导和协调。主要职责包括四点:
确认需求
架构师在需求规格说明书完成后介入,必须认可该文档。需要与分析人员反复交流,确保完整准确地理解用户意图。
系统分解
依据需求,将系统整体分解为子系统和组件,形成逻辑层或服务。既要纵向分层,也要横向分块。确定各层接口及相互关系,这是体现架构师功力的关键。
技术选型
基于架构设计选择技术栈。例如 Web Server 用 Windows 还是 Linux?数据库选 MSSQL、Oracle 还是 MySQL?是否采用 MVC 或 Spring 框架?前端用富客户端还是瘦客户端?
注意,架构师只有评估权,最终决定权归项目经理。项目经理会结合预算、人力和时间进度权衡。架构师提供的方案是重要的决策参考。
制定技术规格说明
作为技术权威,架构师需协调开发人员,确保大家按架构意图实现功能。沟通形式可以是 UML 视图、Word 文档或 Visio 文件。通过规格说明书,让开发者从不同角度理解各自模块。
此外,架构师还需与项目经理、需求分析员甚至最终用户保持沟通,因此不仅要有技术能力,人际交流同样重要。
常见误区
误区一:架构师就是项目经理
两者职能不同。项目经理侧重预算、进度、人员管理和外部协调,具备管理属性。小型项目中常见兼任,但概念上应区分。
误区二:架构师负责需求分析
架构师不是需求分析员。后者负责收集和分析需求,与用户对接。架构师主要负责审核和确认需求,指出不清或不完整的部分,并与分析员保持联系。架构师是技术专家,而非业务专家。
误区三:架构师从来不写代码
这是一个有争议的话题。观点一认为写代码是体力活,架构师应专注于设计;观点二认为架构师源于程序员,经验和知识更高,难免写代码。
实际情况取决于出身和环境。软件架构师多来自程序员,保留着编码情怀,可能会写核心代码;系统架构师可能来自运维,代码量较少。理想状态是不写代码,但现实中公司规模、文化和人员素质都会影响这一判断。写不写代码不是区分两者的根本标准,关键在于能否把控技术方向并落地。


