Chapter 32 Quiz: Modernization Strategy

Section 1: Multiple Choice

1. What is the threshold concept of this chapter — the insight that separates successful modernization architects from those who lead billion-dollar failures?

a) Modernization should always move applications to the cloud b) Modernization is not migration — the goal is making the system better, not moving it somewhere else c) COBOL should always be replaced with Java or Python d) The mainframe is always the best platform for transaction processing

Answer: b) Modernization is not migration — the goal is making the system better, not moving it somewhere else

Explanation: The fundamental insight is that modernization means making the system serve modern business needs. This may or may not involve changing the platform, language, or architecture. Organizations that equate modernization with migration — "getting off the mainframe" — are the ones that lead billion-dollar failures, because they've made a technology decision before understanding what the business actually needs. Successful modernization starts with the question "what does the business need?" not "how do we replace the mainframe?"

2. Which modernization strategy involves moving a COBOL application to a different platform (such as Linux on x86 or cloud) with minimal code changes?

a) Refactor b) Replace c) Rehost d) Replatform

Answer: c) Rehost

Explanation: Rehost (also called "lift and shift") moves the application to a new platform with minimal changes to the code itself. The COBOL runs on a compatible runtime (Micro Focus, GnuCOBOL) instead of z/OS. The key distinction from Replatform is that rehost makes minimal code changes, while replatform involves both a platform change and architectural improvements. Rehost is the cheapest strategy upfront but often fails for applications with deep z/OS dependencies (CICS, IMS, Parallel Sysplex, WLM).

3. In Sandra Chen's portfolio assessment of FBA, what percentage of the portfolio was recommended for retirement (turning off applications nobody needed)?

a) 5% b) 15% c) 25% d) 38%

Answer: d) 38%

Explanation: Sandra's assessment found that 1,847 of FBA's 4,847 programs (38%) could be retired — they were either dead code (never executed) or produced output that nobody consumed. Retiring these programs saved $2.1 million per year in MIPS costs. This is consistent with industry patterns: most large mainframe portfolios have 25-40% dead or near-dead applications. Identifying and retiring them is the highest-ROI modernization activity because it costs almost nothing to execute and immediately reduces licensing costs.

4. What is the primary reason automated COBOL-to-Java conversion tools produce unsatisfactory results?

a) The conversion tools have bugs that introduce logic errors b) Java cannot express the same algorithms as COBOL c) The tools change the syntax but not the architecture, producing unmaintainable "COBOL in a Java costume" d) The converted code always runs faster but is harder to debug

Answer: c) The tools change the syntax but not the architecture, producing unmaintainable "COBOL in a Java costume"

Explanation: Automated conversion tools produce syntactically valid Java that preserves the COBOL program's logic, but the result retains the monolithic structure, procedural flow, and data layouts of the original COBOL. PERFORM THRU becomes nested method calls with complex control flow. WORKING-STORAGE becomes massive static class fields. REDEFINES becomes unsafe type casts. The result is code that no Java developer wants to maintain and that typically runs 3-10x slower than the original COBOL because the JVM wasn't optimized for these patterns. The syntax changes, but the architecture doesn't — you've paid millions for a language translation, not a modernization.

5. Which three axes does the portfolio assessment framework use to score applications?

a) Cost, Timeline, Risk b) Business Criticality, Technical Complexity, Technical Debt c) LOC, MIPS, Transaction Volume d) Platform Dependency, Team Skill, Budget Impact

Answer: b) Business Criticality, Technical Complexity, Technical Debt

Explanation: Business Criticality (how important is this application to the business — scored 1-5 from Peripheral to Mission-Critical), Technical Complexity (how hard is this application to change — considering subsystem dependencies, CALL chains, documentation), and Technical Debt (how much accumulated damage has the code suffered — from clean/well-structured to ALTER/GO TO spaghetti). Plotting applications on these three axes reveals which strategy is appropriate: high-criticality/high-complexity applications need cautious refactoring, low-criticality applications may be candidates for retirement, and so on.

