modernização de sistemas de gestão
TRANSCRIPT
Proposta de Modernização de Sistemas de GestãoRafael Chaveshttp://abstratt.com
Contexto
Sistema de gestão legado
⬇Interface com usuário antiquada
⬇Lock-in com a tecnologia legada
⬇Difícil encontrar mão de obra
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
Base Técnica da Solução
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
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
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
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)
Proposta Técnica
● 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
Estratégias propostas
1. Usar SOA/ESB2. Usar JavaEE/EJB como tecnologia preferencial
(poderia mudar no futuro)3. Cada componente tem seu próprio banco de dados4. Encapsular funcionalidade legada em web services5. Verificar contrato de componentes via testes
automatizados6. Considerar oportunidades para geração de código7. Análisar escopo e estrutura do ERP legado8. Implementar uma aplicação simples de ponta-a-ponta
via abordagem proposta9. Continuar a mover partes do ERP para o ESB
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
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
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
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
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
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
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
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
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
Credenciais
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)
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
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
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
