风险对架构设计的驱动力

我在博客文章《以RAID分析作为架构驱动力》中介绍了RAID分析方法。这个方法将风险作为其中的一个重要驱动力,指导我们进行架构设计,避免陷入未知的陷阱。

无独有偶,Simon Brown在其著作Software Architecture for Developers中专门列出一个章节来阐释风险。他认为:

识别风险是恰如其分的预先设计的一个关键的部分,简而言之,风险就是未来可能发生的坏事,比如所选技术无法满足供应商的承诺。

George Fairbanks在其著作Just Enough Software Architecture中更是将风险看做架构设计的核心,提出“风险驱动设计”的方法论。我作为本书的译者之一,深刻地理解了这一方法,并在诸多项目中尝试实践。

古语云:为将者,未虑胜先虑败,故可百战不殆矣。这种“未虑胜先虑败”的思维实则就是我们时常提及的风险思维。由于软件架构是整个系统中最重要也是最不容易改变的部分(另一层意思就是改变成本太高),若不能正确地预见风险,并给出应对之道,一旦风险成为事实上的问题,就可能导致整个系统架构要推到重来,又或者付出即为沉重的重构成本。

George Fairbanks在Just Enough Software Architecture书中给出一个风险驱动设计的案例,介绍了Rackspace日志处理系统的演化,分别从本地日志文件演化到中央数据库,进而演化到基于HDFS的索引簇方案。这种演化固然说明了在当时当刻做出的所谓“恰如其分”的架构,但从另外一个层面来看,也可以视为风险意识不够,没有充分考虑到日志分析系统的可伸缩性,从而带来两次高成本的架构重构(甚至可以认为是重写)。

与RAID分析方法相似,Simon Brown在Software Architecture for Developers书中提出了一种帮助团队识别风险并排定优先级的协作手段——风险风暴。步骤如下:

  • 首先在白板上绘制系统最高层的架构图(可以参考书中给出的C4模型);
  • 团队成员(架构师、开发者、项目经理、业务分析师)在架构图前,各自写下他们能够识别的风险,一个风险用一张便利贴,并量化该风险;
  • 将各自的便利贴贴在架构图上,邻近风险被识别的区域;
  • 对风险设定优先级。

识别风险并评估其优先级并非最终的目的。风险可以提前给我们以警示,之所以采用风险风暴的形式,是希望通过团队成员的群策群力尽可能让隐藏的风险暴露出来,从而为架构设计提供重要的参考。

于是乎,识别风险大多数时候又与技术决策以及技术选型相关,这才是真正考验架构师技术能力、敏锐性、知识广度与深度,以及设计经验的关卡。这是一个很大的话题,我希望能结合广泛的案例来深度探讨这部分内容。这里揭过不提,算是一个不礼貌的收尾。

2016-12-19 14:1594架构