6. In the TCO comparison for FBA, which was the most expensive option over 5 years?

a) Option A: Stay on Mainframe + Refactor ($152.3M) b) Option B: Replatform to Cloud ($212M) c) Option C: Replace / Big-Bang Rewrite ($200M+) d) All options were approximately equal in cost

Answer: b) Option B: Replatform to Cloud ($212M)

Explanation: The replatform option was the most expensive at $212M over 5 years, driven by three cost categories: $84M for the migration project itself, $44M for cloud operating costs (years 4-5), and $84M in mainframe overlap costs (the mainframe can't be turned off until migration is complete, and at $28M/year for 3 years of overlap, this is a massive hidden cost). Option C (Replace) was listed at $200M+ but with "high probability of failure" — meaning the real cost could be even higher. Option A (Refactor in place) was cheapest at $152.3M because it avoided migration costs and mainframe overlap entirely.

7. What is the primary purpose of "Horizon 1" in the three-horizon modernization roadmap?

a) Complete the full migration to cloud b) Deliver quick wins that build credibility and justify continued investment c) Hire cloud engineers to replace mainframe staff d) Conduct a multi-year planning exercise before taking any action

Answer: b) Deliver quick wins that build credibility and justify continued investment

Explanation: Horizon 1 (0-12 months) focuses on visible results: retiring dead applications (immediate cost savings), exposing high-value transactions as APIs (immediate business value), implementing modern development tools (immediate developer satisfaction), and establishing automated testing. These wins serve a dual purpose: they deliver genuine value AND they create political support for continued investment. Modernization projects that don't show results in the first six months get canceled — Horizon 1 prevents that by front-loading visible impact.

8. Carlos Vega at SecureFirst initially pushed for a microservices rewrite. What data changed his mind?

a) The cost analysis showed rewriting was too expensive b) The COBOL service handled 12,000 req/sec at 0.8ms p99 while his Java prototype handled 3,000 at 14ms p99 c) The CTO mandated keeping COBOL d) The mainframe team refused to cooperate

Answer: b) The COBOL service handled 12,000 req/sec at 0.8ms p99 while his Java prototype handled 3,000 at 14ms p99

Explanation: Carlos's Java prototype for the account balance service performed at 25% of the COBOL throughput (3,000 vs. 12,000 requests per second) with 17.5x worse tail latency (14ms vs. 0.8ms p99). This is a data-driven assessment that demonstrates the mainframe's fundamental advantage for high-throughput transaction processing: the z/OS I/O architecture, CICS quasi-reentrant model, and hardware optimization for transactional workloads produce performance that commodity cloud infrastructure cannot match for these specific workload patterns. Carlos's shift illustrates the chapter's core message: let the numbers make the decision, not technology fashion.

9. Which of the following is NOT one of the "hidden costs" that should be included in a modernization TCO analysis?

a) Parallel running costs during migration b) Compliance re-certification c) Marketing costs for the new system d) Cloud egress charges

Answer: c) Marketing costs for the new system

Explanation: The chapter identifies ten categories of hidden costs: data migration/reconciliation, parallel running, performance tuning on the new platform, regression testing, retraining, third-party software re-licensing, cloud egress charges, incident response capability, compliance re-certification, and opportunity cost. Marketing costs are not a component of modernization TCO. Every other option represents a real and frequently overlooked cost category. Parallel running alone can add tens of millions to a project when the mainframe can't be decommissioned until migration is validated.

10. What governance rule does Sandra Chen consider most important for keeping a modernization project on track?

a) "No phase proceeds until the previous phase is stable in production for 30 days" b) "All decisions must be approved by the CTO personally" c) "Vendor partners must attend every governance meeting" d) "Budget reviews happen annually, not quarterly"

Answer: a) "No phase proceeds until the previous phase is stable in production for 30 days"

Explanation: This rule prevents the common pattern of rushing to the next phase while the current phase is still experiencing production issues. It forces the team to achieve stability before adding more change, which is critical for risk management in multi-year modernization programs. The 30-day stability window provides evidence that the current phase is truly production-ready, not just "deployed and hoping for the best." This gated approach also gives operations and support teams time to build confidence with the changes before being asked to absorb more.

