传统位移模式

当面临更换现有软件系统的需求时，组织通常会陷入技术更换半完成的循环。我们的经验教会了我们一系列模式，这些模式使我们能够打破这种循环，依赖于：有意识地认识到取代遗留软件的预期结果，打破这种部分的取代，逐步交付这些部分，并改变文化组织认识到变化是不变的现实。在过去几十年的大部分时间里，我们一直在帮助大型组织检修他们的遗留系统。在这样做的过程中，我们学到了很多关于什么有效的知识，并看到了许多导致失败的路径。我们决定留出一些时间，以我们看到使用过的各种模式的形式写下我们学到的东西。本文充当这些模式的中心。我们经常看到组织陷入了半途而废的传统更换工作的跑步机上。我们认为打破这个循环的关键是需要按顺序完成四项活动，但主要是在公司的生命周期中反复进行。我们使用这些活动作为组织我们描述的模式的主要结构。我们一直相信，有效的软件开发需要逐步发布有价值的功能，我们认为写作也是如此——尤其是在网络时代。我们从这篇叙述性文章开始，随着我们写下它们的详细信息，将逐渐添加模式，以及展示它们如何组合的其他示例。我们不能保证任何日期，因为我们的首要任务是我们的客户工作，这不乏可以取代的遗产。如果您有兴趣了解这项工作的更多部分，它们将在 Martin 的 twitter 提要和本网站的 RSS 提要上公布。我们与许多组织合作，他们多次尝试删除遗留系统。在一个相当典型的组织中，他们经历了一系列长达 3-5 年的现代化计划。每次他们都会定义一种新的技术方法，然后作为大型多年现代化计划的一部分朝着这种新方法努力。在每个项目的某个时候，他们遇到了一个危机点，不断变化的业务需求将超过他们当前的技术战略，从而触发重新开始的需求。在他们对程序采取瀑布式“大爆炸”方法的地方，这意味着放弃大部分工作。在采用更多增量交付方法的其他情况下，所采取的方法只是在已经很复杂的环境之上添加一层稍微较新的技术。对于这两种情况，他们都无法停用任何遗留堆栈，成本节约和风险降低的关键业务目标仍未实现，这对于许多遗留替换工作来说是非常普遍的结果。首先，他们看到的糟糕结果在很大程度上是组织的产物；特别是它的领导力、结构和工作方式。他们认为只要选择更新的技术，而其他一切都或多或少保持不变，他们会得到与过去不同的结果。事后看来，这显然是不现实的。

其次，现代化将通过一个大型变革计划来实现，该计划本身包括一系列项目和团队。这些项目被视为与任何 BAU（一切照旧）工作无关。因此，BAU 继续根据现有系统交付业务需求，而新项目团队则根据更换计划开始时商定的一组需求交付。随着时间的推移，他们发现企业实际需要的东西与计划开始时实际签署的东西之间的差距越来越大。每个项目运行的时间越长，项目计划与 BAU 和未来需求之间的差距就越大。虽然变更控制流程已到位以向计划添加新要求，但这些流程非常耗时，而且由于前期供应商合同，成本高得令人望而却步。几个失败的第三个关键因素是希望与现有的系统和业务流程集实现功能对等。这些尝试一开始是承诺以某种方式在幕后“改进”技术，为企业提供他们今天所拥有的一切。到那时，业务领导者看到了多次失败并担心中断，认为这是一种风险较低的策略。这里的挑战甚至是定义和同意当前的“原样”功能是一项巨大的努力，它导致了一个大型单一“大爆炸”切换版本的计划。我们对这个组织和许多其他组织的观察是，技术最多只占遗留问题的 50%，工作方式、组织结构和领导力对成功同样重要。显然有必要打破“技术替代计划”的循环。简而言之，组织需要能够继续满足业务需求，同时更换过时的技术，所有这些都是在加速技术变革和更严峻的竞争环境的背景下进行的。我们发现有一系列方法可以帮助应对这些挑战。它们有助于解决将问题分解为更小的部分的挑战，以便在改进技术的同时满足新要求。从广义上讲，它们分为四类： 对于组织来说，在处理遗留问题时就他们想要实现的结果达成一致至关重要。虽然这似乎很明显，但组织的不同部分往往对预期结果有截然不同的看法。大多数遗留现代化计划涉及我们下面列出的几个结果，但在开始旅程之前确定哪些是优先事项至关重要。

