SYSTEM FOR CONVERTING ANALYSIS OUTPUTS INTO MICROSERVISE TECHNICAL DESIGNS

A system integrates static and dynamic analysis outputs from legacy systems into a machine-readable technical design for modern microservices, addressing the lack of unified documentation in current methods, ensuring compliance and providing detailed transformation guidance.

TR202617537A2Pending Publication Date: 2026-10-21TURKIYE GARANTI BANKASI ANONIM SIRKETI
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
TR202617537
Authority / Receiving Office
TR · TR
Patent Type
Applications
Current Assignee / Owner
Filing Date
2026-10-09
Publication Date
2026-10-21

AI Technical Summary

Technical Problem

Current methods fail to integrate static and dynamic analysis outputs from legacy systems into a unified, machine-verifiable technical design for modern microservice architectures, lacking detailed documentation on component separation, target architecture establishment, and transformation order, leading to inconsistent and passive explanations.

Method used

A system that integrates static and dynamic analysis outputs from mainframes or legacy systems into a modern microservice architecture, producing a verified, machine-readable technical design package, including a graphical user interface for user interaction, and utilizing a server to generate a call context tree, visualize interactions, and produce detailed design packages.

Benefits of technology

Enables the production of a consistent, machine-verifiable technical design for modern microservices, ensuring compliance with institutional standards and providing detailed documentation for transformation, thereby facilitating seamless transition from legacy systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000021_0000
    Figure 00000021_0000
Patent Text Reader

Abstract

This invention relates to a system (1) developed to enable the acquisition of static and / or dynamic analysis outputs for mainframes or other legacy systems and to produce a validated, enterprise-standard compliant and machine-processable deep technical design for transitioning to a modern microservice architecture.
Need to check novelty before this filing date? Find Prior Art

Description

