Uma das grandes preocupações de gestores de diversas áreas ao contratar um sistema é conseguir conectar o fluxo de informações de maneira precisa entre outros sistemas já existentes no contexto da empresa.
A grande maioria das empresas de SaaS (Software as a Service) possui uma série de integrações nativas no estilo plug and play desenvolvidas por uma das partes para facilitar a vida do usuário e agregar valor ao serviço oferecido.
Porém o que acontece quando o seu sistema não está nas nuvens ou não existe uma integração nativa entre os dois sistemas?
Neste caso, para que os dados sejam enviados de um lugar a outro, é necessário que uma integração seja desenvolvida. Certo, mas quem fará o desenvolvimento?
Quais são os pré-requisitos? Quais facilidades meu sistema tem que ter? Quanto dinheiro tudo isso vai me custar?
Neste artigo explicarei termos muito comuns entre desenvolvedores que são essenciais para que você não fique perdido ao ser questionado sobre como você espera que a integração ocorra e entenda como uma precificação é calculada.
1 – Middleware
Se você escutar este termo durante a negociação, entenda que ele nada mais é que a integração em si. É um serviço ou software que será responsável pela conversão, formatação e transmissão dos dados de um sistema a outro.
A complexidade e por consequência o custo do middleware variará de acordo com a quantidade de entidades que deseja-se sincronizar (clientes, vendas, negócios).
2 e 3 – API e Webservices
A primeira pergunta que o fornecedor de serviços de desenvolvimento fará é se seu sistema possui API ou Webservices.
API é a sigla para Application Programming Interface. APIs e Webservices têm a mesma função: disponibilizar seus dados nas nuvens para que outros softwares devidamente autorizados possam se conectar e assim transmitir ou receber dados via automações. São interfaces que restringem e formatam o acesso a estes dados.
Em uma analogia com o mundo real, o sistema a ser integrado é o banco, os dados são o dinheiro, a API é o caixa eletrônico, os outros softwares são os clientes que fazem o saque com senha e a Internet é a rua ou espaço público.
Meu sistema não está nas nuvens nem possui API/Webservices – $$$$$
O desenvolvedor será responsável por criar esta interface com sua base de dados utilizando alguma linguagem de programação, além de disponibilizar o acesso a esta interface de maneira segura nas nuvens.
Pelos fatores horas de trabalho e nível de conhecimento técnico (banco de dados, redes, programação), o grau de complexidade e custo da integração entre sistemas aumentará drasticamente, podendo até dobrar.
Meu sistema possui API/Webservices – $
Este é o melhor cenário. Seu prestador de serviços vai gostar disso.
4 e 5 – JSON e XML
Padrões de formatos de dados, estas são siglas que com certeza você deve ter ouvido diversas vezes. Entenda que para um sistema transmitir ou receber dados através de interfaces públicas, é necessário que estes dados sejam enviados sempre no mesmo formato.
Semelhante a como nos comunicamos em português, na escrita ou fala, sistemas também precisam falar a mesma língua. JSON e XML são as “línguas” mais utilizadas no momento.
JSON – $
Este é o formato mais utilizado na Internet. Acrônimo para JavaScript Object Notation, possui diversas vantagens e facilita muito o desenvolvimento, além de ser o preferido pela maioria dos desenvolvedores.
A quantidade de “texto” enviada na transmissão de dados é significativamente menor que XML. Uma interface que “fale” JSON reduzirá o custo da integração entre sistemas em comparação ao XML.
XML – $$
Acrônimo para Extensible Markup Language, é um formato de dados utilizado em sistemas mais complexos, pois oferece algumas vantagens em possibilidades técnicas, já que o JSON é um formato muito simples.
É mais difícil encontrar um desenvolvedor que saiba trabalhar XML com maestria, portanto o custo da integração pode encarecer minimamente.
Outros formatos – $$$
Existe a possibilidade de algum outro formato ser a língua que seu sistema conversa. Exemplo: CSV e TXT. Nestes casos em específico, a comunicação é feita através da troca de arquivos. Menos usuais que o XML, podem encarecer o serviço.
Neste caso até a forma de se comunicar pode ser diferente. Ao invés do tradicional HTTP, pode-se utilizar o FTP. São os próximos termos.
6 e 7 – HTTP e FTP
Você lê esses termos diariamente (pelo menos o HTTP), mas já se questionou o que significam? São protocolos de troca de mensagens. Considerando que JSON e XML são línguas, HTTP e FTP são como a fala ou a escrita.
Você pode escolher se comunicar com outra pessoa falando em português ou escrevendo em inglês, mas a mensagem que deseja passar é a mesma. Existem diversos outros protocolos, mas falando de integrações entre sistemas, estes são os mais utilizados.
HTTP – $
O HyperText Transfer Protocol é um protocolo extremamente popular. Você digita ele todos os dias para acessar sites no seu navegador.
Ele determina como as mensagens do seu computador para um site e vice-versa são enviadas. Também é o protocolo mais utilizado nas integrações entre sistemas e se este não for o caso da sua integração, espere um aumento no custo do projeto.
FTP – $$$
O File Transfer Protocol é um protocolo voltado à transferência de arquivos. Por isso é provável mas não obrigatório que uma integração que converse em CSV ou TXT ocorra desta forma.
A mensagem do HTTP comumente carrega um formato de dados de texto (JSON, XML) e a mensagem do FTP carrega um formato de dados de arquivo (CSV, TXT). Pode ser visto em integrações entre sistemas de ERP antigos.
Outros protocolos – $$$$
Existem muitos outros protocolos para muitas outras finalidades, porém não é comum que sejam utilizados em integrações, portanto se este for o caso, o valor do desenvolvimento poderá crescer consideravelmente.
8 – VPN
Virtual Private Network ou Rede Virtual Privada pode ser uma exigência do seu departamento de T.I. ao decidir que para acessar o servidor onde se encontra o sistema de sua empresa, a comunicação (HTTP ou FTP por exemplo) seja feita de maneira ultra segura.
Estabelecer a comunicação entre dois servidores através de uma VPN é como conectá-los em uma rede local, onde as mensagens trocadas não podem ser interceptadas de nenhuma forma, pois são totalmente criptografadas.
A grande vantagem é não precisar abrir as portas de seu servidor para a Internet. Não ter uma VPN não significa que as mensagens de sua integração serão roubadas, pois alguns protocolos de mensagens também possuem sua versão criptografada, como o HTTPS (o S significa “seguro”).
Preciso de uma VPN – $$$$
Configurar uma VPN não é um trabalho fácil para qualquer desenvolvedor. Normalmente exige-se conhecimento avançado em redes. Isso encarecerá seu projeto consideravelmente.
Não preciso de uma VPN – $
É o cenário mais comum, pois como citei, existem o HTTPS ou o FTPS, as versões criptografadas do HTTP e FTP. A grande maioria dos desenvolvedores está acostumada a programar desta forma. A autenticação será feita através de uma chave.
9 e 10 – Webhooks e Polling
Imagine que sua integração seja enviar um pedido de venda do CRM ao ERP. Como a integração saberá quando enviar a mensagem de um sistema a outro? Como ela ficará sabendo que o pedido foi criado? Para quem está negociando parece pouco importante, mas este fator interfere no trabalho do desenvolvedor.
Webhooks – $
Webhooks são mensagens disparadas geralmente em HTTP e JSON imediatamente após a ocorrência de um evento pré-determinado.
Exemplo: quero que quando um pedido de venda for criado ou alterado, meu sistema envie uma mensagem instantânea para algum endereço na Internet avisando do ocorrido e para isso preciso criar um webhook.
Também podem ser chamados de notificações de alteração em certos sistemas. Sistemas que possuem webhooks facilitam muito o trabalho de um desenvolvedor, portanto resultam em uma redução de preços.
Polling – $$
Quando o sistema não possui webhooks, a sua integração não tem como saber quando deverá enviar uma mensagem de um lugar a outro.
Neste caso é necessário que haja uma verificação periódica neste sistema, em que a integração faz uma busca ativa na API atrás de mudanças nos dados.
A complexidade deste desenvolvimento é maior que trabalhar com webhooks.
Exemplos: Integrar o Ploomes com seu ERP
Exemplo 1: uma integração que sincronize clientes, produtos e pedidos de venda entre o CRM do Ploomes e um ERP instalado em seu servidor que não possui API, conversa em XML e HTTP e não possui webhooks. Seu departamento de T.I. não vai abrir a porta do HTTPS para receber chamadas externas na API que será desenvolvida e portanto exige uma VPN.
1. Sincronizar clientes, produtos e vendas no middleware em uma via de mão dupla.
- Clientes – $$$
- Produtos – $$$
- Vendas – $$$
2. Conectar com o Ploomes.
- Possui API – $
- JSON – $
- HTTP – $
- Possui webhooks – $
- Autenticação por chave – $
3. Conectar com o ERP.
- Não possui API – $$$$$
- XML – $$
- HTTP – $
- Não possui webhooks – $$
- VPN – $$$$
Exemplo 2: agora suponha que o mesmo ERP instalado em seu servidor possui API, conversa em JSON e HTTP e possui webhooks. Seu departamento de T.I. vai abrir a porta do HTTPS para receber chamadas externas na API existente. Como fica a conexão com o ERP:
- Possui API – $
- JSON – $
- HTTP – $
- Possui webhooks – $
- Autenticação por chave – $
Total exemplo 1: $$$$$$$$$$$$$$$$$$$$$$$$$$$$
Total exemplo2: $$$$$$$$$$$$$$$$$$
Considerações finais
Estes são os principais fatores que afetam o valor de um projeto de integração entre sistemas.
Outros pontos poderão afetar o orçamento de forma menos significativa, como por exemplo se o sistema precisa de uma autenticação via OAuth, porém este método de autorização é tradicional entre integrações plug and play, que não é o caso tratado aqui.
Conhecer estes termos é essencial para entender a complexidade do que será desenvolvido. Todas as estimativas de pesos foram feitas com base na experiência dos parceiros desenvolvedores da Ploomes.
