Particularidades na execução de projetos com integrações – Parte Final

Nos dois primeiros posts (disponíveis em 1 e 2), tratamos particularidades da gestão/execução e práticas metodológicas para bons resultados em projetos envolvendo integrações.

Para fechar esta série de artigos, hoje descreveremos alguns riscos importantes e fatores críticos de sucesso (FCS) nestes projetos, para que recebam a devida atenção e, se necessário, tratamento.

Em resumo, grande parte dos riscos e FCS se referem à comunicação e à integração das equipes do projeto, dado que muitas das informações e necessidades de trabalhos desta natureza envolvem algum tipo de compartilhamento.

Desta forma, listamos abaixo alguns itens que consideramos relevantes:

  • O primeiro ponto quem sabe até não seja o mais importante, mas certamente é um dos mais frequentes. Durante testes do sistema, quando ocorrem problemas, costumamos dizer: “até que se prove o contrário, a ‘culpa’ é da integração”. E pode-se dizer que até é um fato lógico. Quando uma das equipes realiza algum teste e não vê o resultado esperado acontecendo na outra “ponta”, naturalmente a primeira desconfiança é de algum defeito ou inconsistência na integração, que justamente faz a “ligação” entre os dois sistemas. Porém, esquece-se que a integração não é uma peça de software isolada, e sim um pequeno sistema formado pela origem, destino e o meio, que é a integração em si. E em qualquer um destes componentes pode ocorrer erro. Assim, é importante tanto alinhar as expectativas das equipes (inclusive para evitar desgastes) quanto definir um processo de teste e avaliação de problemas tecnicamente adequado para o cenário do projeto e dos sistemas envolvidos.
  • Boa parte das etapas de desenvolvimento e testes será realizado de maneira simbiótica por todas as equipes envolvidas (equipe do sistema que será integrado, de integrações e dos legados). Desta forma, uma prática bastante importante é a apresentação destas equipes, visando sua aproximação e integração. Com isto, espera-se que todos se conheçam, saibam os papéis de cada um e a quais responsabilidades respondem, quais os conhecimentos de cada integrante quando precisarem de apoio, etc. Além disso, a própria integração pessoal da equipe auxilia na pró-atividade e facilidade da comunicação.
  • Apesar da metodologia de desenvolvimento normalmente contemplar e se adequar a boa parte do escopo, como as integrações são o meio e dependem da forma como as “pontas” são desenvolvidas e entregues, é fundamental avaliar as eventuais modificações necessárias na metodologia, bem como apresentá-las às equipes. As responsabilidades também devem ficar muito claras. Além disso, é mandatório registrar estas mudanças em algum local, para consulta. Esta preocupação é essencialmente importante pois é muito comum (para não dizer que acontece sempre) que se confundam sobre o que cada equipe deve fazer e até onde sua autonomia vai. Isto pode gerar conflitos e desgastes desnecessários, perda de produtividade ou até problemas mais graves, que se refletem apenas quando o projeto já está em um estágio mais avançado.
  • É comum em um projeto com integrações existirem documentações compartilhadas, nas quais uma equipe preenche parte do documento, e outra(s) o completa(m). Assim, é importante esclarecer com todos quais tópicos cada um é responsável e definir uma política de armazenamento e versionamento adequadas.
  • A comunicação entre as equipes durante a análise e os testes é outro fator crítico. É fundamental definir um fluxo adequado e claro de comunicação entre os integrantes das equipes, de acordo com as responsabilidades no projeto. E, claro, esta definição depende de uma avaliação criteriosa dos estilos e da disposição física das equipes, do ambiente de trabalho e dos recursos de comunicação disponíveis.
  • Por fim, um ponto bastante simples, mas que pode facilitar muito a identificação de problemas. À medida que integrações forem codificadas e estejam razoavelmente estáveis, podem ser disponibilizadas para uso pelas demais equipes. Claro, dependendo do planejamento do projeto e da metodologia utilizada, elas nem serão acionadas antes dos testes integrados. Mas, caso as equipes das “pontas” já estejam prontas para realizar testes com o uso das integrações, isto pode antecipar alertas relevantes sobre inconsistências e defeitos.

