Introdução Change Data Capture (CDC) é uma técnica que identifica e registra todas as mudanças (inserções, atualizações e exclusões) feitas em uma fonte de dados, como um banco de dados relacional, e transmite essas mudanças para outros sistemas, possibilitando uma sincronização em tempo real. Essa abordagem é fundamental para várias arquiteturas de dados modernas que necessitam de informações atualizadas e consistentes entre sistemas distintos. Benefícios CDC traz uma série de benefícios que vão além da simples movimentação de dados. Os principais benefícios podem ser observados na lista abaixo. Redução de carga no sistema fonte, capturando apenas as mudanças e evitando leituras de dados massivas, o que resulta em menor custo de infraestrutura. Replicação de dados em tempo real, eliminando a latência que geralmente existe em processos de ETL tradicionais. Capacidade de rastrear alterações para auditoria, backup e reprocessamento em outras plataformas. Atualizações contínuas de data lakes e data warehouses, alimentando sistemas analíticos com dados atuais. Principais técnicas A implementação de CDC pode ser realizada de diferentes maneiras, cada uma com vantagens e limitações específicas. Conhecer essas alternativas ajuda a selecionar a solução mais adequada para o contexto de cada organização. As técnicas mais comuns estão apresentadas a seguir. Leitura de logs de transações: capta mudanças diretamente nos logs de transações, método utilizado por ferramentas como o Debezium. Colunas de timestamp: uso de uma coluna que registra a última modificação em cada linha. Ideal para sistemas que não possuem logs transacionais detalhados. Gatilhos (triggers): uso de gatilhos para registrar mudanças nas tabelas, embora possa impactar a performance. Diferenciação de snapshots: compara snapshots tirados periodicamente. É uma abordagem mais pesada e menos precisa. Técnicas Binlog (Log de Transações) O binlog, ou log de transações, é um arquivo que registra todas as operações feitas no banco de dados. Bancos como MySQL (binlog) e PostgreSQL (WAL) possuem logs transacionais que podem ser monitorados em tempo real para capturar mudanças. Essa abordagem é eficiente e precisa, pois capta toda alteração feita nos dados, mas exige acesso aos logs e permissões de leitura. A desvantagem é que nem todos os bancos têm logs de transação tão detalhados, e a configuração pode exigir ajustes na infraestrutura. Coluna de Timestamp Consiste na criação de uma coluna que registra a última alteração feita em cada linha de uma tabela. Ao consultar apenas as linhas alteradas desde a última execução, o sistema captura as mudanças incrementais. Essa técnica é simples e aplicável em qualquer banco de dados, porém não captura exclusões de dados e exige que todas as tabelas monitoradas incluam essa coluna. Triggers Os triggers ou gatilhos são funções definidas no banco de dados que executam ações quando um evento específico ocorre (como uma inserção, atualização ou exclusão). Com CDC, os triggers podem ser configurados para registrar essas alterações em uma tabela de histórico. Embora eficiente, esse método é geralmente evitado devido ao impacto de performance e à complexidade de manutenção. Diff entre Snapshots Consiste na criação de snapshots periódicos dos dados e na comparação entre eles para identificar mudanças. É um método trabalhoso e com maior impacto no sistema, pois requer processamento intensivo, sendo utilizado apenas quando outras abordagens de CDC não estão disponíveis. Ferramentas Abaixo algumas das principais ferramentas de Change Data Capture do mercado. Debezium: Ferramenta open-source que usa logs de transação para capturar mudanças em tempo real. Suporta bancos como MySQL, PostgreSQL, MongoDB, e outros, e é integrada ao Kafka, o que facilita a transmissão de dados em pipelines de dados distribuídos. Oracle GoldenGate: Ferramenta proprietária da Oracle para replicação e integração de dados em tempo real, compatível com vários sistemas de banco de dados. StreamSets: Plataforma de integração que inclui componentes para CDC em diversos bancos e fontes de dados. Qlik Replicate (Attunity): Solução robusta de CDC usada para replicação e sincronização de dados entre bancos de dados. Amazon DMS e Azure Data Factory: Soluções de CDC oferecidas nas respectivas plataformas de nuvem para replicação e sincronização de dados entre serviços. Airbyte: O Airbyte é uma plataforma open-source para integração de dados que oferece suporte a CDC através de diversos conectores, inclusive com monitoramento de logs de transação para bancos como MySQL e PostgreSQL. É uma opção flexível e expansível, com uma interface amigável que facilita a criação de pipelines de dados. O Airbyte tem uma ampla biblioteca de conectores e se destaca pela comunidade ativa e pela possibilidade de customização. Striim: O Striim é uma plataforma de integração de dados em tempo real que combina CDC com análises de streaming e processamento de eventos. Suporta várias fontes de dados, como bancos de dados relacionais, e pode transmitir dados para diversas plataformas, incluindo nuvens como AWS, Azure e Google Cloud. Sua arquitetura robusta permite a replicação de dados em grande escala e processamento em tempo real, sendo popular em casos de uso que requerem insights instantâneos a partir dos dados. Embora existam muitas ferramentas, focaremos no Debezium nesse artigo, uma popular opção de código aberto construída sobre o Kafka Connect, para ilustrar uma implementação prática. Kafka Connector O Kafka Connector é uma das funcionalidades principais do Kafka Connect, uma ferramenta da plataforma Apache Kafka projetada para simplificar e automatizar a integração entre o Kafka e outros sistemas, como bancos de dados, data warehouses, sistemas de armazenamento em nuvem e muito mais. O Kafka Connect funciona como uma camada de integração distribuída e escalável, que utiliza conectores especializados para transferir dados de forma confiável entre sistemas. Como o Kafka Connect funciona O Kafka Connect usa conectores, que são plugins especializados para cada tipo de sistema ou fonte de dados, divididos em duas categorias: Source Connectors: Capturam dados de uma fonte externa e os publicam em tópicos do Kafka. Sink Connectors: Consomem dados de tópicos Kafka e os escrevem em um sistema de destino. Os conectores são configurados por meio de arquivos de configuração JSON ou APIs REST, onde é possível definir a fonte ou destino de dados, informações de autenticação, configurações de replicação e transformações opcionais para adequar os dados ao formato desejado. Arquitetura do Kafka Connect A arquitetura do Kafka Connect é composta por workers, que são instâncias executando conectores de forma distribuída. Isso permite que o Kafka Connect: Escale horizontalmente conforme a carga de dados aumenta. Seja tolerante a falhas: se um worker falhar, outro pode assumir as tarefas. Centralize a configuração e monitoramento dos conectores. Os dados são processados em blocos chamados de tasks, que distribuem a carga de trabalho entre workers e possibilitam o processamento paralelo. "Nem tudo são flores" (limitações) Opções limitadas Há menos de 20 tipos diferentes de conectores no Kafka Connect. Se um conector genérico não for adequado, você deve desenvolver um personalizado. Da mesma forma, o Kafka Connect fornece apenas um conjunto básico de transformações, e você também pode ter que escrever suas transformações personalizadas. Isso pode aumentar o tempo e o esforço necessários para a implementação. Complexidade de configuração As configurações do Kafka Connect rapidamente se tornam complexas, especialmente ao lidar com vários conectores, tarefas e transformações. Isso pode dificultar o gerenciamento, a manutenção e a solução de problemas do sistema. Também é desafiador integrar o Kafka Connect com outras ferramentas que sua organização já pode estar usando. Isso cria uma barreira à adoção e retarda o processo de implementação. Suporte limitado para tratamento de erros O foco principal do Kafka é o streaming de dados, o que resulta em capacidades limitadas de tratamento de erros integrados. A natureza distribuída e as potenciais interdependências entre vários componentes do Kafka aumentam a complexidade, dificultando a descoberta da causa raiz do erro. Você pode ter que implementar mecanismos personalizados de tratamento de erros, o que pode ser demorado e nem sempre tão confiável quanto as capacidades integradas fornecidas por outras ferramentas de integração de dados e ETL. Recuperar-se graciosamente de erros complexos também é desafiador no Kafka, pois pode não haver um caminho claro para retomar o processamento de dados após a ocorrência de um erro. Isso pode levar a ineficiências e exigir mais intervenção manual para restaurar as operações normais. Problemas de desempenho A maioria dos aplicativos requer pipelines de dados de alta velocidade para casos de uso em tempo real. No entanto, dependendo do tipo de conector e do volume de dados, o Kafka Connect pode introduzir alguma latência no seu sistema. Isso pode não ser adequado se o seu aplicativo não tolerar atrasos. "Mas há solução" (melhores práticas) Mesmo com essas limitações, seria incorreto afirmar que o Kafka Connect não é uma boa escolha; ele tem inúmeros benefícios que superam em muito suas limitações. O Kafka Connect é uma ferramenta poderosa para construir pipelines de dados escaláveis, mas garantir uma implementação bem-sucedida e adoção operacional requer seguir as melhores práticas. Aqui estão algumas dicas e conselhos para evitar erros e alcançar o sucesso com o Kafka Connect. Planeje seu pipeline Antes de iniciar o processo de implementação, determine as fontes e destinos dos seus dados e garanta que seu pipeline seja escalável e possa lidar com volumes de dados crescentes. Além disso, certifique-se de provisionar a infraestrutura adequadamente. O Kafka Connect requer uma infraestrutura escalável e confiável para desempenho ideal. Use uma arquitetura baseada em cluster com recursos suficientes para lidar com a carga do pipeline de dados e garanta que sua infraestrutura esteja altamente disponível. Use um Schema Registry Utilizar um Schema Registry no Kafka Connect pode ser benéfico, pois permite armazenamento e gerenciamento centralizados de schemas. Isso ajuda a manter a consistência do schema em todos os sistemas, reduz a probabilidade de corrupção de dados e simplifica a evolução do schema. Configurar para desempenho É importante projetar e configurar seu Kafka Connect para escala e desempenho futuros. Por exemplo, você pode implementar uma estratégia de particionamento adequada para distribuir seus dados uniformemente entre as partições. Isso ajudará seu cluster Kafka Connect a gerenciar um alto volume de dados de forma eficaz. Da mesma forma, você pode usar um formato de serialização eficiente, como Avro ou Protobuf, para transferi-lo mais rapidamente na rede. Monitoramento O monitoramento é essencial para garantir o funcionamento tranquilo do seu pipeline de dados. Use ferramentas de monitoramento para rastrear o desempenho da sua implantação do Kafka Connect e identificar e resolver rapidamente quaisquer problemas. Opções para monitoramento do Kafka Connect: Prometheus + Grafana Confluent Control Center Lenses.io Elastic Stack (ELK) Metrics API do Kafka Connect Dead Letter Topic (DLT) Você também pode considerar implementar uma Dead Letter Topic (DLT) como uma rede de segurança para capturar e manipular quaisquer mensagens que falhem repetidamente durante as novas tentativas, garantindo que elas não sejam perdidas, e em cima disso assentar uma estratégia de reprocessamento para todas as mensagem da DLT. Debezium O Debezium é uma plataforma open-source de CDC construída sobre o Kafka Connect. Ele lê diretamente os logs de transação de bancos de dados, capturando mudanças em tempo real e publicando esses eventos em tópicos Kafka. Isso permite a integração desses dados com diversos consumidores e facilita o desenvolvimento de pipelines de dados em tempo real. Arquitetura O Debezium é executado como um conector Kafka Connect e utiliza um conector específico para cada tipo de banco de dados. Quando configurado, o Debezium lê os logs de transação e transmite as mudanças para tópicos no Kafka, onde os consumidores podem acessar esses eventos. Esse processo permite que o Debezium seja altamente escalável e fácil de integrar com outras aplicações e sistemas. Benefícios do Debezium: Open-source e flexível: sendo gratuito e extensível. Escalável com Kafka: ideal para sistemas distribuídos e de alta demanda. Consistência e confiabilidade: captura mudanças sem intervenção na estrutura de dados. Transformações no Debezium (SMTs) As Single Message Transforms (SMTs) no Debezium são transformações que podem ser aplicadas em mensagens individuais durante o processamento de Change Data Capture (CDC). Estas transformações ocorrem após a leitura dos dados da fonte e antes da escrita no kafka ou sistema de destino. Tipos de Transformações Transformações de Roteamento Permitem modificar como as mensagens são encaminhadas dentro do sistema. RegexRouter: Modifica o tópico de destino usando expressões regulares ByteBufferConverter: Converte campos entre diferentes formatos de bytes TopicRouter: Redireciona mensagens para tópicos específicos baseado em condições Transformações de Conteúdo Modificam o conteúdo das mensagens. ExtractField: Extrai um campo específico da mensagem InsertField: Adiciona campos estáticos ou dinâmicos ReplaceField: Substitui valores de campos existentes MaskField: Mascara dados sensíveis DropFields: Remove campos específicos Transformações de Valor Alteram os valores dentro das mensagens. ValueToKey: Move um valor para a chave da mensagem ValueToTimestamp: Converte um campo em timestamp Cast: Converte tipos de dados TimestampConverter: Converte formatos de timestamp Transformações Estruturais Modificam a estrutura das mensagens. Flatten: Converte estruturas aninhadas em estrutura plana HoistField: Eleva campos aninhados para o nível superior WrapField: Encapsula campos em uma nova estrutura Casos de Uso Comuns Mascaramento de Dados Sensíveis { "transforms": "maskFields", "transforms.maskFields.type": "org.apache.kafka.connect.transforms.MaskField$Value", "transforms.maskFields.fields": "creditCard,ssn", "transforms.maskFields.replacement": "****" } 2. Renomeação de Campos { "transforms": "RenameField", "transforms.RenameField.type": "org.apache.kafka.connect.transforms.ReplaceField$Value", "transforms.RenameField.renames": "oldName:newName" } 3. Adição de Metadados { "transforms": "insertSourceDetails", "transforms.insertSourceDetails.type": "org.apache.kafka.connect.transforms.InsertField$Value", "transforms.insertSourceDetails.static.field": "source_database", "transforms.insertSourceDetails.static.value": "production_db" } Considerações de Performance Ordem de Execução: As transformações são executadas na ordem em que são listadas Impacto no Desempenho: Cada transformação adiciona overhead ao processamento Complexidade: Transformações complexas podem afetar a latência Boas Práticas Minimizar Transformações: Use apenas as transformações necessárias Ordem Eficiente: Coloque transformações mais seletivas primeiro Monitoramento: Monitore o impacto das transformações no desempenho Testes: Valide transformações em ambiente de desenvolvimento Documentação: Mantenha documentação clara das transformações aplicadas Limitações Algumas transformações podem não preservar tipos de dados originais Transformações complexas podem afetar a garantia de ordem das mensagens Nem todas as transformações são compatíveis entre si Algumas transformações podem não funcionar com todos os formatos de serialização Recomendações de Uso 1.  Análise de Requisitos Identifique claramente as necessidades de transformação Avalie o impacto no sistema como um todo 2.  Implementação Comece com transformações simples Teste cada transformação individualmente Documente todas as transformações aplicadas 3.  Manutenção Monitore o desempenho regularmente Revise periodicamente a necessidade de cada transformação Mantenha as transformações atualizadas com novas versões do Debezium Casos de Uso O CDC pode ser aplicado em uma variedade de cenários para otimizar a integração e replicação de dados em tempo real, alguns dos quais, referidos abaixo. Outbox Pattern (monitora e encaminha eventos para um Kafka (por ex.), garantindo que as mensagens sejam publicadas, mesmo com falhas, e desacoplando a lógica da entrega de mensagens.) Espelhamento de dados (migração monolito -> microsserviço) Replicação de dados (Integração / microsserviços -> microsserviços) Auditoria de dados Análises em tempo real (dashboards e relatórios em tempo real) Cache de dados (Fazer cache de certos dados do Postgres no Redis por ex) Dados para consulta (disponibilizar dados em um motor de busca como o ElasticSearch)   CQRS (disponibilizando os dados de Command em fontes de dados de Query) etc... Uso Prático do Debezium Preparação da Infra Garanta que o Docker e o Docker Compose estejam instalados e funcionando, pois vamos precisar subir o Kafka, o Zookeeper, o Debezium Connector e o Banco de dados. Criando o Docker Compose Crie um arquivo docker-compose.yml com o seguinte conteúdo: version: '3.8' services: postgres: image: debezium/postgres:16 ports: - "5433:5432" environment: - POSTGRES_DB=inventory - POSTGRES_USER=postgres - POSTGRES_PASSWORD=postgres command: postgres -c wal_level=logical networks: debezium-network: aliases: - postgres zookeeper: image: confluentinc/cp-zookeeper:7.5.0 ports: - "2181:2181" environment: ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TICK_TIME: 2000 networks: debezium-network: aliases: - zookeeper kafka: image: confluentinc/cp-kafka:7.5.0 depends_on: - zookeeper ports: - "9092:9092" environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9093,EXTERNAL://localhost:9092 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT KAFKA_LISTENERS: INTERNAL://0.0.0.0:9093,EXTERNAL://0.0.0.0:9092 KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 networks: debezium-network: aliases: - kafka kafka-connect: image: debezium/connect:2.5 ports: - "8083:8083" depends_on: - kafka - postgres environment: BOOTSTRAP_SERVERS: kafka:9093 GROUP_ID: 1 CONFIG_STORAGE_TOPIC: connect_configs OFFSET_STORAGE_TOPIC: connect_offsets STATUS_STORAGE_TOPIC: connect_statuses KEY_CONVERTER: org.apache.kafka.connect.json.JsonConverter VALUE_CONVERTER: org.apache.kafka.connect.json.JsonConverter CONNECT_KEY_CONVERTER_SCHEMAS_ENABLE: "false" CONNECT_VALUE_CONVERTER_SCHEMAS_ENABLE: "false" CONNECT_REST_ADVERTISED_HOST_NAME: kafka-connect networks: debezium-network: aliases: - kafka-connect networks: debezium-network: driver: bridge Rodando os serviços Na pasta onde foi criado o docker-compose.yml , execute (no terminal): # dependendo de como seu docker foi instalado, # você vai precisar usar o 'sudo' antes do commando docker compose up Configuração do Debezium Connector Envie uma configuração JSON para o endpoint REST do Kafka Connect para configurar o conector do Debezium: # 1. Primeiro, verifique se o Debezium Connect está rodando: curl -X GET http://localhost:8083/connectors # 2. Criando o connector # 2.1. Comando principal para criar o connector (SEM transformação / comece por esse): curl -X POST http://localhost:8083/connectors \ -H "Content-Type: application/json" \ -d '{ "name": "inventory-clientes-connector", "config": { "connector.class": "io.debezium.connector.postgresql.PostgresConnector", "database.hostname": "postgres", "database.port": "5433", "database.user": "postgres", "database.password": "postgres", "database.dbname": "inventory", "database.server.name": "dbserver1", "table.include.list": "public.clientes", "topic.prefix": "inventory", "schema.include.list": "public", "decimal.handling.mode": "precise", "plugin.name": "pgoutput" } }' # 2.2. Comando principal para criar o connector (COM transformação): curl -X POST http://localhost:8083/connectors \ -H "Content-Type: application/json" \ -d '{ "name": "inventory-clientes-connector", "config": { "connector.class": "io.debezium.connector.postgresql.PostgresConnector", "database.hostname": "postgres", "database.port": "5433", "database.user": "postgres", "database.password": "postgres", "database.dbname": "inventory", "database.server.name": "dbserver1", "table.include.list": "public.clientes", "topic.prefix": "inventory", "schema.include.list": "public", "decimal.handling.mode": "precise", "plugin.name": "pgoutput", "transforms": "unwrap", "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState", "transforms.unwrap.drop.tombstones": "false", "transforms.unwrap.delete.handling.mode": "rewrite" } }' # Exemplo de uma configuração de um connector de Sink para Redis curl -X POST http://localhost:8083/connectors \ -H "Content-Type: application/json" \ -d '{ "name": "redis-sink", "config": { "connector.class": "com.github.jcustenborder.kafka.connect.redis.RedisSinkConnector", "redis.hosts": "redis:6379", "topics": "inventory.public.clientes", "tasks.max": "1", "key.converter": "org.apache.kafka.connect.json.JsonConverter", "value.converter": "org.apache.kafka.connect.json.JsonConverter", "key.converter.schemas.enable": "true", "value.converter.schemas.enable": "true" } }' # 3. Para verificar o status do connector: curl -X GET http://localhost:8083/connectors/inventory-clientes-connector/status Explicação dos Parâmetros: name: Nome do conector, usado para gerenciamento (pode ser personalizado). connector.class: Especifica o conector Debezium para PostgreSQL (io.debezium.connector.postgresql.PostgresConnector). tasks.max: Número máximo de tarefas paralelas para o conector (pode aumentar dependendo da carga). database.hostname: Endereço do servidor do PostgreSQL. database.port: Porta em que o PostgreSQL está rodando (padrão é 5432). database.user e database.password: Usuário e senha para acessar o banco (o usuário precisa de permissões para ler os logs de transação). database.dbname: Nome do banco de dados a ser monitorado. database.server.name: Nome lógico do servidor; será usado como prefixo para os tópicos Kafka criados para as tabelas. slot.name: Nome do slot de replicação. Estemudanças nos dados em tempo real usando a replicação lógica. plugin.name: Define o plugin de replicação lógica. Para PostgreSQL 10+ e Debezium, o pgoutput é recomendado. table.include.list: Lista de tabelas para monitorar (no formato schema.tabela ). Caso queira monitorar várias tabelas, você pode separar os nomes com vírgulas. publication.name: Nome da publicação de replicação lógica que captura as alterações na tabela especificada. database.history.kafka.bootstrap.servers: Endereço do Kafka onde o histórico do esquema será armazenado, essencial para Debezium entender a estrutura das tabelas e mudanças de esquema. database.history.kafka.topic: Tópico Kafka onde o histórico do esquema será armazenado. Monitorando as Mudanças kafka-console-consumer Ferramenta da stack do Kafka para fazer o consumo de tópicos diretamente no console. # Console Consumer - verifica as mensagens no tópico sudo docker exec -it cdc-kafka kafka-console-consumer \ --bootstrap-server localhost:9092 \ --topic inventory.public.clientes \ --from-beginning Plugin Big Data Tools para IntelliJ Provectus Kafka UI GitHub - provectus/kafka-ui: Open-Source Web UI for Apache Kafka Management kafka-ui: image: provectuslabs/kafka-ui:latest container_name: cdc-kafka-ui ports: - 8080:8080 depends_on: - kafka environment: DYNAMIC_CONFIG_ENABLED: 'true' networks: debezium-network: aliases: - kafka-ui "Vendo a mágica acontecer" Criar a tabela -- Cria a tabela CREATE TABLE inventory.public.clientes ( id SERIAL PRIMARY KEY, nome VARCHAR(50), email VARCHAR(50), data_criacao TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Verifica se tem dados SELECT * FROM inventory.public.clientes; Conectando o Consumer Você pode conectar o consumer padrão do Kafka para consumir as mensagens assim que entrarem no tópico: # Console Consumer - verifica as mensagens no tópico sudo docker exec -it cdc-kafka kafka-console-consumer \ --bootstrap-server localhost:9092 \ --topic inventory.public.clientes \ --from-beginning Ou usar uma das ferramentas listadas acima (plugin do IntelliJ ou Kafka UI). Testando o funcionamento Inserindo dados INSERT INTO inventory.public.clientes (nome, email) VALUES ('João Silva 1', 'joao1@email.com'); INSERT INTO inventory.public.clientes (nome, email) VALUES ('João Silva 2', 'joao2@email.com'); INSERT INTO inventory.public.clientes (nome, email) VALUES ('João Silva 3', 'joao3@email.com'); Atualizando dados UPDATE inventory.public.clientes SET nome = 'Pedro Silva', email = 'pedro.silva@email.com' WHERE id = 1; UPDATE inventory.public.clientes SET nome = 'José Silva', email = 'jose.silva@email.com' WHERE id = 2; UPDATE inventory.public.clientes SET nome = 'Jacó Silva', email = 'jaco.silva@email.com' WHERE id = 3; Excluindo dados -- Deleta o registro DELETE FROM inventory.public.clientes WHERE id = 1; DELETE FROM inventory.public.clientes WHERE id = 2; DELETE FROM inventory.public.clientes WHERE id = 3; Alterando a quantidade de informações de replicação -- Altera a quantidade de infos que estão disponíveis para decodificação lógica em caso de eventos UPDATE e DELETE. ALTER TABLE inventory.public.clientes REPLICA IDENTITY FULL; Execute novamente os testes (insert, update e delete) após ajustar o nível de replicação. Solucionando Problemas # Visualizando os logs sudo docker compose --file debezium-docker-compose.yml logs kafka sudo docker compose --file debezium-docker-compose.yml logs zookeeper sudo docker compose --file debezium-docker-compose.yml logs postgres sudo docker compose --file debezium-docker-compose.yml logs kafka-connect # Inspecionando a rede sudo docker network inspect debezium-network Conclusão O Change Data Capture é uma técnica amplamente utilizada pelo mercado, nas suas diversas formas, nas suas diversas ferramentas. É especialmente útil em migrações de dados e de sistema, facilitando o estrangulamento de um monolito ou replicando alguns dados de um microsserviço para outro, ou simplesmente aplicado ao padrão Outbox. Nesse cenário o Debezium se apresenta como uma ótima ferramenta pra isso, baseado na já testada e comprovada plataforma Connect do Kafka. Mas como em qualquer cenário ele tem seus pontos de atenção, de risco e de desvantagens. É essencial que as equipes técnicas estejam cientes tanto do potencial quanto das limitações da ferramenta, garantindo decisões arquiteturais bem fundamentadas.

