Integrações é um dos assuntos mais discutidos e um dos maiores desafios no universo de TI corporativo. Com a explosão das startups, junto com as soluções criativas que essas empresas vem criando para diversos setores da indústria, veio o desafio de replicar os dados entre os todos esses novos sistemas e o ERP central. O grande problema é que tudo acabou se transformando em uma grande babilônia, com cada parte falando uma língua diferente e ninguém se entendendo. A ideia aqui é tentar passar um pouco do que considero como fatores de sucesso para desembaraçar esse emaranhado de conexões e sistemas.

Mapa de integração bem feito

Usando um exemplo pessoal como estudo de caso

Refletindo um pouco enquanto escrevo, acho engraçado que o assunto integrações me acompanha desde o início da minha carreira. Vou relatar uma experiência no meu primeiro emprego na área de TI, lá pelo ano de 2009. Não é um caso exclusivamente de integrações como se imagina ao pensar na palavra mas exemplifica exatamente a mensagem que quero passar.

O emprego na época era um estágio em uma empresa que vendia um sistema para cartórios usando uma tecnologia um pouco antiga para a época (Visual Basic 6), algo que definitivamente eu não dominava. Tinha algumas dezenas de clientes espalhados pelo estado, separados em algumas vezes até por algumas centenas de quilômetros e operava já a uns bons anos.

Nas primeiras semanas eu não entendia de muita coisa e não conseguia ajudar muito nas operações diárias da empresa (afinal eu era um estagiário de primeira viagem). Como eu tinha tempo livre e queria ajudar de alguma forma, comecei a observar como era a dinâmica de trabalho da empresa e percebi que um dos maiores gargalos era que, a cada nova versão lançada, era necessário um grande esforço para atualizar todos os clientes com os novos executáveis.

Nessa época o software não era Cloud para disponibilizar atualizações a todos os clientes e não existia nada próximo ao DevOps de hoje para deploy’s automatizados. Cada um dos cliente tinha em torno de 10 ou mais máquinas, que tinham que ser atualizadas manualmente via acesso remoto de forma totalmente manual e essa foi uma das primeiras tarefas que eu consegui ajudar de alguma forma. E com essas primeiro contato com essas atividades, ficou muito claro que esse processo era uma dor e que deveria existir um jeito melhor de realizar aquela tarefa.

Diagrama de máquinas a serem atualizadas

Eu me lembro que em algumas ocasiões, era necessário pegar um carro e se locomover até o cliente fisicamente (algo por volta de 100km) para realizar essa tarefas – caso o software de acesso remoto não funcione por algum motivo. Agora imagine o custo de realizar todas as atualizações, tanto monetário quanto na percepção do seu cliente em relação a velocidade em que as correções e ajuste chegavam – que nessas condições com certeza não eram ideais.

Pensar em integrações é pensar em pessoas e em suas prioridades

Não foi fornecido texto alternativo para esta imagem

Eu tinha na cabeça uma pergunta que não conseguia responder: por que um problema como esse ainda existia e ninguém tinha foco em resolver essa situação? A resposta é simples: o foco do time estava no produto, principalmente em estabilizá-lo e entregar algumas novas funcionalidades. Ninguém tinha como missão melhorar o ferramental que apoia o processo, pelo contrário: já era difícil atender aos requisitos conhecendo o ferramental, imagina se introduzir mudanças? Os clientes se interessavam pelo produto, pelo suporte, pelas novas funcionalidades, pelo atendimento, por tudo menos pelo processo de deploy. Eles sempre pagam pelo produto.

Isso é uma das coisas mais recorrentes nos projetos de integrações: o foco principal das pontas envolvidas definitivamente não está em desenvolver integrações e sim melhorar o produto – o que faz muito sentido. Esse foco acaba por ofuscar os reais benefícios de longo prazo que isso pode trazer para o produto como um todo e o que poderia trazer grandes resultados acaba sendo feito da maneira não otimizada (quando feito). A regra de ouro é funcionar de alguma forma. Cuidar do produto já dá um trabalhar danado, imagina ter que cuidar de mais um ponto de integração.

