modernização de sistemas de gestão

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 (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)

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

Contato

● web: http://abstratt.com● email: rafael@abstratt.com● cidade: Florianópolis-SC