架构师如何做出架构决策? – IasaGlobal

21-09-24 banq

在做出决策时,架构师的主要任务是定义全面的上下文(一组评估标准),以便做出平衡的架构决策。

对于那些对业务至关重要的决策,建议花额外的时间来分析备选方案和架构上重要的需求,并扩展分析上下文,以最大程度地降低做出不平衡决策的风险。

为了做出平衡的决定,考虑技术和非技术性质的内部和外部因素至关重要。

架构设计的高级过程可以被视为如图所示。很明显,要做出深思熟虑的决策,需要访问需求和上下文,并且之前已经评估了替代决策。

听起来很简单,不是吗?但事实上,开发替代方案并为其评估选择“正确”的标准是一项非常具有挑战性的任务。为了应对它,您需要做好准备并接受我们的建议。

通常,对备选方案的评估以表格的形式表示,其中水平显示选项,垂直显示标准。这些单元格包含评估标记,然后可以根据每个标准的重要性对其进行加权。

举个例子,我们来看一下组件之间三种通信方式的对比表。请记住,如果不彻底理解上下文和任务,就不可能在这些选项之间做出有意识的选择。每种方法都有其优点和缺点。这是一个说明性的例子,所有的评价分数都是随机的。

值得一提的是,权重和分数不一定是数字,因为解释这些值并恢复这些分数的逻辑非常困难。

功能 – 3.7;价格 – 2.3;团队经验——4.1?是好还是坏?

建议使用与“bad”、“good”、“great”、“n/a”等对应的整数值。这样会更容易解释标记和最终选择。

 

主要问题是定义评估标准的“完整”组成。为此,必须设置上下文边界,因为上下文是标准的来源。下图显示了上下文的内容如何根据​​架构师的观点而有所不同。

在最简单的情况下,在做出决定时会考虑两件事:需求的描述和架构师的经验。正式的工作方法和做所写的事情可能会产生与预期完全不同的结果。发生这种情况的原因有很多——例如,如果要求是由另一个人制定的。在这种情况下,即使文档“完美无缺”,分析师和架构师对问题的理解也可能不同。

这就是为什么“业务问题”和其他概念已脱离“狭隘”上下文的原因。通过仅根据需求做出架构决策,架构师限制了与利益相关者的沟通,这不可避免地导致风险增加。

例如,基于云技术的“漂亮”解决方案可以立即解决与扩展相关的一系列问题,但如果存在运营费用限制或有义务遵守特定法律要求,则可能看起来完全不可接受。

随着所考虑的上下文的扩展,新的变量被添加到等式中。因此,一方面,决策变得更加平衡,但另一方面,扩展将需要额外的劳动力成本来进行分析。

建议根据当前任务定义最优上下文边界,如下图所示。例如,当涉及到一个对业务至关重要且其成功实施对公司的未来至关重要的系统时,尝试在资源允许的情况下尽可能多地扩展上下文是合理的。另一方面,对业务影响有限的系统的开发也许应该仅限于最低限度的分析。

因此,我们可以得出结论,在做出决策时,架构师的主要任务是定义全面的上下文(一组评估标准),以便做出平衡的架构决策。

对于那些对业务至关重要的决策,建议花额外的时间来分析备选方案和架构上重要的需求,并扩展分析上下文,以最大程度地降低做出不平衡决策的风险。

上下文为王

 

猜你喜欢