Como estruturamos a nova Central de Ajuda do Projuris Empresas utilizando o Confluence. Que a documentação é um processo importante na gestão de produtos, todo mundo sabe. Ela guarda legado, registra decisões e serve como uma grande coletânea para que no futuro todos entendam o quê foi feito e por quê foi feito. Dito isso, ela também assume o papel de comunicadora e educadora, levando ao usuário todas as informações sobre o produto. Ok, mas como alcançar esse propósito e entregar ao usuário tudo que ele precisa sem a necessidade de “sair catando informação”? A resposta é bem simples: estruturando uma Central de Ajuda. Por onde começar? Escolha a ferramenta certa. Aqui o importante é que ela seja dedicada a documentação, pensada com esse propósito, isso faz toda diferença. Anteriormente, aqui no Projuris Empresas, nós utilizávamos o Movidesk, uma ferramenta de suporte que disponibilizava uma pequena funcionalidade de base de conhecimento, o que engessava a estruturação de uma organização mais intuitiva do conteúdo, que fizesse sentido ao usuário e possuía uma usabilidade que limitava a disponibilização de recursos durante a consulta. Entendemos o que precisava melhorar e buscamos ferramentas que atendessem essa expectativa e tivessem no centro das funcionalidades: a documentação. Foi assim que chegamos no Confluence (que já era utilizada e exaltada pelos nossos colegas do Projuris ADV), ele tem como objetivo ser uma ferramenta de documentação e inclusive é uma das referências neste quesito (Habemus Confluence!). Desenhe a sua estrutura Agora que a ferramenta está definida, é hora de pensar na estrutura. Em como apresentar esse conteúdo de uma forma que fará sentido ao usuário e facilitará o acesso às informações. Nós resolvemos isso literalmente desenhando (muito artistas elas): sentamos e pensamos em todo o conteúdo pré-existente e em como apresentá-lo, a ideia principal era que ele deveria refletir o nosso produto e ser intuitivo. Desta forma, criamos grandes categorias que serviram de agrupadores para os artigos e demais conteúdos. Isso também ajudou no momento da migração, pois como já tínhamos o “esqueleto” foi necessário apenas mover os conteúdos para sua categoria correta. Inicie migração Chegou o momento mais esperado: a migração. Depois que a estrutura foi definida nós iniciamos o processo de migração, transferimos exatos 618 artigos (meus amigos, foi suado!) e infelizmente, como Movidesk não disponibilizava um backup em um formato compatível com o Confluence, tivemos que recorrer ao bom e velho “copy & past”. E aqui temos um ponto importante: se a ferramenta escolhida não fosse pensada para documentação esse processo seria ainda mais moroso, como o Confluence é pensado para isso, ao colar o conteúdo ele já ia se adaptando necessitando de pouca interferência. Apesar de todo esse trabalho, ainda assim, concluímos toda a migração em menos de duas semanas. Ah e consideração importante: hoje se precisarmos exportar todo nosso conteúdo, isso pode ser feito rapidamente em poucos minutos, isso porque o Confluence permite a exportação nos formatos “.pdf, .docx, html e xml”, se necessário (uma nova migração hoje seria pá-pum!). Alinhe os detalhes Após a migração, foi hora de cuidar dos pormenores, ou seja, olhar para estrutura do conteúdo em si. Validamos links, imagens, gifs, definimos títulos, padrões, e etc. Nesta fase é importante que você coloque o usuário no centro das decisões, pois o conteúdo tem que conversar com a estrutura pensada: Verifique se a apresentação das informações nos artigos é lógica e clara; Se os artigos estão inseridos na estrutura correta; E principalmente, se são pesquisáveis e fáceis de localizar. Detalhes que fazem a diferença na hora da entrega como um todo. Aqui nós contamos com a ajuda da IA para revisar e criar artigos essenciais, principalmente os que tinham como objetivo o onboarding do usuário. O único problema significativo que tivemos nesse processo foi em relação as imagens e gifs que são utilizadas para ilustrar nossas documentações, porque esse tipo de arquivo não pode ser copiado e colado como o restante do conteúdo, eles devem ser adicionados individualmente (sim, um a um), do contrário, cria-se um vínculo entre as duas ferramentas e depois de um tempo as imagens quebram, pois perdem as referências de hospedagem, portanto é bom ter atenção e cuidado com relação a isso, principalmente na migração de um número considerável de conteúdo (como foi o nosso caso). Pense no design A apresentação é a chave do negócio! Depois que todo o “corpo” da nossa central estava construído nós passamos a nos preocupar com o design em si. Para ajudar nesse item contratamos o Refined que é um plugin que permite a personalização do Confluence, então, foi a vez do nosso Product Designer entrar em ação. Mais uma vez desenhamos a estrutura que queríamos (falei que elas são artistas), e isso serviu para validar visualmente se faria sentido e nortear o especialista. A partir desse desenho ele começou a desenvolver o design da central, considerando a identidade visual do produto e a melhor usabilidade. Nesse passo, novamente pensamos na correlação entre produto x central, nós trouxemos muitas referências do sistema para ela, não apenas a paleta de cores e logos, mas também ícones, estrutura, nomenclaturas, tudo isso para que usuário se sentisse familiarizado com o contexto e estabelecesse essa relação entre as duas coisas (mais a frente você vai entender porquê isso fez sentido). Além disso, não nos limitamos a apenas utilizar o conteúdo do Confluence, também vinculamos links de outras plataformas com informações do Projuris, como Youtube, Blog, Site, Portal de Tickets e etc, isso permite que usuário tenha acesso a tudo a respeito desse universo em um único lugar. Valide antes de lançar Então pronto, temos a estrutura, o conteúdo, o design e agora? Já podemos colocar no ar? Até poderia… mas como ter certeza que ela está aderente ao que o nosso usuário precisa? Que não há nenhuma possibilidade de melhoria? Só testando não é mesmo?! Por isso, antes de publicar a nova central no produto, nós decidimos convidar clientes internos e externos para um teste de validação. Definimos um pequeno roteiro de execuções (busca, navegação, validações de nomenclaturas, estrutura, e etc.), pedimos que as pessoas utilizassem feedbacks para alinhar ainda mais a nossa entrega. O resultado disso? Além de feedbacks que contribuíram para a assertividade do projeto (aquele ok de que tomamos a decisão certa), conseguimos corrigir a rota antes da entrega final, mudando nomenclaturas que não estavam muito claras, reordenando conteúdos na estrutura e criando outros com base nas sugestões. Lembra que eu falei sobre a intenção de fazer uma relação entre o produto e a central? Isso se confirmou aqui, pudemos perceber que os usuários se localizaram de maneira muito mais fácil porque relacionaram seus módulos contratados com a apresentação existente na central, comprovando a familiaridade. Lance e divulgue muito! Agora sim, podemos dizer que ficou tudo “redondinho” (para começar pelo menos) e depois de todas as validações, finalmente é hora de publicar. Nós começamos pedindo para a equipe de engenharia inserir o link da nova central diretamente no Projuris, isso já era uma prática nossa, portanto foi necessário apenas substituir o acesso antigo. Ao mesmo tempo, alinhamos com a equipe de marketing a estratégia de divulgação. Quando ficou tudo pronto nós divulgamos nos canais internos (teams e e-mail), no produto (através do Beamer), na comunidade Heroes (uma comunidade formada por clientes do Projuris) e no e-mail marketing (uff fizemos barulho!). Próximos passos Como eu falei, esse é só começo, a documentação é um trabalho cultural, as pessoas precisam ser educadas tanto para entender importância de produzi-la quanto o hábito de consumi-la. Então, a partir de agora nossos próximos passos incluem a curadoria da nova central, coleta dos dados para analisar as oportunidades de melhoria, a integração com iniciativas de IA e a produção de novos conteúdos. Mas a pergunta que fica é: pronto para dar um upgrade na sua central de ajuda? Se você quer ver de perto como fizemos isso no Projuris Empresas, clica aqui para explorar a nossa nova Central de Ajuda e conte o que achou. Adoraria trocar ideias sobre os desafios (e as vitórias!) desse processo. Me manda uma mensagem, vamos juntos construir documentações ainda mais incríveis!

