傳統系統替換模式

了解您想達成的結果

組織在處理遺留問題時，同意他們想要達成的成果至關重要。雖然這看起來很明顯，但組織的不同部門對於預期的成果往往有截然不同的看法。大多數遺留現代化計畫都包含我們在下面列出的幾個成果，但在開始執行之前，找出哪些成果是優先事項至關重要。

決定如何將問題分解成更小的部分

廣義而言，這涉及在當前的業務和技術架構中找到正確的「縫隙」。重要的是，您必須考慮當前解決方案的元素如何對應到不同的業務功能。對於舊系統，這通常表示找出一個大型技術解決方案如何滿足多個業務需求，然後查看是否有可能使用新的解決方案提取個別需求以進行獨立交付。理想情況下，這些需求應可交付，且彼此之間的依賴性最小。

一個常見的異議是，找到這些縫隙太困難。雖然我們同意這一開始具有挑戰性，但我們發現這是一個比其他替代方案更好的方法，而這些替代方案往往導致功能同等性和大爆炸式釋出。我們還觀察到，許多組織會排除這種方法，因為他們孤立地看待技術或業務流程。僅變更技術的一部分或獨立更新一個業務流程很可能會失敗，但如果我們可以考慮並同時實施這兩者，就有辦法「一口一口吃掉大象」。

成功交付各部分

對變更速度的需求以及逐步交付和獨立變更業務元素的能力（無大型依賴關係）通常會導致「敏捷」交付方法與微服務為基礎的架構並行。持續交付成為這些個別可部署元件的必備條件。除了正常的軟體交付之外，這項挑戰在於找出從現有大型解決方案元素中切換、共存，以及最終取代的策略。有許多成功的策略，包括平行執行、輸入分岔和流程轉移。

† 目前僅為存根

改變組織，讓此過程持續進行

如果我們退一步來看交付新業務需求的整個流程，我們可以很快地看出這只是一個技術問題。如果我們使用較新的技術來縮短建置解決方案的時間和成本，我們將突顯出在同意需求和將變更導入生產方面的任何問題。

我們需要組織結構和流程變更才能充分利用更好的技術，並且根據康威定律，我們也需要一個技術架構來促進這一點。如果團隊及其溝通是圍繞現有的舊解決方案和流程組織的，我們可能需要使用逆康威操作對其進行重新組織，以匹配新的解決方案及其架構。

舊系統可能會限制和限制採用更現代的工程實務的能力，特別是與極端程式設計和持續交付相關的實務。在更換舊系統時，重要的是確保改變工作方式，以確保我們不會最終回到一個緩慢、困難且昂貴的系統。

舊系統也是組織文化和領導力的產物，沒有更廣泛的變革，你應該期待與以前看到相同的結果。我們觀察到許多舊系統現代化工作都因「企業抗體」而失敗，這些抗體會發現有新事物發生並採取行動將其拒絕在組織之外。

僅舉一個廣泛組織如何拒絕變革的例子；我們與一家非常大型的電信公司合作，該公司希望為手機建置軟體。領導階層都明白這意味著比他們在專注於固定基礎設施的現有計畫中看到的更快的回饋週期和更頻繁的變更。

儘管領導階層了解這一點，但現有的工作實務或執行這些流程的中階管理階層並未做出任何變更。因此，現有的變更控制流程被嚴格執行。最後，軟體團隊花在填寫變更控制表單和參加變更控制會議的時間比生產軟體的時間還多。「公司抗體」成功地拒絕了新的工作方式。

組織變革是一個龐大的主題，已有許多文獻探討，傳統系統的主要挑戰通常與時間有關。很少有組織能負擔得起延遲傳統系統現代化，同時重新設計（或重建，針對外包受害者）其整個交付方式以及組織結構和關鍵業務流程。儘管組織轉型的廣泛主題超出了我們的範圍，但我們確實建議一些策略，以便在傳統系統的背景下應用和保護新的工作方式。如果你只是變更傳統系統而沒有做其他事情，預期你將在幾年後再次更換傳統系統是合理的。

