Case Study: GlobalBank — Evaluating Modernization Options for GLOBALBANK-CORE

The Mandate

In June 2024, GlobalBank's CIO formed a modernization task force with a clear objective: "Develop a five-year technology strategy for GLOBALBANK-CORE that enables mobile banking, reduces mainframe costs, and addresses the developer talent gap — without compromising the system's reliability."

Priya Kapoor, the systems architect, led the effort. Her team included Maria Chen (senior COBOL developer), Derek Washington (junior developer with modern tech experience), and representatives from business units, operations, and finance.

The Assessment

Current State Analysis

Priya began with a detailed inventory:

Business Requirements Gap

The business identified five capabilities they needed within 24 months:

1. Mobile banking API — Real-time account inquiry, transfers, and payment from mobile apps
2. Partner API — Third-party fintech access to account data (Open Banking compliance)
3. Real-time fraud detection — Transaction scoring before approval (currently batch-only)
4. Customer 360 dashboard — Unified view of customer across all products (currently siloed)
5. Cloud disaster recovery — Secondary processing capability outside the primary data center

Strategy Evaluation

Priya evaluated five strategies against the requirements:

Option 1: Maintain Only (Do Nothing)

• Cost: $4.8M/year (growing 5-8%/year)
• Mobile API: Not possible without integration work
• Risk: Developer attrition could leave the system unsupportable within 5 years
• Verdict: Rejected — does not meet business requirements

Option 2: Full Rewrite in Java

• Estimated cost: $18-25M over 3-5 years
• Risk: 50% failure rate for projects of this scale (Standish Group data)
• During transition: Must maintain two systems simultaneously ($7M+/year)
• Talent: Need 15-20 Java developers for 3-5 years
• Verdict: Rejected — risk and cost too high for uncertain benefit

Option 3: Wrap and Extend (Priya's Recommendation)

• Phase 1 cost: $400K (wrap critical CICS transactions as REST APIs)
• Phase 2 cost: $1.2M (build mobile platform calling wrapped APIs)
• Phase 3 cost: TBD (selective modernization based on Phase 2 experience)
• Risk: Low in Phases 1-2; manageable in Phase 3
• Talent: 3 COBOL developers + 4 Java developers
• Verdict: Recommended — delivers business value quickly with low risk

Option 4: Platform Migration (z/OS to Linux)

• Cost: $3-5M for migration; ongoing savings of $1.5M/year on licensing
• Risk: Medium — CICS and VSAM emulation may introduce defects
• Breakeven: 2-3 years
• Talent: Need Micro Focus expertise in addition to COBOL
• Verdict: Consider for Phase 3 if cost reduction is prioritized

Option 5: Buy a Package (Replace with COTS)

• Cost: $5-10M for package + $3-5M for implementation
• Risk: High — package may not match all business rules
• Customization: Core banking packages require extensive configuration
• Vendor lock-in: Trading mainframe dependency for vendor dependency
• Verdict: Rejected — GlobalBank's competitive advantage is in customized products that a package cannot replicate

The Decision

The board approved Option 3 (Wrap and Extend) with a conditional review at the end of Phase 2 to determine Phase 3 direction.

Phase 1 Implementation

Phase 1 focused on wrapping three CICS transactions:

1. GBIQ (Account Inquiry) — Read-only, low risk
2. GBXF (Transfer) — Write operation, medium risk
3. GBHX (Transaction History) — Read-only, involves cursor processing

Technical Architecture

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  API Gateway │     │ z/OS Connect │     │  CICS Region │
│  (Kong)      │────►│  EE          │────►│              │
│              │     │              │     │  GBIQ, GBXF, │
│  Rate        │◄────│  JSON ↔      │◄────│  GBHX        │
│  limiting,   │     │  COMMAREA    │     │              │
│  auth, logs  │     │              │     │  (unchanged  │
│              │     │              │     │   COBOL)     │
└──────────────┘     └──────────────┘     └──────────────┘

The COBOL programs were NOT modified. The only changes were: - z/OS Connect configuration (mapping files) - API Gateway configuration (routing, authentication) - Monitoring dashboards

Phase 1 Results

Lessons Learned

1. The biggest risk was organizational, not technical. Getting approval from risk management, security, and compliance took longer than the technical implementation.

2. Start with read-only APIs. GBIQ (inquiry) went live first, building confidence before the write-capable GBXF (transfer) was exposed.

3. Performance was better than expected. The z/OS Connect overhead was minimal (15-20ms), and the underlying COBOL programs were already fast thanks to Maria's tuning (Chapter 36).

4. Zero COBOL changes was the key selling point. Stakeholders were reassured that the core banking logic was untouched — the risk was isolated to the new wrapper layer.

5. Mobile banking became feasible. Phase 2 (mobile app development) began immediately after Phase 1 completion, using the APIs as the backend.

Discussion Questions

1. Priya rejected the full rewrite despite its potential long-term benefits. Under what circumstances would a full rewrite have been the correct decision?

2. The assessment showed that only 26% of programs were modified in the last year. How does this affect the modernization strategy? Should unchanged programs be treated differently from frequently-modified ones?

3. Option 4 (platform migration from z/OS to Linux) was deferred to Phase 3. What information from Phases 1 and 2 would help decide whether to pursue it?

4. GlobalBank's competitive advantage comes from customized products. How does this affect the "buy a package" decision? Would the calculus be different for a community bank with standard products?