Construir a ponte enquanto se atravessa: a jornada pragmática de Benefícios até a plataforma da Flash

Quando a Flash deixou de atuar apenas com benefícios e passou a ampliar sua oferta para uma plataforma integrada de gestão de pessoas e despesas, precisávamos fazer o sistema que já existia funcionar em uma arquitetura completamente nova. Diante de um prazo curto e de uma transformação ampla, mantivemos o SPA em operação, criamos um novo build como microfrontend e conduzimos a mudança de forma incremental, sem interromper o negócio.

A diferença entre um atalho e uma decisão pragmática

Decisões de engenharia acontecem sob restrições concretas. Prazo, risco, capacidade do time, necessidades do cliente e objetivos do negócio definem quanto de complexidade uma solução pode comportar naquele momento.

O pragmatismo aparece quando o time entende o problema mais urgente, torna explícitas as concessões da solução e preserva um caminho seguro para evoluir. A qualidade continua fazendo parte da decisão, assim como a responsabilidade pelo que será entregue e mantido depois.

Foi nesse espaço que nasceu uma das decisões mais importantes da integração de Benefícios à plataforma da Flash.

De um produto de benefícios para uma plataforma de gestão do trabalho

A Flash nasceu com um produto de benefícios. Na web, esse produto era uma Single Page Application (SPA), executada de forma independente.

Quando decidimos ampliar nossa atuação, começamos a construir uma experiência integrada: a Plataforma Flash, que passaria a reunir, em um único lugar, diferentes módulos da empresa.

Essa transformação aparece em perspectiva no artigo História da Flash, de Paulo Henrique. O PH percorre a evolução do produto, o crescimento da operação e o encontro entre arquiteturas diferentes até a consolidação dessa experiência integrada. É o mapa mais amplo de uma mudança que envolveu negócio, produto e tecnologia.

Este texto aproxima a lente de uma decisão específica daquela jornada. Para que a visão da plataforma integrada começasse a ganhar forma, o produto que havia dado origem à Flash precisava encontrar seu lugar na nova arquitetura. Benefícios teria que ser integrado à plataforma sem abandonar de uma vez a experiência que já sustentava a operação e atendia os clientes.

Essa mudança alterava a estrutura fundamental da plataforma. Os novos produtos seriam integrados à nova plataforma como microfrontends, permitindo que diferentes domínios evoluíssem com mais autonomia sem deixar de compor uma experiência única para o cliente.

Benefícios, porém, já existia, atendia nossos clientes e havia sido construído sobre uma arquitetura diferente daquela que estávamos adotando.

A nova plataforma precisava nascer com Benefícios disponível já no lançamento. Ao mesmo tempo, não seria razoável interromper a evolução do negócio para reescrever todo o frontend antes de colocar a plataforma no ar.

O mesmo produto precisava funcionar em dois mundos

O trabalho ia muito além de mover arquivos de um repositório para outro. Precisávamos fazer o mesmo código atender a dois contextos durante a transição:

- A experiência existente, na qual o SPA de Benefícios continuaria funcionando de forma independente para a base ainda não migrada.

- A nova experiência integrada da Flash, na qual Benefícios precisaria ser carregado como um microfrontend dentro da plataforma.

A alternativa mais confortável do ponto de vista arquitetural seria reconstruir toda a experiência de Benefícios no novo padrão antes de colocá-la na nova plataforma. O problema é que isso criaria uma dependência entre o lançamento da estratégia multiproduto e uma reescrita extensa de um sistema que já estava em produção.

Além do prazo, havia outro risco: estaríamos redesenhando toda a experiência antes de aprender como nossos clientes utilizariam a nova plataforma integrada.

A decisão foi preservar o que já funcionava e mudar a maneira como esse software poderia ser entregue.

Dois builds, uma única base de código

Mantivemos o build existente do SPA para os clientes que continuariam acessando Benefícios pela experiência anterior. Em paralelo, adicionamos um segundo processo de build, responsável por preparar a mesma aplicação para funcionar como um microfrontend.

