遗产置换模式

遗留软件系统的有效现代化

当面临替换现有软件系统的需求时,组织通常会陷入一个技术替换完成一半的周期。我们的经验教会了我们一系列模式,使我们能够打破这种循环,依赖于:有意识地认识到取代传统软件的预期结果,打破这种部分取代,逐步交付这些部分,改变组织文化,认识到变革是永恒的现实。

2021年7月20


伊恩·卡特赖特的照片

Ian Cartwright是Thoughtworks的技术总监,他运用自己作为架构师和动手开发人员的20年经验来帮助客户提高他们的技术能力。

罗布·霍恩的照片

Rob Horn是Thoughtworks的技术总监。他是一位经验丰富、充满激情的技术顾问和敏捷实践者,在25年以上的职业生涯中,他花了大约15年的时间与客户一起解决金融、社会、旅游和公共部门的传统现代化挑战。

詹姆斯·刘易斯的照片

James Lewis是Thoughtworks的技术总监和技术咨询委员会的成员。他把时间花在为客户提供分布式系统架构和组织设计方面的建议上,而不是在同一主题的会议上发言。bet188足球


在过去的几十年里,我们花了大部分时间帮助大型组织彻底检修他们的遗留系统。在这样做的过程中,我们学到了很多有用的东西,也看到了许多导致失败的路径。我们决定留出一些时间,把我们所学到的东西用我们看到过的各种模式的形式写下来。

本文是这些模式的中心。我们经常看到组织陷入一种工作半途而废的传统替换工作中。我们认为,打破这个循环的关键是要按一定顺序完成四项活动,但主要是在公司的生命周期中反复进行。我们使用这些活动作为组织我们所描述的模式的主要结构。

我们一直认为,有效的软件开发包括逐步发布有价值的特性,我们认为写作也是如此尤其是在网络时代.我们从这篇叙事性文章开始,并将随着我们写下它们的细节逐渐添加模式,以及其他展示它们如何结合的例子。我们不能承诺任何日期,因为我们的首要任务是我们的客户工作,这其中有很多遗产需要取代。如果你对这项工作的更多部分感兴趣,它们将在马丁的推特,以及本网站的RSS源

传统替代跑步机

我们与许多组织合作,他们多次尝试删除遗留系统。在一个相当典型的组织中,他们经历了一系列长达3-5年的现代化项目。每一次,他们都会定义一种新的技术方法,然后将这种新方法作为大型多年现代化计划的一部分。

在每个项目的某个时刻,他们会遇到危机点,不断变化的业务需求将超过当前的技术战略,从而引发重新开始的需要。在他们采用瀑布式“大爆炸”方法的项目中,这意味着放弃大部分工作。在其他采用增量交付方法的情况下,所采用的方法只是在已经很复杂的环境上添加一个稍微更新的技术层。在这两种情况下,他们都无法停用任何遗留堆栈,节约成本和降低风险的关键业务目标仍未实现,这是许多遗留替换工作的常见结果。

他们屡次失败的原因有几个关键因素。

首先,他们看到的糟糕结果很大程度上是组织的产物;具体来说就是领导力、结构和工作方式。他们认为,只要选择更新的技术,而不改变其他技术,他们就会得到与过去不同的结果。事后看来,这显然是不现实的。

第二,现代化将通过一项大型变革计划来实现,该计划本身包括一系列项目和团队。这些项目被视为与任何BAU(一切照旧)工作正交。因此,BAU继续根据现有系统交付业务需求,而新项目团队则根据更换计划开始时商定的一组需求交付业务需求。

随着时间的推移,他们发现企业实际需要的东西与课程开始时实际签署的东西之间存在着越来越大的差距。每个项目运行的时间越长,项目计划与BAU和未来需求之间的差距就越严重。虽然变更控制过程已经到位,可以向项目中添加新的需求,但由于预先签订的供应商合同,这些过程非常耗时,而且成本高昂。

导致几次失败的第三个关键因素是渴望奇偶特性使用现有的系统和业务流程集。这些尝试开始时承诺给企业提供他们现在拥有的东西,但在某种程度上,在幕后,技术已经“改进”了。在经历了多次失败和对颠覆的担忧之后,商业领袖们认为这是一种风险较低的策略。这里的挑战是定义和同意当前的“现状”功能是一个巨大的努力,它导致了一个大型的单一“大爆炸”转换版本的计划。

