Há uma pasta no repositório da Training App chamada _powerplatform/. Lá dentro estão cerca de quarenta fluxos Power Automate: praticamente toda a lógica da primeira versão da aplicação. Está marcada como só de leitura (o que faz dela a única pasta do repositório garantidamente livre de bugs novos). Ninguém os executa; são lidos. Mudei de tecnologia, fiquei só com as regras de negócio.
A Training App nasceu em 2019, depois de a nossa atividade de formação ter crescido depressa — e depois de um susto. A Swell geria então milhares de formandos e formadores, ações espalhadas pelo país, inscrições e cursos online a partir de uma folha de Excel.
Durante bastante tempo, funcionou. Depois vieram a escala, as exigências da certificação DGERT e os primeiros problemas operacionais.
Com várias ações a decorrer em simultâneo, um erro numa data levou formandos a aparecerem à porta de uma sala no dia errado. Alguns tinham viajado até Lisboa de propósito; reembolsei-lhes as deslocações.
O episódio obrigou-me a olhar para a folha de outra forma. Onde havia células, deviam existir regras. A regra “uma sessão tem uma data e todos os inscritos são avisados quando ela muda” existia apenas na minha cabeça. A minha cabeça não escala nem envia emails.
Do Excel às regras
Nesse ano, o ciclo de uma entidade formadora certificada ganhou um sistema: cursos, ações, sessões, inscrições, formadores e boa parte do dossier técnico-pedagógico exigido pela DGERT passaram a obedecer a regras explícitas.
O sistema corria em Power Platform: dados no Dataverse, lógica em fluxos Power Automate e interfaces em Power Apps. Serviu-nos durante seis anos.
Quando decidimos transformar a aplicação interna num produto para outras entidades formadoras, o problema mudou de natureza. Uma aplicação interna tolera atalhos que um produto multicliente não pode tolerar. Isolamento de dados entre clientes, diferentes planos comerciais, gestão de licenças, controlo de acesso e conformidade auditável não são funcionalidades que se acrescentam no fim. Têm de estar na fundação.
Subestimei essa transição. Conceber um produto é bastante mais difícil do que desenvolver uma boa aplicação interna.
No início de 2026, reconstruí a Training App: PostgreSQL, Azure Functions e Next.js. Da versão anterior, não corre hoje uma única linha em produção.
Isso não significa que tenhamos começado do zero.
O código ficou mais barato
Há uma razão pela qual esta reconstrução se tornou economicamente possível. Fi-la sem uma equipa de engenharia. Os assistentes de programação baseados em IA reduziram drasticamente o custo de produzir a camada de execução: frontend, endpoints, testes, migrações de base de dados e infraestrutura como código.
Esse ganho é importante, mas interessa-me sobretudo pelo que não fez.
Os assistentes não inventaram as regras da Training App.
Esses vieram de seis anos a gerir uma entidade formadora e dos fluxos que fomos construindo à medida que surgiam problemas, exceções e novos requisitos. A IA implementou-os rapidamente porque grande parte do trabalho de descobrir o que o sistema deveria fazer já tinha sido feito.
Escrever código tornou-se muito mais barato. Descobrir as regras certas não.
O que sobreviveu à migração
Cada fluxo Power Automate continha conhecimento operacional acumulado.
Quando uma inscrição é confirmada, gera-se um contrato e é enviado um questionário. Quando uma sessão termina, registam-se presenças e recalcula-se a assiduidade. Quando uma ação fecha, determinados documentos são produzidos segundo uma sequência definida. Há dezenas de regras deste género, muitas delas acompanhadas por exceções que só apareceram depois de casos reais.
Na reconstrução, estes fluxos serviram como parte do caderno de encargos.
Uma das partes caras de qualquer migração é descobrir o que o sistema antigo realmente faz. Neste caso, muito desse trabalho estava visível. Os fluxos tinham sido construídos lentamente, ao longo de seis anos de produção.
Havia, no entanto, um problema prático. O Power Automate apresenta a lógica num editor visual, pouco adequado a uma migração sistemática assistida por agentes. Em vez de trabalhar a partir de capturas de ecrã, liguei o repositório à Power Platform e extraí a definição dos fluxos em JSON — a representação estruturada que existe por baixo do desenho visual.
Os agentes conseguiam então analisar cada definição, identificar condições, ações e dependências e ajudar-me a reconstruir a regra na arquitetura nova.
Foi nesse processo que apareceu uma segunda conclusão: mesmo uma regra escrita conserva uma parte implícita. Um fluxo pode dizer o que acontece perante determinada condição sem explicar por que razão aquela condição existe, que exceção histórica a criou ou se continua a fazer sentido. Essa parte teve de ser discutida e clarificada, regra a regra.
O verdadeiro custo da arqueologia
É também por isso que sistemas muito antigos sobrevivem durante tanto tempo.
Em 2017, a Reuters estimava que existiam cerca de 220 mil milhões de linhas de COBOL ainda em produção, sustentando uma parte substancial da infraestrutura bancária mundial. O COBOL foi introduzido em 1959.
A explicação não é apenas que os bancos gostam de tecnologia antiga. Décadas de software em produção contêm décadas de exceções resolvidas, regras regulatórias, convenções e decisões que deixaram de existir em qualquer outro sítio.
Substituir o código é apenas uma parte da migração. A arqueologia consiste em descobrir as regras que ficaram enterradas dentro dele — incluindo aquelas cuja existência ninguém já conhece.
Este é também o contra-argumento sério a qualquer reconstrução. Cinquenta anos de produção são cinquenta anos de casos-limite resolvidos. Mexer num sistema desses implica o risco de eliminar uma regra antes sequer de perceber que ela existe.
Mas isso reforça a ideia central: grande parte do ativo acumulado não está na sintaxe do código. Está no conhecimento operacional que ele passou a incorporar.
Uma vantagem pouco discutida do low-code
O low-code tem custos conhecidos: dependência do fornecedor, restrições arquiteturais e modelos de licenciamento que podem tornar-se caros à escala.
Mas a experiência da Training App mostrou-me uma vantagem a que se dá menos atenção: parte da lógica operacional fica exposta de forma relativamente acessível. No Power Automate, a especificação e a implementação estão muito próximas uma da outra.
Isso não torna automaticamente um fluxo simples nem bem desenhado. Há fluxos perfeitamente ilegíveis. Mas, quando a lógica foi construída com alguma disciplina, torna-se possível observar o processo, as condições e as exceções sem começar por escavar milhares de linhas de software.
No meu caso, essa visibilidade reduziu bastante o custo da reconstrução.
Quando uma regra sobe para a arquitetura
Nem todas as regras voltaram para a nova aplicação da mesma forma.
Algumas subiram de estatuto.
O isolamento entre clientes é um exemplo. Na primeira versão, várias regras de aplicação ajudavam a garantir que cada utilizador via os dados certos. Na nova, parte dessa garantia é imposta pela própria base de dados através de row-level security. Uma consulta devolve apenas os dados do cliente ativo mesmo que exista um erro numa camada superior da aplicação.
A diferença interessa para além da engenharia. Uma coisa é um fornecedor dizer que os dados dos clientes estão separados. Outra é a separação ser uma propriedade técnica do próprio sistema.
Uma regra importante pode começar como uma instrução num processo. Com maturidade suficiente, algumas merecem tornar-se propriedades que o sistema não permite violar.
Onde estão escritas as regras da tua empresa?
É a pergunta que passei a levar para projetos de consultoria antes de discutir ERP, CRM, aplicações ou IA.
Onde estão escritas as regras de negócio?
Podem estar em software. Podem estar num Excel. Podem estar em documentos de procedimentos que ninguém abre há quatro anos. E podem estar na cabeça do Fernando, que toda a gente consulta quando aparece um caso estranho.
Se uma parte importante estiver apenas no último sítio, o orçamento da próxima migração será também um orçamento de arqueologia.
O mesmo problema aparece agora com agentes de IA. Um agente capaz de recomendar, aprovar ou executar trabalho precisa de saber quais são os critérios, quais são as exceções, quando deve parar e quem responde pelo resultado. Quanto mais autonomia recebe, menos espaço existe para regras que só alguém “sabe como funcionam”.
Não começámos a escrever as regras da Training App por disciplina arquitetural. Começámos depois de alguns erros suficientemente caros para nos obrigarem a fazê-lo.
Seis anos depois, o código que escrevemos nessa altura desapareceu. As regras ficaram.
Entre em contacto com a Swell.
Post Views: 44
