架构活动就是为了一个架构目标而采取的行动。一个架构活动,可能有成百上千的人参与协同,那么在这个工作过程中,架构师要能够明确自己的定位,哪些事情是自己应该做的,哪些事情不该做。
在这个过程中,架构主要会遇到如下几个挑战:
一、“反射式研发行为”。 反射式研发行为就是开发团队面临着巨大的交付压力,导致没有时间去思考,这为架构活动带来了巨大的不确定性。
二、大规模活动。 当前互联网时代大多数都采用微服务架构的模式,势必会出现不同服务归属于不同团队,而不同团队都有自己独立的交付节奏和开发节奏,这就需要保证不同团队间的节奏一致。
三、分布式研发中心。 比较大的公司,一般都会在多个城市设置研发中心,比如上海、北京、武汉、杭州等。那么不同研发中心之间的沟通,其实是比较隔离的,如果一个架构活动会涉及多个研发中心的协同,那么沟通将成为一个难题,如果我们不能改变沟通结构,那么架构设计就会有局限性。
四、认知差异。 不同职能,比如业务、产品、开发,一般都在高强度开发代码,所以普遍会存在认知的差异,这时架构师就需要将这些认知的差异抹平,形成一个宏观的、完整的规划。
**五、大型架构项目。**大型项目本身会有巨大挑战,而往往风险高的项目回报也大,这时架构师就需要保证项目的可交付性和确定性。
基于以上五种技术挑战,架构师需要具备如下四个能力来解决以上问题:
第一个能力是建立共识。 建立共识需要克服当前不同团队间存在的认知差异,和不同成员间的认识局限,让大家在项目的交付时间、项目目标、内容质量、资源分配上等很多方面达成共识。
第二个能力是控制风险。 架构师在项目执行过程中要持续跟踪项目风险,并提前暴露重大项目风险。在跟踪风险的过程中,积极主动思考,并对架构方案及时调整和优化。
其实,项目建设初期,往往架构师和产品开发对项目的理解都不够,随着项目的进行认知也逐渐清晰,这时就要及时调整项目中的不合理的地方。
第三个能力是保障交付。 架构师要尽可能降低大型项目的不确定性和复杂度,最小化爆炸半径。很多情况下,企业项目负责人为了邀功请赏,扩大影响力,不断在架构活动中增加其他团队的人力,导致依赖和阻塞方众多,既影响业务正常进行,又增加了架构活动的不确定性。
其实最理想的情况是,架构活动不影响上层业务,架构升级最好对业务完全透明。
第四个能力是沉淀知识。 有人可能会认为沉淀知识就是梳理文档,且一般架构师或技术负责人才会写类似的文档。
这里有两个误区:
一、沉淀文档不是简单的记录开发的过程,这个过程是被动的,真正的沉淀知识是要通过主动思考,形成文档的结构和内容,这是一个主动思考的过程。
二、事实是无论是产品、开发还是架构师,都需要沉淀各自的文档。这些知识的沉淀为今后的架构活动有重要的指导意义。
以上四个能力是架构师必备的四项软技能,也是成为一名领导者的基本能力。在日常的工作中,有很多提升这四项能力的实践机会,我们要有意地发现并抓住这些机会,这些机会带来的成长远比啃书本知识带来的回报多。