La necesidad de crear software más resiliente y desacoplado ha impulsado la adopción de la mensajería, un estándar de comunicación donde diferentes aplicaciones o partes del sistema “hablan” entre sí a través de mensajes, de forma asincrónica y sin perder información durante el proceso¹. Uno de los protocolos más utilizados para ello es AMQP 0-9-1 (Advanced Message Queuing Protocol) y se basa en cuatro elementos: productor, intercambio, cola y consumidor². Cada uno de ellos juega un papel esencial en el flujo de mensajes: Productor: es la aplicación —o parte de un sistema— que origina la comunicación y envía los mensajes. Él es responsable de publicar la información en la bolsa, sin preocuparse de quién la recibirá. Intercambio: actúa como un enrutador de mensajes, recibiendo mensajes del productor y dirigiéndolos a una o más colas, dependiendo de su tipo (Fanout, Topic, Direct o Headers). Cola: es el repositorio temporal donde se almacenan los mensajes hasta que son consumidos. Puede haber una o más colas, dependiendo de la arquitectura del sistema. Consumidor: es la aplicación que recibe y procesa los mensajes de la cola, completando el ciclo de comunicación. El conjunto de estos componentes permite establecer una comunicación asíncrona entre diferentes partes de un sistema, sin necesidad de conocer los detalles de implementación de cada una. Como resultado, han surgido muchas herramientas para implementar esta arquitectura, y una de las más populares es RabbitMQ. Simular visualmente cómo funciona esta comunicación puede ayudar a planificar una solución adecuada para satisfacer las necesidades del cliente. Para este propósito, existe un sitio web llamado “RabbitMQ Simulator”, que, como su nombre indica, simula cómo funciona la mensajería entre diferentes aplicaciones. En este artículo verás una guía paso a paso sobre cómo simular esta comunicación y utilizarla en tus proyectos y/o estudios. Pasos para usar el Simulador RabbitMQ: Vaya a la página: https://tryrabbitmq.com/; Cree el productor: La página muestra un cuadrado blanco donde se realizará la simulación y los elementos que componen la arquitectura mediante iconos a la izquierda. Arrastre el icono del "productor" al centro y observe el círculo que lo representa. Se puede crear más de un productor. Para editar el nombre, simplemente cambie el texto donde apunta la flecha roja en la imagen. Creemos dos productores: “Productor 1” y “Productor 2”. Imagen 1 – Adición de dos productores a la simulación 3. Crear el consumidor Arrastre el icono “consumidor” hacia el centro y aparecerá el icono amarillo. Se puede crear más de un consumidor. Para editar el nombre, simplemente cambie el texto donde apunta la flecha roja en la imagen. Creemos dos consumidores: “Consumidor 1” y “Consumidor 2”. Imagen 2 – Adición de dos consumidores a la simulación 4. Crear la cola La cola es un elemento importante en esta arquitectura. Aquí se publicarán los mensajes que se enviarán a los consumidores. Para crear, simplemente haga clic en el ícono azul. Puede editar el nombre de la cola, que se muestra con la flecha roja en la siguiente imagen. ¿Observa que hay un contador de mensajes encima del ícono 'msg:0'? Representa la cantidad de mensajes almacenados en cada cola, es decir, aquellos que aún no han sido procesados ​​por los consumidores. Si los mensajes no se consumen, este número puede crecer infinitamente, como una bandeja de entrada llena. Esto afecta el rendimiento del sistema, ya que las colas consumen memoria y, en casos extremos, pueden incluso agotar los recursos del servidor. Por lo tanto, en sistemas reales, es común configurar límites de tamaño para las colas o políticas para descartar mensajes antiguos. Imagen 3 – Añadiendo la cola a la simulación 5. Crear intercambio Como hemos visto, el intercambio es el elemento que se sitúa entre el productor y la cola y define cómo se distribuirán los mensajes entre las colas, y que admite diferentes tipos de intercambios, cada uno con reglas de enrutamiento específicas. A continuación, exploraremos los tipos Fanout, Topic y Direct. 5.1) Fanout El intercambio fanout envía el mensaje recibido a todas las colas. Se puede aplicar en sistemas donde todas las partes interesadas deben recibir todos los mensajes. Para crear un intercambio, simplemente arrastre el ícono que lo representa al centro del cuadrado. Puedes elegir el nombre y su tipo. En este primer ejemplo será del tipo Fanout. Imagen 4 – Creación de un intercambio fanout Es necesario crear una unión entre consumidor, cola, intercambio y productor. Para ello, mantenga presionada la tecla Alt y arrastre el mouse desde el consumidor a la cola, luego desde la cola al intercambio, y desde el productor al intercambio. Aparecerán flechas que representan la conexión de estos elementos, como podemos ver en la imagen de abajo. Se creó una cola más para representar mejor nuestro ejemplo, y cada cola se asoció con un consumidor. Para activar un mensaje de ejemplo, simplemente haga clic en “Productor 1”, vaya a “Nuevo mensaje” y defina el cuerpo del mensaje, su “clave de enrutamiento” y el intervalo de tiempo en segundos para su envío. Podemos ver que nuestro intercambio Fanout distribuye el mensaje a todas las colas. Imagen 5 – Mensaje de disparo 5.2) Tema Un tema utiliza un sistema de enrutamiento basado en dos claves: (i) “claves de enrutamiento”, una configuración adjunta al mensaje por el productor, que funciona como una “dirección de mensaje” y es identificada por el intercambio; y (ii) “claves de enlace” que se configuran en la cola al momento de vincularla al intercambio, son como filtros que ayudan a direccionar el envío de mensajes a las respectivas colas. Para simular este tipo, hacemos clic en el intercambio que hemos creado y cambiamos su nombre a “Tema de intercambio”, lo que requerirá configurar las “claves de enlace”. Haciendo clic en las flechas con el término “binding key”, podemos cambiarlo al nombre que nos interese. Siguiendo nuestro ejemplo, se creará una cola para recibir mensajes con la clave “produc.log” que alimenta el sistema logístico de nuestro cliente y otra “produc.fin” para enviar datos al equipo de finanzas del cliente. Al hacer clic en Productor 1, configuramos el nuevo mensaje con la clave de enrutamiento “product.log”. Tenga en cuenta que el intercambio solo envía a la cola correspondiente. Imagen 6 – Mensaje yendo a la cola correspondiente (product.log) Ahora, si configuramos el Productor 2 para enviar mensajes con “routing key” “product.fin”, y cambiamos la “binding key” de la cola 1 a “product.*” veremos que el mensaje irá a todas las colas que comiencen con el término “product..”. Imagen 7 – Mensaje que va a todas las colas que empiezan con “producto”. 5.3) Directo Finalmente, el intercambio directo dirige el mensaje sólo a una o más colas que están vinculadas por una “clave de enrutamiento” específica. Aquí la coincidencia debe ser exacta. Y se adopta en sistemas donde el mensaje se dirige a consumidores específicos. Siguiendo el ejemplo anterior, si el Productor 2 envía un mensaje con la “clave de enrutamiento” product.log, sólo la cola con esa “clave de enlace” lo recibirá. Imagen 8 – Creación de un intercambio de tipo directo Al permitir el diseño de modelos de mensajería para diferentes configuraciones, el Simulador RabbitMQ se convierte en una herramienta útil para ayudar a los desarrolladores y arquitectos de software en el diseño de sistemas basados ​​en este estándar de comunicación. Finalmente, su forma didáctica de presentar los elementos del protocolo AMQP 0-9-1 puede ayudar en los estudios de quienes quieran conocer más sobre esta tecnología. En este artículo los ejemplos mencionados fueron sólo para presentar este simulador, pero sirven como invitación para que otros desarrolladores exploren esta herramienta en sus proyectos. Fuentes: ¹Desarrollo de un broker de mensajes. Giovanni Henrique Silva Oliveira. Universidad de Coimbra, 2021. https://transportersystems.com/docs/dissertacao-giovanni-oliveira.pdf ²AMQP 0-9-1 Model Explained. Documentación de RabbitMQ. Broadcom, 2025.

