Uma proposta genérica para modernização de sistemas de gestão. Mais informações: http://abstratt.com

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 (rafael@abstratt.com) 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: rafael@abstratt.com
● cidade: Florianópolis-SC