如何有效推进旧系统迁移、软件系统现代化与技术债治理
当企业需要替换既有软件系统时，常常会陷入一种反复循环：启动一轮声势浩大的技术替换计划，投入数年时间和大量预算，却在中途因业务变化、范围膨胀或风险失控而停滞，最终旧系统仍然存在，新系统也未能真正发挥作用。对于正在推进遗留系统现代化、旧系统迁移或软件架构升级的企业来说，这种困境并不少见。
根据我们的经验，要打破这种循环，必须采用一组相互配合的模式：明确替换遗留系统所要达成的业务结果；将庞大的替换问题拆解为更小、更可控的部分；以渐进方式交付这些部分；并推动组织结构和工作方式改变，使企业具备持续演进的能力。
过去二十年里，我们主要帮助大型企业改造遗留系统。在这一过程中，我们积累了大量实践经验，既看到过行之有效的方法，也见证过许多代价高昂的失败。因此，我们决定将观察到的模式整理出来，总结其中的经验与教训。
本文的目标，是为这些模式提供一个总体框架。我们经常看到企业陷入遗留系统替换项目“启动—停滞—重启”的困境。我们认为，要打破这一恶性循环，关键在于持续开展四类活动。它们大体上有先后顺序，但更准确地说，会以迭代方式贯穿企业的整个生命周期。本文也将以这四类活动作为主线，组织和介绍相关模式。
本文适合以下读者阅读：
- 正在规划遗留系统现代化或旧系统迁移的技术负责人；
- 希望降低系统变更成本和技术债风险的企业管理者；
- 正在推进微服务、持续交付或架构重构的研发团队；
- 希望用渐进方式替换大型旧系统的产品与业务团队。
目录
- 遗留系统替换的“跑步机”困境
- 如何打破遗留系统现代化的循环
- 明确遗留系统替换要达成的结果
- 如何将旧系统迁移拆解为更小的问题
- 如何成功交付遗留系统替换的各个组成部分
- 如何改变组织结构，使现代化能力持续存在
- 示例：移除集成中间件
- 常见问题
遗留系统替换的“跑步机”困境
我们曾与许多组织合作，它们都曾多次尝试移除遗留系统。一个相当典型的组织，往往会经历一系列持续三到五年的现代化改造项目。每一次，它们都会制定新的技术方案，并将其作为大型、多年期现代化项目的一部分逐步实施。
然而，在每个项目推进过程中，组织最终都会遇到某个危机点：不断变化的业务需求超出了既有技术战略的承载范围，于是项目不得不推倒重来。如果项目采用瀑布式的“大爆炸”交付方式，这通常意味着大量已经完成的工作将被放弃。而在一些采用渐进式交付方式的项目中，结果则是企业只是在原本已经复杂的系统架构之上，又叠加了一层稍新的技术。无论哪种情况，它们都没能真正淘汰任何遗留系统；降低成本、减少风险这些关键业务目标也没有实现。这正是许多遗留系统替换项目的常见结局。
导致这些项目反复失败的关键因素有很多。
首先，糟糕的结果很大程度上是组织自身问题的产物。更具体地说，问题在于领导方式、组织结构和工作方式。很多组织以为，只要选择一套新技术，而其他一切基本保持不变，就能获得与过去截然不同的结果。事后来看，这显然是不现实的。
其次，现代化改造通常被设计成一个大型变革项目，其中又包含一系列子项目和团队。这些项目往往被视为与日常运营工作彼此独立。因此，日常业务需求仍然基于现有系统交付，而新的项目团队则按照替换项目启动时确认的一组需求开展工作。
随着时间推移，企业会发现，真实业务需求与项目启动时获批的内容之间差距越来越大。项目持续时间越长，项目计划与日常运营及未来需求之间的偏差就越明显。虽然变更控制流程允许向项目中加入新需求，但这些流程通常非常耗时。再加上供应商合同往往在前期就已签订，后续变更成本也高得令人望而却步。
第三个导致多次失败的重要因素，是企业希望新系统与现有系统和业务流程在功能上完全一致。这类尝试通常承诺：只要在底层技术上进行“升级”，企业就能获得与现有系统一模一样的功能。由于此前已经经历过多次失败，而且担心业务中断，企业领导者往往认为这是一种风险较低的策略。然而，即便只是定义并确认当前“现状”功能，也是一项巨大的工程，最终往往导致一次性的大规模“大爆炸式”切换计划。
从这家公司以及许多其他组织身上，我们观察到：技术问题最多只占遗留系统问题的一半。工作方式、组织结构和领导力对最终成败同样重要。
如何打破遗留系统现代化的循环
显然，我们必须打破这种“技术更新换代计划”的恶性循环。简而言之，在技术变革不断加速、竞争环境日益激烈的背景下，企业既要持续满足业务需求，又要同时替换已经过时的技术。
我们发现，有一系列方法能够帮助企业应对这些挑战。这些方法可以将问题拆解为更小的组成部分，使企业能够在推进技术改进的同时，继续满足新的业务需求。总体而言，这些方法可以分为四类：
- 明确你希望达成的结果；
- 决定如何将问题拆解为更小的部分；
- 成功交付各个组成部分；
- 改变组织结构，使这种能力能够持续存在。
明确遗留系统替换要达成的结果
对于任何组织而言，在处理遗留系统之前，就目标达成一致都至关重要。这一点看似显而易见，但组织内部不同部门往往对预期目标有着截然不同的理解。大多数遗留系统现代化项目都会涉及下文列出的多个目标，但在项目启动之前，必须明确哪些目标才是真正的优先事项。
降低变更成本
许多组织决定处理遗留系统，通常是因为它们发现，期望中的业务变更成本已经远远超过任何预期收益。这种成本可能表现为机会成本，例如因延误而错失机会；也可能表现为实施成本。一个早期预警信号是：为了对网站做一项只能带来微弱业务绩效提升的改动，却需要花费数周时间，以及数万甚至数十万美元。
到了这个阶段，任何无法带来可观投资回报的变更，通常都很难找到合理理由。换句话说，技术现状已经开始决定企业能够承担何种规模的变更。对许多企业而言，这意味着它们要么只能做一些“日常运营”层面的微调，要么就不得不启动更大的项目。而这些大型项目又会像磁铁一样，吸附此前那些无法单独成立的小型变更，进而扩大项目范围、增加成本和风险。
改进业务流程
我们看到过很多例子：遗留系统周围逐渐演化出了复杂的业务流程。这些流程与系统的工作方式紧密耦合，受制于系统内部限制，并且经常依赖“系统外”的变通方法。久而久之，这些限制和变通方法共同塑造了人们实际完成工作的方式。
我们曾遇到过这样一个案例：某航空公司使用老式终端办理值机手续。由于旧系统的限制，整个流程必须严格按顺序执行。这意味着任何错误或更正都会导致值机流程从头开始。此外，该航空公司最初并不提供转机服务；后来即便业务上增加了转机服务，由于旧系统的技术限制，转机流程仍只能作为单独的工作流处理。因此，如果乘客在办理值机时没有说明自己有转机航班，系统就会执行错误流程，包括打印错误的行李标签，并且只有在打印完成后才会识别出转机航班。如果能够改进流程，值机人员的工作效率和乘客体验都会显著提升；但由于旧系统的限制，这根本无法实现。
因此，业务流程的更新和变更通常也需要对支撑技术的运行方式进行相应调整，这并不令人意外。试图在不改变技术的情况下改变工作流程，往往会导致“系统外”工作：人们将数据导出到电子表格或其他工具中，在那里完成处理，然后再把数据导回原有系统。
在一家企业，整个库存订购流程实际上都是在团队经理电脑上的某桌面数据库工具中完成的。由于老旧系统无法支持供应商新的工作方式，业务人员对此非常沮丧。他们每周都要进行数次数据导入和导出；与此同时，公司其他部门看到的却都是过时数据，因为没有人意识到真正发生了什么。
值得注意的是，对数据导入和导出功能的需求，往往正是这类变通方案出现的根源。
淘汰旧系统
淘汰旧系统是遗留系统现代化的常见动因。这通常是因为维护老旧硬件或软件变得越来越困难，例如维护成本不断攀升，硬件和软件支持合同即将到期或已经到期。
我们发现，从业务角度审视旧系统淘汰问题非常有帮助。因此，仅仅因为一个系统基于老旧技术，并不足以构成替换它的充分理由。我们真正需要关注的是：这项技术老化会对业务造成什么影响，例如不断上升的运行成本，或者由于缺乏系统支持和知识传承所带来的风险。
有些组织会提前规划旧技术淘汰问题，但许多组织似乎会对这一问题视而不见，直到危机爆发。反过来，这往往会促使组织选择那些看似干扰较小或见效较快的现代化方案，而这些方案往往是反模式。我们将在后文中进一步介绍其中的一些陷阱。
多年来，我们惊讶地发现，许多大型企业仍在使用早已不受支持的硬件和软件运行核心业务，甚至会在某些二手交易平台上购买备件。如果你仍在使用老旧技术，非常值得进行一次全面盘点，并建立一个日历，记录各种产品生命周期结束的日期。
虽然许多组织把淘汰旧系统列为遗留系统现代化的关键成果，但在实际项目中，这一目标往往并没有真正实现。遗留系统最终仍在继续运行，相关业务目标也未能达成。
即将到来的冲击
对某些组织而言，真正促使其着手解决遗留系统问题的转折点，可能来自外部因素，例如监管变化、新兴竞争者出现，或现有竞争对手发生重大转型。通常，只有当组织面临“必须改变”的局面时，才会意识到自己为应对变革所需投入的资金和时间已经变得过于庞大。
所谓外部事件，是指那些让组织领导层清楚意识到：他们已经无法以可接受的成本和速度完成变革的事件。
新技术
采用新技术本身不应成为遗留系统现代化的理由。仅仅为了拥有新技术而采用新技术，对任何组织来说都很少是关键目标。相反，新技术的选择和部署，应当服务于企业当前和未来的需求，并以最合适的方式支撑这些需求。
这里的挑战在于，技术变化的速度正在加快，技术的“有效”生命周期也在缩短。“有效”的具体含义取决于组织自身，但通常需要考虑以下因素：
- 是否能够带来竞争优势；
- 是否能够匹配竞争对手或市场产品；
- 是否能够支持更快的变化速度；
- 替换成本是否更低；
- 运行成本是否更低。
我们今天认为最佳、最实用的技术选择，很可能在相对较短的时间内就会被更好的替代方案取代。这使得企业在选择能够满足未来需求的技术时，很难做出低风险的决策。
一个良好的原则是：不要做出任何在两三年内无法相对轻松“重来”的选择。这不仅影响技术选择，也影响整体设计和实施方法。考虑到当今变化如此迅速，选择一个需要五到十年才能收回成本的大型平台，已经很难令人信服。
如何将旧系统迁移拆解为更小的问题
总体而言，这一步涉及在当前业务架构和技术架构中寻找合适的切入点。重要的是，你必须理解当前解决方案的各个要素如何映射到不同的业务能力。对于遗留系统来说，这通常意味着要弄清楚一个大型技术解决方案如何支撑多个业务需求，然后再判断是否可以将这些需求逐一抽取出来，并用新的解决方案独立交付。理想情况下，这些新方案之间的依赖应尽可能少。
一个常见的反对意见是：找到这些切入点太难了。我们承认，这在一开始确实很有挑战性；但我们发现，这种方法仍然比其他替代方案要好得多，因为其他方案往往会导致功能对等和“大爆炸式”发布。我们也注意到，许多组织之所以排斥这种方法，是因为它们孤立地看待技术或业务流程。单独改变某一部分技术，或单独更新某个业务流程，很可能都会失败。但如果我们能够同时考虑并实施这两方面的变化，就能找到“吃掉大象”的方法。
从理解现状开始
遗留系统现代化在初期阶段常常显得异常艰巨。和任何旅程一样，我们首先必须明确前进方向。同样，和所有旅程一样，你必须从自己当前所处的位置出发。我们经常遇到的问题是：自己仿佛置身森林之中，看不到前方景象，也不知道该往哪个方向走。那么，第一步就是爬上一棵树，好好观察周围的环境。
这意味着要在尽可能短的时间内，尽可能全面地理解当前系统和架构。这通常非常困难，而且很容易陷入过多细节。
幸运的是，有许多非常实用的工具可以配合使用，帮助我们获得足够的理解，从而继续推进工作。这些工具在其他地方已有详细讨论。简而言之，它们包括事件风暴、战略地图、业务能力映射和领域映射。请注意，在这一列表中，我们主要关注的是业务概念如何映射到系统架构，以及该架构如何支撑价值创造。而这种视角在遗留系统中往往是缺失的。
理解问题的模式
创建城镇规划
识别组织中相对稳定的部分，并围绕这些稳定部分构建团队和软件。
事件风暴
一种用于理解业务流程的技术。
识别业务能力
识别组织中相对稳定的部分，并围绕这些稳定部分构建团队和软件。
价值流图
一种描述用户如何完成工作的工件。
具体来说，我们发现，人们常常会在遗留系统边界处停止探索性活动，仿佛那里写着“此处有龙”，于是便止步不前。如果不跨越这道边界，不去探究遗留系统究竟如何支持或阻碍业务流程和业务活动，就很难找到可以抽取出来并独立交付的精简信息。
另一个常被忽视但非常宝贵的信息来源，是系统用户本身。事实上，根据作者的经验，通常可以从用户那里获得大量有用信息，尤其是关于围绕老旧系统形成的各种变通方案和影子 IT 生态系统的信息，例如那些真正支撑业务运作的桌面数据库和带版本的电子表格。客户旅程图、服务蓝图和价值流图等工具，都已被证明能够有效揭示这类细节。
解决问题的模式
抽取产品线
按产品线识别并拆分系统。
抽取价值流
识别并分离关键价值流。
功能对等
使用新的技术栈复制原有系统功能。
如何成功交付遗留系统替换的各个组成部分
为了更快适应变化，并能够在不依赖大型组件的情况下逐步交付、独立变更业务要素，组织通常会采用敏捷交付方法，并结合基于微服务的架构。对于这些可单独部署的组件而言，持续交付至关重要。
与普通软件交付相比，遗留系统替换的挑战在于：如何找到从现有大型解决方案中切换、共存并最终替换既有组件的策略。目前已经有多种成功策略，包括并行运行、入口点分叉和流程分流。
交付模式
金丝雀发布
向部分用户推出变更。
关键聚合器
整合来自企业不同部门的数据，以支持关键决策制定。
暗启动
调用新的后端功能，但不使用其返回结果，以便评估其性能影响。
改变流向
首先将跨组织活动从传统流程中转移出来。
事件拦截
拦截系统状态的任何更新，并将其中一部分路由到新组件。
遗留系统模拟
让新系统以一种使原有系统感知不到变化的方式与其交互。
回归源头
确定数据的原始来源，并将变更整合回该数据源。
停机切换
暂停正常业务活动，同时切换到新系统。
过渡架构
引入若干临时软件组件，以便替换旧系统；这些组件计划在替换完成后移除。
如何改变组织结构，使现代化能力持续存在
如果我们后退一步，审视整个新业务需求交付过程，就会很快发现：这并不只是一个技术问题。如果我们使用新技术缩短解决方案构建时间、降低构建成本，那么需求协商以及将变更投入生产所存在的问题就会更加凸显。
我们需要调整组织结构和流程，才能充分发挥更先进技术的价值。根据康威定律，我们也需要一种能够支撑这种调整的技术架构。如果团队及其沟通方式仍然围绕现有遗留解决方案和流程组织，那么我们可能需要运用逆康威定律对其进行重组，使组织结构与新的解决方案及其架构相匹配。
在工具层面，企业也需要让目标、反馈、需求、评审、排期、开发、测试、发布和知识沉淀形成连续链路。例如，PingCode 这类智能化研发管理工具，可以帮助研发团队将管理过程自动化、数据化和智能化，并通过 Wiki 与研发生态工具集成，让遗留系统现代化过程中的需求、知识和数据更顺畅地流转。
遗留系统可能会限制我们采用更现代的工程实践，尤其是与极限编程和持续交付相关的实践。在替换遗留系统时，务必要确保工作方式也同步改变，否则最终很可能又回到一个运行缓慢、难以变更且成本高昂的系统。
遗留系统也是组织文化和领导力的产物。如果不进行更广泛的变革，结果必然与以往相同。我们观察到，许多遗留系统现代化尝试之所以失败，是因为组织中存在“企业抗体”：这些抗体一旦发现新事物，就会将其排斥在组织之外。
举一个大型组织如何抵制变革的例子。我们曾与某海外大型通信企业合作，该企业希望开发面向移动设备的软件。企业领导层都明白，这意味着他们需要比现有固定基础设施项目更短的反馈周期，以及更频繁的变更。
尽管领导层理解这一点，现有工作流程以及负责这些流程的中层管理人员却没有发生任何改变。因此，既有变更控制流程仍被严格执行。最终，软件团队花在填写变更控制表格、参加变更控制会议上的时间，比实际开发软件的时间还要多。“企业抗体”成功抵制了新的工作方式。
组织变革是一个庞大的话题，已经有大量文献可供参考。对于遗留系统而言，关键挑战往往在于时间。很少有组织能够承受这样的做法：在重塑整个交付模式、组织结构和关键业务流程之前，先暂停遗留系统现代化。对于一些深受外包模式影响的组织而言，这甚至不是重塑，而是重建。虽然更广泛的组织转型话题超出了本文范围，但我们确实建议：在遗留系统现代化过程中应用并保护新的工作方式。如果你只是简单替换遗留系统，而不做其他任何改变，那么几年之后再次需要替换系统，也就不足为奇了。
对于跨部门协作较多、项目类型更复杂的组织，通用项目协作系统也能降低现代化过程中的沟通成本。例如，Worktile 可以覆盖任务、项目、文档、即时沟通、目标、日历、甘特图、工时和审批等协作场景，帮助业务、研发、测试和管理团队在同一节奏下推进旧系统迁移。
持续组织变革的模式
按照你期望的未来来构建
创建你所需要的遗留系统替代方案，使其在上线后能够持续演进。
增量替换
创建你所需要的遗留系统替代方案，使其在上线后能够持续演进。
新公司
成立一家全新的公司，以实现市场颠覆。
受保护的试点
为新的工作方式设立试点项目，并将其与常规公司治理流程隔离开来。
组织转型当然还有其他策略和方法。我们这里只重点介绍这两种方式，是因为它们在一定程度上可以让我们尽早启动遗留系统现代化工作。
示例：移除集成中间件
本案例描述了我们的团队如何在一个大型遗留系统现代化项目中，运用多种遗留系统替换模式，成功替换了一套对客户业务运营至关重要的集成中间件。团队结合多种模式和重构方法，有效管理业务风险，并顺利完成了这项棘手的改造工作。
明确结果
我们的团队面临的挑战是：用一个易于维护、更加灵活的新解决方案，替换一套已经停止支持、难以变更且成本高昂的集成中间件，同时还要确保现有业务运营不受影响，也不会面临额外风险。该中间件用于连接后端系统和前端门店。这两个系统每天负责销售价值数千万英镑的高价值特色产品。
这项工作是更大项目中的重中之重。支撑业务运营的所有后端系统都将被替换，门店前端也将在几年内进行现代化改造。
因此，根据前文第一步，团队需要达成的业务成果已经明确。
改进业务流程
为什么要改进业务流程？因为这套特定的集成中间件解决方案包含大量逻辑，其中包括对业务至关重要的规则，例如哪些渠道可以销售哪些产品，以及如何在门店中展示待售产品。现有系统很难变更，抑制了业务创新；而逻辑缺陷也导致了一些实际问题，例如某些产品甚至没有上架销售。
尽快淘汰旧系统
为什么要尽快淘汰旧系统？一方面是为了降低现有且持续增长的许可和支持成本；另一方面，也是为了降低在老旧、过时的中间件和数据库技术上运行关键功能所带来的业务风险。
高级系统处理：用户通过旧版后端系统中的界面独立管理产品的定价和发布。对于每个已发布的产品，系统会将一条消息放入 SwiftMQ 队列。集成中间件会接收该消息，创建产品状态的视图，并调用旧版商店前端的 SOAP API 来发布该产品。随着时间的推移，集成中间件会使用该 API 更新产品状态，从而改变产品对客户的可用性（例如，将产品状态从“仅供预览”更改为“新品上架”等）。当客户购买产品时，旧版商店前端会调用集成中间件提供的 API。中间件会更新自身的产品状态，并将销售信息更新到旧版系统的主数据库中。
问题拆解：第一道接缝与一次重构
项目启动阶段，团队与对原有系统有深入了解的人员举办了一场研讨会，共同可视化现有软件架构和未来软件架构。通过这场研讨会，他们发现了一个可以利用的技术接缝：原有后端系统与集成中间件之间存在基于消息的集成。
原有后端是一个老旧的企业级 Java 应用程序，它会将“发布产品”消息放入一个由旧消息队列产品提供的队列中。在这里，“事件拦截”模式非常有用。如果将其实现为基于内容的路由，就可以控制来自原有后端的消息如何被路由，并为将消息路由到新系统创造选项。
集成中间件还会处理来自门店前端的消息，例如产品销售消息，并通过数据库连接接口直接更新遗留后端主数据库中的状态。异步消息传递与数据库更新，共同构成了遗留后端与集成中间件之间的接口。
尽管团队当时并未明确意识到，但他们实际上巧妙地在子系统层面运用了“抽象分支”模式，以替换旧版中间件。这里的抽象层就是消息队列和数据库连接接口。只要确保新的实现遵循这一抽象层，就可以在不影响业务运营的情况下替换掉“有问题的供应商组件”。
团队做的第一件事，是通过重构增加一个事件路由器，以实现事件拦截。
事件路由器的设计主要考虑了三个功能。
首先，从系统高层处理方式来看，这里使用“重构”一词，是因为系统结构发生了改变，但外部可观察行为没有变化。现在，当用户发布产品时，原有后端系统仍然会将发布消息放入旧消息队列。不同的是，集成中间件不再直接消费该消息；事件路由器会从该队列消费消息，并将其原封不动地放入另一个消息队列。随后，集成中间件从这个备用队列中消费消息。对集成中间件而言，这一改变只需要简单配置即可完成。
其次，事件路由器会将消息从一个旧消息队列取出，再入队到另一个旧消息队列。通过对配置做一些简单变更，集成中间件就能够从这个新队列消费消息。
总体而言，这次重构并没有改变系统的可观察行为，但事件路由器现在已经成为过渡架构的一部分，因为它被插入到了消息处理管道中。
事件路由器的设计愿景，是通过配置将消息路由到备用目标，从而让新的实现能够处理已发布的消息。这正是事件拦截模式的作用。
事件路由器还需要提供一座桥梁，将旧消息队列技术连接到目标架构中选定的新消息中间件技术。
事件路由的实现并非一帆风顺。由于缺乏可用的驱动程序和库，与旧消息队列集成非常困难，这一方案也曾多次受到质疑。团队清楚这一方案带来的诸多优势，最终完成了开发工作并将其发布到生产环境。他们持续监控新组件的运行状况，并计划利用新的持续交付流水线逐步增强其功能。
成功交付组件：构建功能，维护契约
新的门店前端管理器由团队迭代构建完成。在本例中，该构建包括一个主数据库适配器，用于实现“遗留系统模拟”模式。这个适配器是抽象层的一部分，用来根据从门店前端接收到的销售信息更新主数据库。
由于事件路由器并不转换消息，团队创建了一个遗留事件适配器，也就是消息转换器，用于将消息转换为新格式。这样既可以避免新系统直接暴露于遗留系统细节之下，也能符合新架构原则。
此外，团队还在新的门店前端管理器和旧版门店前端之间实现了一个旧版门店前端适配器，用于将新实现与未来门店前端替换时可能出现的变更隔离开来。
团队还在旧版门店前端上引入了一个新的 API，供新的门店前端管理器使用。同时，他们新增了一项功能，允许将通过新 API 发布产品后的回调发送到新的门店前端管理器适配器。至关重要的是，这使得旧版实现和新版实现能够并行运行。
成功交付组件：过渡到正式运行，利用第二道接缝
此时，测试新解决方案所需的条件已经具备。但问题是：如何以可控方式将它投入实际业务运行？
为此，团队利用了另一个切分点，这一次是按产品进行切分。事件路由功能得到了增强，增加了按产品类型和唯一产品 ID 进行可配置路由的能力。团队可以先测试单个产品按 ID 发布、管理和销售的流程；随后，随着时间推移，逐步配置路由，使其支持越来越多的产品类型，从而有效提高由新解决方案处理的产品比例。
当所有产品都由新系统处理后，原有集成中间件便被停用。由此，公司在许可、支持和数据中心托管费用方面节省了大量资金。
高级系统处理：除非业务另有规定，否则特定产品的处理流程与之前相同。对于业务愿意通过新系统处理的产品，处理流程如下：发布消息被放入 SwiftMQ 队列。事件路由器会检查消息有效负载并检查产品制造商。如果已配置，事件路由器会将此消息原封不动地放入 ActiveMQ 队列。旧版事件适配器会将消息转换为符合目标架构原则的业务事件。新版 Storefront Manager 应用程序会存储其自身的产品表示，并通过队列转发待发布产品的命令消息。旧版 Storefront 适配器会接收该命令，并调用旧版 Storefront 上的新 v2 API。
根据业务需要，用户现在除了管理员可以通过发出新命令来随时更改产品在店面上的展示方式外，还可以控制产品的展示方式。
当产品（通过 v2 API 发布）售出时，旧版店面会回调旧版店面适配器提供的 API，该适配器会将回调转换为业务事件，并将该事件放入 ActiveMQ 队列。新版店面管理器和主数据库适配器会使用这些事件。新版店面管理器会更新其内部产品状态，而主数据库适配器会将销售信息更新到旧版主数据库中。
改变组织结构，使这种能力能够持续运作
我们的团队此前已经与客户组织的另一个部门合作，并成功替换了另一个遗留系统。
在整个组织的工程层面，持续交付和良好的质量保障实践现在已经成为既定规范。微服务架构使容器化服务能够被定期、独立地部署到云平台上。
新的项目团队需要与新的利益相关者合作，带领业务的另一个部门踏上同样的“敏捷与持续交付”之旅。早期那些风险可控的发布，有助于赢得信任。随着时间推移，团队得以证明：包括持续交付在内的新工程实践和质量实践，如何降低那些过去常常导致官僚主义和更高治理成本的风险。因此，低频、大范围发布逐渐被更小、更频繁且置信度更高的部署所取代。当业务部门准备好接受这些变更时，团队便能够根据实际情况进行发布切换。
结语
当然，真实情况远比上述简化描述复杂得多，集成需求也更高。在生产环境中测试新方案后不久，就出现了一个需要深入系统分析的例子：一些关键业务管理信息报告中的数据不一致，部分产品信息“丢失”了。
经过大量调查，团队发现，集成中间件使用的数据库被复制到了组织的数据仓库中，而该数据库原本用于存储长时间运行的业务事务状态。通过一系列批处理作业、存储过程和视图，这些数据最终被提供给业务关键绩效指标报告使用。
为了确保这些报表不出故障，团队需要添加额外的遗留系统模拟组件。他们使用监听器监听来自门店前端的销售消息，并通过数据库连接接口将数据注入数据仓库中的相应表。这些额外的模拟组件也成为过渡架构的一部分，并将在条件允许时移除。
上述通过抽象进行分支的方法，以及相关模式和实践的使用，目的都是降低风险。
通过事件拦截这一技术切入点、遗留系统模拟以及过渡架构，客户得以将问题拆解。随后，团队又按产品这一业务切入点进行细分；在本例中，也就是按产品类型进行细分。这样一来，企业就能够以更细粒度控制更大范围的推广，并进一步管理风险。总体而言，这种方法使企业能够以自己可以接受的节奏推进系统替换。
这种方法虽然能够管控风险，但也需要付出代价。因此，需要考虑的问题是：企业究竟有多重视这种风险缓解能力？明确并量化这种重视程度，将有助于团队持续跟踪相关投资。
事件路由和遗留系统模拟都属于过渡架构投资，其目标是管理风险。它们的作用是创造更多选择，从而实现风险管理。这类工作很容易被视为“可有可无”，因此人们往往会尽量避免相关成本。正因如此，在权衡“风险缓解的价值”与“过渡架构的成本”时，务必要做到明确、透明。
常见问题
什么是遗留系统现代化？
遗留系统现代化，是指在不影响核心业务连续性的前提下，对老旧软件系统、架构、数据流和工作方式进行更新，使其能够更好地支撑业务变化、降低维护成本，并减少技术风险。
遗留系统替换一定要一次性完成吗？
不一定。对于大型企业系统而言，一次性“大爆炸式”替换通常风险较高。更可行的方式，是通过事件拦截、过渡架构、遗留系统模拟、按产品或价值流拆分等方式，逐步迁移和替换旧系统。
企业推进旧系统迁移时，最容易忽视什么？
企业最容易忽视的往往不是技术本身，而是组织结构、工作方式和业务流程。遗留系统通常与组织流程深度绑定，如果只替换技术而不调整组织协作方式，新系统很可能再次演变成新的遗留系统。
如何降低遗留系统现代化的风险？
降低风险的关键，是将大问题拆解为小问题，并通过渐进式交付验证每一步。企业可以优先寻找技术接缝和业务接缝，采用并行运行、事件路由、过渡架构和持续交付等方法，在不中断业务的情况下逐步完成系统替换。
文章包含AI辅助创作，作者：liu，如若转载，请注明出处：https://docs.pingcode.com/baike/5243794