Introducción La captura de datos de cambio (CDC) es una técnica que identifica y registra todos los cambios (inserciones, actualizaciones y eliminaciones) realizados en una fuente de datos, como una base de datos relacional, y transmite estos cambios a otros sistemas, lo que permite la sincronización en tiempo real. Este enfoque es fundamental para muchas arquitecturas de datos modernas que requieren información actualizada y consistente en distintos sistemas. Beneficios CDC aporta una serie de beneficios que van más allá del simple movimiento de datos. Los principales beneficios se pueden ver en la lista a continuación. Reducción de la carga en el sistema de origen al capturar solo los cambios y evitar lecturas masivas de datos, lo que resulta en menores costos de infraestructura. Replicación de datos en tiempo real, eliminando la latencia que normalmente existe en los procesos ETL tradicionales. Capacidad de realizar un seguimiento de los cambios para auditoría, realización de copias de seguridad y reprocesamiento en otras plataformas. Actualizaciones continuas de lagos de datos y almacenes de datos, alimentando los sistemas analíticos con datos actuales. Técnicas principales La implementación del CDC se puede llevar a cabo de diferentes maneras, cada una con ventajas y limitaciones específicas. Conocer estas alternativas ayuda a seleccionar la solución más adecuada al contexto de cada organización. A continuación se presentan las técnicas más habituales. Lectura de registros de transacciones: captura los cambios directamente de los registros de transacciones, un método utilizado por herramientas como Debezium. Columnas de marca de tiempo: uso de una columna que registra la última modificación en cada fila. Ideal para sistemas que no tienen registros transaccionales detallados. Desencadenantes: uso de desencadenadores para registrar cambios en las tablas, aunque esto puede afectar el rendimiento. Diferenciación de instantáneas: compara instantáneas tomadas periódicamente. Es un enfoque más pesado y menos preciso. Técnicas de Binlog (registro de transacciones) El binlog, o registro de transacciones, es un archivo que registra todas las operaciones realizadas en la base de datos. Las bases de datos como MySQL (binlog) y PostgreSQL (WAL) tienen registros transaccionales que pueden monitorearse en tiempo real para capturar cambios. Este enfoque es eficiente y preciso porque captura cada cambio realizado en los datos, pero requiere acceso a los registros y permisos de lectura. La desventaja es que no todos los bancos tienen registros de transacciones tan detallados y la configuración puede requerir ajustes de infraestructura. Columna de marca de tiempo Consiste en crear una columna que registra el último cambio realizado en cada fila de una tabla. Al consultar únicamente las filas modificadas desde la última ejecución, el sistema captura los cambios incrementales. Esta técnica es simple y aplicable a cualquier base de datos, pero no captura las eliminaciones de datos y requiere que todas las tablas monitoreadas incluyan esta columna. Los activadores son funciones definidas en la base de datos que realizan acciones cuando ocurre un evento específico (como una inserción, actualización o eliminación). Con CDC, se pueden configurar activadores para registrar estos cambios en una tabla de historial. Si bien es eficiente, este método a menudo se evita debido a su impacto en el rendimiento y la complejidad del mantenimiento. Diferencia entre instantáneas Consiste en crear instantáneas periódicas de los datos y compararlas para identificar cambios. Es un método laborioso y con mayor impacto en el sistema, ya que requiere un procesamiento intensivo, y sólo se utiliza cuando no se encuentran disponibles otros enfoques CDC. Herramientas A continuación se muestran algunas de las principales herramientas de captura de datos de cambios del mercado. Debezium: Herramienta de código abierto que utiliza registros de transacciones para capturar cambios en tiempo real. Admite bases de datos como MySQL, PostgreSQL, MongoDB y otras, y está integrado con Kafka, lo que facilita la transmisión de datos en canales de datos distribuidos. Oracle GoldenGate: herramienta propietaria de Oracle para la replicación e integración de datos en tiempo real, compatible con múltiples sistemas de bases de datos. StreamSets: Plataforma de integración que incluye componentes para CDC en diversas bases de datos y fuentes de datos. Qlik Replicate (Attunity): Solución CDC robusta utilizada para la replicación y sincronización de datos entre bases de datos. Amazon DMS y Azure Data Factory: soluciones CDC ofrecidas en sus respectivas plataformas de nube para la replicación y sincronización de datos entre servicios. Airbyte: Airbyte es una plataforma de integración de datos de código abierto que admite CDC a través de varios conectores, incluido el monitoreo de registros de transacciones para bases de datos como MySQL y PostgreSQL. Es una opción flexible y escalable, con una interfaz fácil de usar que facilita la creación de canales de datos. Airbyte cuenta con una amplia librería de conectores y destaca por su comunidad activa y posibilidades de personalización. Striim: Striim es una plataforma de integración de datos en tiempo real que combina CDC con análisis de transmisión y procesamiento de eventos. Admite múltiples fuentes de datos, como bases de datos relacionales, y puede transmitir datos a múltiples plataformas, incluidas nubes como AWS, Azure y Google Cloud. Su arquitectura robusta permite la replicación de datos a gran escala y el procesamiento en tiempo real, lo que la hace popular para casos de uso que requieren información instantánea de los datos. Si bien existen muchas herramientas, en este artículo nos centraremos en Debezium, una popular opción de código abierto creada sobre Kafka Connect, para ilustrar una implementación práctica. Kafka Connector Kafka Connector es una característica fundamental de Kafka Connect, una herramienta de la plataforma Apache Kafka diseñada para simplificar y automatizar la integración entre Kafka y otros sistemas, como bases de datos, almacenes de datos, sistemas de almacenamiento en la nube y más. Kafka Connect funciona como una capa de integración distribuida y escalable que utiliza conectores especializados para transferir datos de manera confiable entre sistemas. Cómo funciona Kafka Connect Kafka Connect utiliza conectores, que son complementos especializados para cada tipo de sistema o fuente de datos, divididos en dos categorías: Conectores de fuente: capturan datos de una fuente externa y los publican en temas de Kafka. Conectores de sumidero: consumen datos de temas de Kafka y los escriben en un sistema de destino. Los conectores se configuran mediante archivos de configuración JSON o API REST, donde puede definir la fuente o el destino de los datos, la información de autenticación, la configuración de replicación y las transformaciones opcionales para adaptar los datos al formato deseado. Arquitectura de Kafka Connect La arquitectura de Kafka Connect se compone de trabajadores, que son instancias que ejecutan conectores de manera distribuida. Esto permite a Kafka Connect: escalar horizontalmente a medida que aumenta la carga de datos. Sea tolerante a los fallos: si un trabajador falla, otro puede tomar el relevo. Centralice la configuración y supervisión del conector. Los datos se procesan en bloques llamados tareas, que distribuyen la carga de trabajo entre los trabajadores y permiten el procesamiento paralelo. "No todo es color de rosa" (limitaciones) Opciones limitadas Hay menos de 20 tipos diferentes de conectores en Kafka Connect. Si un conector genérico no es adecuado, deberá desarrollar uno personalizado. De manera similar, Kafka Connect solo proporciona un conjunto básico de transformaciones, y es posible que también tengas que escribir tus propias transformaciones personalizadas. Esto puede aumentar el tiempo y el esfuerzo necesarios para la implementación. Complejidad de configuración Las configuraciones de Kafka Connect se vuelven complejas rápidamente, especialmente cuando se trata de múltiples conectores, tareas y transformaciones. Esto puede dificultar la administración, el mantenimiento y la resolución de problemas del sistema. También es un desafío integrar Kafka Connect con otras herramientas que su organización pueda ya estar utilizando. Esto crea una barrera para la adopción y ralentiza el proceso de implementación. Soporte limitado para manejo de errores El enfoque principal de Kafka es la transmisión de datos, lo que genera capacidades limitadas de manejo de errores integradas. La naturaleza distribuida y las posibles interdependencias entre los distintos componentes de Kafka aumentan la complejidad, lo que dificulta descubrir la causa raíz de un error. Es posible que tenga que implementar mecanismos de manejo de errores personalizados, lo que puede llevar mucho tiempo y no siempre ser tan confiable como las capacidades integradas que ofrecen otras herramientas ETL e integración de datos. La recuperación elegante de errores complejos también es un desafío en Kafka, ya que puede no haber un camino claro para reanudar el procesamiento de datos después de que ocurre un error. Esto puede generar ineficiencias y requerir más intervención manual para restablecer las operaciones normales. Problemas de rendimiento La mayoría de las aplicaciones requieren canales de datos de alta velocidad para casos de uso en tiempo real. Sin embargo, dependiendo del tipo de conector y del volumen de datos, Kafka Connect puede introducir cierta latencia en su sistema. Esto puede no ser adecuado si su aplicación no tolera retrasos. "Pero hay una solución" (mejores prácticas) Incluso con estas limitaciones, sería incorrecto decir que Kafka Connect no es una buena opción; tiene numerosos beneficios que superan ampliamente sus limitaciones. Kafka Connect es una herramienta poderosa para crear canales de datos escalables, pero para garantizar una implementación y una adopción operativa exitosas es necesario seguir las mejores prácticas. A continuación se ofrecen algunos consejos y sugerencias para evitar errores y lograr el éxito con Kafka Connect. Planifique su canalización Antes de comenzar el proceso de implementación, determine las fuentes y los destinos de sus datos y asegúrese de que su canalización sea escalable y pueda manejar volúmenes de datos crecientes. Además, asegúrese de aprovisionar la infraestructura adecuadamente. Kafka Connect requiere una infraestructura escalable y confiable para un rendimiento óptimo. Utilice una arquitectura basada en clústeres con recursos suficientes para manejar la carga del flujo de datos y garantizar que su infraestructura tenga alta disponibilidad. Utilizar un registro de esquemas El uso de un registro de esquemas en Kafka Connect puede ser beneficioso porque permite el almacenamiento y la gestión centralizados de esquemas. Esto ayuda a mantener la coherencia del esquema en todos los sistemas, reduce la probabilidad de corrupción de datos y simplifica la evolución del esquema. Configurar para el rendimiento Es importante diseñar y configurar Kafka Connect para lograr una escala y un rendimiento futuros. Por ejemplo, puede implementar una estrategia de partición adecuada para distribuir sus datos de manera uniforme entre las particiones. Esto ayudará a que su clúster de Kafka Connect administre un gran volumen de datos de manera efectiva. Asimismo, puede utilizar un formato de serialización eficiente como Avro o Protobuf para transferirlo más rápido a través de la red. Monitoreo El monitoreo es esencial para garantizar el buen funcionamiento de su canal de datos. Utilice herramientas de monitoreo para rastrear el rendimiento de su implementación de Kafka Connect e identificar y resolver rápidamente cualquier problema. Opciones de monitoreo de Kafka Connect: Prometheus + Grafana Confluent Control Center Lenses.io Elastic Stack (ELK) Metrics Kafka Connect API Dead Letter Topic (DLT) También puede considerar implementar un Dead Letter Topic (DLT) como una red de seguridad para capturar y manejar cualquier mensaje que falle repetidamente durante los reintentos, asegurando que no se pierdan y además de eso, construir una estrategia de reprocesamiento para todos los mensajes DLT. Debezium Debezium es una plataforma CDC de código abierto construida sobre Kafka Connect. Lee directamente los registros de transacciones de la base de datos, captura los cambios en tiempo real y publica estos eventos en los temas de Kafka. Esto permite la integración de estos datos con múltiples consumidores y facilita el desarrollo de canales de datos en tiempo real. Arquitectura Debezium se ejecuta como un conector de Kafka Connect y utiliza un conector específico para cada tipo de base de datos. Cuando está configurado, Debezium lee los registros de transacciones y transmite los cambios a los temas en Kafka, donde los consumidores pueden acceder a estos eventos. Este proceso permite que Debezium sea altamente escalable y fácil de integrar con otras aplicaciones y sistemas. Beneficios de Debezium: Código abierto y flexible: ser gratuito y extensible. Escalable con Kafka: ideal para sistemas distribuidos y de alta demanda. Consistencia y confiabilidad: captura cambios sin intervenir en la estructura de datos. Transformaciones de Debezium (SMT) Las transformaciones de mensaje único (SMT) en Debezium son transformaciones que se pueden aplicar a mensajes individuales durante el procesamiento de captura de datos modificados (CDC). Estas transformaciones ocurren después de leer los datos de la fuente y antes de escribirlos en el sistema kafka o de destino. Tipos de transformación Transformaciones de enrutamiento Le permiten modificar la forma en que se enrutan los mensajes dentro del sistema. RegexRouter: modifica el tema de destino mediante expresiones regulares ByteBufferConverter: convierte campos entre diferentes formatos de bytes TopicRouter: redirecciona mensajes a temas específicos según condiciones Transformaciones de contenido Modifica el contenido de los mensajes. ExtractField: Extrae un campo específico del mensaje InsertField: Agrega campos estáticos o dinámicos ReplaceField: Reemplaza valores de campos existentes MaskField: Enmascara datos confidenciales DropFields: Elimina campos específicos Transformaciones de valores Cambia valores dentro de los mensajes. ValueToKey: Mueve un valor a la clave del mensaje ValueToTimestamp: Convierte un campo en una marca de tiempo Cast: Convierte tipos de datos TimestampConverter: Convierte formatos de marca de tiempo Transformaciones estructurales Modifica la estructura de los mensajes. Flatten: convierte estructuras anidadas en estructuras planas HoistField: eleva campos anidados al nivel superior WrapField: encapsula campos en una nueva estructura Casos de uso comunes Enmascaramiento de datos confidenciales { "transforms": "maskFields", "transforms.maskFields.type": "org.apache.kafka.connect.transforms.MaskField$Value", "transforms.maskFields.fields": "creditCard,ssn", "transforms.maskFields.replacement": "****" } 2. Cambio de nombre de campo { "transforms": "RenameField", "transforms.RenameField.type": "org.apache.kafka.connect.transforms.ReplaceField$Value", "transforms.RenameField.renames": "oldName:newName" } 3. Adición de metadatos { "transforms": "insertSourceDetails", "transforms.insertSourceDetails.type": "org.apache.kafka.connect.transforms.InsertField$Value", "transforms.insertSourceDetails.static.field": "source_database", "transforms.insertSourceDetails.static.value": "production_db" } Consideraciones de rendimiento Orden de ejecución: las transformaciones se ejecutan en el orden en que se enumeran Impacto en el rendimiento: cada transformación agrega sobrecarga de procesamiento Complejidad: las transformaciones complejas pueden afectar la latencia Mejores prácticas Minimizar las transformaciones: usar solo las transformaciones necesarias Orden eficiente: priorizar las transformaciones más selectivas Monitoreo: monitorear el impacto de las transformaciones en el rendimiento Pruebas: validar las transformaciones en un entorno de desarrollo Documentación: mantener una documentación clara de las transformaciones aplicadas Limitaciones Algunas transformaciones pueden no conservar los tipos de datos originales Las transformaciones complejas pueden afectar la garantía del orden de los mensajes No todas las transformaciones son compatibles entre sí Algunas transformaciones pueden no funcionar con todos los formatos de serialización Recomendaciones de uso 1. Análisis de requisitos Identificar claramente las necesidades de transformación Evaluar el impacto en el sistema en su conjunto 2. Implementación Comenzar con transformaciones simples Probar cada transformación individualmente Documentar todas las transformaciones aplicadas 3. Mantenimiento Supervisar el rendimiento regularmente Revisar periódicamente la necesidad de cada transformación Mantener las transformaciones actualizadas con las nuevas versiones de Debezium Casos de uso CDC se puede aplicar en una variedad de escenarios para optimizar la integración y replicación de datos en tiempo real, algunos de los cuales se mencionan a continuación. Patrón de bandeja de salida (monitorea y reenvía eventos a un Kafka (p. ej.), garantizando que los mensajes se publiquen, incluso con fallas, y desacoplando la lógica de la entrega de mensajes). Duplicación de datos (migración de monolito -> microservicio) Replicación de datos (integración/microservicios -> microservicios) Auditoría de datos Análisis en tiempo real (paneles e informes en tiempo real) Almacenamiento en caché de datos (almacenamiento en caché de ciertos datos de Postgres en Redis, por ejemplo) Datos para consulta (hacer que los datos estén disponibles en un motor de búsqueda como ElasticSearch) CQRS (hacer que los datos de comando estén disponibles en las fuentes de datos de consulta), etc. Uso práctico de la infraestructura de Debezium Preparación Asegúrese de que Docker y Docker Compose estén instalados y en ejecución, ya que necesitaremos cargar Kafka, Zookeeper, Debezium Connector y la base de datos. Creando Docker Compose Cree un archivo docker-compose.yml con el siguiente contenido: 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" entorno: ID_DE_BROKER_KAFKA: 1 CONEXIÓN_ZOOKEEPER_KAFKA: zookeeper:2181 OYENTES_ANUNCIADOS_KAFKA: INTERNO://kafka:9093, EXTERNO://localhost:9092 MAPA_DE_PROTOCOLO_DE_SEGURIDAD_DE_OYENTES_KAFKA: INTERNO:PLAINTEXT, EXTERNO:PLAINTEXT OYENTES_KAFKA: INTERNO://0.0.0.0:9093, EXTERNO://0.0.0.0:9092 NOMBRE_DE_OYENTE_INTER_BROKER_KAFKA: INTERNO FACTOR_DE_REPLICACIÓN_DE_TEMA_DESPLAZAMIENTOS_KAFKA: 1 redes: debezium-network: alias: - kafka kafka-connect: imagen: debezium/connect:2.5 puertos: - "8083:8083" depende de: - kafka - postgres entorno: SERVIDORES BOOTSTRAP: kafka:9093 ID DE GRUPO: 1 TEMA DE ALMACENAMIENTO DE CONFIGURACIÓN: configuraciones de conexión TEMA DE ALMACENAMIENTO DE DESPLAZAMIENTO: desplazamientos de conexión TEMA DE ALMACENAMIENTO DE ESTADO: estados de conexión CONVERSOR DE CLAVE: org.apache.kafka.connect.json.JsonConverter CONVERSOR DE VALOR: org.apache.kafka.connect.json.JsonConverter HABILITAR ESQUEMAS DE CONVERSOR DE CLAVE DE CONEXIÓN: "falso" HABILITAR ESQUEMAS DE CONVERSOR DE VALOR DE CONEXIÓN: "falso" NOMBRE DE HOST ANUNCIADO DE REST DE CONEXIÓN: kafka-connect redes: debezium-network: alias: - kafka-connect redes: debezium-network: controlador: puente Ejecutando los servicios En la carpeta donde se creó docker-compose.yml, ejecute (en la terminal): # dependiendo de cómo se instaló su docker, # deberá usar 'sudo' antes del comando docker compose up Configuración del conector de Debezium Envíe una configuración JSON al punto final REST de Kafka Connect para configurar el conector de Debezium: # 1. Primero, verifique si Debezium Connect se está ejecutando: curl -X GET http://localhost:8083/connectors # 2. Creando el conector # 2.1. Comando principal para crear el conector (SIN transformación / empezar con esto): 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 crear el conector (transformación COM): 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" } }' # Ejemplo de configuración de un conector 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", "valor.convertidor": "org.apache.kafka.connect.json.JsonConverter", "clave.convertidor.schemas.enable": "verdadero", "valor.convertidor.schemas.enable": "verdadero" } }' # 3. Para comprobar el estado del conector: curl -X GET http://localhost:8083/connectors/inventory-clientes-connector/status Explicación del parámetro: name: Nombre del conector, utilizado para la administración (se puede personalizar). connector.class: especifica el conector de Debezium para PostgreSQL (io.debezium.connector.postgresql.PostgresConnector). task.max: Número máximo de tareas paralelas para el conector (puede aumentar dependiendo de la carga). database.hostname: Dirección del servidor PostgreSQL. database.port: Puerto en el que se ejecuta PostgreSQL (el valor predeterminado es 5432). database.user y database.password: Nombre de usuario y contraseña para acceder a la base de datos (el usuario necesita permisos para leer los registros de transacciones). database.dbname: Nombre de la base de datos a monitorear. database.server.name: Nombre lógico del servidor; se utilizará como prefijo para los temas de Kafka creados para las tablas. slot.name: Nombre de la ranura de replicación. Esto cambia los datos en tiempo real mediante la replicación lógica. plugin.name: define el complemento de replicación lógica. Para PostgreSQL 10+ y Debezium, se recomienda pgoutput. table.include.list: Lista de tablas a monitorear (en formato schema.table). Si desea supervisar varias tablas, puede separar los nombres con comas. publication.name: Nombre de la publicación de replicación lógica que captura los cambios en la tabla especificada. database.history.kafka.bootstrap.servers: dirección de Kafka donde se almacenará el historial del esquema, esencial para que Debezium comprenda la estructura de la tabla y los cambios del esquema. database.history.kafka.topic: Tema de Kafka donde se almacenará el historial del esquema. Supervisión de cambios kafka-console-consumer Herramienta de pila de Kafka para consumir temas directamente en la consola. # Consumidor de consola: comprobar mensajes en el tema 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: Interfaz de usuario web de código abierto para la gestión de Apache Kafka kafka-ui: imagen: provectuslabs/kafka-ui:latest container_name: cdc-kafka-ui puertos: - 8080:8080 depende_de: - kafka environment: DYNAMIC_CONFIG_ENABLED: 'true' redes: debezium-network: alias: - kafka-ui "Ver cómo sucede la magia" Crear la tabla -- Crear la tabla CREATE TABLE inventory.public.clientes ( SERIAL PRIMARY KEY id, name VARCHAR(50), email VARCHAR(50), data_criacao TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Comprueba si hay datos SELECT * FROM inventory.public.clientes; Conectando el consumidor Puedes conectar el consumidor predeterminado de Kafka para consumir mensajes tan pronto como ingresan al tema: # Consumidor de consola: verifica los mensajes en el tema sudo docker exec -it cdc-kafka kafka-console-consumer \ --bootstrap-server localhost:9092 \ --topic inventory.public.clientes \ --from-beginning O usa una de las herramientas mencionadas arriba (complemento IntelliJ o Kafka UI). Probando cómo funciona Insertando datos INSERT INTO inventario.public.clientes (nombre, correo electrónico) VALUES ('João Silva 1', 'joao1@email.com'); INSERT INTO inventario.public.clientes (nombre, correo electrónico) VALORES ('João Silva 2', 'joao2@email.com'); INSERT INTO inventario.public.clientes (nombre, correo electrónico) VALORES ('João Silva 3', 'joao3@email.com'); Actualizando datos ACTUALIZAR inventario.public.clientes SET nombre = 'Pedro Silva', correo electrónico = 'pedro.silva@email.com' WHERE id = 1; ACTUALIZAR inventario.public.clientes SET nombre = 'José Silva', correo electrónico = 'jose.silva@email.com' DONDE id = 2; Eliminar datos -- Elimina el 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; Cambiar la cantidad de información de replicación -- Cambia la cantidad de información que está disponible para la decodificación lógica en caso de eventos UPDATE y DELETE. ALTER TABLE inventory.public.clientes REPLICA IDENTITY FULL; Vuelva a ejecutar las pruebas (insertar, actualizar y eliminar) después de ajustar el nivel de replicación. Solución de problemas # Visualización de los registros 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 # Inspeccionando la red sudo docker network inspect debezium-network Conclusión La captura de datos de cambios es una técnica ampliamente utilizada por el mercado, en sus diversas modalidades, en sus diversas herramientas. Es especialmente útil en migraciones de datos y sistemas, facilitando la limitación de un monolito o replicando algunos datos de un microservicio a otro, o simplemente aplicado al patrón Bandeja de salida. En este escenario, Debezium se presenta como una gran herramienta para ello, basada en la plataforma Connect de Kafka, ya probada y comprobada. Pero como en cualquier escenario, tiene sus puntos de atención, riesgos y desventajas.