1 TARIFF INTEGRATING ANALYSIS OUTPUTS INTO MICROSERVICE TECHNICAL DESIGNS. CONVERSION SYSTEM Technical Area 5 This invention relates to static and / or older generation systems in mainframes or other legacy systems. obtaining dynamic analysis outputs and transitioning to a modern microservice architecture. Verified, compliant with institutional standards and machinable deep technical It relates to a system that enables the design to be produced. 10 Previous Technique In the current state of the art, the aim is to modernize legacy applications. Static analysis of source code, dynamic runtime analysis, language conversion, from monolith to 15 decomposition into microservices, application programming interface (API) documentation, Security and dependency analysis (SAST / SCA / SBOM), continuous integration and ongoing These include various processes such as delivery / CD verifications and manual architectural reviews. Independent tools and approaches are used. However, the current methods; analysis results are used in separation decisions, contract production, design 20 detailing, verifying architectural standards, dead code risk management, batch conversion planning, and the resulting return a single integrated system for processes related to the use of notifications in subsequent transformations And it does not integrate them into a verifiable technical design package. Specifically Even in systems that identify microservice candidates, subsequent recoding of these candidates is 25 a class or repository at the level of detail that can be used directly during the (re-coding) phase (repository), service, data transfer object (DTO), entity, sequencing diagram (sequence), error handling, asynchronous communication pattern, API / protocol 2 definitions and rollback mechanisms together and consistently It is generally not possible to produce it. Similarly, classical documentation In production approaches, the documents created are mostly based on the existing source code. It remains a passive explanation; which component during modernization Why it will be separated, how the target architecture will be established, and in what order the transformation will take place. 5 how it will be implemented, which architectural rules will be applied, and the resulting design decisions that guide how to verify during the recoding process, a feasible and machine-verifiable technical design output It cannot provide this. Therefore, current solutions are based on the legacy application's existing features. from the analysis of the situation to the design of the target architecture and the validation of this design 10 The end-to-end process, from making it reprogrammable to a single, unified process. It falls short of being able to unify things under a consistent technical output. Therefore, static and / or data relating to mainframes or other legacy systems Obtaining dynamic analysis outputs and transitioning to a modern microservice architecture 15 Verified, compliant with institutional standards and machinable deep technical It appears that a system is needed to enable the production of the design. United States patent number US2021124577, which falls under the prior art. The document discusses microservice design for applications. (Source 20) The subject of the invention is a method for an application to be transformed into a set of microservices. determining the microservices suite by analyzing the application's software code. Identifying numerous functions within it that are potential candidates for combination, By monitoring a running instance of the application, the connections between these functions can be examined. a calling-context tree that defines interactions 25 the creation and at least partial understanding of the defined interactions between functions This involves determining a proposed design for a set of microservices based on this approach. The method also provides a visualization of the generated call context tree. 3 enabling features in the graphical user interface by the user In response, it was suggested that the microservice design be modified and the modified design be implemented. It also involves building a set of microservices, at least in part. Brief Description of the Invention 5 The purpose of this invention is to analyze static data relating to mainframes or other legacy systems. and / or obtaining dynamic analysis outputs and transitioning to a modern microservice architecture. Verified, compliant with institutional standards and machinable deep technical The goal is to implement a system developed to enable the production of the design. 10 Detailed Description of the Invention The "Microservice Technique for Analytical Outputs" developed to achieve the purpose of this invention. The "Design Conversion System" is shown in the attached figure; this figure is 15. Figure 1 shows a schematic view of the system that is the subject of the invention. The parts shown in the figure are individually numbered, and the corresponding numbers correspond to these numbers. given below. 20 1. System 2. Application 3. Database 4. Server 25 Static and / or dynamic analysis of mainframes or other legacy systems. obtaining the outputs and validating them for the transition to a modern microservice architecture, 4 deep technical design that complies with institutional standards and is machinable The system in question, developed to enable its production (1); - including user interface, the interface can be a web-based screen, desktop application, command-line interface or integrated into an in-house software development platform enabling screen access, allowing authorized users to access the stream, uploading analysis output, 5 to initiate the analysis processes, to review the proposed microservice candidates, to view the verification results and download the generated technical design packages and The user can view the service inventory and data ownership matrix generated in the workflow via the interface. inter-service dependencies, event flows, contract files, complexity scores, dead code reports, bulk job transformation plans, and in-depth technical design 10 at least one application configured to allow viewing of documents (2), - raw analysis outputs, normalized analysis data, generated information graph, microservice candidates, service inventory, service dependencies, data ownership information, events flows, interface conventions, validation results, design outputs, batch processing 15 conversion plans, dead code reports, complexity scores, risk scores, and evidence. structured to ensure that data in the form of packets is kept on record. at least one database (3), -a physical device containing one or more processors, memory, storage units, and network connections. or being able to be a virtual computer system, analysis, transformation, verification, design 20 the execution of production and reporting processes, in the sense of the main computer. from mainframe systems or legacy systems in the sense of old technology systems processing the obtained analysis outputs, and converting these outputs into a modern microservice architecture. the production of suitable technical design packages and the use of the produced design package only 25 It includes at least one configured server (4). The application (2) in the system (1) which is the subject of the invention does not require any communication protocol. to communicate with the server (4) and exchange data using It is structured. The application (2) is in a preferred arrangement of the invention, User approval for proposed microservice boundaries or transformation patterns. 5. Ensuring that the results are retrieved and approved and written back to the pattern library. It is structured accordingly. The database (3) in the system (1) which is the subject of the invention does not use any communication protocol. to communicate with the server (4) and exchange data using is structured. The database (3) contains 10 approved or successful conversion results. The resulting modularization templates, replatforming templates, and in-depth registration of reusable transformation templates in the form of technical design templates It is structured to ensure that the invention is kept under control. The database (3) ensures the preference of the invention. In one of the arrangements made, relational database, graph database, document-based database being a base or a hybrid structure using a combination of these, and graph database 15 If used, programs, procedures, data assets, batch processing jobs, Timers, processes, files, tables, screens, and application programming. the ability to store data in the form of interfaces as nodes and the connections between these nodes edge relationships of call, dependency, data access, peer exchange, ownership and timing. It is structured to enable it to be stored as such. 20 The server (4) in the system (1) which is the subject of the invention, any communication protocol to communicate and exchange data with the application (2) and the database (3) using It is configured to perform. Server (4), host analysis tool 25 of the raw outputs produced by or another legacy analysis tool the process of integrating it into the workflow and analyzing the outputs using source code, call relationships, program lists, Procedural information, file access, table relationships, transaction logs, screen relationships, bulk batch jobs can have scheduler dependencies and job rule declarations. 6 It is configured to provide the server (4), from different analysis tools. JavaScript Object Notation, or JSON, which stands for JavaScript object representation, Yet Another Markup Language, that is, a human-readable data markup language. YAML stands for Comma Separated Values. CSV stands for Extensible Markup Language. file formats such as XML or table-based files are accepted. and the source of the data received, the time of production, the scope of analysis, and any missing information should be examined. to enable the determination of their areas and reliability levels It is configured. The server (4) receives raw analysis outputs in different formats. converting the fields into a common data model, marking missing fields, 10 separating conflicting records, records from different sources belonging to the same entity unification and standardization of resource definitions, information produced The graph should represent the technical and functional structure of the legacy system, within the graph program, procedure, data entity, table, file, screen, process, batch job Timer, application programming interface, and business concept nodes 15 enabling the exchange of data between systems via application programming interfaces (APIs). making a transaction call, call relationship of edges in the information graph, data access relationship, file usage relationship, transaction relationship, batch dependency, scheduler technical terms such as relationship, business concept relationship, data ownership relationship and service dependency It shows the connections and performs microservice decomposition, solution model generation, and deep 20 to be used as a shared reality layer for technical design creation processes It is configured to provide. The server (4) works on the information graph. which microservice candidates monolithic or legacy structures can be divided into the determination of Domain Driven Design (DDD) using the principles to identify bounded context candidates 25 and the limited context ensures consistency in data, behavior, and rules within a specific business area. It is structured to allow the server to express the boundary within which they are considered together. (4), call graph, co-exchange signals, data ownership, transaction limits, batch 7 dependencies, signals in the form of intra-service cohesion and inter-service cohesion together, considering both inbound and outbound coupling (efferent coupling) measurements of the relationship of a candidate service with other services. It can be used to show density, and the same applies to cohesion measurement. 5. Showing how related the functions grouped within the service are to each other. Not only is a candidate service list generated, but also which microservice candidate each one has? related to program, procedure, data entity, transaction, batch job and the concept of work. the calculation of this and the technical justification of the proposed microservice boundary It is configured to enable monitoring. Server (4), Transforming the candidates into a structural and machinable solution model, solution 10 The model includes service inventory, inter-service dependencies, data ownership matrix, and events. flows, service contract candidates, data reading and writing responsibilities, transactions Finding boundaries, batch trigger relationships, and replatform decisions, and to ensure the solution model is used as a common input is structured. Server (4) 15 of the generated solution model and technical design outputs naming standards, versioning rules, field validation rules, backward compliance rules, security rules, data ownership rules, dependency rules, and Checking compliance with enterprise architecture rules in the form of technology stack constraints. ensuring backward compatibility with the newly created service or contract structure to be able to operate without harming consumers, domain verification with contract or data 20 compliance of fields with type, length, requirement, value range and format rules determining, generating error, warning and pass statuses as a result of verification, The design package should not be considered ready for production until the errors are corrected, and integrated with the relevant institution's existing architectural rule repository or security rule repository It is structured to enable transactions to be carried out in this way. 25 Server (4) selects the service contract candidates included in the solution model from among the machine-based readable, OpenAPI Specification, which is the Open Application Programming Interface. Specifications, Protocol Buffers, AsyncAPI Specification 8 asynchronous application programming interface specification or as defined by the institution generating interface contracts in another format and during contract generation relevant institution's naming, versioning, domain validation and backward compatibility It is configured to ensure the application of the rules. The server (4), produced microservice candidates, cyclic complexity, inbound dependency, outbound dependency, 5 cohesion, meaning intra-service compatibility, Lack of Cohesion of Methods, meaning compatibility of methods. LCOM stands for "lack of code," and LOC stands for "lines of code." Technical metrics such as endpoint number, dependency depth, and data sharing. scoring based on the data, generating a risk score for each microservice candidate, high Risky services should first maintain their current behavior by modifying the code or design structure. services that need improvement (refactoring) or more careful design it should be marked as such and the risk score should not be used solely for reporting purposes, recalculating the microservice boundaries, updating the solution model, tightening the verification gates or deepening technical design production It is structured to enable the generation of detailed output. 15 Server (4) is no longer used in the legacy system or is inaccessible under certain conditions. Identifying code blocks, procedures that are never called are considered definitively dead code, Procedures that only receive calls through testing or outdated working methods are potentially dead. In code, a branch that cannot be executed conditionally. the ability to classify blocks as conditionally dead code, conditional branching dead code 20 a piece of code that doesn't work because a specific condition is never met expressing it, generating a removal risk for each code block, and the relevant removal risk batch flows of the code block, transaction relationships, data access, external system calls or calculated according to its connection with user screens and the design package 25 codes that cannot be transferred to the modern system and codes that need to be carefully examined It is configured to enable separation. Server (4), mainframe Java Control Language (JCL) definitions in systems, Batch job definitions, scheduler dependencies, and job chains 9 analyze, generate a job dependency graph, job dependency The graph determines which batch of jobs should run before or after which other jobs. which file or table it created, which data entity it consumed, and in what error condition It should show which return scenario to apply, legacy batch flows to cron. scheduling based on timing, event-driven triggering, hybrid triggering, timer service, or 5 Proposing modern equivalents in the form of a modern batch processing framework, and then reversing it. (rollback) scenario generated and rollback scenario conversion failed. how to revert to the old batch order or the previous safe working order when this happens It is configured to enable the server (4) to explain that it will be returned. Model and production-ready technical design package 10 based on verified contracts its production, unlike the high-level architectural proposal of the package in question can be used directly by the developer or re-encode module detailed preparation, including a class diagram and sequencing diagram within the produced design, Data access layer, business service layer, data transfer object (DTO), entity. object, DTO and entity mapping design, error handling strategy, transaction management design, 15 asynchronous publisher (event publishing component) and consumer (event consuming component) the design allows for finding, DTO and entity mapping structure in MapStruct form. It should be able to be produced in a way that is compatible with libraries and Lombok-style code. Compatibility with simplification libraries is a preferred output feature. It is configured to enable its creation. Server (4), approved or 20 saving the results of the successfully implemented transformation and subsequent design making them reusable in their production, modularization technical solution templates, replatforming templates, microservice technical design templates, batch conversion templates, service contract templates, and data Storing ownership templates, each template belonging to a specific legacy graph signature (25) where it was produced, which service limit it matches, which institutional rules it complies with, which with the information that it received the verification results and in which conversion it was successfully used. keeping them together, feedback technique, human approval or production In its transformation, success is measured by the preservation of outputs and similar to mainframe or legacy. previously validated transformation patterns in their structures, either as a suggestion or an initial step. It is configured to enable it to be used as a point. Server (4), all critical decisions and outputs produced must be packaged and proven in an auditable manner. which raw analysis output of the package was used, which 5 during normalization how the records are merged, and which signals determine the microservice boundaries, which institutional rules were applied, which verification results were produced, and to ensure it includes which design artifacts were created It is configured. Server (4), service inventory report, data ownership matrix, service dependency report, event flow report, complexity report, dead code report, batch 10 conversion report, rollback report, verification report and final technical design package It is configured to enable its production. Server (4), internal or external exchanging data with tools and legacy analysis tools, architectural rule stores, source code repositories, contract repositories, document repositories, recoding modules, establishing connections with software development pipelines and approval mechanisms and 15 It is configured to facilitate the execution of integration processes. Server (4), in a preferred arrangement of the invention, Model Context in integration processes The Model Context Protocol (MCP) enables operations with compatible tools. the implementation, model-based workflow with MCP using different tools and data sources connecting to the streams and the generated contracts, design files, validation 20 results and evidence packages into document management systems or development pipelines It is structured to enable the transfer of data. Industrial Applicability Thanks to the system (1) that is the subject of the invention, mainframes or other legacy systems can be accessed Obtaining static and / or dynamic analysis outputs related to and modern microservices 11 Verified for transition to its architecture, compliant with corporate standards and machine-controlled. This enables the production of a workable, in-depth technical design. Based on these fundamental concepts, the invention focuses on "Analysis Outputs Microservice Techniques". 5 various applications related to the "Design Transformation System (1)" It is possible to develop it further, and the invention cannot be limited to the examples described here; the main point is... as stated in the requests.

