Software Architect
负责软件系统级形态的人：那些难以逆转、代价高昂的重大结构性决策，以及无人认领的非功能性需求。
软件架构师负责那些难以撤销的决策。系统如何拆分成服务或模块、数据如何在其中流动、边界设在何处、技术栈承诺采用哪些技术，以及整体在负载、故障和增长下如何撑住。单个功能改起来很便宜。这些结构性选择则不然，因此需要有人在系统层面而非功能层面思考。
真正的价值在于非功能性需求：性能、可扩展性、安全性、可靠性、可维护性。这些都是没有任何单个功能工单认领、一旦被忽视就会悄悄拖垮产品的东西。架构师的工作是把权衡公开说出来。现在构建更快，还是以后修改更便宜。简单而有限，还是灵活而复杂。没有免费的架构，只有你有意选择的权衡，或你因意外而继承的权衡。
大多数初创公司不需要专职软件架构师，过早招一个通常是个错误。在小规模时架构很小，技术负责人或 CTO 会把它作为本职工作的一部分承担起来。一个全职的架构师，没有代码可写，也没有团队可带，往往只会产出团队随后就忽略的图表和标准文档。只有当系统大到没有人能在脑中装下整幅图景时，这个角色才值回它的位置。
为什么不写代码的架构师会跑偏，举个实际例子：一位两年前就离开了代码库的架构师，设计了一套「干净的」事件驱动系统，配六个队列和三个数据库，因为在白板上这把一切都解耦得很漂亮。而要去构建它的团队发现，本地开发环境现在要花一天才搭得起来，每个功能都要触及四个服务，调试一个用户投诉意味着在所有这些服务之间关联日志。图很优雅；亲历的体验是受罪。一位仍然贴近代码的架构师会预先感受到那份代价，因为正是他得在自己的笔记本上跑那六个队列。
诚实的看法：供应商组织架构图上的「解决方案架构师」往往意味着一个售前角色，设计他永远不必维护的系统。一个好的架构师会离代码足够近，以便感受到自己决策的后果。如果画方框的人永远不必住进那些方框里，那些方框就会画错。