Com este artigo, fechamos esta série dedicada especialmente a dicas, boas práticas e cuidados com projetos envolvendo integrações, que possuem particularidades que os tornam especialmente desafiadores.

Fiquem à vontade para opinar e sugerir outras práticas interessantes.

Esperamos que tenham gostado!

Nos falamos em futuros artigos. Até lá!

Particularidades na execução de projetos com integrações – Parte 2

No primeiro post (disponível aqui), iniciamos uma avaliação de particularidades da gestão e execução de projetos envolvendo integrações, com foco nas dependências técnicas e gerenciais.

Hoje, a ideia é “conversarmos” sobre algumas práticas metodológicas importantes para minimizar riscos e conduzir o trabalho de maneira organizada.

Apesar de podermos citar um grande número de práticas, algumas são especialmente relevantes para o sucesso deste tipo de projeto, a saber:

  • Definição de uma arquitetura do projeto. O básico do básico, mas por vezes esquecido. É fundamental definir uma arquitetura de comunicação, tecnologias a serem utilizadas e padrões de implementação no projeto, especialmente para as integrações. Outro ponto muitas vezes negligenciado – não adianta ter, tem que comunicar. Se for necessário, imprima a arquitetura e cole no monitor dos integrantes da equipe. Cada um precisa ter a arquitetura na cabeça, sem exceções. Criar uma página tipo wiki também pode ser simples e eficiente.
  • Implementação de mocks na etapa inicial de desenvolvimento ou arquitetura. Como citado no primeiro post, a definição e construção de mocks é uma prática que facilita a formalização da comunicação entre os componentes do sistema (principalmente quando estes estão divididos entre vários fornecedores) e auxilia o paralelismo de atividades. Uma outra avaliação é bastante importante – o comportamento interno do mock. Se por um lado um artefato que simplesmente devolve “vazio” é fácil e rápido de implementar, por outro ele não auxilia os testes unitários, por exemplo. Se implementarmos algumas regras, os testes unitários podem ser mais efetivos, mas é um trabalho que posteriormente será descartado. Assim, é fundamental avaliar qual a complexidade e conteúdo dos mocks a ser desenvolvido para cada caso e requisitos do projeto.
  • Testes unitários com componentes já desenvolvidos. Conforme o segundo item, a validação das regras de negócio das integrações não depende apenas das interfaces (assinaturas, contratos, etc) dos componentes chamados por estas, e sim principalmente de sua implementação interna. Desta forma, assim que possível é importante a substituição dos mocks pelos componentes definitivos, o que já ajuda, e muito, na avaliação de eventuais problemas de integração dos dados e até de análise. Porém, um alerta. Caso os componentes ainda estejam em uma fase incipiente de desenvolvimento, podem conter bugs que mais prejudicarão do que ajudarão durante a implementação das integrações. Assim, é necessário avaliar a qualidade dos componentes das “pontas” quando estes forem usados.
    • Revisão periódica de serviços ou componentes que vão ficando prontos. Item relacionado ao tópico anterior. Defina um meio de acompanhar e comunicar quais componentes das “pontas” da integração (serviços que serão chamados, por exemplo) estão prontos e disponíveis para uso no decorrer do projeto. É bastante comum esquecermos disto por vários dias e perdermos a oportunidade de aproveitar os ganhos do tópico acima.
  • Teste de arquitetura com “integração piloto”. Uma prática que resolve várias dores de cabeça e antecipa problemas do desenvolvimento é validar a arquitetura definida para o desenvolvimento das integrações com a implementação de uma “integração piloto”. Aproveite este momento para questionar e validar as diretrizes arquiteturais para o restante do projeto. Claro, nem sempre isto é simples, visto que muitos projetos incluem integrações com “n” formas de implementação e utilização de recursos. Mas, na medida do possível, é uma prática muito vantajosa.
  • Mapa de dependências entre componentes. Prática simples e muito útil. Organize um mapa com todos os componentes do projeto e quem depende de quem. Não use textos – faça o mapa de forma gráfica. Aí temos uma vasta gama de ferramentas que podem ser usadas – aplicativos de mind mapping, de desenho, de modelagem, etc. E use a criatividade. Pinte componentes de cada tecnologia com uma cor diferente, separe-os por equipe responsável, por desenvolvedor, e assim por diante.
  • Repositório único de contratos. É realmente muito importante definir um repositório que armazene a versão oficial de contratos de serviços e demais componentes que são dependência para outros no projeto. Assim, todas as equipes sabem onde consultar a versão a ser utilizada, evitando ruídos de comunicação. Claro, se alguma alteração é feita, deve ser comunicada a todos – e isto deve estar contemplado no Plano de Comunicação do projeto. Este repositório deve estar sempre atualizado.
  • Organizar a análise e desenvolvimento das integrações por assunto. É bastante comum em projetos envolvendo integrações que estas estejam separadas por assuntos de negócio tratados pelo sistema. Por exemplo: ao desenvolver integrações de um ERP com sistemas legados, organizar os profissionais que vão analisar e implementar as integrações por cada módulo do ERP. Nem sempre isto é possível – alguns processos são transversais e passam por vários módulos – mas claramente auxilia o entendimento das integrações pelo conhecimento de negócio que cada profissional adquire. Claro, isto incide em alguns riscos bastante relevantes. Se um profissional, seja analista ou desenvolvedor, sai da equipe, um grande conhecimento pode ir com ele. Uma forma de contornar isto é envolver o líder técnico e um analista líder em pontos-chave da análise e desenvolvimento de todas as integrações, a fim de que possa responder pelo conhecimento destas.
  • Definição de cenários de testes entre as equipes. Um ponto chave do projeto, difícil de gerenciar e que frequentemente enfrenta grandes problemas, é o teste integrado do sistema, principalmente quando existem diferentes equipes envolvidas. Uma sugestão muito interessante é a reunião dos responsáveis das equipes para elaboração de cenários de teste integrados. Veja, a ideia não é detalhar cada cenário neste momento, e sim definir quais são os cenários a serem executados para validar a integração dos sistemas de ponta a ponta. Após, cada equipe detalha seus cenários individualmente, que são validados ao final, novamente entre todos.