Claims

12 REQUESTS 1. Static and / or dynamic data relating to mainframes or other legacy systems. obtaining analysis outputs and transitioning to a modern microservice architecture. Verified, compliant with institutional standards and machinable deep 5 enabling the production of technical design; - to include a user interface, the interface being a web-based screen, desktop application, command-line interface or in-house software development the ability to have a screen integrated into the platform, authorized user access to the flow access, upload analysis output, initiate analysis processes, suggested 10 review microservice candidates, see validation results, and download the generated technical design packages and through the user interface service inventory generated in the flow, data ownership matrix, inter-service dependencies, event flows, contract files, complexity scores, dead code reports, aggregate business transformation plans, and in-depth technical design 15 at least one configured to enable viewing of documents application (2) includes and - raw analysis outputs, normalized analysis data, generated information graph, microservice candidates, service inventory, service dependencies, data ownership information, event flows, interface conventions, validation results, design 20 outputs, batch process transformation plans, dead code reports, complexity scores, keeping records of data in the form of risk scores and evidence packages at least one database configured to provide (3), - containing one or more processors, memory, storage units, and network connections being a physical or virtual computer system, analysis, transformation, 25 The main tasks include executing verification, design production, and reporting processes. mainframe systems or older technology systems in the sense of computers processing of analysis outputs obtained from legacy systems, in this sense, 13 Technical design packages suitable for modern microservice architecture derived from the outputs. and that the design package produced is not just a visual suggestion designed to ensure that it consists of machine-processable content. a system characterized by a small server (4) (1).