11. In the "Billion-Dollar Mistakes" section, what was the root cause of GlobalBank's failed replacement project?

a) The vendor's technology was inadequate b) The project team discovered 800+ undocumented business rules embedded in the COBOL code after go-live c) The mainframe hardware failed during migration d) The new system was too slow for production workloads

Answer: b) The project team discovered 800+ undocumented business rules embedded in the COBOL code after go-live

Explanation: GlobalBank spent 18 months reverse-engineering business rules from 30 years of COBOL code, documented 4,200 rules, and began building the replacement. After go-live on a single product line, they found 800+ additional rules that were embedded as special-case handling, conditional processing, and exception logic — rules that weren't in any requirements document because nobody knew they existed. This illustrates the chapter's assertion that "the business rules ARE the code" — in long-lived systems, the code has accumulated responses to edge cases, regulatory changes, and production incidents that exist nowhere else. Extracting them completely is effectively impossible for large codebases.

12. What distinguishes the Replatform strategy from Rehost?

a) Replatform is cheaper than rehost b) Replatform involves architectural changes during the platform move, while rehost makes minimal code changes c) Replatform keeps the application on the mainframe d) Replatform uses automated conversion tools while rehost uses manual rewriting

Answer: b) Replatform involves architectural changes during the platform move, while rehost makes minimal code changes

Explanation: Both strategies involve moving the application to a new platform. Rehost ("lift and shift") moves the code with minimal changes — the COBOL runs on a compatible runtime on the new platform. Replatform ("move and improve") combines the platform change with architectural improvements: CICS might be replaced with a different transaction manager, DB2 for z/OS might migrate to PostgreSQL, the batch framework might change from JCL/JES to a cloud-native scheduler. The risk of replatform is higher because you're changing more things simultaneously, but the potential benefit is also higher because you're not just moving — you're improving.

13. According to the three-horizon roadmap, which activities belong in Horizon 1 (0-12 months)?

a) Complete IMS-to-DB2 migrations and implement strangler fig pattern b) Retire dead applications, expose top APIs, establish CI/CD toolchain, begin knowledge capture c) Design the long-term hybrid architecture and build the next-generation workforce d) Execute all replatform and replace initiatives

Answer: b) Retire dead applications, expose top APIs, establish CI/CD toolchain, begin knowledge capture

Explanation: Horizon 1 focuses on quick wins and foundation: retiring dead applications (immediate MIPS savings), exposing the 10-20 highest-value transactions as APIs (immediate business value), establishing the modernization toolchain (Git, CI/CD, automated testing), implementing portfolio management tooling, and beginning knowledge capture from retiring SMEs. These activities deliver visible results quickly, build political support for continued investment, and establish the infrastructure needed for the strategic modernization in Horizons 2 and 3. Strategic IMS-to-DB2 migration, strangler fig implementation, and hybrid architecture design belong in Horizons 2 and 3.

14. What is the fundamental reason that big-bang replacement of core mainframe systems has a catastrophic failure rate?

a) The replacement technologies are immature b) Modern developers can't learn mainframe business domains c) The requirements for the new system are derived by examining the old system, making the requirements inherently incomplete d) Big-bang projects always go over budget regardless of domain

Answer: c) The requirements for the new system are derived by examining the old system, making the requirements inherently incomplete

Explanation: Core mainframe systems encode decades of accumulated business logic — not just the rules that were deliberately designed, but also responses to edge cases, regulatory changes, production incidents, and workarounds that nobody documented. When the requirements for the replacement are derived by examining the old system, the requirements document is always incomplete because many behaviors exist only in the code. The edge cases surface in production. The data migration is always harder than expected. This is why the chapter argues that for systems over 500K LOC with unclear requirements, replacement should not proceed until the requirements are independently verified — and for truly large systems, they never can be.

15. Which of the following statements about the mainframe cost structure is correct?

