架构师理应站在更高视角更全面的看待问题，亦需要务实研发一些通用性的工具避免研发团队重复造轮子的问题，也可以借助架构师丰富实战经验避免共性问题的出现。这样子应该是职能要求，也算是关联技术人员对架构师这个岗位的共同期望。
在日常工作过程中架构师会从技术选型、可用性设计、扩展性设计、性能设计、安全性及可监控性设计等方面出发帮助研发团队提升系统的稳定健壮性。大多数架构师也都拥有这些方面的能力能够推行作出贡献。
然而令人比较困惑的是，一旦众多架构师成为一个团队后，与研发团队关系持平成为竞争关系，前面所提及这一伟大使命则发生了重大变化。比起解决共性问题的定位，更多是倾向于维护自身所在团队的利益。这也许是人之本性，亦或许是企业文化所造就。
例如近日发现一怪像，有一部门所谓架构团队封装了几个公共组件，网关里通过过滤器可以对客户端发送的报文进行解密操作，结合自身条件重写了ribbon负载策略，单从这些去看貌似是在做部分架构的工作。然而让人费解的是，实现逻辑里的每一步都打上了info级别的日志，甚至报文也要把解密前后的都要打印，每次请求负载策略里则是把注册服务列表都要打印出来。结果导致服务整体性能下降，日志存储成本剧增，遂协调询问是否可以把这部分日志打印去掉？得到的答案是否定得，需要通过日志数据来证实请求出错的情况下不是他们架构团队的错……
在我看来架构师应该视角更加宽广，不能只盯着自家那一亩三分地。确保系统稳定，提升系统质量又何曾不是架构师的职责？即便不是架构师亲手所做系统也应该尽职尽责参与，很少有企业招聘个架构师就是只负责一个系统的研发。
架构师团队更应该聚焦于服务意识，而非打造产品意识。服务于研发团队亦或者服务于企业内IT系统，包装产品是解决服务对象共性问题的辅助策略，但不可成为拉开与服务对象的屏障。