我们从这个和许多其他组织的观察发现,技术最多只占遗留问题的50%,工作方式、组织结构和领导对成功同样重要。

打破这个循环

显然,有必要打破“技术替代方案”的循环。简而言之,组织需要能够继续交付业务需求,同时替换过时的技术,所有这些都是在加速技术变化和更激烈的竞争环境的背景下进行的。

我们发现了一系列可以帮助应对这些挑战的方法。它们有助于将问题分解成更小的部分,从而允许在改进技术的同时交付新需求。一般来说,它们可以分为四类:

  1. 了解你想要达到的结果
  2. 决定如何将问题分解成更小的部分
  3. 成功交付零件
  4. 改变组织,允许这种情况持续发生

了解你想要达到的结果

对于一个组织来说,在处理遗留问题时,就他们想要实现的结果达成一致是至关重要的。虽然这看起来很明显,但一个组织的不同部分往往对期望的结果有着截然不同的看法。大多数传统现代化计划都涉及我们下面列出的几个成果,但在出发之前,必须确定哪些成果是优先考虑的。

降低变革成本

许多组织在决定处理遗留问题时的一个关键临界点是,由于机会成本(又称延迟)或实现成本,期望的业务更改的成本开始远远超过任何预期的好处。一个早期的预警信号是,你必须花费数周乃至10或100万的时间来改变一个网站,而这只会给你的业务业绩带来很小的提升。

在这一点上,通常不再有理由作出任何改变,不能带来巨大的投资回报。换句话说,技术的状态已经开始决定企业能够做出的改变的大小。对于许多组织来说,这意味着做出一个“BAU”的改变或不得不发起一个更大的项目之间的区别。这些更大的项目会吸引所有之前不合理的小改变,从而增加它们的范围、成本和风险

改进业务流程

我们已经看到了许多例子,其中业务流程在遗留系统旁边演进,流程与系统工作的方式紧密耦合,并且经常绕过“系统之外”塑造人们遵循的业务流程来完成他们的工作。

我们看到的一个例子是使用“绿屏”终端机的航空公司登记系统,由于遗留系统的限制,该过程必须按照严格的顺序执行,这意味着更正或错误意味着重新开始登记过程。而且,最初航空公司没有提供中转航班,当添加这一功能时,由于该技术的限制,它必须作为遗留系统中的一个单独的工作流来完成。因此,如果在办理登机手续时,一名乘客没有提到他们有转机,那么就会遵循错误的流程,包括打印错误的行李标签,只有在这之后,系统才会标记该转机航班。登机人员的工作和乘客的体验本可以通过改变流程得到很大改善,但由于遗留的系统,这是不可能的。

鉴于此,更新和更改业务流程反过来需要更改支持技术的工作方式也就不足为奇了。如果试图在不改变技术的情况下改变工作流程,通常会导致“非系统”工作,即人们求助于将数据提取到电子表格或类似表格中,然后再将数据导入到遗留系统中。

在一个组织中,整个库存订购过程实际上是在团队经理PC上运行的Microsoft Access DB上完成的。他们感到沮丧,因为遗留的系统无法支持他们的供应商更新的工作方式。他们每周会输入和输出几次数据,与此同时,组织的其他成员会看到过时的数据,因为没有人意识到发生了什么。

这里值得注意的是,对于支持数据导入和导出的替换系统的需求,在这种解决方案中通常有一个根本原因。

废除旧制度

需要淘汰旧系统是传统现代化的一个常见原因。这通常是由于在支持较旧的硬件或软件方面遇到的挑战,以及诸如不断上升的支持成本和硬件和软件的支持合同即将到期等问题。

我们发现,从业务的角度来看待旧系统的退役是很有用的。因此,建立在旧技术基础上的系统本身并不是更换的充分理由。相反,我们需要考虑业务影响,这会导致运行成本不断上升,或者由于缺乏对系统的支持或了解而产生风险。

虽然一些组织确实为老技术的过时做了很好的计划,但许多组织似乎忽略了这个问题,直到它达到危机点。反过来,这往往会推动组织走向现代化的方法,这些方法看起来像是低干扰的选择或快速的胜利,这些通常是反模式,我们将在后面描述一些陷阱。