a) Hardware is the largest cost component at 45-60% b) Software licensing (MIPS-based) is the largest cost component at 45-60% c) People costs are the largest component at 45-60% d) Facilities (power, cooling) are the largest component at 35-50%

Answer: b) Software licensing (MIPS-based) is the largest cost component at 45-60%

Explanation: Mainframe cost is dominated by software licensing, which is priced based on MIPS (Millions of Instructions Per Second) consumption. IBM z/OS, DB2, CICS, MQ, and third-party tools all have MIPS-based licensing. This is the number that drives the "mainframe is expensive" narrative and the one that CFOs fixate on. Hardware costs (15-25%), people costs (15-25%), facilities (5-10%), and network (2-5%) are all significant but secondary. The practical implication: every MIPS you save through optimization or retirement directly reduces the largest cost component.

Section 2: Scenario-Based Questions

16. A CTO tells you: "We need to get off COBOL within 3 years. Our mainframe costs $30 million per year and the cloud team says we can run it for $10 million on AWS." Using the framework from this chapter, identify three critical questions you would ask before accepting this analysis.

Answer: Three critical questions:

  1. **"Does the $10M cloud estimate include parallel running costs?"** During migration, both the mainframe and cloud environments must run simultaneously. At $30M/year for the mainframe, even a 12-month overlap adds $30M to the cloud option's total cost. If migration takes 3 years (common for large portfolios), the overlap cost is $90M.

  2. "What z/OS capabilities does the cloud estimate account for replacing?" WLM-based workload management, Parallel Sysplex availability, GDPS disaster recovery, coupling facility-based data sharing, and CICS transaction management don't exist on AWS. Building equivalent capabilities requires additional investment — often $5-15M in tooling, architecture, and operational procedures.

  3. "What does 'get off COBOL' mean in business terms?" "Get off COBOL" is a technology statement, not a business goal. The right question is: "What can't the business do today that it needs to do?" If the answer is "serve mobile customers via APIs," that can be done for $5M by wrapping CICS services with z/OS Connect — no platform change required. If there's no business goal beyond cost reduction, the TCO analysis must be complete and honest before proceeding.

17. You've been asked to evaluate two competing modernization proposals for a government payroll system (8M LOC COBOL, 4,200 MIPS, 500K employees paid biweekly):

Proposal A: Automated COBOL-to-Java conversion, 24-month timeline, $65M Proposal B: Incremental refactoring on z/OS with API exposure, 48-month timeline, $35M

Which proposal do you recommend and why?

Answer: Proposal B (incremental refactoring) is strongly recommended.

Rationale: - Risk: A government payroll system paying 500K employees biweekly is mission-critical — any failure means real people don't get paid. Proposal A's automated conversion creates a single catastrophic risk point: a cutover from old system to converted system. Proposal B's incremental approach means the production system remains stable throughout. - Quality: Automated COBOL-to-Java conversion produces "COBOL in a Java costume" (Section 32.2) — syntactically Java but architecturally COBOL. No Java developer will want to maintain it. Proposal B keeps the COBOL (which works) and adds modern interfaces. - Hidden costs in Proposal A: The $65M likely excludes parallel running ($4,200 MIPS x $5K/MIPS x 2 years overlap = $42M), data migration, regression testing at scale (500K employees, thousands of pay rules), and post-conversion performance tuning. Realistic cost: $120-150M. - Business value delivery: Proposal A delivers zero business value until cutover in month 24. Proposal B delivers API endpoints and developer productivity improvements starting in month 3-6. - Precedent: Queensland Health's payroll replacement (8K LOC replacement that failed catastrophically) is a direct cautionary tale for Proposal A.

18. Your modernization team discovers that 23 critical programs at your organization depend on the knowledge of a single developer who is retiring in 14 months. Using the concepts from this chapter, describe a mitigation plan.