Em 1986, o Brasil apostou tudo em um plano ambicioso para conter a inflação: uma nova moeda (o cruzado), congelamento de preços e uma promessa ousada de estabilização econômica. A euforia foi imediata. Por um breve período, parecia que o país finalmente havia vencido a hiperinflação, mas o otimismo durou pouco. Em poucos meses, a inflação voltou com força — e o plano colapsou. Mas por que o Plano Cruzado fracassou? De forma simplificada, o governo brasileiro não fez um diagnóstico claro e preciso da dinâmica inflacionária. Francisco Lopes, um dos idealizadores do plano, reconheceu depois que o governo subestimou a complexidade da inflação inercial e superestimou o poder de um congelamento de preços sem mecanismos de transição (LOPES, 1989). Havia também disputas políticas internas entre os ministérios que dificultaram a construção de um plano mais sustentável. Luiz Carlos Bresser-Pereira, participante ativo do governo da época, foi um dos primeiros a destacar que o plano carecia de sustentação fiscal e de mecanismos de ajuste mais flexíveis. O resultado? Um alívio passageiro, seguido de um retorno ainda mais desorganizado da inflação, culminando no fracasso do plano em menos de um ano. E o que isso tem a ver com Gestão de Produtos? Mais do que parece. Quantas vezes, em Gestão de Produto, nos sentimos pressionados a entregar logo alguma solução? Quantas vezes pulamos a fase de diagnóstico? Quantas vezes vamos direto para o desenvolvimento, sem entender a fundo a dor do usuário, o cenário de uso, ou até se o problema existe mesmo? Movidos pela urgência, entregamos rápido — e mal. E aí o que lançamos não resolve a dor real, não gera valor, e pode até gerar mais confusão do que solução. Tomemos como exemplo a nova Tela de Consulta de Títulos que criamos para o Sienge. Acreditávamos que o que os usuários mais valorizavam era uma tela completa, repleta de filtros e com o máximo de informações disponíveis. Ainda que tenhamos validado algumas dessas hipóteses — e parte delas até tenham sido confirmadas, no lançamento percebemos que a realidade era diferente: o engajamento foi abaixo do esperado e, durante o piloto, 60% dos clientes ainda preferiam utilizar a tela antiga. Diante desse cenário, partimos para a escuta ativa: coletamos feedbacks, analisamos os principais pontos de atrito e mergulhamos mais fundo no comportamento dos usuários. Descobrimos, então, que a principal dor não estava na falta de informação, mas sim no excesso dela. Para uma parte dos clientes, a nova tela parecia carregada demais e dificultava a navegação. Por outro lado, havia também um grupo que valorizava justamente o acesso amplo e detalhado aos dados. Ou seja: o que parecia um problema de funcionalidade era, na verdade, uma questão de flexibilidade. A solução só surgiu a partir desse entendimento mais profundo: criamos duas versões complementares — uma tela sintética, mais leve e objetiva, e outra com análise mais detalhada dos resultados. Assim, conseguimos atender perfis diferentes de usuários, respeitando seus modos de operar. A versão sintética passará por piloto nos próximos meses. Vejamos abaixo a diferença entre as soluções que foram propostas: Versão Sintética Versão Analítica O que diz a teoria? Essa realidade já foi amplamente discutida em boas práticas de Produto, como as defendidas por Marty Cagan em Inspired (2017), que reforça: os melhores produtos nascem de um entendimento profundo dos problemas dos usuários — e não da pressa por entregar algo. Melissa Perri também destaca em Escaping the Build Trap (2018) que times que não sabem diagnosticar e priorizar problemas reais acabam caindo na armadilha de "entregar por entregar", sem impacto. Diagnóstico importa — e muito. Entender o contexto, investigar as causas, escutar de verdade as dores: isso faz toda a diferença. No Plano Cruzado, a ausência de um diagnóstico sólido comprometeu toda a estratégia. Em Gestão de Produto, acontece o mesmo quando deixamos de lado a descoberta e saltamos direto para a entrega. Referências Bresser-Pereira, Luiz Carlos. A crise do Estado. Nobel, 1992. Cagan, Marty. Inspired: How to Create Tech Products Customers Love. Wiley, 2017. Lopes, Francisco. O choque heterodoxo do Plano Cruzado e a teoria da inflação inercial. Revista de Economia Política, 1989. Perri, Melissa. Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media, 2018.