† 目前僅為存根

組織轉型絕對有其他策略和方法，我們只強調這兩種策略，因為它們在某種程度上允許盡早而不是延後開始傳統系統現代化工作。

了解結果

我們的團隊面臨的挑戰是如何替換已停止支援、難以變更且對企業來說非常昂貴的整合中介軟體，並以新的可支援、彈性的解決方案取代。在不中斷或危及現有業務營運的情況下。有問題的中介軟體用於後端系統和店面之間的整合。這些系統共同負責銷售每天價值數千萬英鎊的高價值獨特產品。

這項工作是一個較大型計畫中的高優先順序部分。支援業務的所有後端系統都正在更換，而店面也將在幾年內進行現代化計畫。

因此，根據上述步驟 1，定義團隊需要達成的業務成果

1. 改善業務流程

如何？此特定整合中介軟體解決方案包含大量邏輯，包括業務核心規則，例如在何種管道上銷售產品，或如何在店面中展示產品以及何時展示。這個現有系統非常難以變更，阻礙業務創新，而且邏輯中的缺陷導致問題，例如產品甚至沒有在銷售期間上架！

2. 盡快淘汰舊系統

原因？降低現有（且持續增加）的授權和支援成本。此外，減輕因在過時的支援中介軟體和資料庫技術上執行關鍵功能而對業務造成的風險。

分解問題：第一個縫合點和重構

在 Inception 期間，團隊與深入了解舊式系統的人員舉辦工作坊，以共同視覺化現有和未來的軟體架構。執行此步驟後，他們發現一個技術接縫，可以利用舊式後端和整合中介軟體之間的訊息整合方式來加以利用。舊式後端（一個老舊的 J2EE 應用程式）會將「發布產品」訊息置於 SwiftMQ 的舊版本所提供的佇列中。事件攔截 模式在此處會很有用，如果實作為 基於內容的路由器，將可以控制舊式後端訊息的路由方式，並建立一個選項，讓訊息可以路由到新系統。

整合中介軟體也會處理來自店面的訊息（例如，產品銷售），使用 JDBC 直接更新舊式後端背後的 Master 資料庫中的狀態。透過 SwiftMQ 的非同步訊息傳遞和 JDBC 資料庫更新，共同形成舊式後端和整合中介軟體之間的介面。

儘管當時並未發現，但團隊能夠在子系統規模上使用Branch by Abstraction模式，作為替換舊版中間件的策略。抽象層為佇列和 JDBC。透過確保新實作遵循該抽象層，便可以在不影響業務運作的情況下將其替換為「有缺陷的供應商」。

團隊執行的第一件事是透過重構新增事件路由器來實作事件攔截。

事件路由器 (1) 的建立考量了三個主要功能

1. 從一個 SwiftMQ 佇列取消佇列訊息，並將其加入另一個 SwiftMQ 佇列 (2)。一些設定的簡單變更讓整合中間件能夠從這個新佇列 (2) 使用訊息。

整體而言，重構並未變更可觀察的系統行為，但事件路由器現在已成為過渡架構的一部分，並已插入訊息處理管線中。

2. 事件路由器的願景是透過設定，將訊息路由到替代目的地，讓新實作能夠處理發布訊息。事件攔截
3. 事件路由器也會提供從舊版 SwiftMQ 技術到目標架構所選用的新版 ActiveMQ 技術的橋梁。

實作事件路由器並非像想像中那麼簡單。由於缺乏可用的驅動程式/函式庫，與 SwiftMQ 整合存在問題，而且此方法也曾多次受到挑戰。團隊了解此方法將解鎖的選項價值，並完成工作並釋出至生產環境。他們在實際環境中監控新元件，並設定使用新的持續傳遞管線逐步提升其功能。

成功交付各部分：建置功能，維護合約