Answer: This is a "knowledge is retiring" emergency (Theme 4). The mitigation plan has four tracks:

  1. Immediate knowledge capture (Months 1-3): Pair the retiring developer with 2-3 junior developers on every maintenance task. Record screen-sharing sessions of the retiring developer explaining each program's business logic, edge cases, and "tribal knowledge." Use AI-assisted code analysis tools (Chapter 35 preview) to generate documentation from the code.

  2. Prioritized documentation (Months 1-6): Rank the 23 programs by business criticality. For the top 10, create full documentation: business rules, data flows, dependency maps, common failure modes, and operational procedures. The retiring developer reviews and corrects every document.

  3. Automated testing (Months 3-10): Build regression test suites for all 23 programs. The retiring developer defines the test cases (they know the edge cases). Once tests exist, the programs can be maintained and modified with confidence even after the SME departs.

  4. Refactoring for clarity (Months 6-14): For the most complex programs, refactor to improve readability — better paragraph names, eliminate dead code, add inline comments explaining business logic. The retiring developer validates that refactored code produces identical results.

Timeline critical path: Knowledge capture and test creation must complete before Month 14. Documentation and refactoring are valuable but secondary to ensuring someone else can maintain the code.

19. An insurance company has completed their portfolio assessment and found the following distribution:

  • 40% Retire candidates
  • 30% Retain candidates
  • 20% Refactor candidates
  • 7% Replatform candidates
  • 3% Replace candidates

The CFO is disappointed: "I thought this modernization project would get us off the mainframe. 30% Retain means 30% stays exactly as-is." How do you respond?

Answer: The response should reframe the conversation around business value:

"The goal isn't getting off the mainframe — the goal is making our technology serve the business better. Here's what this assessment delivers:

  1. 40% retirement saves $X million per year in MIPS licensing — effective immediately. That's the highest-ROI activity in the entire modernization program.

  2. 30% Retain doesn't mean 'unchanged.' It means these applications work correctly, meet business needs, and don't need expensive modification. Leaving them alone is the smart decision — spending money to move working software to a new platform creates risk without business benefit.

  3. 20% Refactor means modernizing on the mainframe — API access for mobile/web consumers, CI/CD pipelines for faster delivery, automated testing for quality. The business gets modern capabilities without the risk and cost of platform migration.

  4. 7% Replatform + 3% Replace is the RIGHT amount of platform change — targeted at applications where the mainframe genuinely isn't the right platform. This is surgical, not a sledgehammer.

  5. Total MIPS reduction from retirement + refactoring optimization: estimated 40-50%. That translates directly to licensing cost savings.

The alternative — migrating everything to cloud — would cost 3-5x more, take twice as long, and carry significant risk of business disruption. This plan maximizes value and minimizes risk."

20. You are reviewing a modernization roadmap that has no quick wins in the first 6 months — the first deliverable is a "comprehensive architecture blueprint" at Month 8. What risks does this create, and how would you restructure the roadmap?

Answer: This roadmap has a fatal flaw: 8 months without visible results.

Risks: 1. Executive support erosion: A new CIO, a budget cut, or a competing initiative could kill the project before it delivers anything. Eight months of "planning" looks like eight months of nothing to executives. 2. Team morale decline: Modernization teams need early wins to maintain energy and belief that the project will succeed. 3. No feedback loop: Eight months of design without production validation means the architecture blueprint may be based on incorrect assumptions. 4. Political vulnerability: Opponents of modernization (they always exist) have eight months to build the case for cancellation.

Restructured roadmap: - Month 1-2: Portfolio inventory and dead code identification (deliverable: retire X batch jobs, save $Y in MIPS) - Month 2-4: First API endpoint (expose highest-value CICS transaction via z/OS Connect; deliverable: working REST API in production) - Month 3-5: Developer tooling modernization (Git, VS Code, Zowe CLI; deliverable: development team using modern tools) - Month 4-6: Automated testing framework for top 20 programs (deliverable: regression test suite catching bugs) - Month 6-8: Architecture blueprint (informed by 6 months of real-world modernization experience, not theory)

The blueprint still gets done — but it's informed by production experience, and the project has already delivered four tangible wins.