虽然我们必须承认在设计和系统开发中出现了问题，但是少量的规划可以避免大量的浪费。

-James Coplien，精益架构

架构跑道

Architectural Runway包含实现近期功能所需的现有代码，组件和技术基础架构，无需过多的重新设计和延迟。

Architectural Runway通过持续交付管道支持持续的价值流，为开发业务计划和实施新功能和/或功能提供必要的技术基础。架构跑道是用于实施框架敏捷架构战略的主要工具之一。

由于新功能和功能的开发消耗了架构跑道，因此必须通过实施启动器来进行持续投资以扩展它。一些使能器解决了当前解决方案的缺点，例如改善性能或用户体验。其他提供将用于支持未来功能的基础功能。

细节

敏捷开发避免了大型设计前期（BDUF），并以简单的信念取而代之，“最好的架构，要求和设计来自自组织团队[3]。”这产生了紧急设计的实践 - 仅在必要时发现和扩展体系结构，以实现和验证下一个功能增量。

但是，组织必须通过需要一些意向性和规划的大规模架构计划同时应对新的业务挑战。因此，单独的紧急设计无法处理大规模系统开发的复杂性，并且开始出现以下问题：

•     过度的重新设计和延迟会降低速度
•     系统变得难以集成，验证和维护
•     系统质量下降，称为非功能需求（NFR）
•     减少团队之间的协作和同步
•     公共组件的低重用和解决方案元素的冗余

所有这些问题都可能导致解决方案性能不佳，经济性差，并缩短产品上市时间。

策划的架构支持更大的图画

所有团队都无法预测可能在其环境之外发生的变化。个别团队也不能完全理解整个系统，避免产生冗余和/或冲突的设计和实现。简而言之，大型企业中的任何一个团队都无法看到整体情况，也无法合理地预测所有变化的方向 - 其中很多都是在本地控制之外。

出于这个原因，团队需要一些有意的架构 - 一组有目的的，有计划的架构指南，在同步实施的同时增强解决方案设计，性能和可用性以及跨团队设计的方向。

有意识的架构和紧急设计共同应用，使敏捷发布列车（ART）能够创建和维护大规模解决方案。紧急设计可实现快速的本地控制，以便团队能够针对不断变化的需求做出适当的反应，而无需过多地尝试未来的系统验证。有意架构提供了确保整个系统具有概念完整性并且适合其目的所需的指导。实现紧急设计与有意结构的正确平衡是有效开发大规模系统的关键。

通过架构实现持续交付和按需发布

架构师在设计能够为用户提供持续价值流的系统方面发挥着关键作用。 Enterprise Architects在Portfolio Level上定义启动器，而System and Solution Architects / Engineering通常在Program和Large Solution级别定义它们。定义启动器的架构师帮助引导他们通过看板系统，提供分析，估计和实施它们所需的指导。此支持确保受影响的元素 - 子系​​统，组件，功能，协议，内部系统功能 - 具有支持路线图中近期特性和功能所必需的体系结构。

为了避免BDUF方法，企业承诺逐步实现体系结构。这意味着必须将启用器史诗分成启用器功能和/或功能，这些功能和/或功能最终由各个ART实现。每个启用程序功能必须在程序增量（PI）中完成，以确保系统始终运行 - 这意味着它可以部署，即使在开发过程中也是如此。

架构是持续交付管道（CDP）的关键推动因素，架构跑道与构建CDP有关。有效的CDP通过持续集成和持续部署为团队提供即时质量反馈。它还通过直接的用户反馈和经过验证的学习为持续探索和按需发布提供支持（参见Lean UX。结果是一种适应性和适用性的高质量产品。

建造架构跑道

当新平台特别具有创新性，或者在全新开发的情况下，系统或解决方案架构师/工程师在定义和构建跑道方面发挥作用是很常见的。通常，新的基础架构最初只需要几个敏捷团队就位 - 有时在最初的几次迭代期间，架构师/工程师担任产品负责人，如图1所示。

图1.启动架构跑道

建立跑道的规则既简单又敏捷：

•     构建跑道的团队像程序中的其他敏捷团队一样迭代。
•     归功于工作解决方案，而不是模型和设计。
•     时间就是生命。实现和证明新架构应该只需要几次迭代。
•     之后很快，该程序扩展为添加一些功能团队，他们使用初始的可消耗功能测试新架构，如图2所示。

图2.在新跑道上实施一些新功能

