架构团队的职责定位
开篇说一下架构团队的定位，亦或者说职责范围。
注意：下图的职能很多可以做归并，只当参考。非本文的论点。
笔者关于架构团队的职责定位明确为以下几个方面。
扩展性预期
确保系统的架构和设计可以随着业务的发展而扩展，需要在"业务需要"发生之前就想好，远在业务部门的预测超过平台的容量之前，就已经对如何扩展系统深思熟虑了。软件的整个生命周期中，开发交付其实只是一小部分，后期的需求变更、维护升级、重构优化才是主旋律。那么多考虑软件的扩展性和未来预期是很有必要的，作为架构师至少看得到半年后的规模扩展吧？
标准规范
负责各项标准、规范、流程的设定和推行。这是架构团队的一个重要职能，也是最容易被忽视的。技术手段并不是所有的问题的最佳解决方案，很多场景通过推行标准规范就可以达到不错的预期效果。
比如编码规范，可以通过投入大量人力来开发IDE/代码库的插件进行代码规范的自动检查，再需要不断的测试来验证这个插件的可靠性。通过编程考试或者平时的review来强化这一规范的落地，再加上编程规范的不断宣导可以达到至少八成的效果，何乐而不为，最后那两成效果就放到公司真到一定的级别了考虑技术实吧。再比如架构组研发了统一的基础日志组件，可以规范日志格式、掩码敏感信息、自动截取/压缩超长日志报文等功能，这种组件就应该作为标准全员推广。
拆解抽象
在参与业务迭代的过程中，能够抽丝剥茧(拆解)，发现需求、编码、测试、发布等环节中的痛点、共性点或未来瓶颈点等进行抽象、实现并最终推广全员。在代码层面也适用，拆解交织繁杂的代码逻辑，抽象出基础公共模块。都是架构团队的基本技能。
举例来说，架构师经常会参加各种各样的评审，对那些常见的review comments，五花八门的自造轮子，一旦发现就要有这种敏感度需要制定标准规范或者研发统一的组件了。
技术宽度
架构师需要足够的技术宽度，从软件到硬件，从语言到操作系统，从编码到测试，从运维到安全，从拥抱开源到自造轮子都要有所涉猎。有个比喻，说架构师需要具备某种上帝视角，来俯视软件产品的诞生、成长、重构整个生命过程。而且架构师要有空杯心态，若学习的技术越多，就觉得自己的水平越高，那基本不会是一个合格的架构师；实际应该是越学习觉得自己不懂的越多。
另外，特别要有面对疑难杂症的自信和能力，为业务团队提供强力的技术输出。因为疑难杂症的最后一关就只有架构团队。
协调领导
架构团队绝对不是偏安一角写写基础组件，既然要制定标准，推行规范，那就必须与其他团队进行协作，需要征得他们的合作态度，才能顺畅的推行，这个靠架构团队在技术和业务上的影响力来驱动协调基本可以办到。但在某些情况下，需要一些强制的手段，比如设计文档的强制评审，那就必须赋权给架构团队一定的权力，或者在一些矩阵型组织里架构师就是拥有技术的绝对权威，这个就是领导力。
深入业务
技术的存在就是为业务服务的，脱离业务的架构都是耍流氓，99%的情况下这句话都没毛病。有些技术人有严重的重技术轻业务思想，这种人除非真的是钻研技术的一把好手，可能不善言谈不善沟通（笔者本人是可以接受的），但是架构团队里这种人不能多。后文我们会详细讨论下架构团队和业务团队的协作问题。
创新突破
架构团队在IT内部必须是第一生产力，不管是单兵作战还是团战能力。除了过硬的基本功外，不断的学习和寻求技术上的突破，是贯穿架构团队始终的一个Object。前人已经累计了很多经典优秀的平台、框架或思想作为传承，我们可以继承但绝不能守旧。
在学术研究中，“创新”一词用来表示团队有增加值的产出。而有些创新调研项目很多时候并不会有实际的产出，甚至更糟糕些，会产生许多沉没成本，但这都不是阻碍创新的借口。创新是架构团队延续生命力的最佳营养品和必要条件。可以想象没有创新突破，架构团队完全可以就地解散。