2. To communicate with the server (4) using any communication protocol and The application is characterized by (2) which is structured to perform data exchange. A system like the one in Request 1 (1).

3. In a preferred arrangement of the invention, the proposed microservice boundaries or 10 User approval must be obtained for conversion patterns and approved. configured to ensure the results are written back to the pattern library A system (1) such as in Claim 1 or 2, characterized by application (2).

4. To communicate with the server (4) using any communication protocol and 15 with the database (3) configured to carry out data exchange a system like any of the above characterized demands (1).

5. Modularization derived from approved or successful conversion results. templates, replatforming templates and deep technical design templates 20 reusable conversion templates in this form are registered. characterized by the database structured to ensure its retention (3) a system like any of the above requests (1).

6. In a preferred arrangement of the invention, the relational database, graph database, 25 a document-based database or a hybrid structure using both. and if a graph database is used, programs, procedures, data assets, Batch jobs, timers, processes, files, tables, screens, and Data in the form of application programming interfaces as nodes 14 the ability to maintain and manage calls, dependencies, data access, and peer-to-peer relationships between these nodes. the ability to preserve the edges of change, ownership, and timing relationships The above is characterized by the database (3) structured to provide a system like any of the requests (1).

7. Using any communication protocol, application (2) and database (3) structured to communicate and exchange data as in any of the above requests characterized by the server (4) a system (1).

