Low-code ou sob medida: quem decide e com que critério

Em resumo

• Low-code é montar o sistema por configuração, com ferramentas como Power Apps e Power Automate, em vez de programá-lo linha a linha, e a decisão de até onde ele vai é conjunta: a área responde pelo processo, e a TI responde pela integração e pela sustentação.
• O critério prático é avançar o máximo possível com low-code e chamar o desenvolvimento sob medida só para o bloqueio que não tem contorno, e não para o processo inteiro.
• Seis perguntas decidem a escolha: volume de transações, integração com o sistema central, regra de cálculo, usuário externo, licença por usuário e quem sustenta depois que o fornecedor sai.
• Alto volume transacional, integração em tempo real com o sistema central e cálculo regulatório pesado são os casos em que o low-code não deve ser a base da solução.
• O erro mais comum é decidir pelo gosto de quem está na sala, seja a TI que só programa, seja a área que monta sozinha um aplicativo crítico sem dono.

Low-code ou sob medida: quem decide e com que critério?

Decidem juntas a área dona do processo e a TI, cada uma respondendo pelo que conhece: a área pelo volume, pelas regras e pelas exceções do processo, e a TI pela integração com os sistemas centrais, pela segurança e por quem mantém a solução depois da entrega. O critério é avançar o máximo possível com low-code e reservar o desenvolvimento sob medida para o ponto em que aparece um bloqueio sem contorno, em vez de escolher uma das duas abordagens para o processo inteiro.

É a lógica que a Microsoft descreve na orientação de adoção do Power Platform para modernização de aplicativos, que afirma que low-code não é uma decisão de tudo ou nada: primeiro se avalia se a solução inteira cabe, depois se alguma parte dela cabe, e o que não cabe pode ser coberto por código tradicional ligado ao restante. O mesmo texto recomenda treinar equipes de fusão, que misturam quem conhece o negócio e quem programa, e é essa combinação que sustenta a divisão de decisão descrita acima. A página fala de aplicativos antigos, mas o método de avaliação serve igual para um processo novo, que é o caso aqui.

Onde esta decisão entra na trilha do processo

Quem chegou até aqui já desenhou o processo e já decidiu que ele vale a automação, que foram as perguntas dos textos anteriores da trilha, "Mapear processo antes de automatizar" e "O que vale automatizar", e agora tem um desenho na mão e precisa saber como construir. A pergunta seguinte, qual ferramenta resolve o processo, será tratada num próximo texto, sem data fechada, porque só faz sentido escolher a ferramenta depois de saber até onde a configuração chega e onde começa o código.

Pense numa aprovação de reembolso que recebe algumas centenas de pedidos por mês, tem três alçadas e lança o pagamento no sistema financeiro no fim do dia. Quase tudo ali cabe em configuração, e a dúvida real se concentra em um ponto: o lançamento no financeiro, que precisa ser confiável e auditável. Sob medida, nesse contexto, significa uma equipe de desenvolvimento escrevendo código para o processo, hospedado e versionado como qualquer outro sistema, e a diferença que importa para o dono do processo é o que cada caminho exige depois da entrega.

Os seis critérios que decidem a escolha

Os critérios abaixo são perguntas que a área e a TI respondem juntas, por escrito, antes de aprovar o orçamento, e cada uma aponta para um lado com bastante clareza quando a resposta é honesta. Nenhuma delas decide sozinha, mas duas respostas "sob medida" no mesmo processo costumam indicar que o desenho precisa ser dividido, com a parte crítica em código e o restante em configuração.

Volume de transações

O low-code atende bem o volume que vem de pessoas, como pedidos, aprovações, formulários e cadastros, que chega em ritmo humano mesmo em empresas grandes. O volume que vem de máquina é outro problema, como o lote que carrega milhares de linhas toda madrugada ou o pico de fechamento do mês em que tudo dispara ao mesmo tempo, e aí o Power Platform aplica limites de requisições por licença e por período que o fluxo precisa respeitar, o que na prática vira lentidão ou falha no pior horário. A pergunta para o dono do processo é quantas operações acontecem por dia, em que dia do mês elas se concentram e se o pico é gerado por pessoas ou por outro sistema.

Integração com o sistema central

Quando o sistema central tem conector pronto ou API e o processo tolera que a informação chegue em alguns segundos ou minutos, o low-code integra sem drama, e o conector personalizado permite ligar qualquer API REST que não tenha conector pronto. O que não cabe é o processo que precisa gravar no sistema central em tempo real, com confirmação transacional, porque a falha no meio do caminho exige tratamento de erro e reversão que um fluxo configurado faz mal. O meio-termo costuma ser o melhor desenho: a regra e a gravação ficam numa API sob medida, e o aplicativo ou o fluxo consome essa API pelo conector, que é justamente o padrão híbrido que a Microsoft recomenda.

Regra de cálculo complexa

O Power Fx, linguagem de fórmulas do Power Apps inspirada no Excel, resolve bem a regra que a área já sabe escrever na planilha, como alçada por valor, desconto por faixa ou prazo por tipo de pedido. A regra que muda por lei, que precisa de teste automatizado e de histórico de quem alterou o quê para uma auditoria, como cálculo de imposto, de provisão ou de comissão com dezenas de exceções, deve viver em código com testes e ser exposta por API. O teste simples é perguntar o que acontece se a regra estiver errada por uma semana: se a resposta for um erro corrigível, fórmula na tela basta, e se for autuação ou perda financeira, a regra merece ciclo de desenvolvimento.

