iPaaS vs point-to-point vs middleware: como escolher

A maioria dos parques de integrações do mid-market nunca foi desenhada. Foi acumulada. Alguém ligou o CRM ao ERP porque uma encomenda tinha de chegar à área financeira. Outra pessoa ligou a plataforma de ecommerce porque o armazém precisava de preparar as expedições. Uma terceira ligou o sistema de armazém a uma transportadora. Cada decisão era sensata isoladamente e foi tomada por alguém competente, e o resultado agregado é um parque que ninguém consegue desenhar num quadro branco.

O custo disso chega mais tarde e de forma indireta. Surge como uma estimativa de projeto que parece desproporcionada face à alteração pedida, porque a alteração toca em quatro ligações não documentadas. Surge como uma atualização do ERP que fica bloqueada porque ninguém sabe o que depende de uma determinada interface. Surge como um relatório que não coincide com outro relatório por motivos que levam dois dias a rastrear.

Este artigo trata da decisão estratégica e não da ligação individual: que abordagem de integração adotar como padrão, quanto custa realmente cada uma ao longo da sua vida e — a pergunta que quase ninguém faz no momento da seleção — quanto custa abandoná-la.

O artigo 16 desta série aplica as mesmas opções arquitetónicas especificamente ao fluxo de encomendas de ecommerce. Este texto aborda a decisão ao nível de todo o parque.

Por que é que isto importa

A arquitetura de integração determina o custo da mudança, e o custo da mudança determina a rapidez com que uma empresa consegue fazer qualquer coisa.

Uma empresa do mid-market, ao longo de cinco anos, irá tipicamente acrescentar ou substituir vários sistemas: uma nova plataforma de ecommerce, um sistema de armazém, uma migração de CRM, uma aquisição que traz consigo o seu próprio conjunto de aplicações. A abordagem de integração escolhida hoje fixa o custo marginal de cada um desses acontecimentos. Uma plataforma bem governada torna cada um deles uma questão de semanas. Um parque point-to-point não documentado torna cada um deles um projeto com uma estimativa imprevisível.

Existe também uma dimensão de resiliência. Os parques point-to-point concentram o conhecimento em indivíduos, e as empresas do mid-market não retêm esses indivíduos durante toda a vida da integração. Quando a pessoa que escreveu a ligação sai, a ligação passa a ser uma caixa negra que todos contornam em vez de atravessar — que é a forma como os parques adquirem fluxos de dados duplicados e contraditórios.

E existe uma dimensão de auditoria que aparece nos momentos mais inconvenientes. Quando um número financeiro é questionado, a resposta exige frequentemente rastrear como é que os dados chegaram à razão geral. Um parque sem linhagem documentada não consegue responder a isso com rapidez, e «não temos a certeza de como este número chegou aqui» é uma frase desagradável à frente de um auditor.

Numa vista rápida: as três abordagens ao longo da sua vida

A linha que os clientes examinam menos e de que mais se arrependem é o custo de saída. A lógica implementada dentro de uma plataforma é expressa nos construtos dessa plataforma, e movê-la significa reimplementá-la e não migrá-la. Isto não é um argumento contra as plataformas — é um argumento a favor de manter um registo em linguagem simples do que cada fluxo faz, independente da ferramenta que o implementa.

O que funciona e sobre o que é preciso ser honesto

O que funciona:

Padronizar uma única abordagem, com exceções documentadas. O problema na maioria dos parques não é a abordagem escolhida — é que três abordagens coexistem sem que ninguém tenha decidido. Escolha uma como opção por omissão e exija justificação para se afastar dela.

Nomear um responsável antes de construir o primeiro fluxo. Os parques de integrações degradam-se por acumulação de fluxos não documentados. Um responsável com autoridade sobre nomenclatura, documentação e revisão evita isso. É a decisão de governação com maior valor e não custa nada.

Documentar cada fluxo independentemente da ferramenta. Para cada fluxo: origem, destino, objetos, sentido, evento desencadeador, regras de transformação em linguagem simples, comportamento em caso de erro, responsável. É isto que torna o parque compreensível para a pessoa seguinte, sobrevivível quando a plataforma mudar e defensável perante um auditor.

