External Decoupling

External Decoupling is a modernization pattern used when external applications integrate via gateways (like CTG, IMS Connect, or MQ) and must remain unchanged, while the processing behind those gateways is modernized.

This pattern is implemented using a mix of OpenLegacy components (Interceptors, Bridges, Services) and Planner governance. It supports incremental modernization with minimal disruption.


When to Use External Decoupling

Use this pattern when:

  • You want to modernize a gateway-backed legacy program (e.g., CICS behind CTG),
  • External consumers (e.g., desktop apps, partners) cannot change,
  • You need a low-risk cutover strategy that keeps channels live,
  • You want governed control over traffic redirection and rollback.

Gateway Types Supported

GatewayDecoupling MechanismInterceptor?
CTGRouted through OpenLegacy BridgeYes
IMS ConnectRouted through OpenLegacy BridgeYes
IBM MQLogic handled in the queue logicNo


How It Works

General Architecture

  1. External app calls the same gateway (CTG, IMS, or MQ queue).
  2. Interceptor or routing logic receives the call.
  3. The request is passed to an OpenLegacy Bridge.
  4. Bridge invokes a modern service (refactored, rehosted, or reimagined).
  5. Response flows back the same path.

Contracts stay stable. Logic evolves.

CTG / IMS: Using Interceptors

  • CTG or IMS request is intercepted by a generated Interceptor.
  • Interceptor transforms the protocol and payload.
  • Calls a REST/gRPC endpoint exposed by a Bridge.

MQ: Using Queue Logic

  • Message lands on same queue.

  • Queue processing logic (consumer) is updated to:

    • Deserialize the message,
    • Call a Bridge / modern service,
    • Return message if needed.

From Baseline to Plan (CTG Example)

Baseline

branch (Digital desktop app) calls CTG → routes directly to customer_acc_mng (CICS) → calling.card_mng → uses VSAM.


Plan: With CTG Interceptor

Planner introduces:

  • customer_acc_mng-new: modern refactored service

  • customer_acc_mng-new-bridge: exposed via OpenLegacy

  • card_mng-service: wraps legacy card_mng functionality

  • CTG Interceptor (CE-CTG): redirects CTG traffic to the new path

Traffic flow becomes:

branch → CTG → Interceptor → Bridge → customer_acc_mng-new → (optional call to card_mng-service)

No change for the external app. Full control for modern rollout.


Tasks Generated by Planner

Planner automates the modernization via:

  • Module and project creation
  • Refactor/Rehost/Reimagine actions
  • Interceptor generation & deployment
  • CTG/IMS endpoint reconfiguration
  • Governance and observability in Hub

Example task sequence:

  1. Refactor customer_acc_mng
  2. Create card_mng-service
  3. Create customer_acc_mng-new-bridge
  4. Install and configure CTG Interceptor
  5. Update CTG configuration to redirect traffic

Benefits

  • No change for external clients
  • Modern logic, same entry point
  • Coexistence-friendly: run legacy and modern in parallel
  • Planner-governed rollout: traceability, rollback, observability

Related Patterns

  • Internal Decoupling: modernize internal call flows between programs
  • Bridge Pattern: decouple legacy and modern execution via REST/gRPC
  • Refactor, Rehost, Reimagine: supported Plan Actions in External Decoupling

See Also