最近，负责公司架构师人才培养和推进计划，负责助理架构师和架构师的认证。很多同事申请面试，在开始的阶段，来面试的都是技术骨干，在公司大约都有5到8年的工作经验。虽然对架构还不甚了解，但都参与到了架构的一些工作内容。在项目推进的中期，各个团队的开发人员（大概3到5年经验）开始申请面试，但失败率达到80%以上，多数原因是对于架构方面，他们顶多是了解经典的三层架构和MVC架构，对于下面很多问题无法回答：
- 所在项目的应用/系统采用了哪几种风格的架构？
- 应用/系统有哪些涉众？主要的业务需求是什么？
- 应用/系统处理的主要数据有哪些类型？在系统中和系统之间如何流转？
- 与其他系统的集成方式是什么？
以及针对架构设计提出的一些问题：
- 为什么采用现有的技术？有哪些替代技术？优缺点如何？
- 为什么采用现有的架构设计？
- 为什么采用现有的集成技术？
- 未来的技术趋势和方向，如何影响你的架构？
大部分开发人员只关注自己手中的工作，对项目环境、架构并不了解，每天在做的事情是听从架构师指导，按照架构师翻译过来的“技术语言”工作。
想成为架构师，首先要对自己的项目有高屋建瓴的认识。从代码结构、开发/运行时环境、DevOps流程（构建/测试/部署）到业务需求，都需要有深刻的认识。可能很多人会问，架构师不是应该更多的关心技术，因为大部分都是“技术架构师”，其实这是从技术转职架构师经常犯的一种低级错误。架构师无论是应用架构是、技术架构师还是解决方案架构师或企业架构师。都是在团队中负责沟通业务团队（客户、涉众）与技术团队（开发团队、测试团队、运维团队等），把业务需求中的隐藏技术需求提炼出来，开发和跟踪技术债列表，为项目避免风险的角色：
- 架构师要熟悉项目所使用的技术，避免出现风险；
- 架构师要熟悉项目业务需求，知道如何设计架构来满足业务需求，并从业务需求中提炼出潜在的技术需求，如可用性需求、可扩展性需求及性能需求等。
- 如上的技术需求或称为非功能性需求，也称为架构特性，是一种衡量架构好坏的质量属性。
- 架构无好坏之分，只是是否能够满足业务需求（功能性需求），且较好地满足技术需求（非功能性需求），如承载用户量、响应速度等，满足了技术需求则说明架构可以满足当前的需要，是合适的as-is架构，如果不合适，我们就要设计to-be架构。而在大型项目中可能需要把to-be架构拆成几个阶段实施。一方面是考虑到当前的需求和费用的平衡，另一方面随着技术进步很多新兴架构样式和技术的不断出现也会给架构设计带来许多变数。所以架构设计应该是演进式的。