与此同时，团队建立了额外的架构跑道，如图3所示。

图3.构建架构跑道的进展

为了支持稳定的速度，架构跑道需要不断维护和扩展。容量分配（参见计划和解决方案积压）用于确保对启动器的持续投资 - 扩展跑道所需的活动。

产品/解决方案管理和架构师/工程师与受影响的团队合作，定义了许多这些促成因素。但实施是ART的责任。在支持成功的近期交付的同时，架构跑道不应过度限制开发的远程技术承诺。只需要适量的架构跑道：

•     太多了，体系结构限制了团队，并且与当前的上下文断开连接
•     太少了，团队将难以制定并履行他们的近期承诺

消费架构跑道

有了新的架构，并且已经部署了有价值的功能，所有这些都很好。然而，这种初步成功可能是暂时的，因为随着时间的推移，许多自然力量将倾向于消耗架构：

•     敏捷团队很快 - 他们拥有无与伦比的专注力和能力来提供新功能，从而消耗现有的跑道
•     产品所有者和产品/解决方案管理人员不耐烦 - 他们在内部系统功能上投入了一些时间，他们会快速将积压优先级转移到用户愿意支付的功能上
•     架构本身很脆弱，需要不断发展 - 技术变化迅速，过时
•     客户需求快速变化 - 在当今快节奏的数字经济中，机遇和威胁迅速出现，客户需求不断发展

除非敏捷团队确实参与其游戏，否则结果将如图4所示。

图4.使用架构跑道

延伸架构跑道

团队如何避免在他们开始的地方回来？通过认识到投资架构不能是一次性或罕见的事件。毕竟，ART使用各种看板系统在连续流程中运行。因此，团队必须致力于不断详细阐述，分析和实施推动因素。此外，架构师/工程师和敏捷团队需要掌握将启动器分成小片的技能，这些技巧可以在每次迭代和PI期间实施，从而不断为客户提供价值（参见系统和解决方案架构师/工程部和敏捷软件需求，第20章和第21章[2]，用于增量实施策略）。

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

在构建非常大的系统时，架构跑道扮演着更为关键的角色，因为多个ART作为解决方案培训的一部分为同一解决方案做出了贡献。 Business Solutions和Lean Systems的文章描述了构建大型解决方案的八种实践，其中有几种与架构跑道密切相关：

•     在解决方案意图中不断细化系统规范 - 解决方案Intent以非功能需求（NFR）的形式定义了许多约束。许多NFR都是跨领域的问题，可以通过有意为其实施和测试构建架构支持来解决和简化。解决方案中的更改意图可能会创建额外的工作来构建更多的体系结构跑道或使现有跑道无效。
•     应用多个规划视野 - 在大型解决方案中，基础功能可能需要较长时间才能实施。这些系统需要更长的架构跑道，通常在程序和/或解决方案看板系统中使用Enabler Epics实现。
•     规模，模块化，可发布性和可维护性的架构师 - 在大型解决方案中实现这些目标需要有意的架构来实施有效的持续交付管道，并通过应用程序遥测确保简化的操作和强大的反馈。
•     持续解决合规问题 - 精益合规方法可以自动化合规数据的测试和生成，从而提供更有效和可预测的结果。此目标通常要求尽早与合规审计人员和当局商定，以就可接受的方法达成一致，然后通过架构跑道创建功能，以确保一致性并消除重大的合规风险。

架构跑道的背景故事

术语“架构跑道”起初是一个类比，同时观察PI级烧毁图表。通常，当团队启动PI时没有足够的架构跑道时，任何依赖于新架构的功能都是高风险。

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

在SAFe Big Picture中，随着时间的推移，架构跑道线会上下移动，因为团队会建立一些跑道，然后使用一些跑道，建造更多跑道，然后再使用它。简而言之，任何时候都必须有恰当的数量。

为了延长跑道比喻，飞机（系统）越大，飞行速度（速度）越快，安全降落PI所需的跑道越多。在Agile Architecture中进一步解释了Architectural Runway。

 
学到更多

• [1] Leffingwell，Dean。扩展软件敏捷性：大型企业的最佳实践。艾迪生 - 韦斯利，2007年。
• [2] Leffingwell，Dean。敏捷软件要求：团队，计划和企业的精益需求实践。 Addison-Wesley，2011年。
• [3]敏捷软件开发宣言。 http://www.agilemanifesto.org。

讨论：请加入知识星球【首席架构师圈】