Tratamento centralizado de erros com triagem por agentes. Um tratamento de falhas consistente e visível em todos os fluxos é um dos argumentos mais fortes a favor de uma plataforma. Um agente que classifica as falhas, resolve as mecânicas e encaminha as restantes com o respetivo contexto é o que torna isto operacionalmente sustentável em vez de uma fila que ninguém lê.

Revisão periódica para retirar fluxos mortos. Os parques acumulam fluxos que servem processos que já não existem. Uma revisão anual, retirando o que não é usado, mantém o parque proporcional ao negócio.

Sobre o que é preciso ser honesto:

Uma plataforma não salvará uma empresa que não esteja disposta a governá-la. Plataformas sem governação tornam-se parques point-to-point com uma mensalidade de licença — a mesma lógica não documentada, numa interface mais agradável. A disciplina é o produto; a plataforma apenas torna a disciplina mais barata.

O preço em função do volume pode surpreendê-lo. Os custos de plataforma escalam com o volume de transações, e o tráfego de ecommerce e de marketplace escala de forma imprevisível. Modele os seus custos com o triplo do volume atual antes de se comprometer, e compreenda o que conta como transação faturável.

O middleware tradicional é normalmente a resposta errada à escala do mid-market. É capaz, e exige competências especializadas que as empresas do mid-market têm dificuldade em contratar, reter ou substituir. A exceção é uma empresa que já tenha a plataforma, já tenha as competências e tenha um parque substancial já construído sobre ela.

O point-to-point não está sempre errado. Para uma empresa com dois sistemas e sem planos de acrescentar mais, uma ligação direta bem documentada é proporcional. A falha não está em escolhê-lo — está em escolhê-lo repetidamente.

A migração é trabalho a sério, e o atraso agrava-a. Passar um parque existente para uma plataforma implica funcionar em paralelo, reconciliar e fazer o corte fluxo a fluxo. É um projeto genuíno. É também mais barato este ano do que no próximo, porque o parque continua a crescer.

Quadro de decisão: escolher e governar

Percorra por ordem. Pare na primeira correspondência.

1. Consegue desenhar o seu parque de integrações atual — cada fluxo, da origem ao destino?
Se não, produza primeiro esse inventário. Normalmente leva uma a duas semanas e rotineiramente encontra fluxos cuja existência ninguém conhecia, mais pelo menos um duplicado. Todas as decisões seguintes dependem de saber o que tem.

2. Tem exatamente dois sistemas a precisar de integração, sem planos de acrescentar mais?
Uma ligação point-to-point documentada é proporcional. Documente-a externamente e defina um evento desencadeador de revisão para quando aparecer um terceiro sistema.

3. Tem três ou mais sistemas, ou o plano de acrescentar um dentro de dois anos?
Padronize uma plataforma de integração. Atribua um responsável e defina normas de documentação antes do primeiro fluxo. A maioria das empresas do mid-market que leem isto está aqui.

4. Já tem middleware substancial e as competências para o operar?
Mantenha-o, e governe-o. Migrar um parque de middleware que funciona e está bem dotado de pessoas raramente compensa a disrupção. Reavalie quando as competências especializadas se tornarem difíceis de sustentar.

5. Está atualmente em point-to-point com três ou mais sistemas?
Planeie uma migração, sequenciada fluxo a fluxo fora dos períodos de pico, com funcionamento em paralelo e reconciliação. Comece pelo fluxo que falha mais frequentemente — o alívio operacional financia o capital político para os restantes.

6. Tem uma plataforma sem responsável nomeado e sem norma de documentação?
Corrija a governação antes de acrescentar fluxos. Está a acumular o problema que a plataforma foi comprada para evitar, e o custo de documentar retroativamente sobe todos os meses.

7. Parque governado, documentado e ainda assim caro de alterar?
É provável que a restrição esteja nos sistemas e não na integração — uma customização do ERP que torna um objeto padrão num objeto não padrão, ou um sistema sem uma API utilizável. Isso é um problema aplicacional, não de integração.

Custo e esforço indicativos

