架构师的角色定位
曾经有个段子：新人入职，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 文件。通过规格说明书，让开发者从不同角度理解各自模块。
此外，架构师还需与项目经理、需求分析员甚至最终用户保持沟通，因此不仅要有技术能力，人际交流同样重要。
常见误区
误区一：架构师就是项目经理
两者职能不同。项目经理侧重预算、进度、人员管理和外部协调，具备管理属性。小型项目中常见兼任，但概念上应区分。
误区二：架构师负责需求分析
架构师不是需求分析员。后者负责收集和分析需求，与用户对接。架构师主要负责审核和确认需求，指出不清或不完整的部分，并与分析员保持联系。架构师是技术专家，而非业务专家。
误区三：架构师从来不写代码
这是一个有争议的话题。观点一认为写代码是体力活，架构师应专注于设计；观点二认为架构师源于程序员，经验和知识更高，难免写代码。
实际情况取决于出身和环境。软件架构师多来自程序员，保留着编码情怀，可能会写核心代码；系统架构师可能来自运维，代码量较少。理想状态是不写代码，但现实中公司规模、文化和人员素质都会影响这一判断。写不写代码不是区分两者的根本标准，关键在于能否把控技术方向并落地。