Este artigo foi elaborado com o apoio de ferramenta de Inteligência Artificial, utilizadas para estruturar e organizar informações, com revisão e supervisão humanas em todas as etapas. No mundo corporativo, tempo é o recurso mais escasso e, muitas vezes, indiscriminadamente, o mais mal aproveitado. Milhares de horas são perdidas em tarefas repetitivas, processos manuais e demandas de baixo valor estratégico. Por que isso é importante?O impacto da ineficiência vai muito além do financeiro: compromete a produtividade, reduz o engajamento e enfraquece o alinhamento estratégico das equipes, afetando diretamente a capacidade de inovação e competitividade organizacional. É nesse contexto que a Inteligência Artificial (IA) deixa de ser “mais uma” inovação tecnológica e passa a atuar como um pilar estratégico para a transformação organizacional, impulsionando a reconfiguração de processos e a criação de novos modelos de trabalho. Não estamos falando apenas de automação, mas de mudar o próprio papel das pessoas dentro das organizações, criando espaço para que o talento humano seja investido em criatividade, estratégia e inovação. Os números Processos manuais que não exigem análise profunda ou estratégica podem ser verdadeiros sabotadores de produtividade.A automação com IA devolve horas valiosas e, mais importante, devolve foco, propósito e autonomia. Um estudo realizado pela BCG X (2024) mostrou que profissionais que adotaram IA ganharam, em média, 5 horas por semana para desempenhar ainda mais atividades de maior valor. Do ponto de vista empresarial, isso significa semanas inteiras de produtividade extra por ano. E os impactos vão além, desses entrevistados: 41% relataram mais eficiência nas entregas. 39% expandiram suas responsabilidades para novas tarefas. 38% passaram a atuar de forma mais estratégica. A OCDE (2025) reforça que empresas que aplicam IA em tarefas operacionais ganham entre 5% e 25% de produtividade. O ganho não está só na redução de tempo, mas no reposicionamento do trabalho humano. E ainda, segundo a empresa de tecnologia, HP, que conduziu pesquisa global entrevistando mais de 15 mil pessoas em 12 países, identificou que 73% dos entrevistados dizem que a IA facilita o trabalho, e 69% personalizam o uso da IA para aumentar a produtividade. Panorama geral – O mundo já mudou. E o trabalho também. Os benefícios da Inteligência Artificial, quando bem utilizada e integrada de forma estratégica à rotina de trabalho, são claros e indicam que precisaremos mudar a maneira como estamos acostumados a trabalhar. Segundo a consultoria global McKinsey, mais de 50% das ocupações têm pelo menos 30% de suas atividades automatizáveis com tecnologias já disponíveis. Até 2030, metade das atividades laborais poderão ser executada total ou parcialmente por IA. Embora o dado possa parecer preocupante, a interpretação mais produtiva é otimista: a IA não vai roubar empregos, mas sim potencializar a execução de tarefas repetitivas e rotineiras, liberando espaço para que os profissionais desenvolvam habilidades mais humanas e criativas. A questão já não é mais “se” você vai adotar IA, mas como vai usá-la de forma responsável, estratégica e mensurável. Onde a IA é forte e o humano é insubstituível Kai-Fu Lee, cientista da computação e especialista em IA, diz que a Inteligência Artificial veio para nos libertar de trabalhos rotineiros e nos lembrar do que nos torna humanos. Em seu livro Inteligência Artificial (2019), ele relata a derrota de Ke Jie, o melhor jogador humano de Go, para a AlphaGo (uma IA), como um símbolo do potencial da interação entre humanos e IA: O humano traz propósito, sentimento e criatividade para tudo que faz. A IA executa e segue comandos com precisão. Com base nisso, Lee criou uma matriz que nos ajuda a entender melhor onde a IA pode potencializar os processos e onde a presença humana continua essencial: Precisa de interação social/empatia Não de interação social ou empatia Fonte: Kai Fu Lee A matriz considera duas dimensões: Complexidade cognitiva e criatividade: tarefas que exigem julgamento, empatia, decisão estratégica ou inovação. Rotina e dados: tarefas repetitivas, previsíveis ou baseadas em análise de dados. A partir dessas dimensões, os processos podem ser classificados em três categorias: IA sozinha: atividades que são padronizadas, previsíveis ou baseadas em regras e dados. São processos que podem ser automatizados sem perda de qualidade ou risco. Humano sozinho (podendo utilizar a IA como apoio): atividades que exigem compreensão contextual, criatividade, empatia ou tomada de decisão estratégica. São processos que não podem ser delegados exclusivamente à IA sem comprometer o resultado. Humano + IA: processos onde a IA executa tarefas repetitivas ou analíticas, liberando o humano para focar no que exige julgamento, visão estratégica ou criatividade. Essa combinação gera resultados mais eficientes e permite que o humano atue em alto valor. Assim, qualquer área pode analisar seus processos pensando: o que pode ser automatizado de forma segura e o que precisa da inteligência e sensibilidade humanas. A matriz funciona como guia para priorizar onde investir IA e onde manter o humano no centro do processo. Segundo Kai-Fu Lee, são três as áreas em que a IA fica aquém da capacidade humana e é improvável que consiga fazer isso nas próximas décadas, são elas: Criatividade – A IA não cria, conceitua, ou planeja estrategicamente. Apenas otimiza objetivos definidos, sem capacidade de definir metas, aplicar conhecimento em diferentes áreas ou usar bom senso. Empatia – A IA não pode sentir ou interagir com base em emoções. Não transmite cuidado, compreensão ou motivação genuína, e dificilmente substitui o toque humano em serviços que dependem dessa conexão; Destreza física – A IA não pode realizar um trabalho físico complexo que exija destreza ou coordenação motora, ou lidar com espaços desconhecidos e não estruturados, especialmente aqueles que ela não tenha observado.  O futuro do trabalho não é sobre humanos ou máquinas, mas sobre a sinergia entre ambos, uma colaboração em que a IA potencializa o que fazemos de melhor, enquanto nós damos direção, propósito e criatividade ao que ela executa. 6. Case Starian e Softplan O time de Privacidade da Starian e Softplan identificou uma oportunidade estratégica para otimizar duas atividades essenciais, porém operacionais e de alto consumo de tempo: análise de contratos e resposta a questionários de privacidade. Contratos: precisam ser implementados e revisados para assegurar aderência às políticas internas e à legislação. Questionários de privacidade: exigem respostas fundamentadas com base em regulamentos e documentos internos, sendo extensos e determinantes para transparência e consistência. Apesar da importância, o processo era manual, seguia padrões internos e demandava muitas horas, o que aumentava o risco de erros à medida que a demanda crescia. A equipe viu na IA a chance de transformar esse cenário. Da ideia à implementação Com apoio do TI, a solução foi criada de forma estruturada e segura. Operando em um ambiente fechado, o que garante maior proteção e privacidade dos dados.O desenvolvimento seguiu cinco passos: Priorizar atividades de maior impacto e volume. Definir limites da IA, mantendo decisões críticas sob supervisão humana. Treinar o modelo com contratos, políticas internas e referências relevantes. Configurar padrões e comandos para o contexto organizacional. Integrar a entrega final com comentários e sugestões para revisão do time de privacidade. O resultado: uma ferramenta que analisa contratos e questionários, entrega o documento pronto para revisão e mantém consistência e qualidade. Impacto na produtividade Os ganhos foram tangíveis: Contratos: Considerando uma média de 70 contratos recebidos por mês, sendo que, cada um levava em média 2h para análise. Com a IA, economizamos 30 minutos por contrato, equivalente a 35h/mês ou 420h/ano. Questionários de privacidade: Houve uma redução de 50% do tempo, economizando 2h30 por questionário, equivalente a 50h/mês ou 600h/ano. Essa automação liberou a equipe para decisões estratégicas, sem comprometer a qualidade ou a confiabilidade dos processos. Aprendizados e boas práticas Ao longo da implementação, o time de Privacidade da Starian percebeu que o sucesso da IA depende do equilíbrio entre tecnologia e supervisão humana. Alguns pontos se destacaram: Personalização é chave: a IA precisa ser treinada e ajustada ao contexto específico do negócio, demandas e atividades. Cada detalhe conta. Supervisão contínua é indispensável: alucinações e erros podem ocorrer, e a intervenção humana garante precisão e adequação. Qualidade dos dados importa: quanto melhor os insumos melhores e mais confiáveis os resultados gerados. Interação constante gera melhorias: feedback real do time aprimora a ferramenta e cria evolução contínua. Decisões críticas continuam humanas: a IA é aliada, mas a análise estratégica permanece sendo condição essencialmente humana. Soluções contratadas aumentam segurança: ferramentas validadas garantem consistência e proteção. Esses aprendizados mostram que agilidade e cautela precisam andar juntas. O uso inadequado de IA pode gerar riscos sérios: prejuízos financeiros, vazamento ou retenção indevida de dados pessoais, sensíveis e confidenciais, criação de informações falsas e confiança excessiva em sistemas não seguros. Portanto, algumas práticas são essenciais: Evitar inserir dados pessoais ou documentos confidenciais, especialmente em ferramentas não contratadas. Revisar sempre o conteúdo gerado. Questionar vieses ou distorções nos resultados. Utilizar apenas soluções aprovadas e adequadas pela organização. Capacitar a equipe e registrar riscos de cada uso junto com as áreas de privacidade e segurança da informação. Na Starian, aprendemos que quando humanos e IA trabalham em sinergia, os ganhos vão muito além da produtividade: entregamos mais qualidade, segurança e tempo para focar no que realmente importa, decisões estratégicas que apenas pessoas podem tomar. A tecnologia potencializa, mas é o olhar humano que garante consistência e confiança. Conclusão A experiência da Starian e da Softplan mostra que a Inteligência Artificial, quando implementada com propósito, personalização e supervisão humana, vai muito além da automação: ela se torna um multiplicador de valor. O ganho não é apenas em horas economizadas, mas em qualidade, consistência e capacidade de dedicar energia ao que realmente impulsiona resultados, decisões estratégicas, inovação e relações de confiança. O futuro do trabalho já começou. Organizações que aprendem a combinar a precisão da IA com o olhar crítico e criativo do humano não apenas otimizam processos, mas constroem equipes mais engajadas e preparadas para os desafios de um mercado em constante mudança. Mais do que substituir tarefas, a IA nos convida a redefinir prioridades, ampliar nosso alcance e, principalmente, reforçar aquilo que nenhuma máquina pode replicar: propósito, sensibilidade e visão. Quando humanos e IA atuam juntos, produtividade e impacto deixam de ser metas isoladas e passam a ser o novo padrão de excelência.