多年来,我们一直震惊于如此多的大型组织在不受支持的硬件和软件上运行业务,在eBay上购买备件的故事令人惊讶地普遍。如果您有遗留技术,那么做一个适当的调查并创建一个具有各种临终支持日期的日历是非常值得的。

虽然许多组织将旧系统的退役作为遗留系统现代化的关键结果,但发现这并没有实际发生的情况并不罕见,遗留系统在最后仍然被使用,而相关的业务目标仍未实现。

迫在眉睫的中断

对于一些组织来说,处理遗留问题的实际临界点可能是由外部因素引起的,比如监管变化、新的“初创”竞争对手或现有竞争对手的重大变化。通常在这个时候,当面对“必须做”的改变时,很明显,做出反应所需的金钱和时间变得太大了。

外部事件会让一个组织的领导层明白,他们不再有能力按比例成本做出改变。

更新的技术

采用更新的技术不应该是遗留现代化的原因,仅仅为了更新技术本身而拥有它很少是任何组织的关键目标。相反,应该以最能满足当前和未来业务需求的方式进行选择。这里的一个挑战是,技术变革的步伐正在加快,技术的“有用”寿命越来越短。“有用”的实际定义取决于组织,但一般来说,我们需要考虑以下事情:

  • 获得竞争优势
  • 匹配竞争对手或市场产品
  • 允许更快的变化步伐
  • 便宜的改变
  • 运行成本更低

我们今天做出的关于最好和最有用的技术的选择很可能在相对较短的时间内被更好的替代技术所取代。这使得在寻找技术以满足未来需求方面做出正确的决定具有潜在的风险。

这里的一个好方法是不要做出任何2-3年内无法轻易“完成”的选择。这对技术选择以及总体设计和方法都有影响。当我们意识到这种变化的加速时,选择一个回报期为5-10年的大型平台是很难证明的。bet188足球

决定如何将问题分解成更小的部分

广义地说,这涉及到在当前的业务和技术体系结构中找到正确的“接缝”。重要的是,您必须考虑当前解决方案的元素如何映射到不同的业务功能。对于遗留系统,这通常意味着发现一个大型技术解决方案如何满足多个业务需求,然后看看是否有可能提取出使用新解决方案进行独立交付的单个需求。理想情况下,这些内容应该是可交付的,彼此之间的依赖性最小。

一个常见的反对意见是,找到这些接缝太困难了。虽然我们同意这在一开始是具有挑战性的,但我们发现这是一个更好的方法,比那些经常导致功能平价和大爆炸版本的替代方案更好。我们还观察到,许多组织排除了这种方法,因为他们孤立地看待技术或业务流程。仅更改技术的一部分,或仅独立地更新一个业务流程可能会失败,但如果我们能同时考虑并实现这两者,就有办法“吃掉大象”。

开始

在旅程的开始,传统现代化似乎是一个最令人望而生畏的命题。就像任何旅程一样,我们必须首先尝试并理解最初的方向。而且,像所有的旅行一样,你必须从你所在的地方开始。我们遇到的一个常见问题是,我们似乎常常从一片森林开始,看不到前方的风景,因此不知道前进的方向。那么,第一步就是爬上一棵树,好好看看四周!这意味着在最短的时间内尽可能了解当前的系统和体系结构。这通常非常难做到,而且很容易陷入太多细节。

幸运的是,有许多真正有用的工具可以协作使用,以获得足够好的理解,以便继续进行。这些工具在其他地方有详细的讨论,但其中包括一个摘要列表事件风暴Wardley映射、业务能力映射和域映射。请注意,在这个列表中,我们主要查看业务概念是如何映射到系统架构的,并反过来理解这是如何映射的架构支持价值生成.这是一个经常缺失的视图,特别是对于遗留系统。

理解问题的模式
价值流图__ 描述用户如何完成工作的人工制品
事件风暴__ 用于理解业务流程的技术

†目前只有存根

特别地,我们发现人们经常在遗留系统的边界上停止发现式的活动,“这里有龙”,不再深入。在没有跨越边界和揭示遗留系统如何支持(或阻碍)业务流程和活动的情况下,找到和提取要交付的薄片是很有挑战性的。