Pressupõe volumes de transações de mid-market e uma única instância de ERP. Parques multi-instância ou multientidade alargam estes prazos. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Como comparamos os custos das plataformas quando os modelos de preços são diferentes?
Modele o custo total a três anos com o volume projetado, e não com o volume atual, e estabeleça com precisão o que conta como unidade faturável — uma mensagem, um registo, uma execução de fluxo. Duas plataformas com preços de tabela semelhantes podem diferir substancialmente a volume real por causa da forma como contam.

O vendor lock-in é uma razão para evitar plataformas?
É uma razão para mitigar, não para evitar. Mantenha documentação independente da ferramenta sobre a lógica de negócio de cada fluxo e converte uma saída de um exercício de engenharia inversa numa reimplementação. A alternativa — point-to-point — tem o seu próprio lock-in, a pessoas concretas, que é mais difícil de gerir.

Onde é que os agentes encaixam?
Por cima de qualquer uma destas abordagens, a tratar exceções e não o transporte. A integração move os dados; o agente trata do que acontece quando o dado está errado, incompleto ou sem correspondência. Selecionar uma plataforma pela sua capacidade de agentes é razoável; esperar que um agente compense uma má adequação arquitetónica não é.

Devemos construir a nossa própria camada de integração?
Quase nunca à escala do mid-market. É um compromisso de desenvolvimento de produto — monitorização, novas tentativas, registo de eventos, gestão de credenciais, versionamento — a competir pela capacidade de engenharia que devia ir para o seu negócio real. A exceção é um requisito genuinamente invulgar que nenhuma plataforma suporta, algo mais raro do que as equipas acreditam.

Como justificamos isto quando neste momento nada está avariado?
Enquadre-o como custo da mudança e não como custo da falha. Pegue nos três últimos projetos que tocaram na integração e estime quanto de cada um foi gasto a compreender as ligações existentes. Esse número é o imposto recorrente, e é o caso de negócio honesto.

Depois de escolher, quanto tempo demora realmente a pôr um iPaaS ou uma camada de sincronização a funcionar?
Menos do que a maioria das equipas orçamenta, se a decisão acima for tomada primeiro. Um parceiro de implementação certificado — a Stacksync, especificamente para sincronização bidirecional em tempo real — costuma conseguir ter uma primeira integração em produção em poucas semanas. O que demora mais é exatamente aquilo de que trata este artigo: acordar o padrão, mapear o modelo de dados e decidir quem é responsável pelas exceções. Escolha a plataforma depois desse trabalho, não antes, e a implementação deixa de ser o obstáculo.

Fecho — Próximos passos

A estratégia de integração é uma decisão sobre o custo marginal de cada futura alteração de sistemas, tomada antes de se saber quais serão essas alterações. É por isso que os critérios que importam não são funcionalidades mas governação: quem é o responsável, como é documentada, como são tratadas as falhas e quanto custa sair.

O ponto de partida é o mesmo independentemente da linha do quadro em que se enquadre: inventarie o parque. Uma a duas semanas, e vai encontrar fluxos de que ninguém se lembra, pelo menos um duplicado e normalmente a razão pela qual um projeto recente custou mais do que o esperado.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora de NetSuite que serve clientes do mid-market em toda a Ibéria. É especializado em ligar sistemas CRM e ERP para fluxos de order-to-cash sem atritos, construindo pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comerciais e financeiras. Como partner oficial de implementação da Stacksync, Bruno desenha e coloca em produção agentes de IA em plataformas de integração para tratar do encaminhamento de exceções, do processamento de documentos e da reconciliação — transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são ao nível do editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de SuiteTalk e de integração — https://docs.oracle.com/en/cloud/saas/netsuite/
• Gartner, investigação sobre plataformas de integração e Magic Quadrant for iPaaS (em grande medida de acesso reservado a clientes) — https://www.gartner.com
• The Open Group, TOGAF — orientações de arquitetura aplicacional e de integração — https://www.opengroup.org
• Comissão Europeia, VAT in the Digital Age (ViDA) — implicações dos dados estruturados e da faturação eletrónica no desenho de integrações — https://taxation-customs.ec.europa.eu
• Experiência de projetos da Atypical Tech, parques de integrações do mid-market em toda a Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog