架构活动，简单来说就是围绕一个架构目标而采取的行动。一个架构活动可能有上百人甚至上千人的参与。在这么大规模的人员协同中，架构师就需要找准自己在其中的定位：明确什么事情是自己应该做的，什么事情是其他参与者应该做的。
时代的变化导致了研发方式的变化。在互联网时代，敏捷开发成了开发模式的主流。不过敏捷的行为方式在帮助业务高速迭代的同时，也导致了大量短期行为，也就是所谓的技术债。这些技术债，就构成了架构活动所面临的主要技术挑战。具体而言，有如下五种。
1、反射式研发行为
不论是初创公司还是大企业里的初创团队，往往持续面临着巨大的交付压力，导致一种被我称之为“反射式研发”的行为：写代码就像膝跳反射一样。研发人员的日常工作都是在接需求、写代码、上线、修故障之间循环，很少有时间去思考和追求长远的设计。
这种短期行为虽然不影响业务迭代，但如果在一个大型架构活动中出现频繁，造成的后果将是灾难性的。
2、大规模活动
分布式研发模式往往采用微服务架构。微服务架构有一个优势，就是服务之间可以独立做变更，在保持 API 稳定的情况下，团队之间很少需要协同。所以每个服务的维护者可以独立决定自己的发布流程和交付节奏。
在互联网时代，为了最大化流量的传播，我们往往会通过一个大型商业活动来聚合和放大营销效果，比如 618 大促、双十一大促、春节红包、新品线上发布会等等。那么微服务相对独立自主的研发模式，对于制定跨团队统一流程和交付节奏就构成了一个巨大的挑战。
3、分布式研发中心
互联网企业往往有多个分布在全球各地的研发中心。在这种跨国家、跨地域、跨语言的研发模式之下，每个研发中心内部可能有非常多的交流，但是各个研发中心之间的沟通，相比之下就是互相隔离的。时间长了，康威定律就开始发挥作用：“系统的结构和产生这些设计的组织的沟通结构是同构的”。也就是说，在我们不能改变一个组织的沟通结构的时候，架构活动产生的设计就会有很大的局限性。
4、普遍存在认知差异
每个团队，甚至每个研发，平时都在自己的隔离环境下高强度地开发代码，所以大家一般没有统一的语言和全局的认知。这种情况在业务和产品团队也同样存在。因此，达成一个宏观的、完整的、可行的、被普遍认可的规划就变得非常困难。
5、大型架构活动本身面临的挑战
在高风险和高回报预期的场景下，必须保障项目完成的高确定性和对目标的高保真性。
在这些挑战之下，架构师要发挥的作用其实就非常明显了。我们需要帮助团队抵抗反射式的研发行为、独立决策的研发模式、分散的研发团队、普遍存在的沟通障碍和认知差异，以及高风险、高工作强度和高复杂度的场景，最终保障架构活动以高确定性完成目标。
此文章为4月Day30 学习笔记，内容来源于极客时间《郭东白的架构课》，推荐该课程。