另一个经常被忽视的非常有价值的信息来源是系统本身的用户。事实上,根据作者的经验,这通常是您可以找到大量有用的东西的地方,特别是暴露了许多工作区和影子IT生态系统,通常建立在旧系统——即Access数据库和版本化的Excel电子表格实际上经营企业。客户旅程图、创建服务蓝图和价值流图是用于展示此类细节的有效工具。

解决问题的模式
提取生产线 根据产品线识别和分离系统。
提取价值流__ 识别并分离关键价值流
奇偶特性 使用新技术堆栈复制遗留系统的现有功能。
至尊魔戒__ 通过识别独特的和共享的业务能力来细分问题

†目前只有存根

成功交付零件

对于快速更改的需求以及增量交付和独立更改业务元素的能力,而不需要大的依赖关系,这通常会导致“敏捷”的交付方法以及基于微服务的体系结构。对于这些单独的可部署组件来说,持续交付是必须的。使这一挑战超越正常的软件交付的是寻找从现有的大型解决方案元素中分离、共存和最终替换的策略。几种成功的策略包括并行运行、入口分叉和分流。

交付模式
金丝雀释放__ 向用户的子集推出更改
停止切断世界__ 暂停正常业务活动,切换到新系统
恢复到源__ 识别原始数据源并与之集成
把流__ 首先将关键业务活动和流程从遗留业务中转移出来
黑启动__ 在不使用结果的情况下调用新的后端功能,以评估其性能影响。
传统模拟__ 新系统与遗留系统交互的方式使旧系统不知道任何更改。
事件的拦截__ 拦截对系统状态的任何更新,并将其中一些更新路由到新组件

†目前只有存根

改变组织,允许这种情况持续发生

如果我们后退一步,看看交付新业务需求的整个过程,我们很快就会发现这只是部分技术问题。如果我们使用更新的技术来减少构建解决方案的时间和成本,那么我们就会突出关于同意需求和将变更投入生产的任何问题。

我们需要改变组织结构和流程来充分利用更好的技术,根据“康威定律”,我们还需要为我们的技术提供一个架构来促进这一点。如果团队及其通信是围绕现有的遗留解决方案和过程组织的,那么我们可能需要使用逆康威机动以匹配新的解决方案及其架构。

遗留系统会限制和限制采用更多现代工程实践的能力,特别是那些与极限编程和持续交付相关的工程实践。在替换遗留系统时,确保改变工作方式以确保我们不会返回一个缓慢、困难和昂贵的系统是很重要的。

遗产也是一个组织的文化和领导的产物,如果没有更广泛的变化,你应该期待与前面看到的相同的结果。我们已经观察到许多遗留的现代化工作失败了,因为“公司抗体”发现了一些新发生的事情,并采取行动从组织中拒绝它。

仅举一个例子说明一个广泛的组织如何拒绝变革;我们与一家非常大的电信公司合作,该公司希望为手机开发软件。领导层都明白,这意味着反馈周期要快得多,变化也要比关注固定基础设施的现有计划频繁得多。

虽然领导层明白这一点,但没有对现有的工作实践或运行这些过程的中层管理人员做出改变。因此,现有的变更控制过程得到了严格的应用。最后,软件团队花在填写变更控制表格和参加变更控制会议上的时间比他们生产软件的时间要多。“企业抗体”成功地抵制了这种新的工作方式。

组织变革是一个大话题,已有大量文献可供参考,遗留问题的关键挑战往往与时间有关。很少有组织能够在重新设计(或为外包受害者重建)其整个交付方法以及其组织结构和关键业务流程的同时,延迟遗留的现代化。虽然组织转型这一更广泛的话题超出了我们的范围,但我们确实建议在遗留问题的背景下应用和保护新的工作方式的一些策略。如果你只是改变了传统,而不做任何其他事情,那么可以公平地预期,你将用几年时间再次取代传统。

持续组织变革的模式
想继续就开始吧__ 以您需要的方式创建旧版替换,以便在其启用后继续。
受保护飞行员__ 为新工作创建一个试点计划,并将其与正常的公司治理流程分离
新公司__ 组建一家全新的公司以寻求市场颠覆

†目前只有存根

组织转型肯定还有其他战略和方法,我们只是强调了这两种,因为在某种程度上,它们可以让遗留现代化的工作尽早开始。

