Legacy-Core Modernization β the Oracle legacy (GlobalCore) & the strangler
:::note Status β BUILT & LIVE on dev (2026-09-29); sections below partially superseded The strangler is no longer planned β it is built end-to-end on dev. The section-by-section detail below (esp. Β§2βΒ§3 "on Oracle") describes the earlier direction and is partially superseded by What's live just under here. This is ktayl-solution IS work (business/org context), not the Retrieva certification. :::
What's live (2026-09-29) β Slices AβD of the Claims stranglerβ
The modern Claims capability (ktayl-claims, #11) is built AS the Anti-Corruption Layer over a
frozen legacy core, and the full modernization pattern runs on dev:
| Slice | What it delivers | Live proof |
|---|---|---|
| A β Legacy core | GlobalCore SOAP service (Java/Spring) + its DB as Docker containers on the controller, outside k3s. The DB is MySQL 8 (binlog + GTID), a simulated stand-in for an Oracle-era legacy β not real Oracle (ADR-002 amended: Oracle XE too heavy; the strangler/ACL/CDC pattern was the point, and MySQLβPostgres makes the CDC pipeline genuinely cross-engine). | SOAP FindPolicy/CreateClaim/Reserve/Settle + faults; rows in MySQL gc_claim. |
| B β ACL writes (SOAP) | The ACL calls GlobalCore's SOAP for commands (createClaim/reserve/settle) under the soap profile, translating cryptic XML β clean JSON, authority-checked server-side. | FNOL via the ACL β CLM-2026-000005 created in the legacy; authority + coverage guards enforced. |
| C β CDC (Debezium β NATS) | Debezium Server tails the MySQL binlog β NATS JetStream stream CLAIMS_CDC (claims-cdc.globalcore.*), zero legacy change. | A live FNOL emits a gc_claim CDC event on the bus within <1s. |
| D β CQRS read-model | An in-process CDC projector (durable JetStream consumer) projects claim changes into a CNPG Postgres read-model; GET /api/claims/{id} reads that (eventually consistent), while commands keep authoritative read-your-writes via the legacy (ADR-008). | GET reads from the read-model; a fresh FNOL is reflected in <2s; unknown β 404. |
Detailed design + decisions: ktayl-claims/docs/architecture/adr
(ADR-001 strangler Β· ADR-002 legacy=MySQL simulated Β· ADR-003 SOAP+CDC Β· ADR-004/008 CQRS read-model). The
"on Oracle" wording in Β§2βΒ§3 below is the superseded earlier plan.
1. Why a legacy core β and where it sitsβ
A real IARD insurer's IS is not all greenfield. It runs a legacy core that still works (old, authoritative, stored-procedure-heavy, SOAP/batch) and grows a modern platform around it that wraps, intercepts and strangles it β but rarely replaces it (Strangler Fig + Anti-Corruption Layer). This is the ktayl IS's Track C (Modernization Practice Lab) on the IS Build Roadmap, and β crucially β it is pointed at a real, needed domain so the wrapping delivers value, not a throwaway.
Two deliberate choices:
- Policy is already modern (the live
ktayl-policy-service, #6), so the legacy is NOT policy β wrapping a legacy policy core would just re-deliver what we already have. - The legacy delivers a domain we NEED but haven't built β Claims (#11). Wrapping the legacy is how we deliver modern Claims. The practice lab (Track C) and the real business domain (Track A) reinforce each other instead of competing.
2. GlobalCore β the legacy engine (on Oracle)β
The legacy is GlobalCore (globalcore-legacy) β a deliberately-legacy carrier we own and freeze,
so wrapping it teaches the real modernization architecture. Its authentic-legacy traits are the point:
| Trait | How it shows up | Why it matters |
|---|---|---|
| Oracle | the system-of-record runs on Oracle (Free edition) with PL/SQL stored procedures | real Oracle experience β the HDI-relevant skill; rules live in the DB, not the app |
| SOAP/XML only | the only API is /ws (WSDL) β no REST, no JSON | forces an ACL translator (SOAPβJSON) |
| Batch, not real-time | a create lands pending; a nightly batch activates it | you design around async issuance (batchβevents) |
| Cryptic shared schema | β€8-char columns, codes not enums (STATCD P/A/L/Cβ¦) | the ugly representation the ACL must hide |
| Outside k8s | plain Docker container on the controller | legacy isn't cloud-native; the modern platform reaches out to it |
| FROZEN | you never add modern capability inside it | the constraint that forces a real wrap, not an edit |
Evolution (from the current build): GlobalCore v0 is Java 8 / SOAP / batch on PostgreSQL-pretending- to-be-Oracle, domain = Policy. It evolves to (a) real Oracle (Free edition + PL/SQL), and (b) the Claims domain (claims Β· reserves Β· payments + supporting refs) β the needed, unbuilt capability. Policy data stays as a supporting reference (coverage lookups), but the wrapped/delivered domain is Claims.
3. How Oracle runs β the image & placementβ
No standalone Oracle infrastructure β one Free-edition container (the old XE lineage; zero licence).
- Image:
container-registry.oracle.com/database/free:latest-lite(community mirrorgvenzl/oracle-freeas fallback). GlobalCore (Java 8 / Spring) connects via Oracle JDBC. - Placement β OUTSIDE Kubernetes, as Docker containers on the controller (GlobalCore + its Oracle,
like MinIO). Realistic ("legacy on traditional infra, modern platform on k8s") and keeps Oracle off the
constrained k3s cluster (no Longhorn). The modern ACL reaches GlobalCore's SOAP + Oracle at
controller-ip. - Sizing gate: the controller disk is tight (98 G, MinIO ~33 G, prior disk-full cascades). Oracle Free needs a few GB β size + gate it, or place the containers on a worker node's local disk (still outside k3s).
- Oracle creds β Vault (
secret/platform/oracle-legacy) β ESO β the ACL; a least-privilege app user, never SYS/SYSTEM, never in Git.
4. The wrap β how Claims #11 delivers the domainβ
ktayl-claims (#11) is the modern Claims capability, built as the ACL/strangler over GlobalCore. Three
seams, matching GlobalCore's authentic-legacy interfaces:
- SOAP β JSON translation (the ACL API). The modern claims API calls GlobalCore's SOAP for writes
(create claim β
pending), translating the cryptic XML (codes, β€8-char fields) into clean JSON. No app, portal or AI speaks SOAP or touches Oracle directly. - Batch β events. A create is only official after the nightly batch flips it active. The ACL models
this async issuance and, via CDC (Debezium on Oracle β NATS), turns legacy changes into domain events
(
CLAIM_CREATED,CLAIM_STATUS_CHANGED,RESERVE_ADJUSTED) so consumers react instead of polling. - Read-model + governed AI. A Postgres read-model (CQRS-lite) projects the events to power a modern claims workbench (reads never hit the legacy). AI reaches claims only via approved SQL-tools behind the ACL (identity-propagated, PII-masked) + RAG for documents β never the LLM on Oracle.
5. How it fits the roadmap (Track A Γ Track C)β
| Piece | Track | State |
|---|---|---|
GlobalCore (globalcore-legacy) β Oracle/SOAP/batch legacy | C (practice lab) | built β , evolving to Oracle + Claims |
| ktayl-claims #11 β the modern wrap that delivers Claims | A (business) | scaffold β Path-C planning done |
| ktayl-integration #25 β the ACL/CDC wrapper capability | foundations | wrapper spec authored |
| GenApp (M1βM4) β the real IBM COBOL core, optional advanced track | C | forked, study-now |
| Policy #6, Underwriting #12, distribution, finance⦠| A | modern greenfield (NOT wrapped) |
The wrapping skill built here (SOAPβJSON, batchβevents, ACL, CDC, legacy comprehension) feeds back into Track A whenever a real domain must integrate with something legacy β the whole point of Track C.
6. Build sequence (gated)β
now Underwriting #12 thin slice (greenfield, in flight β don't interrupt)
β align docs (EA Β§2b + this + the wrapper spec) β YOU VALIDATE HERE
β ktayl-claims Path-C planning set (brief/PRD/arch/threat/ADRs) aligned to GlobalCore+Oracle+Claims β validate
β evolve GlobalCore: Oracle (Free) + PL/SQL + the Claims domain (frozen, outside k8s)
β build ktayl-claims: ACL (SOAPβJSON) β CDC(DebeziumβNATS) β read-model β workbench
β governed AI read-tools Β· then the AI Ops Copilot (#19) LAST
Validation gates before any Oracle/Claims build. No Oracle is stood up and no Claims code is written until this alignment + the Claims Path-C set are validated β same discipline as Underwriting #12.
7. Governance & complianceβ
Path-C (a legacy datastore, CDC, cross-boundary AI) β architecture + security review gates. Compliance-by-design in the Claims threat model: legacy creds (Vault/ESO), least-privilege Oracle user, default-deny egress to the controller only, PII masking before AI, identity propagation, audit on every ACL
- AI action. Evidence β Regulatory & Compliance #15 control library.
Referencesβ
- Enterprise Architecture Blueprint Β§2b β the spine in the IS model
- IS Build Roadmap β Track C (Modernization Practice Lab)
- Wrapper initiative spec:
ktayl-integration/docs/legacy-wrapper-initiative-spec.md - Legacy engine:
globalcore-legacyΒ· Claims wrap:ktayl-claims(#11)