Minha experiência em modernização de Mainframe para um grande banco dos EUA (Bhasheer Lepakshi)

Histórico da modernização do Mainframe:

      Depois que a revolução do computador começou no setor bancário, de seguros e em outros setores importantes, o Mainframe foi uma das maiores revoluções para armazenar e gerenciar dados de maneira mais segura. Mesmo agora, muitos grandes bancos e seguradoras ainda mantêm o sistema Mainframe.

      Com o passar do tempo, muitas mudanças tecnológicas ocorreram, e o mundo se tornou mais digital, e os usuários/clientes desejam acessar dados em frações de segundos e não há tempo para entrar no modo tradicional de bancos e outros serviços. Assim, os bancos e outras indústrias são forçados a se mover para o caminho digital.

 Neste mundo digital rápido para acessar dados de sistemas legados como Mainframe, torna-se difícil fornecer serviços rápidos aos clientes, então os clientes estão procurando a modernização.

As principais iniciativas a serem seguidas para a modernização do Mainframe são:

1. Reengenharia: transformação disruptiva para plataformas digitais como nuvem e micro serviços
2. Re-Hosting: Re-platforming de aplicativos qualificados para a plataforma distribuída, mantendo a arquitetura e o código herdados
3. Modernização no local: aproveite os recursos de modernização do System ze System I com uma combinação certa no Legacy
4. Substitua: Substitua a aplicação por um produto COTS adequado após fazer uma análise completa da instalação​

Este blog descreve sobre o cenário de Reengenharia. Neste cenário, precisamos extrair as regras de negócios do código legado que a equipe de engenharia avançada será usada como documento de requisitos:

Como converter o código do Mainframe em Regras de Negócio?

1. Preparação do Modelo:

     Sempre que iniciamos qualquer conversão de legado, o primeiro maior desafio é entender a lógica de negócios existente e trazê-la para o formato adequado que a equipe de engenharia avançada possa entender e criar sua maneira de codificação.

O modelo é a chave para reunir as regras de negócios, se o modelo puder descrever o seguinte, seria útil:

1. Resumo do Trabalho (Resumo JCL) que deve descrever o seguinte -
   1. Funcionalidade/Descrição do trabalho
   2. Arquivos usados ​​no trabalho (leitura/gravação)
   3. Tabelas DB2 usadas (em termos de programa)
   4. Informações de agendamento
   5. Fluxo de trabalho (provavelmente estrutura em árvore)
   6. Instruções de reinicialização
2. Regras de Negócio – deve descrever as regras associadas à função específica do programa específico
3. Layout de Registro - Layout de Registro/Estruturas de Arquivos usados ​​no programa
4. Mapeamento de campo - Deve descrever em formato pictórico ou de tabela como o mapeamento de origem para destino é feito na lógica/programa de negócios

   2. Escrevendo as Regras de Negócios:

     Analise o código e entenda o fluxo lógico do programa. Não tente escrever cada parágrafo como uma Regra, se necessário podemos ter que combinar os parágrafos para trazer a lógica/regra do negócio de forma lógica.

O seguinte deve ser considerado ao escrever as Regras de Negócios:

