红帽公司 CEO Jim Whitehurst 在 2018 年红帽峰会上做的主题演讲中指出：『众所周知，计划已经消亡。在一些不太了解的环境中，计划的效率非常低下。』随着业务环境的运行速度逐步加快，而且重大变更持续发生，计划会迅速被打破，而受限于一种行动方案可能会付出巨大代价。

这意味着您掌握的信息越少，或者您的环境越不稳定，计划的价值就越低。

您不知道自己不知道什么 - 基础架构规划通常是一个长期的过程，有时跨越多年时间。如果尝试制定多年计划，可能会扼杀企业随着市场变化而创新或转型的能力。Jim Whitehurst 提到的计划『消亡』最终可以归结为更快制定计划和执行计划的能力，这会令计划的期限缩短，有利于孕育新的计划。

当团队已经习惯于 6 个月甚至 24 个月的开发周期时，这种快速变化可能带来巨大的挑战。对于一些采用更传统结构的企业而言，当他们必须以全新的方式与正在开辟市场的初创企业进行竞争时，这一问题就会加剧。Netflix 与 Blockbuster，或者 Uber 与传统的出租车服务企业，就是很典型的例子，但初创企业的颠覆性影响可追溯到信息时代的初期，即从 1993 年的亚马逊或 20 世纪 80 年代的个人电脑开始。

初创企业和颠覆者的优势在于他们可以自由构建基础架构、团队、应用、架构、甚至部署流程。他们不仅有创新的想法，而且关键是他们能够执行这些想法，因为不受传统基础架构（或者如 Rachel Laycock 所称的『守旧人』）制约，所以可以实现敏捷运营。

除了构建新设施的能力之外，这些企业还构建可以应对变化的系统。软件基础架构是其差异化能力的一部分，并且系统的几乎任何部分都可以根据不断变化的市场需求而更换、更新或移除。随着初创企业走向成熟，一些企业的适应能力下降，但最好的企业不惜一切代价确保自身能力应对变革。

迎接挑战

要在快速变化的环境中取得成功，整个IT基础架构必须以敏捷的方式运行。

变革需要在两个层面上发生：

技术和文化变革不会带来敏捷性，而是敏捷性的基础。

eBay 产品经理 Marty Cagan 对每个例行项目都实行了他称之为『收税』的做法——从每个例行项目中省出一些时间和资源，以开展新的基础架构项目。这使得新项目和创新能够优先实施。

如果在探索改进方案的过程中，不同的团队朝着不同的方向发展，那么大量新技术的引入往往无助于构建敏捷的基础架构。如果没有一套完整的总体目标，就很难确定哪些新能力会对组织的整体运营产生真正的影响。

敏捷集成理念需要三个主要技术的支撑。

这三种技术使 IT 基础架构更加敏捷，因为它们分别提高了抽象级别，使不同团队可以互相协作。使用带有 API 和分布式集成能力的容器平台，将集成的实施过程与集成本身分离。团队的敏捷性得以提高，因为 API 和分布式集成模式能够以易于理解的方式将特定资产打包，而无需理解或更改底层基础架构。

如果分别使用，每项技术都将为特定的集成挑战提供显著的敏捷性。如果结合使用，则可以带来乘数效应。技术有赖于文化：与 DevOps 实践结合，尤其是自动化和部署流程，可以让该技术的优势进一步增强。

基础架构的生命周期与软件开发或运行的生命周期截然不同。开发周期是完成一个项目，然后转到下一个项目，效率意味着加快产品发布或者在指定时间内创建多少个新特性。即使对于更关注维护和稳定性的运营方式而言，更有效而且更快地应用安全补丁和更新、部署新服务或撤销更改仍然很有用。

但是，基础架构采用了截然不同的方法。基础架构倾向于在更长的时间段内运行，并且与不同的高度专业化小组合作，这与开展特定软件工程项目的跨职能团队完全不同。基础架构项目通常比软件项目的规模大得多，这意味着在较短发布周期内可能无法完成太多工作，或者可能导致结果不完整。如企业 IT 专业人士 Andrew Froelich 在《InformationWeek》中所写的那样，基础架构有一个无返回限制的点， 特别是对于硬件和数据中心，但即使对于公有云，在达到某个时间点后，不能放弃项目并重新开始。基础架构是永久的。然而，您可以根据基础架构的性能而调整所用的方法。

