Case Study 2: MedClaim Hybrid Architecture Vision
The Business Pressure
MedClaim faced pressure from three directions: 1. Members wanted a self-service portal and mobile app 2. Providers wanted real-time claim status and eligibility checks 3. Regulators wanted faster compliance reporting and data analytics
The existing system — 800,000 lines of COBOL running on z/OS — could not directly serve web or mobile users. But it contained decades of refined adjudication logic that could not be easily replaced.
The Hybrid Design
James Okafor and Sarah Kim designed a three-layer architecture:
Layer 1: Experience Layer (Cloud)
- Member portal (React/Next.js on AWS)
- Provider portal (React on AWS)
- Mobile app (React Native)
- Analytics dashboard (Tableau/Power BI on cloud data warehouse)
Layer 2: Integration Layer (Hybrid)
- API Gateway (Kong on AWS)
- z/OS Connect EE (on mainframe)
- Event streaming (MQ to Kafka bridge)
- Change Data Capture (IBM InfoSphere CDC)
Layer 3: Core Processing (Mainframe)
- Claims adjudication (CLM-ADJUD) — COBOL
- Eligibility determination (ELIGCHK) — COBOL
- Payment processing (CLM-PAY) — COBOL
- Provider management (PRV-MAINT) — COBOL
- Nightly batch pipeline — COBOL
- DB2 (system of record)
Key Design Decisions
Decision 1: COBOL stays for adjudication. The 112 business rules in CLM-ADJUD represent 20 years of regulatory compliance. Rewriting them in Java would take 18+ months with significant regression risk. Keeping them in COBOL and exposing via API takes 3 months with zero logic changes.
Decision 2: Analytics moves to the cloud. Compliance reporting requires complex queries across large datasets. DB2 on the mainframe can handle these queries, but they compete with transaction processing for resources. Replicating data to a cloud data warehouse isolates analytics from transactions.
Decision 3: Real-time events via MQ-to-Kafka bridge. When a claim is adjudicated on the mainframe, an MQ message is published. The Kafka bridge relays it to the cloud, where the member portal updates the claim status in real-time.
Decision 4: Containerized dental processing. The dental division (acquired via acquisition) runs adjudication on containers using the shared ADJCORE subprogram (Chapter 40). Medical stays on the mainframe.
Implementation Timeline
| Quarter | Milestone |
|---|---|
| Q1 | API Gateway and z/OS Connect deployment |
| Q2 | Eligibility API live for providers (50K checks/day) |
| Q3 | Member portal MVP (claim status, eligibility) |
| Q4 | Mobile app launch, claim status notifications |
| Q5 | Analytics data warehouse operational |
| Q6 | Provider portal with real-time claim tracking |
| Q7 | Compliance reporting automated on cloud |
| Q8 | Full hybrid architecture operational |
Results After Year 1
- Member satisfaction: 2.8/5 to 4.1/5
- Provider satisfaction: 2.1/5 to 4.4/5
- Eligibility check response time: 24 hours (batch) to 280ms (real-time)
- Compliance report generation: 2 weeks (manual) to 4 hours (automated)
- COBOL programs changed: 0 (business logic unchanged)
- Mainframe MIPS consumption: reduced 15% (analytics offloaded to cloud)
Discussion Questions
- What is the most critical risk in this hybrid architecture? How would you mitigate it?
- The design keeps DB2 on the mainframe as the system of record. Under what circumstances would you consider moving the system of record to the cloud?
- The MQ-to-Kafka bridge introduces latency in event delivery. How would you handle a scenario where the bridge fails?
- If MedClaim acquires another company (e.g., vision insurance), how would this architecture accommodate the new business line?