让成本与风险驱动敏捷架构设计

本文最初发表在 IEEE__ 软件杂志上， IEEE__ 软件_ 杂志致力于发表严谨的、经过互相审校的文章，专注于当今世界的战略科技。_为了满足运行可靠且灵活企业所面临的挑战，IT__ 经理和技术管理者依赖 __IT Pro__ 获取最先进的解决方案。

关于敏捷开发与架构之间的关系的文章与各种讨论已经足够多了。大约 4 年前，IEEE 软件还专门发表了一份相关主题的期刊（《敏捷与架构：它们到底能否共存？》，IEEE 软件杂志 2010 年第 27 期第 2 刊）。目前看起来这一争论已经开始逐渐平息了：我们已经看到包含了架构过程的敏捷方法，例如大规模敏捷框架的出现，我们也看到开放组织架构框架（TOGAF）这样的架构框架也加入了各种敏捷元素。当一切尘埃落定之后，我们到底学到了些什么？在 CGI（一个全球的 IT 与业务流程服务提供商）内部，架构师们已经学会如何使用经济方面的驱动因素，例如风险与成本等等增加工作的敏捷性。

有五个方面的建议可以帮助架构师们在敏捷的世界中表现出更高的效率，而无需实施新的方法或使用新的框架。这些建议对态度或行为方面的改变进行了描述，而不是纯粹的实践或原理，因此这些建议非常易于消化和应用。这些思想是基于一个名为风险与成本驱动架构的解决方案架构方法所派生的。这一方法的核心是通过风险与成本决定关注点的架构重要性。通过将架构保持轻量级，让它只处理那些特别高风险或高成本的关注点，以此实现架构的敏捷性。一个由风险与成本驱动的架构关注点的待办事项列表能够平衡通常由价值驱动的产品积压工作列表，以实现“刚好足够的期望”这种软件方案的演变。

你的主要交付成果就是你的决策