Usuário externo

Quando o usuário é fornecedor, cliente ou parceiro, o aplicativo muda de natureza, porque a identidade fica fora da empresa, o acesso precisa de regras próprias e a segurança passa a ser exigida por quem está de fora. O Power Pages existe para esse cenário e atende bem o portal de cadastro ou de acompanhamento de pedido, mas tem modelo de licenciamento próprio, então a conta não é a mesma do aplicativo interno. Portal de autoatendimento simples cabe em low-code, e portal com alta audiência, identidade complexa ou experiência muito personalizada tende a ir para sob medida.

Licença por usuário

O low-code troca custo de desenvolvimento por custo de licença, e a conta muda conforme o número de usuários e a frequência de uso. Para uma equipe pequena que usa o aplicativo todo dia, a licença é irrisória perto de meses de programação, e para milhares de usuários que abrem o sistema uma vez por trimestre ela pode superar a hospedagem e a manutenção de um sistema próprio. Por isso a comparação precisa ser feita dos dois lados, com o preço vigente na documentação de licenciamento, e incluir no sob medida o que costuma ficar fora da proposta: hospedagem, atualização de dependências e segurança contínua.

Quem sustenta depois que o fornecedor sai

Este é o critério que mais pesa e menos aparece na escolha, porque a pergunta só dói meses depois da entrega. O low-code sem dono para quando o autor muda de área, e o sob medida sem repositório e documentação fica refém de quem escreveu, então nos dois casos é preciso saber quem corrige na segunda-feira seguinte a uma mudança de regra e quem renova uma conexão que expirou. No low-code, o que torna isso viável são os ambientes e as soluções, que levam o que foi construído do desenvolvimento à produção de forma controlada, e os ambientes gerenciados, em que a TI limita quem compartilha e quais conectores são usados. Se ninguém na empresa pode assumir essa manutenção, ela precisa ser combinada junto com a construção, e não depois dela.

Em sequência, as três primeiras perguntas funcionam como filtro de bloqueio, e a figura abaixo mostra a ordem em que a conversa com a TI costuma andar mais rápido.

O caminho do "não" até o low-code só vale com dono nomeado, ambiente de produção e alguém que sustente depois da entrega.

A armadilha: escolher pelo gosto de quem está na sala

Numa reunião de levantamento, a TI chega com a resposta pronta, porque o que sabe fazer é programar, e a aprovação de reembolso que sairia em prazo curto entra na fila de projetos do semestre. Na sala ao lado, um analista animado com a ferramenta monta sozinho, no ambiente pessoal, um fluxo que lança pagamento no financeiro, e funciona tão bem que três áreas passam a depender dele. A escolha nos dois casos foi feita pelo conforto de quem decidiu, e não pelos critérios do processo.

O custo aparece depois, e de formas diferentes: no primeiro caso o processo espera enquanto a área volta para a planilha, e no segundo o analista muda de cargo, a conexão expira e ninguém sabe onde o fluxo roda nem quem pode mexer nele. A defesa contra os dois é a mesma, que é registrar a decisão com os seis critérios, nomear um dono por parte da solução e usar as regras de governança que a própria plataforma oferece, como as do CoE Starter Kit, um conjunto de orientações e ferramentas para organizar quem constrói o quê dentro do Power Platform.

Quando não usar low-code

Não use low-code como base da solução quando o processo tem alto volume transacional, quando exige integração em tempo real com o sistema central ou quando depende de cálculo regulatório pesado. Nesses três casos o problema não é falta de recurso na ferramenta, e sim a combinação de limite de requisições, tratamento de falha e necessidade de teste e auditoria, que pede engenharia de software tradicional, com repositório, testes automatizados e pipeline de entrega.

A mesma documentação da Microsoft lista, do lado do usuário, outros cenários em que o ajuste é ruim: dispositivos que dependem de drivers ou APIs específicos, grande volume de dados trazido para o aplicativo e requisitos offline complexos. Isso não significa jogar o processo inteiro para sob medida, porque muitas vezes a tela e o fluxo de aprovação continuam em low-code e só o núcleo crítico vai para código, conectado por API. O erro é o contrário, forçar a configuração até o ponto em que ela passa a ser contornada com gambiarras que só o autor entende.

O que levar para quem aprova

Propomos construir o processo em low-code até o limite em que volume, integração em tempo real ou cálculo regulatório exijam código sob medida, e só essa parte vai para desenvolvimento, o que entrega mais cedo o ganho de prazo e de histórico de aprovação sem abrir mão do controle do que é crítico. O risco de não decidir com critério é duplo: o processo espera na fila de projetos da TI, ou um aplicativo crítico nasce sem dono e para no primeiro afastamento de quem o montou. O próximo passo é a área e a TI preencherem juntas os seis critérios por escrito, com o responsável pela sustentação de cada parte nomeado, antes da aprovação do orçamento.

Se for útil, a Trinapse monta com a sua área o quadro dos seis critérios aplicado ao seu processo, e na etapa de manter o que foi construído atua pela oferta de Operação de Processos e Agentes, que cuida de quem corrige, atualiza e responde depois da entrega.