Em termos conceituais, a arquitetura de transição se parecia com isto:

Para evitar uma substituição imediata do sistema antigo, encapsulamos o frontend existente e o preparamos para operar também no novo ambiente. A mesma base de código passou a gerar dois artefatos adequados a contextos diferentes.

A compatibilidade ficou nas bordas da aplicação

Compartilhar o núcleo da aplicação evitou a criação de duas versões do produto. As diferenças entre os ambientes foram tratadas nos pontos em que a aplicação se conectava à plataforma.

O código identificava o contexto em que Benefícios estava sendo executado e ajustava aspectos como:

- A navegação entre as experiências.

- A obtenção das informações de sessão.

- O registro de eventos de uso.

- A composição da interface, evitando repetir elementos que já pertenciam à plataforma.

- Alguns comportamentos e jornadas que precisavam variar entre a experiência antiga e a nova.

Essa camada de adaptação concentrava boa parte da complexidade da convivência entre os dois mundos. O núcleo do produto permanecia compartilhado, enquanto suas integrações respondiam ao contexto de execução.

A estratégia também existia no pipeline

Os dois artefatos tinham comandos e destinos próprios. Um processo gerava a distribuição standalone, enquanto o outro escrevia o microfrontend em uma saída separada. A esteira de CI mantinha jobs distintos para publicar as duas versões em preview, staging, pré-produção e produção.

Essa separação era importante para a segurança da migração. Cada experiência podia ser entregue e operada de forma independente, ainda que ambas compartilhassem a maior parte do código.

Isso permitiu que Benefícios estivesse presente na plataforma da Flash desde o lançamento sem exigir uma reescrita completa antes de colocarmos a plataforma no ar.

A primeira entrega ainda ficava aquém da experiência que buscávamos. Havia diferenças de produto, design e engenharia a resolver, porém a solução atendia à necessidade mais importante daquele momento: tornar real a proposta de uma plataforma integrada sem interromper o produto que sustentava o negócio.

Estrangular o legado sem interromper o negócio

A arquitetura com dois builds cumpria o papel de ponte entre o produto existente e a plataforma que queríamos construir

A partir dela, passamos a aplicar uma estratégia de estrangulamento: novas experiências eram construídas no novo padrão arquitetural e substituíam progressivamente partes do SPA. O sistema anterior continuava sustentando as jornadas ainda não migradas enquanto sua responsabilidade diminuía ao longo do tempo.

O fluxo de pedidos de benefícios mostra essa transição de forma concreta. Conforme uma nova jornada era lançada fora do legado, o SPA precisava reconhecer o novo contexto e encaminhar parte do comportamento para a experiência nova. Onde essa experiência ainda não se aplicava, o caminho anterior continuava disponível. Uma funcionalidade podia mudar de responsável sem exigir a substituição imediata de toda a aplicação.

Isso nos permitiu repensar o produto em partes menores. Cada nova experiência podia assumir uma parte da jornada sem exigir que todo o restante fosse reconstruído junto. O valor chegava ao cliente de maneira incremental, e o risco de cada mudança permanecia limitado.

Ao longo do processo, fomos reduzindo o espaço ocupado pelo SPA até que suas funções pudessem ser absorvidas pela nova estrutura de microfrontends.

O que fez dessa solução uma escolha pragmática?

O resultado inicial tinha limitações conhecidas. Por algum tempo, sustentamos dois builds, dois contextos de execução e uma experiência que ainda não representava por completo a visão da plataforma integrada.

A diferença estava na forma como assumimos a decisão. A dívida e as concessões eram conhecidas, e cada uma delas estava ligada a um objetivo concreto:

- O problema de negócio estava explícito: Benefícios precisava estar na plataforma da Flash desde a estreia da plataforma.

- As limitações da solução eram conhecidas e aceitas conscientemente.

- O produto existente continuava disponível durante a migração.

- A mudança podia ser distribuída em etapas menores e reversíveis.

- A arquitetura transitória tinha um objetivo: permitir que as novas experiências assumissem gradualmente as jornadas antes concentradas no SPA.