许多组织在决定解决遗留问题时的一个关键转折点是，由于机会成本（也称为延迟）或实施成本，所需的业务变更开始的成本远高于任何预期收益。一个预警信号是，必须花费数周、数十或数以千计的时间来对网站进行更改，从而只带来业务绩效的小幅提升。在这一点上，通常不再可能证明进行任何不会带来大量投资回报的更改是合理的。换句话说，技术的状态已经开始决定企业可以做出的改变的规模。对于许多组织而言，这意味着进行“BAU”更改或必须发起更大的项目之间的区别。然后，这些较大的项目会吸引所有以前不合理的小变化，从而增加其范围、成本和风险该系统与系统中的约束一起工作，并且通常解决“系统外”塑造人们完成工作所遵循的业务流程。我们看到的一个例子是使用“绿屏”终端的航空公司值机系统，由于遗留系统的限制，必须按照严格的顺序执行该过程，这意味着更正或错误意味着重新开始值机过程。同样最初航空公司没有提供转机航班，当添加此功能时，由于该技术的限制，它必须作为遗留系统中的单独工作流程来完成。因此，如果在办理登机手续时，乘客没有提到他们有转机航班，则会遵循错误的流程，包括打印错误的行李标签，只有在此之后系统才会标记转机航班。通过改变流程，值机人员的工作和乘客的体验本可以得到很大改善，但由于旧系统，这是不可能的。鉴于此，更新和更改业务流程反过来需要更改支持技术的工作方式也就不足为奇了。试图在不改变技术的情况下改变工作流程通常会导致“离系统”工作，在这种情况下，人们会求助于将数据提取到电子表格或类似工具中，在那里进行处理，然后再将数据导入到遗留系统中。在一个组织中，整个股票订购过程实际上是在运行在团队经理 PC 上的 Microsoft Access DB 上完成的。由于遗留系统无法支持供应商的新工作实践，他们变得沮丧。他们每周会进行几次数据的导入和导出，与此同时，组织的其他成员会看到过时的数据，因为没有人意识到发生了什么。这里值得注意的是，支持数据导入和导出的替换系统的要求通常可能是这种解决方法的根本原因。

需要淘汰旧系统是遗留系统现代化的常见原因。这通常是由支持旧硬件或软件方面的挑战所驱动的，这些问题包括支持成本上升和硬件和软件支持合同到期等问题。我们发现通过业务的视角来查看旧系统的退役很有用。因此，建立在旧技术上的系统本身并不是更换的充分理由。相反，我们需要查看业务影响，这会导致运行成本不断上升，或者由于缺乏系统支持或知识而产生的风险。虽然一些组织确实为旧技术的淘汰做好了计划，但许多组织似乎在问题达到危机点之前忽略了这个问题。反过来，这往往会促使组织采用看起来像低中断选项或快速获胜的现代化方法，这些通常是反模式，我们稍后会描述其中的一些陷阱。多年来，我们一直震惊于有多少大型组织在不受支持的硬件和软件上运行业务，在 eBay 上购买备件是令人惊讶的常见故事。如果您拥有遗留技术，则非常值得进行适当的调查并创建包含各种终止支持日期的日历。虽然许多组织将旧系统的退役作为遗留现代化的关键结果，但发现这种情况实际上并没有发生的情况并不少见，遗留在最后仍在使用，相关的业务目标仍未实现。对于某些组织而言，处理遗留问题的实际临界点可能会由于外部因素而出现，例如监管变更、新的“初创”竞争对手或现有竞争对手的重大变化。通常在这一点上，当面临“必须做”的更改时，资金和响应所需的时间变得过长。外部事件使组织的领导层清楚他们不再有能力以成比例的成本进行更改。

采用新技术不应该成为传统现代化的原因，仅仅为了自己的利益而拥有更新技术很少是任何组织的关键目标。相反，它应该以最能满足企业当前和未来需求的方式进行选择和选择。这里的一个挑战是技术变革的步伐正在加快，技术的“有用”寿命越来越短。 “有用”的实际定义取决于组织，但一般而言，我们需要考虑以下事项： 我们今天做出的关于最佳和最有用技术的选择可能会在相对较短的时间内被更好的替代方案所取代。这使得在寻找技术以满足未来需求方面做出正确的决定可能非常危险。这里的一个好方法是不要做出任何在 2-3 年内无法轻易“完成”的选择。这对技术选择以及整体设计和方法都有影响。当我们承认这种加速的变化步伐时，选择一个具有 5 到 10 年回报时间的大型平台是很难证明的。需要更快的更改以及在没有大量依赖的情况下增量交付和独立更改业务元素的能力通常会导致“敏捷”交付方法以及基于微服务的架构。持续交付成为这些可单独部署的组件的必备条件。使这一挑战超出普通软件交付范围的原因在于，寻找从现有大型解决方案的元素中切入、共存并最终替换元素的策略。存在几种成功的策略，包括并行运行、入口分叉和流量分流。在不使用结果的情况下调用新的后端功能以评估其性能影响。新系统以旧系统不知道任何更改的方式与遗留系统交互。拦截系统状态的任何更新并将其中一些路由到新组件