• Mapeie cada transação e trabalho para uma função de negócios   
• Depois que as regras forem capturadas, mapeie-as para o nível 4, nível 3, nível 2, nível 1 e nível 0. O nível 0 é o mais alto e é a combinação dos níveis 1 a 4 para atingir o recurso (exemplo: a integração do cliente será nível 0)
• Títulos, Subtítulos – Títulos e subtítulos são muito cruciais ao escrever as regras de negócios para ex: em geral, o parágrafo de processamento estará lá para processar a lógica central, todas as funcionalidades nesta seção/parágrafo virão como subtítulos, você será capaz de entender todo o fluxo ou lógica vendo o título e os subtítulos.
• Variáveis ​​temporárias/variáveis ​​de armazenamento de trabalho – Certifique-se de fornecer a referência para qualquer variável Temp, mencione o número da regra em que usaremos ou referenciaremos essa variável 
• Condições IF e instruções EVALUATE – No estilo de programação antigo para condições IF, END-IF não seria mencionado, portanto, certifique-se de mencionar END-IF e use as cores no caso de IFs aninhados. Divida cada condição em uma regra específica.
• Executar loops - Mencione claramente sobre o Loop quando está começando e quando está terminando
• ARRAYS/Tabelas – Mencione toda a declaração no caso de Arrays/Table e seu uso associado para uma função específica.
• Base de dados - Ao escrever a lógica relacionada ao banco de dados, é melhor escrever o DECLARE CURSOR e quaisquer outras instruções SQL como uma regra e fornecer a referência sempre que precisar. Mencione o significado de SQLCODE ao adicionar a lógica na Regra de Negócios.
• Manipulação de erros - Certifique-se de que o tratamento de erros esteja devidamente documentado junto com as instruções DISPLAY.
• Rotinas Comuns – Regras de rotinas comuns podem ser colocadas em uma planilha ou documento comum para que a equipe de engenharia avançada possa construí-las uma vez e usá-las.

Apresentando regras de negócios para a equipe de engenharia avançada:

       O principal desafio é quão eficaz você pode explicar a lógica para a equipe de engenharia avançada, se você conseguir algum BA técnico que tenha conhecimento sobre o sistema, você terá sorte! Para que você possa explicar a lógica e o BA entender e apresentar casos de uso.

A melhor maneira do lado do mainframe é criar algum diagrama de fluxo com fluxo de alto nível no nível do trabalho. Para que seja fácil de digerir para a equipe de engenharia avançada em todo o fluxo e fácil para os caras do mainframe explicar sobre o fluxo também.

Certifique-se de explicar toda a lógica para BA e para a equipe de engenharia avançada. E se o design de baixo nível fosse criado no lado da engenharia avançada, então em sua própria maneira de trabalhar. Seria útil para a equipe.

Convertendo Regras para Java:

      Ao converter o Mainframe COBOL para Java, deve-se entender a diferença entre COBOL e Java. Primeiramente, COBOL é Linguagem Processual, e teria definido as etapas em sequência. Já Java é uma linguagem orientada a objetos que segue os conceitos de OOPs.

Considere os tipos de aplicativos que são adequados para COBOL. O termo COBOL é um acrônimo para Common Business Oriented Language. A linguagem foi projetada para oferecer suporte a funções de negócios, como geração de relatórios, processamento de números e processamento de dados. Isso não significa que o COBOL não possa realizar outros tipos de processamento; pode. Só que alguns tipos de programas podem ser melhor desenvolvidos usando outra linguagem.

    Java é uma linguagem de programação orientada a objetos adequada para computação multifuncional, com o benefício adicional de ser portátil em várias plataformas de hardware. A capacidade de executar o mesmo programa em diferentes computadores (se uma Java Virtual Machine estiver disponível para a plataforma) é uma das razões pelas quais Java é uma das linguagens mais populares para novos desenvolvimentos atualmente.

As considerações abaixo a serem feitas do lado Java para converter o código COBOL:

1. Entenda os padrões de codificação java de acordo com o ambiente do cliente
2. A diferença entre tipos de dados COBOL e Java
3. Funções equivalentes entre COBOL e Java.
4. Qual conexão de banco de dados deve ser usada em Java no caso de chamadas de banco de dados legados (JPA ou JDBC)?
5. Existe alguma otimização de consulta que pode ser feita para as consultas de banco de dados?
6. Existe alguma execução paralela (entre as etapas) possível?
7. Podemos implementar a lógica Chunking em operações DML?
8. Quaisquer rotinas/serviços comuns precisam ser criados e reutilizados

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://www.finextra.com/blogposting/23602/my-experience-on-mainframe-modernization-for-major-us-bank?utm_medium=rssfinextra&utm_source=finextrablogs