架构活动就是为了一个架构目标而采取的行动。一个架构活动，可能有成百上千的人参与协同，那么在这个工作过程中，架构师要能够明确自己的定位，哪些事情是自己应该做的，哪些事情不该做。

在这个过程中，架构主要会遇到如下几个挑战：

一、“反射式研发行为”。 反射式研发行为就是开发团队面临着巨大的交付压力，导致没有时间去思考，这为架构活动带来了巨大的不确定性。

二、大规模活动。 当前互联网时代大多数都采用微服务架构的模式，势必会出现不同服务归属于不同团队，而不同团队都有自己独立的交付节奏和开发节奏，这就需要保证不同团队间的节奏一致。

三、分布式研发中心。 比较大的公司，一般都会在多个城市设置研发中心，比如上海、北京、武汉、杭州等。那么不同研发中心之间的沟通，其实是比较隔离的，如果一个架构活动会涉及多个研发中心的协同，那么沟通将成为一个难题，如果我们不能改变沟通结构，那么架构设计就会有局限性。

四、认知差异。 不同职能，比如业务、产品、开发，一般都在高强度开发代码，所以普遍会存在认知的差异，这时架构师就需要将这些认知的差异抹平，形成一个宏观的、完整的规划。

**五、大型架构项目。**大型项目本身会有巨大挑战，而往往风险高的项目回报也大，这时架构师就需要保证项目的可交付性和确定性。

基于以上五种技术挑战，架构师需要具备如下四个能力来解决以上问题：

第一个能力是建立共识。 建立共识需要克服当前不同团队间存在的认知差异，和不同成员间的认识局限，让大家在项目的交付时间、项目目标、内容质量、资源分配上等很多方面达成共识。

第二个能力是控制风险。 架构师在项目执行过程中要持续跟踪项目风险，并提前暴露重大项目风险。在跟踪风险的过程中，积极主动思考，并对架构方案及时调整和优化。

其实，项目建设初期，往往架构师和产品开发对项目的理解都不够，随着项目的进行认知也逐渐清晰，这时就要及时调整项目中的不合理的地方。

第三个能力是保障交付。 架构师要尽可能降低大型项目的不确定性和复杂度，最小化爆炸半径。很多情况下，企业项目负责人为了邀功请赏，扩大影响力，不断在架构活动中增加其他团队的人力，导致依赖和阻塞方众多，既影响业务正常进行，又增加了架构活动的不确定性。

其实最理想的情况是，架构活动不影响上层业务，架构升级最好对业务完全透明。

第四个能力是沉淀知识。 有人可能会认为沉淀知识就是梳理文档，且一般架构师或技术负责人才会写类似的文档。

这里有两个误区：

一、沉淀文档不是简单的记录开发的过程，这个过程是被动的，真正的沉淀知识是要通过主动思考，形成文档的结构和内容，这是一个主动思考的过程。

二、事实是无论是产品、开发还是架构师，都需要沉淀各自的文档。这些知识的沉淀为今后的架构活动有重要的指导意义。

以上四个能力是架构师必备的四项软技能，也是成为一名领导者的基本能力。在日常的工作中，有很多提升这四项能力的实践机会，我们要有意地发现并抓住这些机会，这些机会带来的成长远比啃书本知识带来的回报多。