Cómo estructuramos el nuevo Centro de ayuda Projuris Empresas Usando Confluence. Todos sabemos que la documentación es un proceso importante en la gestión de productos. Preserva el legado, registra decisiones y sirve como una colección completa para que todos comprendan qué se hizo y por qué en el futuro. Dicho esto, también actúa como comunicador y educador, proporcionando a los usuarios toda la información sobre el producto. Bien, pero ¿cómo podemos lograr este objetivo y ofrecerles todo lo que necesitan sin tener que buscar información? La respuesta es bastante simple: configurando un Centro de Ayuda. ¿Por dónde empezar? Elija la herramienta adecuada. Lo importante es que esté dedicada a la documentación, diseñada con este propósito en mente; marca la diferencia. Anteriormente, aquí en Projuris EmpresasUsamos Movidesk, una herramienta de soporte que ofrecía una pequeña base de conocimientos, lo que dificultaba la estructuración de una organización de contenido más intuitiva y comprensible para el usuario, y su usabilidad limitaba la disponibilidad de recursos durante las consultas. Comprendimos qué era necesario mejorar y buscamos herramientas que cumplieran con esta expectativa y que tuvieran la documentación como eje central de su funcionalidad. Así llegamos a Confluence (que ya utilizaban y elogiaban nuestros colegas en... Projuris ADV), su finalidad es ser una herramienta de documentación e incluso es uno de los referentes en este sentido (Habemus Confluence!). Diseña tu estructura Ahora que la herramienta está definida, es momento de pensar en la estructura. Cómo presentar este contenido de una manera que tenga sentido para el usuario y facilite el acceso a la información. Lo solucionamos dibujando literalmente (son muy artísticos): nos sentamos y pensamos en todo el contenido preexistente y cómo presentarlo, la idea principal era que reflejara nuestro producto y fuera intuitivo. De esta manera creamos grandes categorías que sirvieron como agrupaciones para artículos y otros contenidos. Esto también ayudó en el momento de la migración, porque como ya teníamos el “esqueleto” solo necesitábamos mover el contenido a su categoría correcta. Iniciar migración El momento más esperado ha llegado: la migración. Una vez definida la estructura, iniciamos el proceso de migración, transfiriendo exactamente 618 artículos (¡amigos, fue un trabajo duro!) y desafortunadamente, como Movidesk no proporcionó un respaldo en un formato compatible con Confluence, tuvimos que recurrir al viejo y confiable “copiar y pegar”. Y aquí tenemos un punto importante: si la herramienta elegida no estuviera diseñada para la documentación, este proceso sería aún más lento. Como Confluence está diseñado para esto, al pegar el contenido, ya se adaptaría, requiriendo poca intervención. A pesar de todo este trabajo, completamos toda la migración en menos de dos semanas. Ah, y una consideración importante: hoy, si necesitamos exportar todo nuestro contenido, se puede hacer rápidamente en apenas unos minutos, porque Confluence permite exportar en formatos “.pdf, .docx, html y xml”, si es necesario (¡una nueva migración hoy sería pan comido!). Alinear los detalles Después de la migración, llegó el momento de ocuparse de los detalles, es decir, mirar la estructura del contenido en sí. Validamos enlaces, imágenes, gifs, definimos títulos, patrones, etc. En esta etapa, es importante poner al usuario en el centro de tus decisiones, ya que el contenido debe estar alineado con la estructura deseada: asegúrate de que la información presentada en los artículos sea lógica y clara; que los artículos estén estructurados correctamente; y, lo más importante, que se puedan buscar y encontrar fácilmente. Detalles que marcan la diferencia a la hora de la entrega en su conjunto. Aquí, confiamos en la IA para ayudarnos a revisar y crear artículos esenciales, especialmente aquellos destinados a la incorporación de usuarios. El único problema significativo que tuvimos en este proceso fue en relación a las imágenes y gifs que se utilizan para ilustrar nuestra documentación, debido a que este tipo de archivos no se pueden copiar y pegar como el resto del contenido, deben agregarse individualmente (sí, uno por uno), de lo contrario, se crea un enlace entre ambas herramientas y al cabo de un tiempo las imágenes se rompen, pues pierden las referencias de alojamiento, por lo que es bueno ser cuidadosos y atentos en este aspecto, sobre todo al migrar una cantidad considerable de contenido (como fue nuestro caso). Piense en el diseño ¡La presentación es la clave de los negocios! Una vez construido todo el “cuerpo” de nuestra planta, comenzamos a preocuparnos por el diseño en sí. Para ayudarnos con esto, contratamos Refined, un plugin que permite personalizar Confluence. Así que fue el turno de nuestro Diseñador de Producto. Una vez más, dibujamos la estructura que queríamos (mencioné que son artistas), y esto sirvió para validar visualmente si tendría sentido y orientar al especialista. A partir de este dibujo, comenzó a desarrollar el diseño de la central, considerando la identidad visual del producto y su mejor usabilidad. En este paso volvimos a pensar en la correlación entre producto y core, trajimos muchas referencias del sistema a ello, no solo la paleta de colores y logos, sino también iconos, estructura, nomenclatura, todo esto para que el usuario se sintiera familiarizado con el contexto y estableciera esa relación entre ambas cosas (más adelante entenderás por qué esto tenía sentido). Además, no nos limitamos solo a utilizar contenidos de Confluence, también enlazamos links de otras plataformas con información de Projuris, como YouTube, Blog, Sitio Web, Portal de Tickets, etc. Esto permite al usuario tener acceso a todo sobre este universo en un solo lugar. Validar antes de lanzar Entonces, tenemos la estructura, el contenido, el diseño, ¿y ahora qué? ¿Podemos ponerlo al aire ahora? Podría… pero ¿cómo podemos estar seguros de que está en línea con las necesidades de nuestros usuarios? ¿Que no hay posibilidad de mejora? ¡Solo probando, ¿verdad?! Por lo tanto, antes de publicar el nuevo hub en el producto, decidimos invitar a clientes internos y externos para una prueba de validación. Definimos una pequeña hoja de ruta de ejecución (búsqueda, navegación, validaciones de nombres, estructura, etc.) y solicitamos a las personas que brindaran comentarios para alinear aún más nuestra entrega. ¿El resultado de esto? Además del feedback que contribuyó a la asertividad del proyecto (ese “ok” de que tomamos la decisión correcta), pudimos corregir el rumbo antes de la entrega final, cambiando nomenclatura que no estaba muy clara, reordenando contenidos en la estructura y creando nuevos contenidos en base a sugerencias. ¿Recuerdas que hablé de la intención de crear una relación entre el producto y el centro? Esto se confirmó aquí, pudimos ver que los usuarios se orientaron mucho más fácilmente porque relacionaron sus módulos contratados con la presentación disponible en el centro, demostrando familiaridad. ¡Lanzamiento y promoción amplia! Ahora, podemos decir que todo está “redondeado” (al menos al principio) y después de todas las validaciones, finalmente llega el momento de publicar. Empezamos pidiendo al equipo de ingeniería que insertara el enlace al nuevo centro directamente en Projuris. Esto ya era nuestra práctica, así que solo fue necesario reemplazar el acceso antiguo. Al mismo tiempo, alineamos la estrategia de difusión con el equipo de marketing. Cuando todo estuvo listo, lo anunciamos en los canales internos (equipos y email), en el producto (a través de Beamer), en la comunidad Heroes (una comunidad formada por clientes de Projuris) y en email marketing (¡uf, armamos un revuelo!). Próximos pasos. Como dije, esto es solo el comienzo. La documentación es una labor cultural, y es necesario educar a la gente para que comprenda tanto la importancia de producirla como el hábito de consumirla. Entonces, a partir de ahora, nuestros próximos pasos incluyen seleccionar el nuevo centro, recopilar datos para analizar oportunidades de mejora, integrarlo con iniciativas de IA y producir contenido nuevo. Pero la pregunta sigue siendo: ¿estás listo para actualizar tu centro de ayuda? Projuris EmpresasHaz clic aquí para explorar nuestro nuevo Centro de Ayuda y compartir tu opinión. Me encantaría compartir mis ideas sobre los desafíos (¡y los logros!) de este proceso. ¡Envíame un mensaje y creemos juntos documentación aún más increíble!

