IBM watsonx Mainframe Modernization Architect

Rehosting, refactoring, rewriting, replacing and retaining are different bets with different risks. You learn to pick among them, why incremental approaches usually win, and where a code assistant helps and where people must decide.

• Rehost, refactor, rewrite, replace and retain
• Incremental modernization and the strangler approach
• Business drivers and technical risks
• What watsonx Code Assistant for Z does in a modernization effort
• Where AI assistance helps and where it misleads
• Defining success for a modernization program

You build A strategy note that picks an approach for three applications and explains each choice.

An assistant is only useful if it is installed and connected properly. You learn the main components of watsonx Code Assistant for Z, where each runs, how they reach z/OS and source code, and what you configure to deploy them.

• The main components and what each one does
• What runs on Z and what runs elsewhere
• Connecting to z/OS and source repositories
• Configuring components for a deployment
• Security and access for the assistant
• Planning environments for a modernization project

You build A deployment architecture diagram for the assistant in one organization’s environment.

An architect needs to read the code even without writing it daily. You learn how COBOL programs are structured, how data is defined, how control flows, and where files, databases and transactions appear.

• Divisions and program structure
• Data definitions and PICTURE clauses
• Paragraphs, PERFORM and control flow
• File handling and embedded SQL
• CICS commands in online programs
• Copybooks and shared data layouts

You build An annotated walkthrough of one program’s structure and data flow.

Nobody can safely change what they do not understand. You inventory programs, jobs and data, build dependency and call maps, find unused code, and surface the business rules buried in the logic.

• Inventorying programs, jobs and datasets
• Call graphs and dependency maps
• Data flows between jobs and online programs
• Finding dead code and duplicated logic
• Complexity measures and what they suggest
• Surfacing business rules

You build A dependency map and complexity report for one application.

Generated explanations speed up understanding when you can trust them. You use the assistant to explain programs and rules, check those explanations against the code, and turn them into documentation others can use.

• Generating explanations of programs and sections
• Checking an explanation against the source
• Capturing business rules in plain language
• Producing documentation from explanations
• Where generated explanations go wrong
• Reviewing explanations with the people who know the system

You build Verified documentation for one program, with each explanation checked against the code.

A monolith has to be cut along natural lines before it can be moved. You clean and improve code, find seams where it can be split, and restructure it into modular business services with clear interfaces.

• Removing dead code and simplifying logic
• Finding seams for service boundaries
• Untangling shared data and copybooks
• Restructuring into modular components
• Defining interfaces between the pieces
• Sequencing the pieces for modernization

You build A modular decomposition of one application with proposed service boundaries.

Translation is more than syntax. You map data types and decimal arithmetic precisely, convert control flow, review generated Java for structure and style, and keep Java and remaining COBOL working together.

• Mapping COBOL data types to Java
• Packed decimal and exact arithmetic
• Converting control flow and file handling
• Character encoding differences
• Reviewing generated Java for quality
• Calling between Java and COBOL during transition
• Coding standards for generated code

You build A COBOL module converted to Java, with a written review of the generated code.

A conversion is only done when its behavior matches. You capture real inputs and outputs, compare old and new results including edge cases, write tests, and define the evidence needed before a piece is cut over.

• Capturing representative test data
• Comparing outputs of old and new programs
• Rounding, dates and encoding edge cases
• Unit and regression tests for converted code
• Batch output comparison at scale
• Cutover criteria and rollback

You build An equivalence test suite that compares original and converted program output.

Take one application from discovery to a converted, validated module. You document it, split it, convert a piece, prove equivalence and write the plan for the rest, ready for review by those who own the business.

• Discovering and explaining the application
• Choosing and refactoring the first module
• Converting and validating it
• Planning the remaining pieces
• Presenting the plan and its risks

You build A modernization plan backed by one converted and validated module.