No próximo post, que encerra esta série, trataremos de riscos e pontos de atenção em projetos com integrações, visando auxiliar principalmente seu planejamento e gestão. Até lá!

Orquestrar é uma arte

Recentemente perdi o sono com um pensamento que me intrigou positivamente. Fiquei impressionado por ter constatado algo tão simples e, ao mesmo tempo, tão interessante.

Trabalho com orquestração de webservices há mais de 2 anos. Também sou músico amador há pelo menos 25 e talvez, até o momento, eu nunca tivesse feito uma relação entre as duas coisas.

Ora, a coisa é simples! Imaginemos uma orquestra musical. Nela, o maestro é responsável por determinar o tempo da música, o seu pulso. Os gestos que ele faz determinam a textura da música, ou seja, se as notas vão ser mais suaves ou mais duras; e a amplitude da regência determina o volume (forte ou piano), quando a música deve crescer e quando deve diminuir; em suma, a interpretação dinâmica.

Além disso o maestro é quem dá as entradas para os músicos (já que nem todas as músicas começam e terminam com todos os instrumentos tocando ao mesmo tempo) e também determina o fechamento da música de forma que todos os músicos possam parar de tocar na hora certa.

A maioria dos maestros faz uma regência bem parecida, mas as diferenças são adaptáveis, dependendo do seu costume e dos ensaios.

O maestro, porém, não pode fazer tudo sozinho. Ele é o ‘regente’ e é quem deve ter a capacidade de contagiar sua orquestra. Mas não é ele que, no fim, irá gerar o som… É aí que entra o papel dos músicos e dos seus instrumentos. Se os músicos são bons o resultado é fabuloso!! Igualmente, se os músicos são limitados, não há maestro que faça milagres… E, por mais fantástico que seja um instrumento, se o musicista não é tão competente assim, o resultado pode ser desastroso. E vice-versa.

Se não bastasse, ainda devemos pensar em utilizar o instrumento certo para a tarefa certa, e este deve estar devidamente afinado. Não posso utilizar uma flauta no lugar de um baixo, por exemplo.

Algo semelhante ocorre na orquestração de sistemas. A orquestração é capaz de integrar sistemas de forma melodiosa e harmônica. Ela dita o ritmo da integração, invocando o serviço certo no momento certo, informando as entradas de cada serviço. Mas esse ‘maestro’ é totalmente dependente do serviço, o nosso músico, ao ponto de limitar-se à tarefa de realizar uma requisição e obter ou não uma resposta.