En 1986, Brasil lo apostó todo a un ambicioso plan para frenar la inflación: una nueva moneda (el cruzado), una congelación de precios y una audaz promesa de estabilización económica. La euforia fue inmediata. Durante un breve período, pareció que el país finalmente había superado la hiperinflación, pero el optimismo duró poco. En pocos meses, la inflación regresó con fuerza y ​​el plan fracasó. Pero ¿por qué fracasó el Plan Cruzado? En pocas palabras, el gobierno brasileño no realizó un diagnóstico claro y preciso de la dinámica inflacionaria. Francisco Lopes, uno de los creadores del plan, reconoció posteriormente que el gobierno subestimó la complejidad de la inflación inercial y sobreestimó el poder de una congelación de precios sin mecanismos de transición (LOPES, 1989). También hubo disputas políticas internas entre ministerios que obstaculizaron la construcción de un plan más sostenible. Luiz Carlos Bresser-Pereira, miembro activo del gobierno en aquel momento, fue uno de los primeros en señalar que el plan carecía de apoyo fiscal y de mecanismos de ajuste más flexibles. ¿El resultado? Un alivio fugaz, seguido de un retorno aún más desorganizado de la inflación, que culminó en el fracaso del plan en menos de un año. ¿Y qué tiene esto que ver con la Gestión de Producto? Más de lo que parece. ¿Con qué frecuencia, en Gestión de Producto, nos sentimos presionados a entregar una solución rápidamente? ¿Cuántas veces nos saltamos la fase de diagnóstico? ¿Cuántas veces nos lanzamos directamente al desarrollo, sin comprender completamente el problema del usuario, el escenario de uso o incluso si el problema existe? Impulsados ​​por la urgencia, entregamos rápido y mal. Y luego lo que lanzamos no resuelve el verdadero problema, no genera valor e incluso puede generar más confusión que solución. Tomemos, por ejemplo, la nueva Pantalla de Consulta de Título que creamos para SiengeCreíamos que lo que más valoraban los usuarios era una pantalla completa, con numerosos filtros y la máxima información disponible. Aunque validamos algunas de estas hipótesis —e incluso algunas se confirmaron— en el lanzamiento, nos dimos cuenta de que la realidad era diferente: la interacción fue menor de lo esperado y, durante la prueba piloto, el 60 % de los clientes seguía prefiriendo usar la pantalla anterior. Ante esta situación, iniciamos una escucha activa: recopilamos opiniones, analizamos los principales puntos de fricción y profundizamos en el comportamiento de los usuarios. Descubrimos que el principal problema no era la falta de información, sino su exceso. Para algunos clientes, la nueva pantalla parecía demasiado recargada y dificultaba la navegación. Por otro lado, también había un grupo que valoraba un acceso amplio y detallado a los datos. En otras palabras, lo que parecía un problema de funcionalidad era en realidad un problema de flexibilidad. La solución surgió de esta comprensión más profunda: creamos dos versiones complementarias: una pantalla sintética, más ligera y objetiva, y otra con un análisis más detallado de los resultados. De esta forma, podemos atender a diferentes perfiles de usuario, respetando sus métodos de trabajo. La versión sintética se someterá a pruebas piloto en los próximos meses. Analicemos las diferencias entre las soluciones propuestas a continuación: Versión sintética Versión analítica ¿Qué dice la teoría? Esta realidad ya se ha debatido ampliamente en las mejores prácticas de producto, como las que defiende Marty Cagan en "Inspired" (2017), quien enfatiza que los mejores productos nacen de una comprensión profunda de los problemas de los usuarios, no de la prisa por entregar algo. Melissa Perri también destaca en "Escaping the Build Trap" (2018) que los equipos que no diagnostican ni priorizan los problemas reales terminan cayendo en la trampa de "entregar por el simple hecho de entregar", sin ningún impacto. El diagnóstico importa mucho. Comprender el contexto, investigar las causas, escuchar atentamente los puntos débiles: esto marca la diferencia. En el Plan Cruzado, la falta de un diagnóstico sólido comprometió toda la estrategia. En la Gestión de Producto, ocurre lo mismo cuando omitimos el descubrimiento y pasamos directamente a la entrega. Referencias: Bresser-Pereira, Luiz Carlos. La Crisis del Estado. Premio Nobel, 1992. Cagan, Marty. Inspirado: Cómo crear productos tecnológicos que los clientes amen. Wiley, 2017. Lopes, Francisco. El shock heterodoxo del Plan Cruzado y la teoría de la inflación inercial. Journal of Political Economy, 1989. Perri, Melissa. Escapando de la trampa de la construcción: Cómo la gestión eficaz de productos crea valor real. O'Reilly Media, 2018.

Este artículo fue elaborado con el apoyo de herramientas de Inteligencia Artificial, utilizadas para estructurar y organizar la información, con revisión y supervisión humana en todas las etapas. En el mundo empresarial, el tiempo es el recurso más escaso y, a menudo, indiscriminadamente, el peor utilizado. Se desperdician miles de horas en tareas repetitivas, procesos manuales y demandas de bajo valor estratégico. ¿Por qué es importante? El impacto de la ineficiencia va mucho más allá de lo financiero: compromete la productividad, reduce el compromiso y debilita la alineación estratégica de los equipos, afectando directamente la capacidad de innovación y la competitividad organizacional. Es en este contexto que la Inteligencia Artificial (IA) deja de ser “una innovación tecnológica más” y comienza a actuar como un pilar estratégico para la transformación organizacional, impulsando la reconfiguración de procesos y la creación de nuevos modelos de trabajo. No hablamos sólo de automatización, sino de cambiar el rol mismo de las personas dentro de las organizaciones, creando espacios para que el talento humano se invierta en creatividad, estrategia e innovación. Los procesos del Manual de Números que no requieren un análisis profundo ni estratégico pueden ser verdaderos saboteadores de la productividad. La automatización impulsada por IA te permite recuperar horas valiosas y, lo que es más importante, te devuelve el enfoque, el propósito y la autonomía. Un estudio realizado por BCG X (2024) mostró que los profesionales que adoptaron IA ganaron, en promedio, 5 horas por semana para realizar actividades de mayor valor aún. Desde una perspectiva empresarial, esto significa semanas enteras de productividad adicional por año. Y los impactos van más allá de los entrevistados: 41% reportó mayor eficiencia en las entregas. El 39% amplió sus responsabilidades a nuevas tareas. El 38% comenzó a actuar de forma más estratégica. La OCDE (2025) refuerza que las empresas que aplican IA a tareas operativas ganan entre un 5% y un 25% en productividad. La ganancia no está sólo en la reducción del tiempo, sino en el reposicionamiento del trabajo humano. Y, sin embargo, según la empresa de tecnología HP, que realizó una investigación global entrevistando a más de 15 personas en 12 países, descubrió que el 73% de los encuestados dice que la IA facilita el trabajo y el 69% personaliza el uso de la IA para aumentar la productividad. Descripción general – El mundo ya ha cambiado. Y trabajar también. Los beneficios de la Inteligencia Artificial, cuando se utiliza bien y se integra estratégicamente en nuestra rutina de trabajo, son claros e indican que necesitaremos cambiar la forma en la que estamos acostumbrados a trabajar. Según la consultora global McKinsey, más del 50% de las ocupaciones tienen al menos un 30% de sus actividades que pueden automatizarse con tecnologías ya disponibles. Para 2030, la mitad de todas las actividades laborales podrían ser realizadas total o parcialmente por IA. Aunque estos datos puedan parecer preocupantes, la interpretación más productiva es optimista: la IA no robará empleos, sino que mejorará la ejecución de tareas repetitivas y rutinarias, liberando espacio para que los profesionales desarrollen habilidades más humanas y creativas. La pregunta ya no es si adoptarás IA, sino cómo la utilizarás de manera responsable, estratégica y mensurable. Dónde la IA es fuerte y los humanos son irremplazables Kai-Fu Lee, científico informático y experto en IA, dice que la Inteligencia Artificial ha llegado para liberarnos del trabajo rutinario y recordarnos lo que nos hace humanos. En su libro Inteligencia Artificial (2019), relata la derrota de Ke Jie, el mejor jugador humano de Go, a manos de AlphaGo (una IA), como símbolo del potencial de la interacción humano-IA: El humano aporta propósito, sentimiento y creatividad a todo lo que hace. La IA ejecuta y sigue comandos con precisión. Basándose en esto, Lee creó una matriz que nos ayuda a entender mejor dónde la IA puede mejorar los procesos y dónde la presencia humana sigue siendo esencial: Necesita interacción social/empatía No hay interacción social ni empatía Fuente: Kai Fu Lee La matriz considera dos dimensiones: Complejidad cognitiva y creatividad: tareas que requieren juicio, empatía, toma de decisiones estratégicas o innovación. Rutina y datos: tareas repetitivas, predecibles o basadas en datos. En función de estas dimensiones, los procesos se pueden clasificar en tres categorías: IA sola: actividades estandarizadas, predecibles o basadas en reglas y datos. Son procesos que se pueden automatizar sin pérdida de calidad ni riesgo. Solo humanos (con posibilidad de utilizar IA como apoyo): actividades que requieren comprensión contextual, creatividad, empatía o toma de decisiones estratégicas. Se trata de procesos que no pueden delegarse exclusivamente a la IA sin comprometer el resultado. Humano + IA: procesos en los que la IA realiza tareas repetitivas o analíticas, liberando al humano para que se concentre en lo que requiere juicio, visión estratégica o creatividad. Esta combinación genera resultados más eficientes y permite a los humanos actuar con alto valor. De esta manera, cualquier área puede analizar sus procesos, pensando en qué se puede automatizar de forma segura y qué requiere inteligencia y sensibilidad humana. La matriz sirve como guía para priorizar dónde invertir en IA y dónde mantener a los humanos en el centro del proceso. Según Kai-Fu Lee, hay tres áreas en las que la IA no alcanza las capacidades humanas y es poco probable que pueda hacerlo en las próximas décadas: Creatividad: la IA no crea, conceptualiza ni planifica estratégicamente. Sólo optimiza objetivos definidos, sin capacidad de fijar metas, aplicar conocimientos en diferentes áreas o utilizar el sentido común. Empatía: La IA no puede sentir ni interactuar basándose en las emociones. No transmite atención, comprensión ni motivación genuina, y es poco probable que sustituya el contacto humano en los servicios que dependen de esta conexión. Destreza física: La IA no puede realizar tareas físicas complejas que requieran destreza o coordinación motora, ni navegar en espacios desconocidos y desestructurados, especialmente aquellos que no ha observado. El futuro del trabajo no se trata de humanos ni de máquinas, sino de la sinergia entre ambos, una colaboración en la que la IA potencia lo que mejor hacemos, mientras que nosotros le damos dirección, propósito y creatividad a lo que hace. 6. Softplan El equipo de privacidad de Starian y Softplan identificó una oportunidad estratégica para optimizar dos actividades esenciales, pero operativas y que consumen mucho tiempo: el análisis de contratos y la respuesta a cuestionarios de privacidad. Contratos: deben implementarse y revisarse para garantizar el cumplimiento de las políticas y la legislación interna. Cuestionarios de privacidad: requieren respuestas fundamentadas en regulaciones y documentos internos, son extensos y cruciales para la transparencia y la consistencia. A pesar de su importancia, el proceso era manual, seguía estándares internos y requería muchas horas, lo que aumentaba el riesgo de errores a medida que crecía la demanda. El equipo vio la IA como una oportunidad para transformar este escenario. De la idea a la implementación Con el soporte de TI, la solución fue creada de forma estructurada y segura. Operando en un entorno cerrado, lo que garantiza una mayor protección y privacidad de los datos. El desarrollo siguió cinco pasos: Priorizar las actividades de mayor impacto y volumen. Defina los límites de la IA mientras mantiene las decisiones críticas bajo supervisión humana. Entrenar el modelo con contratos, políticas internas y referencias relevantes. Configurar estándares y comandos para el contexto organizacional. Integrar la entrega final con comentarios y sugerencias para revisión por parte del equipo de privacidad. El resultado: una herramienta que analiza contratos y cuestionarios, entrega el documento listo para su revisión y mantiene la consistencia y la calidad. Impacto en la productividad Las ganancias fueron tangibles: Contratos: Considerando un promedio de 70 contratos recibidos por mes, cada uno tomó un promedio de 2 horas para analizar. Con IA ahorramos 30 minutos por contrato, equivalente a 35 horas/mes o 420 horas/año. Cuestionarios de privacidad: Se produjo una reducción de tiempo del 50%, ahorrando 2h30 por cuestionario, equivalente a 50h/mes o 600h/año. Esta automatización liberó al equipo para tomar decisiones estratégicas sin comprometer la calidad o confiabilidad de los procesos. Aprendizajes y mejores prácticas A lo largo de la implementación, el equipo de Starian Privacy se dio cuenta de que el éxito de la IA depende del equilibrio entre la tecnología y la supervisión humana. Algunos puntos destacados: La personalización es clave: la IA debe entrenarse y adaptarse al contexto, las demandas y las actividades comerciales específicas. Cada detalle cuenta. La supervisión continua es esencial: pueden producirse alucinaciones y errores, y la intervención humana garantiza la precisión y la adecuación. La calidad de los datos importa: cuanto mejores sean los datos ingresados, mejores y más confiables serán los resultados generados. La interacción constante genera mejoras: el feedback real del equipo mejora la herramienta y crea una evolución continua. Las decisiones críticas siguen siendo humanas: la IA es un aliado, pero el análisis estratégico sigue siendo una condición esencialmente humana. Las soluciones contratadas aumentan la seguridad: las herramientas validadas garantizan la consistencia y la protección. Estas lecciones muestran que la agilidad y la precaución deben ir de la mano. El uso inadecuado de la IA puede generar graves riesgos: pérdidas financieras, fuga o retención indebida de datos personales, sensibles y confidenciales, creación de información falsa y dependencia excesiva de sistemas inseguros. Por ello, algunas prácticas son esenciales: Evitar introducir datos personales o documentos confidenciales, especialmente en herramientas no contratadas. Revise siempre el contenido generado. Cuestionar los sesgos o distorsiones en los resultados. Utilice únicamente soluciones aprobadas y adecuadas por la organización. Capacitar al equipo y registrar los riesgos de cada uso junto con las áreas de privacidad y seguridad de la información. En Starian, hemos aprendido que cuando los humanos y la IA trabajan en sinergia, los beneficios van mucho más allá de la productividad: ofrecemos mayor calidad, seguridad y tiempo para concentrarnos en lo que realmente importa: las decisiones estratégicas que solo los humanos pueden tomar. La tecnología mejora, pero es el ojo humano el que garantiza la consistencia y la confianza. Softplan demuestra que la Inteligencia Artificial, cuando se implementa con propósito, personalización y supervisión humana, va mucho más allá de la automatización: se convierte en un multiplicador de valor. La ganancia no solo se ve en horas ahorradas, sino en calidad, consistencia y la capacidad de dedicar energía a lo que realmente impulsa los resultados, las decisiones estratégicas, la innovación y las relaciones de confianza. El futuro del trabajo ya ha comenzado. Las organizaciones que aprenden a combinar la precisión de la IA con la mirada crítica y creativa de los humanos no solo optimizan los procesos, sino que también construyen equipos más comprometidos y preparados para los desafíos de un mercado en constante cambio. Más que reemplazar tareas, la IA nos invita a redefinir prioridades, expandir nuestro alcance y, lo más importante, reforzar lo que ninguna máquina puede replicar: propósito, sensibilidad y visión. Cuando los humanos y la IA trabajan juntos, la productividad y el impacto dejan de ser objetivos aislados y se convierten en el nuevo estándar de excelencia.

Recientemente, dirigí los equipos de Producto y UX en el desarrollo de una solución SaaS de IA para SEO, con un enfoque estratégico en la adopción de tecnologías que aceleren la búsqueda del ajuste producto-mercado (PMF) y el producto mínimo viable (MVP). El enfoque elegido también tuvo como objetivo optimizar factores cruciales, como reducir los costos de desarrollo y acortar la curva de aprendizaje, garantizando un proceso más eficiente y accesible. Por lo tanto, decidimos utilizar la siguiente pila de soluciones para el desarrollo de software: Figma (creación de prototipos); solución sin código para el front-end web; inicialmente, íbamos a utilizar un back-end de bajo código, pero cambiamos a tecnología de alto código. Una de las principales ventajas de este stack es que la velocidad de desarrollo del front-end sería mucho más rápida gracias a los facilitadores, pero mantuvimos el núcleo de la solución en el back-end utilizando tecnología de alto código, lo que permite escalar con mayor eficiencia y flexibilidad en la nube. Puedo explicar el fundamento y las opciones que consideramos en una publicación futura, pero sigamos adelante (comenta aquí si deseas leer sobre ello). 5 lecciones aprendidas del no-code: 1. Mayor velocidad: Es indiscutible que una solución sin código aporta mayor agilidad al desarrollo. Creo que hemos reducido el tiempo de desarrollo frontend en aproximadamente un 80 %. Es realmente agradable ver lo fácil que es crear interfaces y flujos de trabajo, especialmente cuando puedes simplemente usar un complemento e importar las pantallas directamente desde Figma. Si eres UX o PM, imagina validar entregas y realizar ajustes rápidamente. Mejor aún: ¡puedes crear las interfaces tú mismo! Hice esto yo mismo varias veces a lo largo del proyecto. A menudo dedicamos tiempo a documentar pequeños ajustes de usabilidad para que los desarrolladores los solucionen, pero con este enfoque, simplemente podría seleccionar la capa y ajustarla directamente, sin intermediarios. Hay un punto positivo que vale la pena destacar: El software no-code que utilizamos tiene una estructura de auto-layout muy similar a Figma, si dominas Figma podrás hacerlo fácilmente. 2. Habrá una curva de aprendizaje: hay pocos profesionales con experiencia práctica en el uso de tecnología de bajo código o sin código en el país. Esto significa que probablemente tendrás que entrenar al equipo para lidiar con esta tecnología, y naturalmente esto generará algunos errores operacionales, bugs, y freirá algunas neuronas. La curva de aprendizaje es mucho menor que con la tecnología de alto código, pero llevará algún tiempo formar un equipo maduro. 3. Tendrás que repensar algunos procesos: gestión de equipos, sucursales, fusiones, servidores de homologación, despliegues... Tendrás que pensar en estos procesos para garantizar entregas de calidad y mitigar errores. Imagínese a alguien haciendo un “clic incorrecto” en un software sin código y cargando la rama equivocada en producción… 4. Surgen nuevos problemas: No todo es perfecto. Al usar una plataforma para desarrollar software, se puede acabar dependiendo de la empresa que la proporciona (la famosa dependencia del proveedor), por lo que es importante elegir con cuidado la tecnología que se utilizará. En el caso del software que elegimos, es posible exportar el proyecto en código, por lo que si en el futuro se quiere sacar de la plataforma, es posible, aunque yo nunca lo he hecho, ¿alguna vez habéis exportado un proyecto en producción? Cuéntanos cómo te fue. Adicionalmente, empiezas a encontrarte con diferentes problemas, por ejemplo, había una pantalla que tenía un comportamiento que con un simple bucle “for” se podía resolver en el código, pero en no-code era un reto… Impresión de una llamada donde estábamos tratando de resolver este problema: 5. Habrá cambios de paradigma: como ocurre con cualquier cambio, algunas personas pueden sentirse amenazadas, temerosas o resistentes. Es necesario encontrar personas dispuestas a reaprender muchas cosas y explorar cosas nuevas. No tuvimos ninguna resistencia en este proyecto, pero he visto gente en otros entornos que todavía cree que estas soluciones no escalan y no funcionan. Conclusión El uso de herramientas low-code/no-code, como WeWeb, nos ha ayudado significativamente a acelerar la experimentación y el desarrollo de software. Sin embargo, no todo es color de rosa: a lo largo del camino, tuvimos que repensar varios procesos de DevOps a medida que surgían matices específicos del mantenimiento de software de bajo código en producción. El verdadero desafío para cualquier negocio es comprender profundamente las necesidades de los clientes y encontrar formas efectivas de aumentar el compromiso, el valor percibido, la adquisición y la retención. Además, cada producto de software conlleva un coste que a menudo se pasa por alto: el coste de oportunidad. Este coste representa el tiempo y los recursos que decidimos invertir en una determinada iniciativa (tiempo que podría destinarse a otras inversiones potencialmente más valiosas).