Pilot-first, value-stream delivery
Program evidence: the wins-along-the-way structure that produced five platform proof points in three months from a small core team.
Decision Room — Modernization vendor assessment
One proposal on the table. One question: what do we buy, and what do we build?
A vendor modernization proposal from AWS ProServe was previewed on June 24, 2026, with proposal materials shared since. The formal proposal remains the next decision input. The program’s job is to assess it against demonstrated internal capability and alternative proposals, and to recommend a forward path.
Assessment in progress
Formal proposal pending
01 — What the proposal contains
The vendor proposes to prove itself in three days, three weeks, and three months.
Everything below is vendor-provided material from the presented proposal, recorded here as a decision input pending program validation.
- Approach
- A pilot-first “3-3-3” method: 3-day discovery, 3-week proof of concept, and 3-month production delivery per value stream, with Finance and Admin module pilots running in parallel.
- Method
- Reverse engineering with the vendor’s agentic analysis tooling — code, data, and activity analysis, business-logic extraction, decomposition, and migration planning — followed by forward engineering. COBOL to Java; DB2 z/OS and VSAM to Aurora PostgreSQL.
- Timeline
- Phase 1, July 20 to December 21, 2026: discovery, a proof of concept covering roughly 39K LoC in Finance and 31K LoC in Admin, then approximately 300–350K LoC taken to production. Phase 2, January 8 to February 23, 2027: observability, parallel run, and cloud operations. A full-migration decision gate follows on March 1, 2027.
- Economics
- Vendor-projected savings of $7.5M+ per year at full run rate from year four, break-even around year five, and roughly $25.5M cumulative by year ten. The proposal also carries a vendor claim that IBM MIPS pricing compounds 10–15% per year.
All figures vendor-provided, pending program validation. The proposal scope covers the Finance and Admin lanes, not the full program business case ($28.5M annual savings by FY30), so the two are not directly comparable.
02 — The vendor’s module discovery
Two domains sized: the premium engine and the enrollment lifecycle.
The vendor’s discovery pass mapped the Finance and Admin estates by code volume, batch orchestration, and the business surface each one carries.
| Domain | Scale | Orchestration | Business surface |
|---|---|---|---|
| Finance | ~5M LoC; ~30% of MIPS | 295 JCLs in scope, 200 matched in Control-M; 179 daily jobs; 7 functional areas | Premium payment processing, cash posting and distribution, non-pay termination; ~$7B+ annual premiums across ~20 carriers |
| Admin | ~1.5M LoC | 237 JCLs, 81 matched; 4 functional areas | Enrollment lifecycle across FFM and state-based exchanges (~2.9M members); HIPAA 834 EDI; CMS reconciliation; APTC/CSR subsidy settlement |
Discovery figures are vendor-provided from the presented proposal. Program validation against the operational estate is a precondition of any commitment.
03 — What the proposal affirms
The proposal’s strongest evidence is that it agrees with us.
Point by point, the vendor’s recommended approach independently validates the strategy the program is already executing — with evidence on the board.
Modular decomposition of the estate
Program evidence: the platform-lane model already in motion — GroupLink Portal, BrokerLink Portal / MarketLink, Contact Center AI, and ReconLink.
DB2 and VSAM to PostgreSQL
Program evidence: the GroupLink path is already running in production coexistence via IBM CDC, with the database migrated and the bridge active.
Agentic, AI-assisted delivery
Program evidence: the WHPS AI SDLC Factory already governs regulated platform work, human-governed and evidence-first.
The strongest signal in the proposal is agreement: the strategy the program chose is the one the vendor now recommends.
04 — Where vendor help is real, and where it is not
Partnership is worth buying where the gap is real, and nowhere else.
The assessment separates capability the program has already demonstrated from capability a vendor could genuinely add. Only the second column is a purchase candidate.
Gaps a vendor can help close
- Mainframe reverse engineering at scale: COBOL, JCL, and copybook analysis with business-rule extraction tooling.
- A data migration factory for DB2 z/OS and VSAM to cloud PostgreSQL.
- Batch dependency analysis across the 500+ vendor-counted JCLs.
- MIPS and workload baselining to ground the economics in measured fact.
What the program self-performs
- Application forward-engineering, proven with the GroupLink Portal cloud-native rebuild and the MarketLink six-week regulated pathway.
- The next build, ServiceLink Portal: a member CRM for enrollment and billing in the regulated marketplace domain, squarely inside proven capability.
- Business, regulatory, and system context: the program’s teams know the carriers, the members, and the regulators.
- The evidence and compliance system.
- Product ownership and roadmap control.
05 — The recommendation taking shape
Build what we have proven. Buy only what we have not.
Recommendation under evaluation — decision pending the formal proposal and competitive assessment.
Recommendation under evaluation
Self-perform all application build
Application forward-engineering is the program’s demonstrated, evidence-backed strength. Every application the exit requires is built inside the program’s own delivery system.
Consider a bounded vendor engagement where the gap is real
A scoped pilot of the vendor’s mainframe analysis tooling (e.g. AWS Transform) on the Finance and Admin COBOL/JCL estate, for reverse engineering and rule extraction. The deliverable is the documented rule corpus and migration-plan inputs, not application code.
Benchmark before any commitment
Alternative proposals are assessed on the same evidence standard. The formal proposal is one input to the decision, not a default.
Keep every phase evidence-gated
Discovery validation, parity evidence, and verified retirement gate each phase, consistent with the program’s savings-recognition rule: savings count only when workloads are verifiably retired.
- Gate 01
- Formal proposal received and validated.
- Gate 02
- Alternative proposals assessed.
- Gate 03
- Pilot scope and funding envelope agreed.
- Gate 04
- Evidence gates defined before work starts.
06 — The decision
We have already proven we can build. The decision is where partnership genuinely accelerates the exit.
The assessment continues on evidence, not enthusiasm. When the formal proposal lands, it will be judged against demonstrated capability, alternative bids, and the program’s own gates.