8. By a mainframe analytics tool or another legacy analytics tool. The process of taking the raw outputs produced by the system into the stream and converting the outputs into source code. analyses, call relationships, program lists, procedural information, file access, table relationships, transaction logs, screen relationships, batch processing operations, Enabling timer dependencies and business rule declarations is key. 15 the above requests are characterized by the server (4) configured to be so. a system like any other (1).

9. JavaScript Object Notation derived from various analytics tools, i.e., JavaScript JSON, meaning Object Representation, is Yet Another Markup Language, meaning human 20 YAML, which stands for Data Markup Readable by Comma CSV, which stands for Separated Values, is Extensible. XML, which stands for Markup Language, or Extensible Markup Language. the acceptance of file formats in the form of table-based files and the received the source of the data, the time of production, the scope of the analysis, any missing fields, and 25 server configured to enable the determination of reliability level (4) like any of the above-mentioned claims characterized by system (1).

10. Fields in raw analysis outputs received in different formats share a common data point. converting to a model, marking missing fields, identifying conflicting records separation of records from different sources belonging to the same entity unification and standardization of resource definitions, produced The information graph should represent the technical and functional structure of the legacy system, graph 5. Includes program, procedure, data entity, table, file, screen, operation, batch operation. job (batch job), timer, application programming interface, and the concept of a job. enabling nodes to be found via application programming interface (API) making data and operation calls between systems, edges in the information graph call relationship, data access relationship, file usage relationship, transaction 10 relationship, batch dependency, timer relationship, business concept relationship, data ownership It shows technical connections such as relationship and service dependency, and microservices. The processes of decomposition, generating a solution model, and creating in-depth technical designs. to enable its use as a shared reality layer Any of the above requests characterized by the configured server (4) 15 a system like one of them (1).