一个例子:集成中间件移除

这个例子描述了我们的一个团队如何使用许多遗留现代化模式来成功地替换集成中间件,这些集成中间件对他们客户的业务操作至关重要,是更大的遗留现代化计划的一部分。他们将模式和重构结合在一起,成功地管理了业务风险,并促188足球比分直播进了对大象这一特别棘手的部分的消化。

理解结果

我们团队面临的挑战是如何用一个新的可支持的、灵活的业务解决方案来替换不受支持、难以更改且成本很高的集成中间件。在不干扰或危及现有业务的情况下。所讨论的中间件用于在后端系统和前端存储系统之间的集成。这些系统共同负责每天销售价值数千万英镑的高价值独特产品。

这项工作是一个更大计划的高度优先部分。支持业务的整个后端系统都被替换了,店面也将在几年内接受现代化计划。

因此,按照上面的步骤1,团队需要实现的业务成果被定义为:

  1. 改进业务流程
  2. 如何?这个特殊的集成中间件解决方案包含大量的逻辑,包括业务核心规则,比如在哪个渠道销售产品,或者在商店前台如何以及何时展示销售产品。现有的系统很难改变,抑制了商业创新,逻辑上的缺陷导致了一些问题,比如有一段时间产品甚至没有销售!

  3. 尽快废除旧制度
  4. 为什么?减少现有的(和正在增加的)许可和支持成本。此外,还可以降低在过时的中间件和数据库技术上运行关键功能所带来的业务风险。

集成中间件移除示例

分解问题:第一个接缝和重构188足球比分直播

期间《盗梦空间》该团队与对遗留系统有深入了解的人一起举办了一个研讨会,以协作地可视化现有和将来的软件架构。这样做之后,他们发现了一个技术接缝,可以以遗留后端和集成中间件之间基于消息传递的集成的形式加以利用。遗留后端(一个老化的J2EE应用程序)将“发布产品”消息放置到由非常旧的SwiftMQ版本提供的队列中。的事件的拦截模式在这里很有用,如果作为基于内容的路由器将允许控制如何路由来自遗留后端的消息,并创建一个选项来支持将消息路由到新系统。

集成中间件还处理来自Store Front的消息(例如产品销售),使用JDBC直接更新遗留后端主数据库中的状态。通过SwiftMQ的异步消息传递和JDBC数据库更新一起形成了遗留后端和集成中间件之间的接口。

分支的抽象

虽然当时没有被发现,但团队可以使用分支的抽象模式,在子系统规模上,作为支持替换遗留中间件的策略。抽象层是队列和JDBC。通过确保新实现符合该抽象层,可以在不影响业务操作的情况下将其替换为“有缺陷的供应商”。

团队所做的第一件事是通过重构添加事件路由器来实现事件拦截。188足球比分直播

(P)188足球比分直播重构以添加事件拦截器

事件路由器(1)的创建有三个主要功能:

  1. 将一个SwiftMQ队列中的消息从队列中取出,并将它们放入另一个SwiftMQ队列(2)。对一些配置做一个小小的更改,就允许集成中间件使用来自这个新队列(2)的消息。
  2. 总的来说,重构保持了可观188足球比分直播察的系统行为不变,但是事件路由器现在是过渡架构的一部分,已经被插入到消息处理管道中。

  3. 事件路由器的愿景是通过配置使消息路由到备选目的地——使新的实现能够处理发布消息。事件的拦截
  4. 事件路由器还将提供从旧的SwiftMQ技术到为目标体系结构选择的新ActiveMQ技术的桥梁。

实现事件路由器并不像它本来可以的那样简单。由于缺乏可用的驱动程序/库,与SwiftMQ的集成存在问题,而且这种方法多次受到挑战。团队理解了这种方法可以解锁的选项的价值,并完成了工作并将其发布到生产环境中。他们在野外监视新组件,并设置使用new逐步增强其能力连续交付管道。

成功交付部分:构建功能,维护合同

新的实施和推出

