Internal Decoupling

Summary

This Internal Decoupling flow enables the Accounts domain to be refactored to the cloud without breaking existing legacy consumers.

The combination of the Proxy and Reverse API pattern ensures seamless coexistence between legacy and cloud-native components, while Planner and Hub provide full governance over the execution lifecycle.

Internal Decoupling Variants

The Internal Decoupling pattern applies consistently across multiple modernization strategies. While the core mechanics (Proxy, Reverse API, Bridge) remain the same, the target implementation and modernization intent differ by Plan Action.

---

Internal Decoupling Example: Refactoring the Accounts Domain to the Cloud

This example illustrates a standard Internal Decoupling scenario in which a legacy domain is refactored to the cloud while dependent legacy applications continue operating without disruption.

---

Initial Baseline State

In the Baseline:

• The Customers application runs on the legacy environment
• The Accounts domain also runs on the legacy environment
• Customers calls Accounts directly through internal program-to-program invocation
• The Accounts database resides on the legacy system

This represents a tightly coupled legacy architecture, where both business logic and data are physically and logically bound to the same environment.

---

Modernization Goal

The objective of this plan is to:

• Refactor the Accounts domain to the cloud
• Preserve the existing Accounts interface for all consuming applications
• Avoid any changes to the Customers application during the initial phase
• Maintain controlled access to the existing Accounts database while it remains on the legacy system

This transformation is implemented using the Internal Decoupling pattern with the Refactor Plan Action.

---

Resulting Target Architecture

After executing the plan:

• A new cloud-native microservice named Accounts-New is deployed in the cloud
• A Proxy program is generated and deployed in the legacy environment:
  • The Proxy exposes the same interface as the original Accounts domain
  • The Customers application continues calling Accounts exactly as before
• The Proxy forwards requests using a Reverse API invocation to:
  • The OpenLegacy Bridge Microservice
  • Which routes the request to Accounts-New in the cloud

Database Access (If the Database Remains on the Legacy)

When the Accounts database remains on the legacy environment:

• The Accounts-New microservice accesses the database via:
  • A JDBC connection
  • Over controlled network routing and governed security policies

From the perspective of the Customers application, the call path and contract remain unchanged.

---

Logical Call Flow After Decoupling

1. Customers (Legacy) invokes Accounts (Legacy Interface)
2. The call is intercepted by the Accounts Proxy Program (Legacy)
3. The Proxy invokes the Reverse API
4. The call is routed through the OpenLegacy Bridge
5. The request is processed by Accounts-New (Cloud Microservice)
6. If required, Accounts-New accesses the legacy database via JDBC
7. The response propagates back through the same chain to Customers

This enables runtime decoupling without modifying the consuming application.

---

How Planner Implements This Flow

Using Planner:

1. The Baseline captures:

   • The Customers → Accounts dependency
   • The placement of the Accounts domain
   • The location of the Accounts database

2. The user selects the Refactor Plan Action for the Accounts application.

3. Planner automatically generates a governed execution plan that includes:

   • Proxy generation on the legacy environment
   • Reverse API exposure
   • Bridge deployment and routing
   • Cloud microservice scaffolding for Accounts-New
   • JDBC connectivity configuration (if the database remains on legacy)
   • Validation, rollout, and sequencing tasks

4. The plan is reviewed and approved by the user.

5. All tasks are executed via the OpenLegacy Hub, with full:

   • Orchestration
   • Monitoring
   • Logging
   • Auditability

---

Key Architectural Benefits

• The Customers application remains unchanged
• The Accounts domain is actively modernized in the cloud
• Legacy-to-cloud traffic is governed, observable, and secure
• The database can remain temporarily on the legacy platform
• The migration process is:

  • Phased

  • Reversible

  • Fully traceable

---

Rehost Variant

Lifting Accounts to the Cloud Without Code Changes

Goal

The objective of the Rehost action is to:

• Move the Accounts runtime as-is to the cloud
• Avoid refactoring or changing business logic
• Preserve the existing interface and execution model
• Ensure dependent applications remain unchanged

---

Resulting Architecture

After execution:

• The Accounts runtime is rehosted in the cloud without functional changes
• The legacy Accounts instance is replaced by a Proxy program
• The Proxy:
  • Exposes the original Accounts interface
  • Forwards all calls using a Reverse API to:
    • The OpenLegacy Bridge
    • The rehosted Accounts service in the cloud

If the database remains on the legacy platform:

• The rehosted service accesses it via:
  • JDBC connectivity
  • Governed security and routing policies

---

Key Characteristics

• No functional refactoring
• No API redesign
• Infrastructure-only migration
• Zero impact on consuming legacy applications

---

Reimagine Variant

Redesigning the Accounts Domain in the Cloud

Goal

The objective of the Reimagine action is to:

• Fully redesign the Accounts domain using modern architecture patterns
• Introduce new APIs, data models, and business workflows
• Preserve legacy compatibility during the transition

---

Resulting Architecture

After execution:

• A new cloud-native Accounts service is designed and implemented
• A Proxy program remains on the legacy platform:
  • Preserves the original legacy interface
  • Translates legacy calls into the new cloud API model
• All traffic flows through:
  • The Reverse API
  • The OpenLegacy Bridge
  • Into the reimagined Accounts service

The database may:

• Remain on legacy temporarily
• Be migrated as part of the reimagination phase

---

Key Characteristics

• New business logic and workflows

• New API contract

• Legacy consumers remain stable

• Enables long-term architectural transformation

---

Augment Variant

Introducing a New Cloud Capability Without Replacing Legacy

Goal

The objective of the Augment action is to:

• Introduce a new cloud-native capability
• Extend the business domain without replacing the legacy system
• Allow the cloud service to consume legacy functionality

---

Resulting Architecture

After execution:

• A new cloud microservice named Accounts-New is deployed
• The legacy Accounts system remains the source of record
• The cloud service:
  • Calls the legacy Accounts system using:
    • OpenLegacy connectivity
    • Standard service exposure mechanisms
• No Proxy replacement of the legacy Accounts interface is required
• No redirection of existing legacy consumers is performed

---

Key Characteristics

• Legacy system remains authoritative

• Cloud service consumes legacy services

• No impact on existing legacy call flows

• Ideal for innovation and incremental feature delivery

  

---

Summary of Variants

---

These variants allow Planner to apply the same Internal Decoupling control pattern across different modernization strategies while maintaining full governance and traceability.