Investimento chega logo após o anúncio da divisão das operações da Softplan em duas empresas independentes; Além do fortalecimento dos produtos atuais, capital será usado para expandir a tese de crescimento inorgânico, com objetivo de abertura de novas verticais  Florianópolis, agosto de 2025 – A Starian, empresa recém-lançada no mercado e que passou a gerir todas as soluções para o setor privado da Softplan, acaba de levantar R$ 640 milhões (US$ 115 milhões) em um investimento estratégico da General Atlantic, um dos principais fundos de investimento globais. A companhia, que já nasceu com 16 mil clientes, usará a injeção de capital para alavancar M&As, fortalecer o modelo de SaaS vertical e abrir novas unidades de negócio.  A Starian desenvolve ecossistemas de software verticais altamente especializados, com complementariedade de produtos e gestão integrada, oferecendo jornadas completas dentro de um segmento.  Reúne sob seu guarda-chuva soluções dedicadas à Indústria da Construção, com o Ecossistema Sienge, além da Inteligência Legal, liderada pelo Projuris, e Eficiência Operacional, com as soluções de produtividade e eficiência Checklist Fácil e Runrun.it. Após a separação das operações em duas empresas independentes, a Softplan segue no mercado focada exclusivamente nas soluções voltadas ao setor público. "Toda a solidez construída ao longo de mais de 30 anos comprova que investir no fortalecimento do modelo de SaaS vertical é uma decisão estratégica acertada. Agora, com uma operação 100% autônoma e o aporte da General Atlantic, que traz não apenas capital, mas também expertise global em tecnologia, poderemos acelerar nosso potencial de crescimento, ampliando a força das unidades de negócio nas quais já somos referência e avançando em novas verticais”, destaca Ionan Fernandes, CEO da Starian.  Com o aporte da General Atlantic, que se torna sócia minoritária, a companhia pretende intensificar o ritmo de M&As, mirando tanto a consolidação de suas verticais atuais quanto a entrada em novos segmentos de alto potencial. “O cenário de software no Brasil permanece fragmentado e o mercado é amplamente subatendido”, afirma Rodrigo Catunda, Managing Director e Co-Head da General Atlantic no Brasil. “Vemos na Starian uma empresa única para liderar a consolidação de software vertical no Brasil, combinando produtos líderes, gestão profissionalizada e uma cultura de integração disciplinada. Estamos entusiasmados em apoiar a empresa em uma nova fase de crescimento acelerado, com foco em aquisições e criação de valor de longo prazo", diz. Com a assinatura dos termos do SPA (Share Purchase Agreement), o fechamento da transação ainda depende do cumprimento das condições usuais de mercado, incluindo aprovações regulatórias e demais etapas previstas no cronograma. Sobre a General Atlantic   A General Atlantic é um dos principais investidores globais de capital para crescimento com mais de quatro décadas de experiência no fornecimento de capital e suporte estratégico para mais de 830 empresas ao longo de sua história. Fundada em 1980, General Atlantic continua sendo uma parceira dedicada para empreendedores visionários e investidores que buscam construir negócios dinâmicos e criar valor a longo prazo. A empresa alavanca seu capital paciente, experiência operacional e plataforma global para dar suporte a uma plataforma de investimento diversificada abrangendo estratégias de Growth Equity, Crédito, Clima e Infraestrutura. A General Atlantic tem aproximadamente US$ 114 bilhões em ativos sob gestão, incluindo todas as estratégias, em 30 de junho de 2025, com mais de 900 profissionais em 20 países em cinco regiões. Para obter mais informações sobre a General Atlantic, visite: www.generalatlantic.com.  Para mais informações:  Starianstarian@vcrp.com.br  General AtlanticSara Widmann & Jess Gillmedia@generalatlantic.com