O foco das integrações sempre vai ser melhorar a vida de todos

Lente com foco

Pessoas com uma postura conciliadora possuem uma aptidão natural para conseguir trabalhar com esse tipo de projeto de forma eficiente. Elas sempre tentarão entender as prioridades das pessoas envolvidas para avaliar qual o melhor caminho a ser seguido – sempre ouvindo mais do que falando. Esse com certeza é o principal requisito para quem trabalha com integrações: ouvir e entender as necessidade de todos os lados. O sucesso de um projeto de integração é diretamente proporcional a capacidade de ouvir por parte do responsável por desenhar o processo, e entender as necessidades – mas também conhecer as limitações de ambos os lados. O que considero como sucesso em um projeto de integração é ver que todos os lados estão trabalhando de forma mais eficiente e que tarefas repetitivas adicionais foram eliminadas sem adicionar novas cargas de trabalho sempre que possível.

O sonho de todos é que as coisas funcionem de forma transparente, sem a necessidade de procedimentos adicionais ou novas atividades de rotina e cabe a quem irá planejar as integrações garantir que as coisas funcionem dessa forma. O cenário ideal para ambos os lados é que eles nem saibam que exista uma integração após o go-live. Vamos tentar dar alguns exemplos de integrações ideais do ponto de vista do usuário final:

  • Um cadastro de clientes no CRM que é replicado automaticamente para o ERP alguns segundos depois.
  • Novos colaboradores que são replicado automaticamente do sistema de folha de pagamento para o Active Directory (AD) a meia-noite do seu primeiro dia na empresa.
  • Um novo centro de custo no sistema financeiro principal que é sincronizado com o sistema lançamento de despesas de viagem após alguns segundos.

Agora se pegarmos esses mesmos exemplos podemos ter falhas no design de integração que podem levar a situações que sejam bem indesejadas:

  • Imagine que na primeira integração, no momento do projeto ficou definido que usuário teria que apertar um botão sempre que quiser que seja o cliente seja enviado para o ERP – pois em um primeiro momento as informações necessárias para o ERP não estão disponíveis. Com o tempo, o usuário deixa de realizar essa operação ou saí da empresa sem passar essa rotina para seu substituto e os clientes deixam de ser integrados ao ERP.
  • Na integração de novos colaboradores que tenta replicar automaticamente para o Active Directory (AD) as 00h do seu primeiro dia na empresa, periodicamente acontece uma manutenção ou indisponibilidade temporária em um dos sistemas, que não consegue replicar a informação. A integração não tenta reprocessar automaticamente e nem avisa a nenhum responsável e ao chegar na empresa o novo colaborador não possui acesso a nenhum sistema.
  • No cadastro do novo centro de custo no sistema lançamento de despesas de viagem, devido a uma manutenção ou indisponibilidade temporária, não consegue integrar a informação. A integração não tenta reprocessar automaticamente e nem avisa a nenhum responsável e o centro de custo só será cadastrado quando um usuário precisar realizar um lançamento e não estiver disponível.

São detalhes bem pequenos mas que acabam fazendo muita diferença no longo prazo, e somente com o tempo e a experiência que esse tipo de problema costuma entrar no radar. Algumas regras de ouro para um projeto de sucesso:

  • Automatizar ao máximo rotinas de reprocessamento em caso de erros – com o mínimo de intervenção humana possível.
  • Criar um monitoramento para possíveis erros e que, de preferência, seja acessível ao usuário final responsável e não somente ao time de TI.
  • Criar notificações automáticas avisando as pessoas certas em caso de comportamentos não esperados.
  • Validar se os campos necessários em ambos os sistemas possuem as mesmas regras de obrigatoriedade. Caso não seja, é necessário puxar uma conversa para alinhar o fluxo de cadastro das informações.