Esse exemplo também nos ajuda a visualizar os papéis envolvidos num processo de orquestração. Se pensarmos que a orquestração é como o maestro e os serviços são como os músicos, fica muito claro entender a separação entre a lógica da orquestração e a lógica de negócio: assim como o maestro não toca nenhum instrumento, a lógica de negócio não deve ser implementada junto com a lógica de orquestração e sim em serviços separados para serem orquestrados.

É fundamental, também, escolher o instrumento certo para tocar o trecho correto. O instrumento errado ou desafinado pode comprometer toda a orquestração, toda a peça. Da mesma forma que o serviço chamado na hora errada poderá comprometer os resultados da orquestração.


Chego à conclusão que orquestrar é uma arte!! E é por isso eu tenho tanto prazer em desenvolver esse tipo de trabalho!

Particularidades na execução de projetos com integrações – Parte 1

Projetos envolvendo integrações, sejam elas o escopo completo ou apenas parte dele, possuem uma série de particularidades, do planejamento e gestão às mais específicas decisões técnicas.

Integrações são, em muitos casos, o calcanhar de aquiles dos projetos. Não apenas quando falamos dos pontos de contato entre dois ou mais sistemas, ou em projetos de orquestração de serviços (SOA), mas também quando temos equipes com entregas específicas, eventualmente falando idiomas diferentes, em locais distantes, com culturas distintas… mas que em determinado momento precisam literalmente juntar todo o código-fonte do projeto e fazê-lo “conversar” harmoniosamente. Dados devem ser transportados e transformados de acordo com as regras, formatos e tipos especificados. Um sistema deve entender o outro como se tivessem nascido juntos, filhos do mesmo pai. E o mais importante: os usuários devem ter a segurança de que as informações que compartilharam estão íntegras e disponíveis a todos os interessados, no tempo certo, no formato esperado.

Diante de tudo isto, gostaria de compartilhar, nesta série de artigos, idéias sobre gestão e execução de projetos com integrações. Na verdade, o principal objetivo aqui é levantar dúvidas. Sim, isto mesmo. Estes projetos em especial possuem, é claro, premissas, características, desafios e problemas comuns. Entretanto, cada um possui variáveis internas e de ambiente que tornam a avaliação e solução destes itens particular para cada caso. A simples discussão sobre estes pontos, bem como a citação de exemplos e experiências, faz com que nos forcemos a perguntar no início e no decorrer do projeto:

- Estou controlando adequadamente minhas dependências?

- Onde está o contrato das entradas e saídas dos dados deste sistema?

- Estou realmente comunicando a todos os interessados as informações necessárias?

Nesta primeira parte será abordado um tema que não inicia nem termina o projeto, mas que é crítico para sua execução: o controle de dependências técnicas e gerenciais.

Quando falamos de dependências, nos referimos a qualquer item, seja técnico, metodológico ou gerencial, que é gerado por um participante do projeto e que é insumo ou referência para outro. Exemplos? Temos vários:

  • Serviços ou APIs que precisam ser implementados (às vezes, eles até existem, mas precisam ser encontrados!).
  • Informações que devem ser buscadas com algum usuário e que será base para análise de negócio de algum ponto do sistema.
  • Documentações de produto que precisam ser repassadas, para viabilizar o desenvolvimento.
  • Profissionais com conhecimento em sistemas que devem ser integrados.
  • Disponibilidade do fabricante de produtos para repasse de conhecimento.

E assim por diante…

Integrações possuem um cenário padrão: temos uma origem, um destino e a integração em si, que pode ser implementada em inúmeros níveis de complexidade. Mas é nas duas “pontas” que residem os principais problemas com dependências.