新的店面经理(1)现在是由团队迭代构建的。与此示例相关的是,该构建包含了实现Legacy Mimic模式的主数据库适配器(2)。这作为抽象层的一部分是必需的,以便使用从Store Front接收到的销售信息更新主数据库。由于事件路由器不转换消息,遗留事件适配器(3)(消息翻译)创建的目的是将消息转换为新的格式,而不是将遗留世界暴露给新的环境,并与新体系结构的原则保持一致。传统店面适配器(4)也在新的店面管理器(1)和遗留店面之间实现,以将新的实现与未来的更改隔离开来,这些更改将在店面被替换时发生。

在Legacy Store Front(5)上引入了一个新的API,新的Store Front Manager将使用它。此外,还增加了一个功能,可以将发布在新API上的产品的回调发送到新的Store Front Manager的适配器(4)。重要的是,这使旧实现和新实现并行运行。

成功交付零件(续):过渡到现场服务-使用第二个接缝

在所有部分就绪后,业务部门能够测试新的解决方案,以及如何将其推出到活动服务中以风险管理的方式

为了做到这一点,他们利用了另一个接缝——这次使用的是按产品分段模式。事件路由器被增强,以根据产品类型以及唯一的产品id添加可配置路由(6)。该团队能够通过ID测试单个产品的发布、管理和销售,然后随着时间的推移,用越来越多的产品类型配置路由器,本质上增加了新解决方案处理的产品的百分比。

当所有产品都由新系统处理时,遗留的集成中间件就退役了,实现了在许可证、支持和数据中心托管费用上的显著节省。

遗产消失

改变组织,使其能够持续进行

我们的团队已经在组织的另一部分与客户合作,并且已经成功地取代了一个不同的遗留系统。

在整个组织的工程级别上,持续交付和良好的支持质量实践现在已成为既定的规范,微服务风格的体系结构使容器化服务能够定期独立部署到基于云的平台上。

新项目的团队与新的利益相关者合作,需要在同样的“敏捷和CD”旅程中完成业务的另一部分,并且早期的风险管理版本能够赢得信任。随着时间的推移,我们有可能证明新的工程和质量实践(包括CD)是如何减轻历史上导致更高层次的官僚主义和治理的相同风险的。因此,频率较低、范围较大的发布也被更小、频率更高、可信度更高的部署所取代,并在业务准备好接受更改时切换发布。

结语

当然,这里的复杂性和集成需求比上面的简化故事所暗示的要多得多。在生产中测试新实现后不久,就出现了一个需要考古学的例子。许多业务关键管理信息报告不符合要求——产品正在“丢失”。

经过大量挖掘,团队发现集成中间件(用于存储长期运行业务事务的状态)使用的数据库已复制到组织的数据仓库中。通过大量批处理作业、存储过程和视图,这些数据可在业务关键型KPI报告中使用。

LegacyModernizationExample_Archeology

需要额外的Legacy模拟来确保这些报告不被破坏。该团队使用了线龙头使用JDBC将数据注入到数据仓库中的适当表中。这些额外的仿制品也成为了过渡建筑的一部分,并将在可能的情况下被移除。

通过抽象进行分支的方法,以及上面描述的模式和实践的使用是一种旨在降低风险的方法。

通过使用事件拦截(技术接缝)、遗留模拟和过渡体系结构,客户端能够分解问题。然后按产品(业务缝)进行细分,在本例中是按产品类型进行细分,可以对更广泛的推出进行精细控制,并进一步管理风险。总的来说,该方法允许业务以他们满意的速度进行系统替换。

这种方法允许管理风险,但也付出了代价。因此,需要考虑的一个问题是“业务对这种风险缓解的价值是什么?”明确和量化它,将允许团队根据它跟踪投资。事件路由器和遗留模拟是旨在管理风险的过渡架构投资的一部分。他们的职责是创建能够管理风险的选项。这类工作很容易被视为“扔掉”——因此尽可能避免成本。在“风险缓解价值”与“过渡架构成本”之间的权衡中,要明确透明。


确认

Bill Codding, Chris Ford, James Emmott, Kief Morris, Mark Taylor, Meaghan Waters, Peter Gillard-Moss, Rebecca Parsons,和Simon Brunning在我们的内部邮件列表中讨论了这些模式的草稿。詹姆斯·埃默特建议在标题中使用“替换”。

卡片插图中使用的新旧曼彻斯特有轨电车的照片由毕加索、剪短、上色。

重大修改

2021年7月20日:发表