Modernização de Sistemas de Gestão
0 gostou385 visualizações
Este documento propõe a modernização dos sistemas de gestão legados da empresa através da adoção de uma arquitetura baseada em serviços e componentes, encapsulando a funcionalidade existente como web services e migrando gradualmente para novas implementações em JavaEE. A proposta visa entregar valor continuamente, simplificar o desenvolvimento e evitar lock-ins, preservando investimentos no legado.
Modernização de Sistemas de Gestão
- 1. Proposta de Modernização de Sistemas de Gestão Rafael Chaves http://abstratt.com
- 2. Contexto
- 3. Sistema de gestão legado ⬇Interface com usuário antiquada ⬇Lock-in com a tecnologia legada ⬇Difícil encontrar mão de obra
- 4. Possibilidades (não mutuamente exclusivas) ➡ Reescrita manual ou automatizada de funcionalidade existente em arquitetura nova ➡ Integração da funcionalidade existente (via web services) ➡ Adoção de componentes genéricos de mercado ➡ Manutenção de partes da aplicação legada sem alterações
- 5. Base Técnica da Solução
- 6. Orientação a Serviços e Componentes ● Sistema distribuído, separado em componentes ○ componentes são autônomos ○ comunicam via mensagens (via ESB) ○ isolados, sem conhecimento direto ⬆ implantação/desenvolvimento independente ⬆ integração sistemas internos com terceiros
- 7. Serviços e Componentes Componentes ○ unidades de empacotamento e implantação ○ um componente por contexto (domínio) ○ componentes de negócio e técnicos ○ um componente, muitos serviços Serviços ○ funcionalidade exposta/consumida por componentes
- 8. Componentes por tipo de domínio Componentes de negócio (verticais) ○ maior parte da aplicação, servem os stakeholders do negócio ○ contas a pagar, distribuição ou mais específicos Componentes técnicos (horizontais) ○ domínios: logging, posicionamento global, provedores de pagamento ○ normalmente providos por terceiros
- 9. Componentes/serviços por origem ● Novos ○ criados na empresa, rodam no serv. de aplicações ● Legados ○ funcionalidade existente (em legado Progress/Delphi/etc) ● De terceiros ○ funcionalidade adquirida, rodam externamente ao serv. de aplicações ⬆ todos expostos no ESB de maneira uniforme ⬆ substituíveis (legado <-> novo, legado <-> 3o , etc)
- 10. Proposta Técnica
- 11. ● Entregar valor continuamente ● Evitar lock-in com produtos e tecnologias ● Simplificar o fluxo de trabalho do desenvolvimento ● Abraçar a heterogeneidade de sistemas grandes e complexos ● Progredir com rapidez e ainda evitar regressões ● Preservar valor investido no legado, e no desenvolvimento dos novos componentes ● Promover uma cultura de modularidade ● Criar uma solução que está preparada para lidar com mudanças técnicas e de negócio Objetivos
- 12. Estratégias propostas 1. Usar SOA/ESB 2. Usar JavaEE/EJB como tecnologia preferencial (poderia mudar no futuro) 3. Cada componente tem seu próprio banco de dados 4. Encapsular funcionalidade legada em web services 5. Verificar contrato de componentes via testes automatizados 6. Considerar oportunidades para geração de código 7. Análisar escopo e estrutura do ERP legado 8. Implementar uma aplicação simples de ponta-a-ponta via abordagem proposta 9. Continuar a mover partes do ERP para o ESB
- 13. Estratégia 1 Usar SOA/ESB ● mas componentes não precisam saber disso ● componente é utilizável/testável sem ESB ● conexão entre componente e ESB é um elemento aditivo/substituível ⬆facilita desenvolvimento (requisitos de ambiente mais simples) ⬆evita lock-in no fornecedor ou tecnologia
- 14. Estratégia 2 Usar JavaEE/EJB como tecnologia padrão hoje ● no futuro outra escolha pode fazer mais sentido ● componentes diferentes podem vir a usar tecnologias diferentes (Java e Spring, ou mesmo não-JVM) ⬆ evita criar o novo legado ⬆ permite evolução do padrão de tempos em tempos
- 15. Estratégia 3 Cada componente tem seu próprio banco de dados ○ esquema e dados pertencem ao componente ○ outros componentes usam ESB para acessar dados/funcionalidade ⬆ evita acoplamento entre componentes ⬆ componente pode evoluir sem quebrar outros
- 16. Encapsular funcionalidade legada em web services ● consumidores não sabem se legado/moderno/3o ● preservação do legado não atrasa evolução do sistema como um todo ⬆ preserva o investimento feito, sem impedir evolução Estratégia 4
- 17. Estratégia 5 Verificar contrato de componentes via testes automatizados ● contra a API (mais estável, acessível), não contra a GUI ● para substituir um componente (legado -> novo ou 3o ), basta fazer os testes passarem contra a nova implementação ● testes executam em ambiente de integração contínua ⬆ permite evoluir com segurança, sem regressões
- 18. Estratégia 6 Considerar oportunidades para geração de código ● para produzir wrappers para serviços legados ● ou mesmo para implementar serviços em JavaEE ⬆ aumento da produtividade/turnaround
- 19. Análisar escopo e estrutura do ERP legado ● mapeamento inicial de subsistemas como candidatos a reescrita, integração como legado, substituição por 3os ● priorização das funcionalidades/subsistemas deveriam ser portados/integrados em valor e risco relativos Estratégia 7
- 20. Estratégia 8 Implementar uma aplicação simples de ponta-a- ponta via abordagem proposta ● encapsular funcionalidade existente na tecnologia legada em um web service conectado ao ESB ● ou portar funcionalidade para JavaEE e expor via ESB ● deveria ser acessível por GUI existente ou a ser criada ● esforço paralelo com participação primária do consultor ⬆ piloto para estabelecer e documentar um padrão para o desenvolvimento na nova abordagem ⬆ impacto limitado na carga de trabalho do time
- 21. Estratégia 9 Continuar a mover partes do ERP para o ESB ● re-escrever vs. integrar existente vs. integrar de 3os ● esforço contínuo e incremental (meses, mesmo anos) ● foco onde há maior valor ● time assume a condução do projeto ⬆ time gradualmente absorve cultura de serviços, componentes e testes automatizados ⬆ valor é entregue desde o início, e continuamente
- 22. Credenciais
- 23. Histórico Rafael Chaves ([email protected]) desenvolve software há mais de 15 anos ● Experiência desenvolvendo software básico em Java como desenvolvedor da IBM nos projetos Eclipse e Jazz (Ottawa, Canadá, 2002-2006) ● Experiência como desenvolvedor sênior/arquiteto/líder técnico na Genologics (Victoria, Canadá, 2008-2013) ● Consultor independente (Abstratt) em arquitetura, melhoramento e modernização de software e desenvolvimento baseado em modelos (desde 2013)
- 24. Java/JavaEE 15+ anos de experiência em tecnologia Java Diversas tecnologias para aplicações de negócios (EJB, Hibernate, JTS, Spring-*, JNDI, LDAP, Grails) Diversas tecnologias para aplicações distribuídas (JMS, CORBA, RMI, JAX-RS, JAXB) APIs para software básico: threads, sockets, classloaders
- 25. Componentes e Serviços Parte do time que portou o runtime do Eclipse para OSGi (SOA intra-JVM) na versão 3.0 (IBM Canada, 2003-2004) Liderou um projeto para componentização de uma base de código monolítica com 6 anos de existência (Genologics, 2009) Liderou o desenvolvimento de uma API REST que permitia a clientes estender a funcionalidade do produto (Genologics, 2011-2013) Longa experiência com modularização, projetos de APIs, e desenvolvimento efetivo com bases de código extensas
- 26. Modernização Participou de vários projetos de modernização ao longo dos anos. Estratégias mais efetivas: ● fazer entregas incrementais ● estabelecer interfaces claras entre componentes ● permitir evolução segura através de testes automatizados ● usar geração de código para eliminar boilerplate requerido em integração de componentes distribuídos
- 27. Contato ● web: http://abstratt.com ● email: [email protected] ● cidade: Florianópolis-SC