Apesar de óbvia, a primeira preocupação nem sempre é lembrada: as dependências devem ser PLANEJADAS. Nesta etapa, alguns pontos parecem particularmente críticos:

  • Disponibilidade de recursos - Os responsáveis por fornecer as informações referentes a cada origem e destino de dados devem estar disponíveis no momento planejado para suas participações. Porém, geralmente são profissionais que não estarão disponíveis em tempo integral, provavelmente dividindo seu tempo de trabalho com as demandas de projeto. Assim, é importante antecipar suas necessidades.
  • Documentações de sistemas - Muitas vezes a análise pode ser muito facilitada a partir da disponibilização antecipada de documentações de sistemas ou suas camadas de integração já desenvolvidas. Com isto, diminuem-se também os riscos do projeto associados ao entendimento das origens e destinos de dados envolvidos nas integrações.
  • Participação de fabricantes de produtos - É comum a implementação integrações entre sistemas com fornecedores localizados fisicamente em regiões distantes da sede do projeto. Por vezes, o fabricante nem existe mais! Desta forma, é fundamental antecipar a participação deste stakeholder, a qual possivelmente envolverá custo e pode impactar significativamente o planejamento do projeto.
  • Definição clara de metodologia, formato de documentação e estrutura de informações da análise das interfaces - A definição de um procedimento e linguagem comuns entre as equipes e envolvidos no projeto auxilia muito a evitar ruídos de comunicação e perda de informações durante a análise das integrações.

Com as dependências identificadas e com planos de ação definidos, começa a execução. Porém, o planejamento em si não garante de forma alguma o sucesso na administração das dependências. Agora, elas precisam ser CONTROLADAS. Isto requer, dentre outras necessidades:

  • Um mecanismo comum de controle - Deve ser possível, mas é muito mais difícil controlar as dependências entre equipes e sistemas através de meios próprios de cada participante do projeto. Um sistema para isto auxilia de maneira bastante prática (um software de controle de issues é uma boa alternativa), mas uma planilha compartilhada e bem organizada já pode, dependendo do caso, resolver. A questão é: é fundamental ter algum mecanismo.
  • Comunicação centralizada, atualizada e disponível a todos - A situação, pendências e problemas de cada dependência deve ser controlada rigidamente, evitando assim complicações posteriores e agilizando a resolução de eventuais problemas.
  • Definição clara e compartilhada de responsabilidades - Um desafio clássico em projetos com integrações é definir de quem é a responsabilidade por levantar uma informação, entregar um artefato, dar um parecer técnico. Parece simples, mas definitivamente não é. E, é claro, não basta definir, tem que compartilhar. Não adianta termos o responsável, se quem precisa dele não o conhece.

Mesmo com todas as preocupações acima, controlar dependências sempre é delicado e trabalhoso. E é muito difícil, senão impossível, definir um processo isento de falhas. Assim, uma outra diretriz pode ser usada em projetos: buscar que as dependências sejam ELIMINADAS – ao menos o maior número possível delas.

Olhando para o desenvolvimento, um exemplo clássico é a utilização de componentes mock (ou fake) para simular o comportamento dos componentes definitivos que serão entregues posteriormente. Com isto, a implementação da integração em si e suas regras de negócio independem das entregas da origem e destino, com um custo geralmente baixo. Estes componentes podem ser implementados com diferentes níveis de simulação das regras de negócios. Podem tanto simular a simples troca de dados quanto ter diferentes retornos e emular as regras reais, dependendo da necessidade de implementação, testes e avaliação de qualidade em cada etapa do projeto.

No aspecto técnico, é claro que isto acarreta a necessidade de controle do “contrato” ou especificação dos componentes que se comunicam com as integrações – mas isto é assunto para mais adiante.

No próximo artigo, abordaremos algumas questões metodológicas que podem ajudar na execução de projetos com integrações, buscando eliminar riscos e controlar o andamento do trabalho. Até lá!

Respostas sobre o webinar: A orquestração para integração de sistemas

Recentemente tive a oportunidade de apresentar um webinar pela iProcess sobre “A orquestração como instrumento para integrar sistemas”, que apresentou conceitos de SOA, BPEL e orquestração de webservices, além de apresentar uma breve introdução sobre como desenvolver projetos de integração utilizando orquestração.

Você pode rever o webinar no canal do Youtube da iProcess ou nos links abaixo:

Ao final do webinar recebemos algumas perguntas dos nossos participantes. Procurei resumir abaixo em principais idéias, levando em consideração que alguns assuntos são amplos e seria impossível esgotar o argumento nas respostas. Deixo aos leitores completarem com seus comentários e percepções.