O sucesso do produto no longo prazo

Estrada longa

O responsável por integrações tem que ser a pessoa com foco no sucesso da operação no longo prazo. O foco exclusivamente em funcionalidades do produto não pode vir em primeiro lugar aqui e sim o foco em eficiência e no processo. Um exemplo é bem vindo para exemplificar o que estou falando. Imagine o seguinte backlog com 3 epics:

  • Criar um novo relatório com gráficos que consolida as informações X,Y,Z e aplicar técnicas de Machine Learning para fornecer análises preditivas.
  • Desenvolver um novo módulo que faz W, T, V e que tenhas as funcionalidades BLA BLU BLE, envolvendo Blockchain,
  • Projetar um novo modelo de integração que atenda todos os clientes

Qual vocês acreditam que despertará mais interesse? Acho que todos concordam que faz muito mais sentido comercialmente para o produto trazer novas funcionalidades como relatórios ou módulos que possam agregar mais valor envolvendo novas tecnologias que estejam em alta, do que criar uma arquitetura de integrações com os clientes já existentes que seja ‘topo de linha’.

Porém se a integração não for bem estruturada, infelizmente os clientes não permanecerão na plataforma por muito tempo e e logo estarão contribuindo para a temida estatística de Churn. Se o cliente for do padrão Enterprise a coisa fica um pouco mais complicada: eles terá como pré-requisito para contratação que as integrações sejam bem estruturadas. Se o time de arquitetura e segurança não se convencer que as integrações criadas atendes os padrões, nem com os mais belos relatórios do mundo a compra será aprovada – independente da quantidade de buzzworks que o setor comercial possa dizer. Um exemplo de questionamentos aplicáveis:

  • Qual são as opções disponíveis para autenticação? Suporta integração com diretório corporativo?
  • Existe monitoramento de disponibilidade e tempo de resposta? Esse monitoramento é acessível aos clientes e com permissões segmentadas?
  • Foram realizados testes de intrusão e sobrecarga? Foram geradas as devidas evidências?
  • Qual a política de proteção aos dados transitados?
  • O período de retenção de dados é configurável?
  • Como funciona o processo de gerenciamento de mudanças? É realizada comunicação no caso de mudanças?

Pensar nos pontos acima é extremamente trabalhoso e tecnicamente complexo mas deixar isso de lado devido a falta de tempo pode ser uma decisão ruim no longo prazo.

Como obter melhores resultados?

+ Resultados / - Desculpas

Durante todos os exemplos que apresentamos nesse texto abordamos diversas atividades importantes mas eu acho que as que mais merecem destaque são:

  • A pessoa responsável pela integração precisa saber ouvir as necessidades de ambos os lados. Muito além de somente sistemas, estaremos sempre trabalhando com pessoas.
  • É necessário automatizar ao máximo o tratamento de possíveis erros e, caso não seja possível corrigir de forma automática, enviar notificações claras e com comunicação objetiva para as pessoas envolvidas no processo
  • O mercado de Enterprise tem complexidade e necessidades técnicas além do padrão. Se for trabalhar com pontas desse porte, é importante ter pessoal técnico qualificado para atender a essas necessidades.

Uma outra alternativa é buscar uma solução como o nosso serviço de integrações gerenciadas TunnelHub. Devido a grande quantidade de projetos de integração que tive durante minha vida profissional, percebi que colocar em prática todos esses princípios é extremamente complexo, principalmente se considerarmos a grande rotatividade – natural em um setor tão competitivo. Vi que seria muito interessante poder oferecer um serviço em que tudo isso seja levado em consideração e eles sejam responsáveis por todo o processo de integração.

Bom , o que eu gostaria de passar era isso! Em breve vou compartilhar alguns conteúdos mais técnicos com alguns exemplos práticos de boas práticas e implementações inteligentes. Estou sempre a disposição para bater um papo sobre integrações nas minhas mensagens.