架构跑道：虽然我们必须承认设计和系统开发中的出现，但一点规划就可以避免太多浪费。

虽然我们必须承认设计和系统开发中的出现，但一点规划就可以避免太多浪费。

----James Coplien，《精益架构》

架构跑道

架构跑道由现有代码、组件和技术基础设施组成，这些代码、组件及技术基础设施需要以最小的重新设计和延迟实现近期功能。

架构跑道支持通过持续交付管道实现持续的价值流，提供快速定义、构建、验证和发布特性和功能所需的技术。它还支持敏捷体系结构的实践，允许组织的技术环境随着业务需求的变化而发展。

详情

敏捷开发避免了大型的前期设计（BDUF），简单地认为“最好的架构、需求和设计来自自组织团队”。这就产生了紧急设计的实践，即仅在必要时定义和扩展架构，以提供下一个功能增量。

然而，仅靠紧急设计无法处理大规模解决方案开发的复杂性。在规模上，仅依赖紧急设计会导致以下问题：

缺乏标准会增加交付成本和延误

一次性解决方案变得难以更改和维护

系统容易受到安全性和稳定性问题的影响

质量取决于部落知识

解决方案组件的互操作性和可重用性较差

这些问题可能导致解决方案性能不佳、经济结果不利以及上市时间延迟。组织通过平衡紧急设计与有意架构来克服这些问题，这需要一些集中规划和跨团队协调。两者都是通过 Enablers 实现的，并一起“铺设”架构跑道（图 1）。

意向架构支持系统演进

敏捷团队通过开发史诗故事来应用紧急设计，这些故事逐步发展解决方案的各个部分。但是，他们通常缺乏端到端解决方案的广泛知识，而这些知识使他们能够有效地跨所有领域设计组件和基础设施。其中许多设计因素完全超出了他们的职责范围。

意向架构考虑了这些系统性设计考虑因素，并提供了有目的的、有计划的架构指南，使敏捷团队的独立工作能够集成到一个有凝聚力的、可持续的解决方案中。这些跨领域指南通常由企业架构师、解决方案架构师和系统架构师与产品经理和解决方案经理密切合作定义。这些角色非常适合这项任务，因为他们对技术环境有广泛的了解，对解决方案上下文有深入的了解。

意向架构在项目组合待办事项、解决方案待办事项和ART待办事项中编纂为史诗故事、功能和特性。然后，架构师通过适当的看板系统帮助引导推动，确保他们产生预期的架构跑道。

建造架构跑道

在定义架构跑道时可能涉及多个角色，但其实现是敏捷团队的责任。这些团队通常负责提供以最终用户为中心的产品或服务。因此，建造架构跑道不应过度限制它们。

在任何给定时间都需要合适数量的架构跑道。太多了，架构会使团队和工程师面临瓶颈，从而增加当前的解决方案。太少，组织将没有满足近期业务承诺所需的跑道。将能力分配应用于团队待办事项，以帮助确保启用人员工作与面向客户的工作的比例始终保持平衡。

当需要对架构跑道进行大量投资时，通常会有专门的敏捷团队监督初始实施，例如启用新产品发布、Horizon 3 产品组合计划或旧环境。（图 2）。

在这种情况下，架构师通常扮演产品负责人的角色，在主要由待办工作中充当客户和内容权威的代言人。一组专门的团队成员负责开发，Scrum Master/Team Coach负责指导执行。

这个团队会一直持续到ART所需的跑道工作量不再足以保证一个专门的团队。此时，根据需要实现额外架构跑道的责任将由 ART 的持久敏捷团队分担，如图 3 所示。

无论谁执行工作，建造跑道的规则既简单又敏捷：

构建跑道的团队像 ART 上的其他敏捷团队一样进行迭代

价值在于工作系统，而不是型号或规格

启用功能和故事应分别不超过一个PI或迭代才能交付

敏捷团队是架构跑道的利益相关者，利用它来实现客户承诺，并就其有效性提供反馈

持续投资架构跑道

架构跑道是动态的。它通过提供近期功能来“消耗”，并且必须扩展以支持未来的功能。以下是消耗架构跑道的力量的示例：

快速移动的敏捷团队 – 他们快速使用最新的跑道来提供近期功能

客户偏好 – 在投资架构跑道后，利益相关者通常会将待办事项优先级转移到直接使客户受益的功能上

技术创新 – 技术日新月异，现有跑道过时

不断变化的业务需求 – 企业的需求因应对新出现的机遇和威胁而变化

使用架构跑道来提供计划的功能。随着业务需求的变化和新功能的需要，需要额外的跑道（图 4）。

由于新特性和功能的开发会占用架构跑道，因此必须进行持续投资以扩展它。团队承诺在每次迭代中根据需要扩展跑道，以支持快速、可持续的交付速度。这可能包括向 CDP 添加自动化、增强 DevOps 实践、增加服务器容量或任何其他加快交付速度的活动。

大型解决方案中的架构跑道

在构建真正大型系统时，架构跑道发挥着更加关键的作用，因为多个 ART 作为解决方案列车的一部分为同一解决方案做出贡献。《企业解决方案交付》一文介绍了指导大型解决方案交付的十种精益敏捷实践，其中几种与架构跑道直接相关：

以增量方式指定解决方案 – 解决方案意图将许多约束定义为非功能性需求 （NFR）。许多 NFR 都是跨领域问题，可以通过构建支持集成和测试的架构跑道来解决和简化。架构跑道还允许解决方案意图的元素从可变到固定的平稳和渐进式演变。

应用多个规划范围 – 大型解决方案通常需要更长的架构跑道，并在多个 PI 甚至数年内通过史诗故事实施。这些长跑道的高效交付是通过连接的迭代计划、PI路线图和解决方案路线图来协调的。

为变更而设计 – 在大型解决方案中实现这些目标需要有意识的架构来实施有效的持续交付管道，并通过应用程序遥测提供强大的反馈来确保简化操作。

持续解决合规问题 – 精益合规方法可自动收集和测试合规数据，以提供更有效和可预测的结果。要实现这一目标，需要尽早与审计师和利益相关者接触，以就可接受的方法达成一致。通过架构跑道创建功能可确保一致性并消除重大合规性风险。

演进已部署的系统 – 快速、经济的持续交付管道意味着解决方案以及对这些解决方案的更改可以按需发布。架构跑道提供了一个 CDP，通过该 CDP，部署的解决方案可以以增量模式极少的扰乱客户。

逐步实施长跑道至关重要。史诗故事被拆分为子特性或功能，然后由 ART 实现。每个启用功能都必须在 PI 中完成，并且启用故事必须在迭代中完成。这使得对架构跑道的大量投资能够在有意建筑和紧急设计之间取得适当的平衡。

架构跑道的背景故事

“架构跑道”一词最初是在观察 PI 级别的燃尽图时进行类比的。通常，当团队启动 PI 时没有足够的架构跑道时，任何依赖于新架构的功能都是高风险的。

ART 不能总是“登陆这些 PI”（在 PI 结束时将燃尽降为零）。在这种情况下，它们不符合 PI 目标。PI就像飞机一样，需要足够的跑道才能安全着陆。

在 SAFe 中，架构跑道线会随着时间的推移而上下波动，因为它是建立起来的，然后使用，然后再建立一些，然后使用等等，依此类推。在任何时候都必须有合适的数量来支持近期业务目标。

为了暗喻扩展跑道，飞机（系统）越大，飞行速度（速度）越快，就需要更多的跑道来安全降落PI。