Recentemente, liderei as frentes de Produto e UX no desenvolvimento de uma solução SaaS de IA para SEO, com um foco estratégico na adoção de tecnologias que acelerassem a busca pelo Product-Market-Fit (PMF) e pelo Minimum Viable Product (MVP). A abordagem escolhida também visava otimizar fatores cruciais, como a redução dos custos de desenvolvimento e a diminuição da curva de aprendizagem, garantindo um processo mais eficiente e acessível. Por isso, decidimos utilizar a seguinte stack de soluções para o desenvolvimento do software: Figma (prototipagem); Solução no-code para front-end web; A princípio íamos utilizar backend low-code, mas pivotamos e usamos tecnologia high code. Uma das principais vantagens dessa stack é que a velocidade de desenvolvimento do front-end seria muito maior por conta dos facilitadores, mas mantivemos o core da solução no backend em tecnologia high code, permitindo escala com melhor eficiência em cloud e flexibilidade. Posso explicar melhor o racional e quais opções nós cogitamos em um próximo post, mas vamos em frente aqui (comenta aqui se você gostaria de ler sobre isso). 5 lições aprendidas com no-code: 1. Velocidade maior: É indiscutível que uma solução no-code traz mais agilidade no desenvolvimento, acredito que reduzimos o tempo de desenvolvimento do front-end na ordem de 80%. Chega a ser bonito ver a facilidade que é criar as interfaces e os workflows, ainda mais quando você pode simplesmente utilizar um plugin e importar as telas diretamente do Figma. Se você é UX ou PM, imagine validar entregas e fazer ajustes de forma ágil. Melhor ainda: você mesmo pode criar as interfaces! Eu mesmo fiz isso diversas vezes ao longo do projeto. Muitas vezes, gastamos tempo documentando pequenos ajustes de usabilidade para que os desenvolvedores os corrijam, mas, nessa abordagem, bastava selecionar a camada e ajustar diretamente, sem intermediários. Tem um ponto positivo que vale destacar: O software no-code que usamos tem uma estrutura de auto-layout bem parecida com o Figma, se você domina Figma, vai tirar de letra. 2. Existirá uma curva de aprendizagem: Existem poucos profissionais com experiência prática na utilização de tecnologia low/no-code no país. Isso significa que você provavelmente vai ter que treinar o time a lidar com essa tecnologia, e naturalmente isso vai gerar alguns erros operacionais, bugs, e vai fritar alguns neurônios. A curva de aprendizagem é bem menor que uma tecnologia high-code, mas vai levar um tempinho para você construir um time maduro. 3. Você vai ter que repensar alguns processos: Gestão de equipes, branches, merges, servidores de homologação, deploys… Você vai ter que pensar nesses processos para garantir qualidade nas entregas e mitigar erros. Imagina alguém dar um “misclick” no software no-code e subir em produção uma branch errada… 4. Problemas novos surgem: Nem tudo são flores, ao utilizar uma plataforma para desenvolver um software, você pode acabar ficando dependente da empresa que fornece a plataforma (o famoso vendor lock-in), por isso é importante escolher de forma consciente qual tecnologia você vai utilizar. No caso do software que escolhemos, é possível exportar o projeto em código, então se no futuro você quiser tirar da plataforma, é possível, apesar que nunca fiz isso, você já exportou um projeto em produção? Conta aqui como foi. Além disso, você começa a se deparar com problemas diferentes, por exemplo, tinha uma tela que possuía um comportamento que com um simples “for” resolvia no código, mas no no-code foi um desafio… Print de uma call onde estávamos tentando resolver esse problema: 5. Vai haver quebras de paradigmas: Como em qualquer mudança, algumas pessoas poderão se sentir ameaçadas, com medo, ou resistentes. Você precisa encontrar pessoas dispostas a reaprender várias coisas, e a desbravar o novo. Não tivemos pessoas resistentes nesse projeto mencionado, mas já presenciei em outros ambientes pessoas que ainda acreditam que essas soluções não escalam e que não funcionam. Conclusão O uso de ferramentas low-code/no-code, como o WeWeb, tem nos ajudado significativamente a acelerar experimentações e o desenvolvimento de software. No entanto, nem tudo são flores: ao longo do caminho, tivemos que repensar diversos processos de DevOps, à medida que surgiam nuances específicas de se manter um software low-code em produção. O verdadeiro desafio de qualquer negócio está em entender profundamente as necessidades dos clientes e encontrar maneiras eficazes de aumentar o engajamento, o valor percebido, a aquisição e a retenção. Além disso, todo produto de software carrega um custo muitas vezes negligenciado: o custo de oportunidade. Esse custo representa o tempo e os recursos que decidimos investir em uma determinada iniciativa (tempo que poderia estar sendo direcionado a outras apostas potencialmente mais valiosas). Ao acelerar o desenvolvimento com low-code/no-code, conseguimos reduzir substancialmente esse custo, permitindo que o foco da equipe esteja onde realmente importa: gerar valor para o cliente, e não apenas escrever código.