新的店面管理程式 (1) 現在由團隊反覆建置。與此範例相關，該建置包含實作傳統模仿模式的主資料庫轉接器 (2)。這是抽象層的一部分，用於使用從店面收到的銷售資訊更新主資料庫。由於事件路由器未轉換訊息，因此建立了傳統事件轉接器 (3) (訊息轉譯器)，用於將訊息轉換為新格式，不讓傳統世界接觸到新世界，並與新架構的原則保持一致。傳統店面 轉接器(4) 也在新的店面管理程式 (1) 和傳統店面之間實作，以將新的實作與店面更換後會發生的未來變更隔離。

在傳統店面 (5) 上引進新的 API，新的店面管理程式將使用它。此外，還新增了一項功能，讓在新的 API 上發布的產品的回呼可以傳送到新的店面管理程式的轉接器 (4)。至關重要的是，這讓傳統實作和新實作可以並行執行。

成功交付各部分（續）：轉換成即時服務 - 使用第二個縫合點

在所有部分就定位後，企業便可以測試新的解決方案，但如何以風險管理的方式將它推廣到實際服務中。

為此，他們利用了另一個接縫，這次使用依產品區隔模式。事件路由器已增強，以新增依產品類型以及依唯一產品 ID 的可組態路由 (6)。團隊能夠依 ID 測試個別產品的發布、管理和銷售，然後隨著時間推移，使用愈來愈多的產品類型組態路由器，本質上增加了由新解決方案處理的產品百分比。

當所有產品都由新系統處理時，傳統整合中介軟體已停用，實現了授權、支援和資料中心託管費用的大幅英鎊節省。

改變組織，讓此過程持續進行

我們的團隊已經與客戶合作，在組織的另一部分，並且已經成功取代了不同的傳統系統。

在整個組織的工程層級中，持續傳遞和良好的支援品質實務現在已成為既定常態，而微服務風格架構能夠定期且獨立地將容器化服務部署到雲端平台上。

新計畫的團隊與新的利害關係人合作，需要讓業務的其他部分踏上相同的「敏捷和 CD」旅程，而早期風險管理的版本能夠贏得信任。隨著時間推移，我們得以展示新的工程和品質實務（包括 CD）如何減輕過去導致更高層級官僚主義和治理的風險。因此，較不頻繁、範圍較大的版本發佈也由較小、較頻繁、信心較高的部署所取代，並在業務準備好接受變更時進行切換發佈。

結語

當然，與上述簡化故事所暗示的相比，還有更多複雜性和整合需求。在製作環境中測試新實作後不久，就出現了需要考古學的範例。許多業務關鍵管理資訊報告無法對應 - 產品「遺失」了。

經過一番挖掘，團隊發現整合中介軟體（用於儲存長期商業交易狀態）所使用的資料庫已複製到組織的資料倉儲。透過多個批次作業、儲存程序和檢視，此資料可供商業關鍵績效指標報告內部使用。

需要額外的舊系統模擬，以確保這些報告不會中斷。團隊使用 Wire Tap 擷取來自店面的銷售訊息，並使用 JDBC 將資料注入資料倉儲內的適當表格。這些額外的模擬也成為過渡架構的一部分，並將在可能的情況下移除。

上述以抽象分歧和使用模式與實務的方法，旨在降低風險。

使用事件攔截（技術接縫）、舊系統模擬和過渡架構，讓客戶能夠解決問題。然後，透過產品（商業接縫）分段，在本例中為產品類型，能夠精細控制更廣泛的推出，並進一步管理風險。整體而言，此方法讓企業能夠以他們感到自在的速度進行系統更換。

此方法可以管理風險，但代價不小。因此，需要考慮的問題是「企業對此風險緩解的重視程度為何？」明確說明並量化它，將讓團隊能夠追蹤其投資。事件路由器和舊系統模擬是過渡架構投資的一部分，旨在管理風險。它們的角色是創造選項，使風險能夠被管理。此類工作很容易被視為「拋棄式」的，因此應盡可能避免此類成本。在「風險緩解的價值」與「過渡架構的成本」之間的權衡中，要明確且透明。