敏捷和 DevOps 等快速响应式迭代流程的优点对于开发和运营团队来说显而易见，而对于基础架构团队不太明显。然而，Froehlich 在对基础架构敏捷性的优缺点进行分析时忽略了一个关键方面：基础架构团队与开发和运营团队的协调一致。Rohan Pearce 在《CIO》中介绍了要将基础设施团队转变为敏捷式工作单元，而不是职能团队。Telstra Enterprise Services 团队让开发团队忽略内部系统，因为检查系统或进行更新的过程非常痛苦和复杂。通过调整工作组，他们的开发周期从 212 天减少到了 42 天。

本例说明了基础架构团队如何更有效地服务内部团队，从而实现关键流程的改变。

敏捷集成技术可以支撑更灵活的基础架构。API、容器镜像和分布式集成已经成为软件基础架构中新的热点。

敏捷宣言为软件开发定义了四个核心原则。在基于集成技术的敏捷基础架构中，这些原则可应用于集成战略。

敏捷集成使用技术来支持基础架构团队中的文化变革。它是基础架构战略的基础，并将基础架构技术及其团队，与开发和业务战略更紧密地结合在一起。

敏捷方法指出了软件项目中的一些关键部分，例如个人、构建和依赖关系。然后，它可以定义这些元素之间的关系。在将集成基础架构作为敏捷项目进行实施时，可以识别与敏捷方法类似的元素和关系，例如团队、容器镜像、API 和集成点。表 3 描述了其中的一些相似点。

将敏捷原则应用于基础架构计划

大多数变更管理方法要求所有子系统都有全面的文档记录。该文档必须详细介绍系统的各个方面，包括监控方法、性能参数、负责的团队。敏捷原则需要协作和适应性，这与需要大量文档的变更管理流程相冲突。

定义一套可用于评估变更请求和计划的准则和标准，而不是试图规范地定义所有潜在的利益相关者、变更和系统组件。应考虑以下问题：

敏捷基础架构内的变更管理应该更多关注持续协作，而不是合同。

拥有共享技术堆栈后，讨论的焦点从独立代码转移到了系统及其相互依赖关系。这是系统级思维，它将整个软件基础架构作为单个系统，包括内部开发的软件、供应商系统以及它们之间的连接。API 和消息系统可以跨越整个基础架构，并努力实现软件系统的统一性。

由于 API 和分布式集成可由单个开发或运营团队开发和理解，因此对团队职责会有更清楚的认识。集成本身也可以更好地被理解，原因是负责开发和部署的团队认识到了系统和应用程序之间的相互依赖关系。

将集成作为基础架构的基础，然后为不同的团队分配集成责任，这创建了一种更适合采用敏捷方法的基础架构环境。

敏捷性是一个过程，而不是单个项目。

企业应对市场变化的能力从未像现在这样重要，从很大程度上讲，IT 系统必须提供这种能力，这样才能快速启动新服务或更新现有服务。重新思考 IT 基础架构比以前更加重要，因为这是数字化服务的基础。

由于需要降低风险并保持稳定性，基础架构团队过去需要完成一个冗长的调整过程。然而，基础架构的理念可以从基于硬件或平台转变为基于集成。集成不是基础架构的一个子集，它是基础架构的概念性方法，包括数据、应用以及硬件和平台。

我们将此方法定义为敏捷集成，这是使用集成技术来创建更灵活、更具适应能力的基础架构的一种方式。敏捷集成有三个技术支柱：

技术必须用于支持文化变革，这意味着要使基础架构团队更加敏捷，而不仅仅是他们的软件。随着基础架构团队与敏捷原则保持一致，可以逐渐引入技术来支持这些变革。没有一个项目可以将整个企业改造得具有敏捷性。更加有效的方法可能是实施一种敏捷集成技术或改变业务的一个领域，然后在更大范围内逐步扩展这些变化。

增强 IT 基础架构对变化的响应能力是一个长期的战略目标。无需在整个企业内开展彻底的变革即可实现进步，甚至可能没有必要尝试进行单独的变革然后逐步推广。

在技术和组织层面，敏捷集成提供了一个框架，可帮助重塑 IT 基础架构。