敏捷社区对于架构的批评之一源自于他们的某种误解，在他们的想法中，一个架构师的职责永远是交付“一种架构”，这种架构总是被解读为某种文档。而根据敏捷宣言 ( http://agilemanifesto.org ) 中的声明，文档的价值低于能够运行的软件。这种说法是对真正的架构师每日工作的一种非常糟糕的解读：架构师的工作是找出需要处理的架构上的关注点，找到能够应对这些关注点的各种选项，然后根据当前的上下文决定最佳的行动（图 1 中的三个圆）。这样来看的话，架构师的主要交付成果就不是某种文档，而是一个决策流 1。这种看待架构工作的方式能够完全地相容于敏捷思维，无论这些决定是由早期的实现和重构演变而来，还是通过仔细的前期建模而来，或是通过两者的结合而得出。在敏捷项目中，决策通常是由一组拥有共享的所有权的流程演变而来的，但即使如此，也可以将架构师视为守卫着整个设计的概念完整性的人。那么，架构师的角色就是要确保整个小组的决策在整个解决方案中是一致的，即使同一时间有多个团队在此方案中工作。

维护一个包含架构关注点的待办事项表

敏捷环境中的架构师们没有一种已事先批准的、固定的规格说明集，能够让他们在设计时进行参照。甚至是在传统的瀑布式背景中工作的架构师们也不能够依赖于整个环境能够保持固定不变，因为他们需要能够设计出一种支持未来需求的解决方案，它应该能够经受住一定数量的变更的考验。在敏捷世界中有一种拥抱变化的工具，那就是产品待办事项表（product backlog）：这是一个等待实现的、排序的需求列表。随着时间的推进，可以对待办事项表进行重新排序，以适应需求的变化，或所对应的价值的变化。比起设计一种非常完整的计划，这种方式更易于拥抱变化。如图 1 所示，架构师的待办事项表中包含了架构上有待解决的关注点，因为这些关注点决定了她的工作内容。通过频繁地重新评估待办事项表上关注点的优先度，架构师在处理新的业务需求和新兴的见解时就能够表现得更灵活。

让经济影响力决定你的专注点

那么我们该如何排列待办事项表上关注点的优先级呢？要先解决哪一点呢？十年之前，Martin Fowler 曾经写道“架构就是指重要的东西，无论它是什么。2”

图 1 —— 架构师的每日工作：一个“架构微周期”。架构师要观察需要解决的架构关注点，列举出解决这些关注点的各种选项，并根据当前的上下文决定他们的最佳行动。

我们发现对经济影响的思考能够帮助我们决定重要的事。换句话说，我们发现对某个关注点可能会产生的经济影响进行评估，对于我们评定它的架构重要性起到了很好的指示作用。如果这些关注点的内容是应该创建些什么产品，那么它的商业价值就显得非常重要了。但是，许多架构师将大部分的时间用于考虑如何创建它，在这种情况下，风险与成本就是关键因素。如果你能够运用风险与成本来决定应当专注于哪些方面，那么你不仅能够确定项目的经济影响力，并且你也能够将你的优先级排列结构以一种业务干系人可以理解的方式解释给他们听。以经济影响作为架构重要性的一种指示作用，也消除了这一种谬论，即架构只应当关心高层次的抽象上的关注点，也不是具体细节。很多时间，问题就出在细节中，一些细层次的设计决策可能会具有很高的风险。架构师要牢牢掌握它们，甚至是自己动手编码实现。

图 2 —— Scrum 上下文：让架构微周期与每日站会的日程保持一持，以促进集体式架构决策。

保持小型架构

即使在大型项目中，选择最小架构方式也有着两种非常合理的原因：

• 架构很难改变，架构越大就越难调整。如果架构决策过多，在条件发生变化时就会成为沉重的负担，因而难以很快地做出回应。这些架构决策也可能会对在这个架构中进行工作的个别团队的设计空间造成不必要的限制。
• 只有了解架构的全部，架构师才能够守卫它的概念完整性。过多的细节会使架构师失去在这个复杂的解决方案中维护一致性所必需的大局观。

在大多数由计划驱动的项目中，你都能够指出某个架构里程碑的存在，因为这就是往架构中签入代码的时刻：在这个里程碑完成之后，对关键架构决策的任何颠覆都会产生巨大的成本与时间。在到达这个里程碑之前要完成多少“前期”架构设计才是最理想的呢？这就要仔细的考虑以下三个因素才能够得到最好的结论：即规模、重要性和易变性 3，而不是一些教条式的口号，例如“You ain’t gonna need it.（你不需要它）”。规模更大、复杂度更高的解决方案的商业重要性也更高，因此需要更多的前期架构设计。而在更容易生产变化的环境中，选择较少的前期架构设计的方式更合理。但许多敏捷项目并没有架构里程碑的存在，因此需要采取其它的方式以决定要将架构保持在多小的范围内。

交付足够的预期

敏捷项目中的架构师如何决定正确的架构规模？按照上文建议中的第一条来看，架构是一种架构决策流。这种流应当在解决方案开发之前进行，并交付足够的预期。你可以选择多种工具帮助你决定正确数量的预期，包括依赖分析、技术债控制以及对未来的经济考虑等选项 4：

• 使用依赖分析帮助你决定需要哪些架构组件以实现预期的用户故事。
• 使用技术债控制避免在没有时间进行重构解决方案的情况下，不会由于加入了过多的用户特性而使方案产生退化。要及时地找出架构上的技术债并计划处理它。我们在这里所说的并不是可以通过代码分析工具而检测出的实现过程中的技术债，架构债是的是会影响到项目敏捷度的结构上的不完美以及技术鸿沟，如果不处理掉这些债务，会使得整个方案逐渐僵化。
• 仔细地考虑经济方面的因素以衡量你的选择。像净现值（Net Present Value）这样的模型能够让你的客观洞察力表现为在正确的时间实施架构决策。使用这些技术与满心期盼的产品经理、忧心忡忡的运维人员以及其他项目干系人去讨论正确的项目预期。虽然商业预测有时不够精确，但比起参考敏捷教条、通用的设计原则或本能的感受还是更有说服力一些。

大规模敏捷框架（ http://scaledagileframework.com ）中使用了这样一个比喻，一条跑道可以在运转中不断地扩展，让它永远刚刚好能够容纳预期中会投入使用的新飞机（在这个比喻中的飞机就是即将到来的方案需求）。只要在跑道进行扩展之后，才能够让新的大型飞机进行着陆：由依赖分析决定容纳这些飞机需要对跑道进行多大规模的扩展。有时候你可以在扩展跑道时暂时使用一些较次的材料，换取进展的加快：它代表了那些技术债，你必须在某一时刻偿还（重新铺砌跑道）这些债务，以免出现事故。所有的决策（何时扩展或重新铺砌跑道）都要基于合理的经济原因。这就是敏捷架构的 5 条建议。决策是你主要的交付成果，这些决策将处理你放在待办事项表中，并根据经济影响，即风险与成本进行优先级排列的关注点。这些决策将产生一个最小的架构，其中只包含足够的预期。关于敏捷架构能够发挥的内容还有许多，包括项目组织（架构师是否应当成为开发团队的一员）以及开发流程（如何获取短反馈循环）等主题。这 5 点建议只是你在任何一个组织或流程中都能够应用的内容。

这些建议可以应用在例如 Scrum（见图 2）这样的敏捷项目方法中，而图 1 中的架构微周期用于将架构跑道的改进也放到产品待办事项表中。这些架构上的改进能够补足用户特性，在产品待办事项表中创建一种平衡的预期。但即使是在由计划驱动的项目中工作的架构师，这些建议也同样适用，这些架构师也经常要挤出大量的时间以应对变更和新产生的见解。无论使用哪种项目开发方法，架构师都必须确保他们已经处理了大多数重要的架构上关注点，而风险与成本已被证实是一种指出架构重要性的良好方式。

参考

1. J. Tyree and A. Akerman, “架构决策：让架构去神秘化”（“Architecture Decisions: Demystifying Architecture”），IEEE Software, vol. 22, no. 2, 2005, pp. 19–27.
2. M. Fowler, “谁需要架构师”（“Who Needs an Architect?”）， IEEE Software, vol. 20, no. 6, 2003, pp. 11–13.
3. B. Boehm, “架构：规模与时间？”“Architecting: How Much and When?,” “软件之道：软件开发争议问题剖析”（Making Software: What Really Works, and Why We Believe It）, A. Oram and G Wilson, eds., O’Reilly Media, 2010, pp. 141–186.
4. N. Brown, R.L. Nord, and I. Ozkaya, “通过架构实现敏捷性”（“Enabling Agility Through Architecture”） CrossTalk, vol. 23, no. 6, 2010, pp. 12–17.

关于作者

Eltjo R. Poort是一位来自于 CGI 的解决方案架构师。可以通过eltjo.poort@gmail.com 联系他。

本文最初发表在 IEEE__ 软件杂志上， IEEE__ 软件_ 杂志致力于发表严谨的、经过互相审校的文章，专注于当今世界的战略科技。_为了满足运行可靠且灵活企业所面临的挑战，IT__ 经理和技术管理者依赖 __IT Pro__ 获取最先进的解决方案。

查看英文原文： Driving Agile Architecting with Cost and Risk