ExampleModernizationFinancial Services

Legacy Modernization

From undocumented COBOL to a governed modern application

A financial-services company depends on a 30-year-old mainframe application for account servicing and fee calculation. ASE recovers the application's behavior, connects code to business rules and incrementally modernizes bounded capabilities without a high-risk big-bang rewrite.

Example project. The company, systems and figures are made up.

The situation

Documentation has not kept pace with three decades of change. The people who understand fee calculation are retiring, downstream operations depend on batch file interfaces, and every proposed change carries unquantified risk.

The request

Modernize account servicing and fee calculation into maintainable cloud-ready services without changing customer outcomes or disrupting downstream operations.

Systems involved

  • 1.8 million lines of COBOL
  • 420 batch jobs
  • 1,100 copybooks
  • CICS transactions
  • DB2 tables
  • JCL schedules
  • Downstream file interfaces
  • Limited current documentation

How it runs

Step by step

What ASE does at each stage and who approves it.

DiscoverHuman approval gate

Inputs

  • COBOL source, copybooks and JCL
  • CICS metadata and DB2 schemas
  • Downstream interfaces and existing tests
  • Masked operating evidence

Agent activity

  • Ingest and parse the estate to build dependency graphs and data flows
  • Extract candidate business rules and critical execution paths
  • Produce a risk map of high-impact and ambiguous logic

Human authority

Mainframe engineers and business SMEs validate high-risk rules and select a bounded capability.

Approval criteria: High-risk rules validated and the pilot capability boundary agreed.

Outputs

  • Dependency graph
  • Data-flow model
  • Business-rule inventory
  • Risk map

Traceability created

  • Each recovered rule links to the program, paragraph and copybook it came from

Hand-off: Validated rule inventory scopes the functional recovery.

Output

What ASE produced

Sample outputs from this project. All data is made up.

Dependency graph

Program, copybook, job and table dependencies for the pilot capability.

  • CAPABILITY fee-calculation (pilot boundary)
  • PROGRAMS FEECALC0 → FEETBL01 → FEEACC02 → ACCPOST9
  • COPYBOOKS CPYFEE01 · CPYACC14 · CPYTAX03 (shared with 6 programs)
  • DB2 FEE_SCHED · ACCT_MASTER · TXN_HIST
  • JOBS FEEDLY01 (daily 02:10) · FEEMTH04 (month-end)
  • DOWNSTREAM GL extract file GLX-0042 · statement feed STM-0117
  • in-scope dependencies mapped: 96% (human validated)

Approvals

Where people decide

  • Discover

    Validate high-risk rules and select the bounded capability

    Approved by: Mainframe engineers and business SMEs

  • Define

    Resolve contradictory or unknown behavior

    Approved by: Business SMEs

  • Design

    Approve capability boundaries and coexistence controls

    Approved by: Architecture, security and operations

  • Validate

    Approve equivalence evidence and difference classification

    Approved by: Business and technology owners

  • Deploy

    Authorize each traffic increment

    Approved by: Operations

Solution

What got built

Target architecture

  • ROUTING controlled traffic split · parallel execution · output comparison
  • MODERN fee-calculation service · recovered rule engine · telemetry
  • ACL anti-corruption layer over CICS transactions and copybook records
  • LEGACY COBOL programs · DB2 tables · batch schedules (unchanged)
  • GOVERNANCE behavior-change approval · difference classification · rollback authority

How it traces back

  • FEECALC0 §2100 → rule FEE-WAIVER-03 → spec REQ-CBL-021 → TC-CBL-770 → equivalence run → cutover 7%

Targets

What a pilot would test

Goals to prove in a pilot, not client results.

  • In-scope dependencies mapped

    Modeled pilot target 95% or more with human validation

    Target range depends on system and process complexity

  • Critical fee rules traced to source

    Modeled pilot target 100% for the pilot capability

    Potential outcome to validate

  • Golden-master equivalence

    Modeled pilot target at least 99.9%, with all differences classified

    Potential outcome to validate

  • Production traffic moved

    Modeled pilot target 5–10% controlled pilot

    Target range depends on system and process complexity

Starting points are made up. Real results depend on your systems and processes.

More example projects

ExampleProcessManufacturing

Enterprise Process Transformation

Procure-to-Pay Control Tower

A global manufacturer runs procurement through email, spreadsheets and different ERP workflows across twelve business units.

  • Policy-driven intake
  • Three-way match visibility
  • Exception workflows
  • Audit-ready lineage

DISCOVER · DEFINE · BUILD · OPERATE

ExampleDataCross-industry

Data Intelligence & API Enablement

Enterprise Data Intelligence Fabric

A diversified enterprise holds customer, product, service and commercial data across operational systems, warehouses and files.

  • Source-aware answers
  • Reusable data products
  • Governed APIs
  • End-to-end lineage

DISCOVER · DEFINE · DESIGN · OPERATE

Select one bounded COBOL capability. Build its modernization evidence.

In a guided build, we run your own project through the same steps, with your systems and approval rules.