11. By working on an information graph, identify which structures are monolithic or legacy. Determining that it can be allocated to microservice candidates, Domain Driven Using DDD principles, which stand for area-oriented design, 20 Identifying bounded context candidates and the bounded context data, behaviors, and rules in a specific business area are considered consistently together. The server (4) is configured to express the limit that was received. a system like any of the above characterized demands (1).

12. Call graph, co-existing change signals, data ownership, transaction limits, batch dependencies in the form of intra-service cohesion and inter-service cohesion. the combined evaluation of signals, inferential coupling, and efferent coupling measurements of one candidate service to another 16 It can be used to show the intensity of the relationship with services, compliance cohesion is the measurement of how well functions grouped within the same service interact with each other. It shows that there is a relationship, not only is a candidate service list generated, but also the same At the same time, which program, procedure, data asset, each microservice candidate It should be calculated that it is related to the concepts of transaction, batch job and work, and 5 Making the technical rationale for the proposed microservice boundary traceable. The above is characterized by the server (4) configured to provide a system like any of the requests (1).

13. Candidates must develop a structural and machinable solution model of 10. transformation, service inventory within the solution model, inter-service dependencies, data ownership matrix, event flows, service contract candidates, data read and write responsibilities, transaction boundaries, batch trigger relationships and finding replatforming decisions and a common input for the solution model 15 characterized by the server (4) configured to enable its use as a system like any of the above-mentioned requests (1).

14. Naming standards for the generated solution model and technical design outputs, Version control rules, domain validation rules, backward compatibility rules, security rules, data ownership rules, dependency rules and technology 20 Checking compliance with organizational architectural rules in the form of stack constraints. ensuring backward compatibility with the newly created service or contract structure. to be able to operate without disrupting previous consumers, through domain verification or contract. type, length, requirement, value range, and format rules of data fields determining suitability, errors, warnings and valid 25 as a result of verification. the production of the states, the design package cannot be ready for production until the errors are corrected. not to be accepted as and the relevant institution's existing architectural rulebook or enabling transactions to be carried out in an integrated manner with the security rule repository. 17 The above is characterized by the server (4) configured to provide a system like any of the requests (1).

15. Among the service contract candidates included in the solution model, those that are machine-readable, The OpenAPI Specification, or Open Application Programming Interface Specification, 5 Protocol buffers, also known as AsyncAPI Specifications, asynchronous application programming interface specification or by the institution the generation of interface agreements in another specified format and the contract during its production, the relevant institution's naming, versioning, domain validation and 10 structured to ensure the application of backward compatibility rules as in any of the above requests characterized by the server (4) a system (1).

16. Cyclic complexity, incoming dependency, of the generated microservice candidates, Outgoing dependency, cohesion (i.e., intra-service compatibility), Lack of Cohesion of Methods 15 LCOM, meaning lack of method compatibility, refers to Lines of Code. LOC stands for number of rows, number of endpoints, dependency depth, and data. scoring based on technical metrics such as sharing, for each microservice Generating a risk score for the candidate, prioritizing high-risk services first. 20 where code or design structure needs to be improved while preserving the behavior. (refactor) or services that need to be designed more carefully. the marking and risk score should not be used solely for reporting purposes, recalculating the microservice boundaries, the solution model updating, tightening verification gates, or deep technical 25 The above is characterized by the server (4) configured to provide a system like any of the requests (1). 18 17. Legacy system code that is no longer used or is inaccessible under certain conditions. Identifying blocks, procedures that are never called are considered definitively dead code, only procedures that receive calls via test or legacy working methods Potentially dead code, meaning it's not possible to run under certain conditions. The ability to classify branch blocks as conditionally dead code, 5 Conditional branch dead code means that a specific condition will never be met. It refers to the piece of code that doesn't work because it didn't happen, each code generating a removal risk for the block, the removal risk of the relevant code block batch flows, transaction relationships, data accesses, external system calls, or Calculations based on user screen connectivity and design package 10 codes that cannot be transferred to the modern system and require careful examination the server (4) configured to enable the separation of codes a system like any of the above characterized demands (1).