1) Quais são as principais vantagens da utilização de BPEL em relação ao desenvolvimento de um serviço orquestrador, escrito em Java por exemplo?

Entendo, com essa pergunta, que estamos falando da utilização de um produto que implementa o SOA/BPEL. Vou pegar como exemplo o Oracle SOA Suite 11g, que inclusive foi desenvolvido em Java.

Falemos, então, de vantagens e desvantagens da utilização desse tipo de produto.

VANTAGENS

  •  a principal vantagem é poder contar com uma infraestrutura de middleware pronta (estilo caixa-preta) que possibilita o rápido desenvolvimento de soluções complexas, além de incluir o controle de instâncias de curta e longa duração, a disponibilização de adaptadores para conexão direta a diferentes serviços (banco de dados, AQ, MQ, JMS, arquivos, webservices, etc), monitoramento do ambiente, ferramentas de configuração, etc;
  • a possibilidade de implementar rapidamente processos de negócio bem definidos;
  • no caso do Oracle SOA Suite, é possível utilizar toda a infraestrutura disponibilizada pela suite, que inclui, além do BPEL, componentes de business rules, tarefas humanas (human task), mediator e BPM.

DESVANTAGENS

  • quando trabalhamos em projetos que exigem alta-disponibilidade, grandes quantidades de operações por minuto, cloud-computing, grande quantidade de serviços, entre outros desafios, o middleware deixa de ser uma caixa-preta e passa a ser uma caixa-cinza, exigindo do time de arquitetura, desenvolvimento, infraestrutura e suporte um conhecimento profundo do produto, o que nem sempre é fácil;
  • o custo do produto costuma ser alto;
  • o middleware é um produto que inclui muitas camadas (sistema operacional, máquina virtual [Java, por exemplo], banco de dados, conexões diversas, além de utilização de memória, disco, processador, temperatura). Em ambientes de produção tudo isso deve ser controlado. Nem sempre é fácil identificar rapidamente quando um problema ocorre, exigindo novamente grande conhecimento do produto.

 

 

2) Quando vai ser feita a implantação de uma orquestração, espera-se que já esteja implementada uma arquitetura orientada a serviço?

Não necessariamente. Como foi comentado durante a apresentação, uma boa orquestração prevê a descrição do processo de negócio que será orquestrado e todos os pontos de orquestração bem definidos.

Porém já tivemos casos de orquestração que utilizavam somente troca de arquivos, conexões a banco de dados e filas e acesso direto a API’s de outros sistemas utilizados pela empresa, sem que existisse, de fato, uma arquitetura orientada a serviço na empresa.

É certo, porém, que os projetos que podem contar com esse pré-requisito acabam utilizando melhor todos os recursos que a orquestração dispõe, desde o controle das instâncias, erros e execuções até o completo monitoramento do ambiente como um todo.

3) É comum construir orquestração de serviços e “expor” essa orquestração dentro de um ESB?

Já atuei em projetos que nem sequer utilizavam ESB e outros que expunham sempre um serviço no ESB. Na minha visão isso depende da arquitetura que será utilizada no projeto.

4) Gostaria que o Eduardo comentasse mais sobre os papéis dos projetos e a interação entre eles.

Durante a apresentação utilizamos a imagem abaixo:

Falando um pouco sobre a função de cada um desses papéis:

  • Arquiteto de integração: ele será responsável por desenhar toda a solução técnica da integração e definir quais serão os padrões utilizados. É papel do arquiteto, também, desenhar os diagramas de componentização das integrações.
  • Analista de processo: irá trabalhar junto aos usuários de negócio na definição dos processos que serão orquestrados e na definição da estrutura de dados.
  • Desenvolvedores e técnicos de infraestrutura que farão o desenvolvimento das integrações propriamente ditas.

Nos projetos nos quais trabalhei a figura do arquiteto foi essencial. Ele deve ter clara a visão do todo e entender realmente o problema, definindo quais recursos de TI serão utilizados na integração. Além dele, o analista de processo tem um papel fundamental na compreensão e na documentação dos processos que serão automatizados e orquestrados, cabendo aos desenvolvedores uma boa implementação e aos técnicos de infraestrutura a garantia de que o middleware estará bem configurado para suportar a solução.