如果我们退后一步并查看交付新业务需求的整个过程，我们会很快发现这只是部分技术问题。如果我们使用更新的技术来减少构建解决方案的时间和成本，那么我们将强调与达成一致的要求和将更改投入生产的任何问题。我们需要改变组织结构和流程以充分利用更好的技术，根据“康威定律”，我们还需要一个促进这一点的技术架构。如果团队和他们的沟通是围绕现有的遗留解决方案和流程组织的，我们可能需要使用逆康威机动来重新组织他们，以匹配新的解决方案及其架构。遗留系统可以约束和限制采用更现代工程实践的能力，尤其是那些与极限编程和持续交付相关的实践。在更换遗留系统时，重要的是要确保改变工作方式，以确保我们最终不会回到一个缓慢、困难且更改成本高的系统。遗产也是组织文化和领导力的产物，如果没有更广泛的变化，您应该期待与之前看到的相同的结果。我们已经观察到许多传统的现代化工作由于“企业抗体”而失败，这些抗体发现新发生的事情并采取行动将其从组织中拒绝。举一个广泛的组织可以拒绝变革的方式的例子；我们与一家非常大的电信公司合作，该公司希望为手机开发软件。领导层都明白这意味着比他们看到的专注于固定基础设施的现有计划更快的反馈周期和更频繁的变化。虽然领导层理解这一点，但没有对现有的工作实践或运行这些流程的中层管理人员进行任何更改。因此，现有的变更控制流程得到了严格的应用。最后，软件团队花在填写变更控制表格和参加变更控制会议上的时间比他们制作软件的时间要多。 “企业抗体”成功地拒绝了新的工作方式。组织变革是一个大话题，已有很多文献可用，遗留问题的关键挑战通常与时间相关。很少有组织能够在重新设计（或重建，对于外包受害者）整个交付方法以及组织结构和关键业务流程的同时延迟遗留现代化。虽然更广泛的组织转型主题超出了我们的范围，但我们确实推荐了一些策略，用于在遗留环境中应用和保护新的工作方式。如果你只是改变传统而不做其他事情，那么期望你会在几年内再次取代传统是公平的。

以您需要在上线后继续的方式创建您的旧版替代品。为新工作创建一个试点计划，并将其与正常的公司治理流程分开 组织转型肯定还有其他策略和方法，我们只是强调了这两种策略和方法，因为它们在某种程度上允许尽早开始遗产现代化的工作.这个例子描述了我们的一个团队如何使用许多遗留现代化模式来成功替换对其客户业务运营至关重要的集成中间件，作为更大的遗留现代化计划的一部分。他们将模式和重构相结合，成功地管理了业务风险，并促进了大象这一特别坚硬的部分的食用。我们团队面临的挑战是如何用新的可支持、灵活的业务解决方案替换不受支持、难以更改且成本高昂的集成中间件。不会破坏现有业务运营或将其置于风险之中。有问题的中间件用于在后端系统和店面之间进行集成。这些系统共同负责每天销售价值数千万英镑的高价值独特产品。这项工作是一个更大计划的一个高度优先的部分。支持业务的整个后端系统正在被替换，店面也将在几年内进行现代化计划。因此，按照上面的第 1 步，团队需要实现的业务成果被定义：如何？这个特定的集成中间件解决方案包含大量逻辑，包括业务核心规则，例如在哪个渠道销售产品，或如何以及何时在店面内展示待售产品。这个现有的系统很难改变，扼杀了业务创新，逻辑上的缺陷导致了产品甚至没有销售的时期等问题！

为什么？减少现有（和增加）的许可和支持成本。此外，为了降低因在过时的支持中间件和数据库技术上运行关键功能而对业务造成的风险。在 Inception 期间，团队与对遗留系统有深入了解的人举办了一个研讨会，以协作可视化原样和未来的软件架构。完成此操作后，他们发现了一个技术接缝，可以在遗留后端和集成中间件之间以基于消息的集成形式加以利用。 Legacy 后端，一个老化的 J2EE 应用程序，将“发布产品”消息放置到一个非常旧版本的 SwiftMQ 提供的队列中。事件拦截模式在这里很有用，如果实现为基于内容的路由器，将允许控制来自旧后端的消息的路由方式，并创建一个选项，使消息能够路由到新系统。集成中间件还处理来自店面的消息（例如用于产品销售），使用 JDBC 直接更新遗留后端后面的主数据库中的状态。通过 SwiftMQ 的异步消息传递和 JDBC 数据库更新共同构成了传统后端和集成中间件之间的接口。尽管当时没有发现，该团队能够在子系统规模上使用抽象分支模式作为替代遗留中间件的策略。抽象层是队列和 JDBC。通过确保新的实现遵循该抽象层，它可以被替换为“有缺陷的供应商”而不会影响业务运营。该团队所做的第一件事是通过重构添加一个事件路由器来实现事件拦截。将消息从一个 SwiftMQ 队列中取出，并将它们放入另一个 SwiftMQ 队列中 (2)。一个微不足道的变化......