18. Java Control Language (JPL), or business control language, in mainframe systems. 15 JCL definitions, batch job definitions, and schedulers are all related to this meaning. analysis of dependencies and work chains, job dependency graph (job (dependency graph) generation, which batch job belongs to which job in the job dependency graph whether it needs to work before or after work, which file or table it produced, which data asset it consumed and which return value it sends in case of error 20 It shows that the scenario will be implemented, legacy batch flows will be cron scheduling based on timing, event-driven triggering, hybrid triggering, timer modern equivalents in the form of service or modern batch processing framework the proposal, the creation of a rollback scenario and the rollback If the conversion fails, revert to the old batch order or the previous 25 to provide an explanation of how to return to a safe working environment any of the above requests characterized by the configured server (4) a system like one of them (1). 19 19. Solution model and production-ready technology based on verified contracts. the production of a design package, the high-level architecture of said package unlike the suggestion, by the developer or re-coding module It should be prepared in a level of detail that can be used directly, and the design produced should be classified within the class. diagram, sequencing diagram, data access layer, business service layer, data 5 Transfer object (DTO), entity object, DTO and entity mapping. design, error handling strategy, process management design, asynchronous publisher (event publishing component) and consumer (event consuming component) design the ability to find them, DTO and entity mapping structure in MapStruct form It should be able to be produced in a way that is compatible with libraries and the Lombok-shaped 10 Compatibility with code simplification libraries is a preferred output feature. characterized by the server (4) configured to enable its creation. a system like any of the above-mentioned requests (1).

20. Storing the results of approved or successfully implemented conversions. 15 and making it reusable in subsequent design and production processes, modularization of technical solution templates, replatforming templates, microservice technical design templates, batch conversion templates, service agreement templates, and data ownership templates the preservation of which legacy graph signature each template was generated from, and which 20 It matched the service limit, which institutional rules it exceeded, and which verification process it followed. along with information on the results obtained and in which transformation it was successfully used. retention, feedback technique, human-approved or production In its transformation, success is measured by the storage of outputs and similar mainframes or In legacy structures, previously validated transformation patterns are suggested or 25 configured to allow it to be used as a starting point as in any of the above requests characterized by the server (4) a system (1).

21. Ensuring that all critical decisions and outputs produced are packaged in an auditable manner. and which raw analysis output from the evidence package was used, normalization which records were merged during the process, what are the microservice boundaries that it is determined by signals, which institutional rules are applied, which verification results were generated and which design artifacts were present in the 5 the server configured to include the creation of (4) a system like any of the above characterized demands (1).

22. Service inventory report, data ownership matrix, service dependency report, event. flow report, complexity report, dead code report, batch conversion report, back 10 Production of the acquisition report, verification report and final technical design package The above is characterized by the server (4) configured to provide a system like any of the requests (1).

23. Data exchange with internal or external tools and legacy analysis 15 tools, architectural rule repositories, source code repositories, contract repositories, documentation repositories, recoding modules, software development pipelines, and approvals. establishing connections with mechanisms and integration processes characterized by the server (4) configured to enable its execution a system like any of the above requests (1). 20 24. Model in integration processes in a preferred arrangement of the invention. Context Protocol (MCP), or Model Context Protocol, compatible tools. performing operations, using MCP with different tools and data sources connecting to model-based workflows and the contracts generated, design 25 document management of files, verification results and evidence packages to ensure that it is transferred to their systems or development pipeline any of the above requests characterized by the configured server (4) a system like one of them (1).