Leonardo Peron5 min de leitura
A pergunta aparece depois que a primeira já foi respondida. Alguém decidiu que os sistemas precisam conversar, e agora surge a bifurcação: contratar uma plataforma que já sabe falar com os dois lados, ou escrever a conexão direta. Hub de integração, plataforma de integração, iPaaS: nomes diferentes para a mesma ideia de um intermediário no meio do caminho.
A resposta honesta não é uma das duas. É saber o que se compra e o que se paga em cada uma, porque a decisão erra por motivo previsível: comparar o preço da licença com o preço de escrever, e ignorar o resto.
O que o hub realmente é
Um middleware empacotado como produto. Ele traz conectores prontos para sistemas conhecidos, uma tela onde se define de qual campo para qual campo o dado vai, um motor que executa isso no horário ou no evento, e um registro do que passou.
A promessa é tirar do seu time o trabalho que não é do seu negócio: descobrir como o outro lado autentica e o que ele chama de pedido. A promessa é real; o que fica mal dimensionado é a fronteira dela.
O que ele resolve de verdade
O conector já foi escrito por outra pessoa. O levantamento é a fase mais longa e menos visível de qualquer integração: ler documentação, testar o que ela não diz, descobrir o campo que só aparece em certo tipo de pedido. Quando o conector cobre o seu caso, esse tempo não acontece.
O monitoramento vem junto. Painel de execução, histórico por mensagem, fila de erro e reprocesso são a parte que times internos deixam por último e às vezes nunca fazem: a diferença entre saber que uma troca parou e descobrir pelo cliente, que é o assunto de a fila que ninguém olha. Num hub, isso é o produto.
Alguém mantém quando a API do outro lado muda. É o item mais subestimado e provavelmente o de maior valor. Plataforma de venda e marketplace mudam regra, campo e obrigatoriedade por conta própria, e a integração quebra sem ter sido tocada. Com conexão direta, essa sustentação é sua para sempre, sobre código que ninguém abre há meses. Com hub, está no contrato de quem vendeu o conector.
O que ele cobra por isso
O preço quase nunca é por sistema conectado. É por transação, por execução, por volume de mensagens ou por conector ativo, e o modelo importa mais que o valor, porque é ele que decide como a conta cresce.
Há um custo fora da fatura: a lógica de mapeamento passa a morar dentro do produto. Ela existe em telas, não num repositório que você versiona, revisa e leva embora. Trocar de hub depois significa refazer o mapeamento inteiro. É por isso que a decisão se comporta como escolha de longo prazo mesmo sendo vendida como assinatura mensal.
E há um teto de expressividade. Enquanto o fluxo for "pegue este campo e ponha naquele", a tela resolve. Quando entra regra própria (rateio entre filiais, tabela de preço por cliente, reserva de saldo com critério seu), ela vira código dentro do hub, numa linguagem que só serve ali, ou vira um serviço fora dele, e o hub deixa de ser a plataforma para virar mais uma peça no caminho.
Quando o custo por transação vira o problema
Não quando o negócio cresce. Quando o número de mensagens cresce mais rápido que a receita. São coisas diferentes, e é essa diferença que pega as pessoas de surpresa.
Um pedido é uma mensagem. Mas a atualização de saldo de um catálogo grande é uma mensagem por item por rodada, o status de entrega gera várias por pedido, e a sincronização de cadastro dispara sem ninguém ter vendido nada. A conta que engorda raramente é a do pedido: é a do tráfego de manutenção em volta dele, que também é o que esbarra em limite de requisições.
A projeção honesta, então, não se faz sobre pedidos por mês: faz-se listando cada fluxo, quantas mensagens ele produz por rodada e quantas rodadas existem por dia. Se o número cresce com o catálogo em vez de crescer com a venda, essa é a variável a vigiar.
Quando o hub é claramente a escolha certa
Quando os fluxos são poucos e padrão, entre sistemas populares, sem regra própria no meio do caminho. Quando não há time técnico interno para sustentar código de integração, e sustentar é o verbo que decide, não construir. E quando integrar é meio, não produto: a empresa vende outra coisa e precisa que isso funcione sem virar assunto.
Ele também é uma ponte legítima. Entrar com hub agora e trocar depois o que ficar caro é defensável, desde que a troca seja considerada desde o começo em vez de descoberta na renovação.
O que levantar antes de decidir
- A lista de fluxos, com quantas mensagens cada um gera por dia, não quantos pedidos a empresa faz.
- Quais desses fluxos têm regra que não cabe em "de tal campo para tal campo".
- Se existe conector pronto para os seus sistemas nas versões que você usa. Conector que trata pedido mas não trata devolução resolve metade.
- Quem sustenta o que sobrar de fora, e se essa pessoa existe.
- Como o mapeamento sai de lá, caso um dia precise sair.
- O que muda se a resposta for direta: as mesmas variáveis aparecem em o que determina o prazo, e a decisão anterior a esta está em o que é integração de ERP e no levantamento.
O teste que separa é o quinto item. Se ninguém souber dizer como o mapeamento sai do produto, a decisão não é sobre custo por transação, é sobre para quem vai a chave da sua operação.