Para impedir que uma solução temporária vire dívida esquecida, é preciso definir responsáveis, limites, acompanhamento e uma estratégia de saída. Com esses elementos, a estrutura transitória se torna uma ferramenta para conduzir mudanças maiores com segurança.

O custo técnico fazia parte da escolha e foi assumido para viabilizar um resultado concreto de negócio.

O preço da decisão

O principal desafio apareceu quando as novas experiências começaram a nascer fora do legado. O SPA havia sido construído com a premissa de que controlava a jornada inteira: navegação, sessão, interface e sequência dos fluxos. Quando uma etapa passava a fazer parte da plataforma integrada, alguns trechos antigos precisavam ser adaptados para reconhecer que parte daquela experiência agora acontecia em outro contexto.

Isso exigia decisões caso a caso sobre responsabilidades que antes estavam concentradas em um único lugar. Quem iniciava o fluxo? Quem preservava o contexto da navegação? Qual ambiente deveria montar o próximo destino? Qual parte da interface ainda cabia ao legado?

Essas adaptações acrescentavam complexidade e pediam atenção contínua. O custo tinha uma função explícita: preservar a continuidade do produto enquanto a plataforma nova avançava sobre jornadas reais, sem obrigar a empresa a interromper a evolução do negócio para reconstruir tudo de uma vez.

Uma decisão pragmática pode exigir bastante trabalho de implementação. O critério está na relação entre valor, risco e capacidade de evolução dentro das restrições daquele momento.

No nosso caso, o custo de sustentar a transição era menor e mais controlável do que o risco de adiar o lançamento da plataforma integrada até que todo o produto de Benefícios fosse reescrito.

Ao escolher o caminho incremental, distribuímos o risco ao longo do tempo e preservamos a capacidade de ajustar a solução conforme a transição avançava.

O que aprendemos

Essa jornada deixou alguns aprendizados que continuam relevantes para decisões de arquitetura:

1. A melhor arquitetura depende do momento

Uma solução pode ser inadequada como estado final e, ainda assim, ser a melhor forma de atravessar uma transição. Avaliar uma arquitetura sem considerar prazo, risco e contexto de negócio produz uma visão incompleta.

2. O legado também carregava valor

Mesmo com suas limitações, o SPA concentrava anos de regras, jornadas validadas e familiaridade dos clientes. Reaproveitá-lo durante a transição preservou esse valor enquanto construíamos o futuro da plataforma.

3. Migrações incrementais criam espaço para aprender

Ao reduzir o tamanho de cada mudança, conseguimos compreender melhor as fronteiras entre o legado e as novas experiências. Cada adaptação ajudava a preparar a seguinte.

4. Toda solução transitória precisa de uma direção

Aceitar uma estrutura temporária sem saber o que ela viabiliza ou como será reduzida é apenas adiar um problema. No nosso caso, os dois builds existiam para permitir o estrangulamento progressivo do SPA.

5. A complexidade precisa ficar no lugar certo

Parte da complexidade foi concentrada em uma camada controlada, simplificando a evolução do produto e a migração dos clientes.

Resolver o problema que existe agora sem perder o futuro

Transformar Benefícios em parte da plataforma integrada da Flash exigia velocidade e responsabilidade com um produto que já era utilizado por nossos clientes. A solução nasceu com limitações conhecidas e com o propósito de viabilizar uma mudança de negócio muito maior sem apostar toda a operação em uma única entrega.

Mantivemos o sistema existente, adaptamos sua forma de execução, integramos Benefícios à plataforma da Flash e usamos o tempo conquistado para reconstruir a experiência de maneira incremental.

Foi uma decisão com concessões, custos e prazo de validade. E justamente por isso foi uma decisão pragmática.

Resolver problemas com pragmatismo exige escolhas proporcionais ao desafio, trade-offs explícitos e responsabilidade pelo que vem depois. Velocidade e qualidade entram na mesma equação: precisamos gerar valor no presente enquanto mantemos aberto o caminho para construir algo melhor.