El código es un medio
El producto es un sistema que corre, se audita y sobrevive al mantenimiento. El código es uno de sus materiales.
Introducción
Construyo sistemas. Pero primero los entiendo.
En los entornos donde trabajo, ese orden importa: construir el sistema equivocado cuesta mucho más que tomarse el tiempo de entenderlo primero.
Qué hago
- Arquitectura de sistemas
- Arquitecturas diseñadas para entornos complejos, donde operación, seguridad, trazabilidad y evolución pesan tanto como el código.
- Modernización de sistemas legacy
- Transformo sistemas que ya están funcionando, sin perder el conocimiento acumulado dentro de ellos.
- Transformación técnica
- Conecto tecnología, procesos y organización para que un problema estructural se convierta en un plan implementable, con responsables y etapas verificables.
- RegTech y sistemas empresariales
- Sistemas donde reglas, seguridad y auditoría pertenecen a la arquitectura desde el primer día.
- Ingeniería AI-native
- Agentes, modelos locales y automatización aplicados a la forma en que se construye el software.
Cómo pienso
Todo problema empieza con la misma pregunta: ¿qué está pasando realmente aquí?
- Problema
- Modelo
- Arquitectura
- Sistema
- Evolución
- El problema primero
- La primera formulación de un problema rara vez es la real. Renegocio el problema antes de diseñar cualquier cosa.
- Estructura antes que síntoma
- Un síntoma es barato de arreglar una vez y caro de seguir arreglando. Busco la causa estructural.
- Descomposición
- La ambigüedad cede ante la descomposición: dominios, procesos, datos, reglas, actores, estados, integraciones.
- Niveles
- Las decisiones viajan entre niveles, del código a los servicios, a la arquitectura, a la organización. Diseño en el nivel donde el problema realmente vive.
- La deuda es una decisión
- La deuda técnica tomada a propósito sirve para ganar tiempo. Tomada por accidente, cobra intereses.
- Complejidad explícita
- La complejidad nunca desaparece. El trabajo consiste en hacerla lo suficientemente explícita para gestionarla.
Arquitectura
Modelos recurrentes de proyectos reales.
- Metadatos en lugar de ramas de código
- Cuando las variaciones se multiplican, las saco del código y las paso a metadatos. La configuración es más barata de auditar que una rama en el código.
- Reemplazo incremental
- Contratos estables alrededor del sistema viejo, y reemplazo pieza por pieza detrás de ellos. La versión riesgosa de la modernización es el big bang.
- Linaje y observabilidad
- Si una cifra importa, su origen importa. El linaje de datos y la observabilidad se diseñan desde el inicio, mucho antes de cualquier incidente.
- Identidad como capa
- Control de acceso modelado sobre funciones de negocio, aplicado centralmente, adaptado localmente.
Experimentos
Aprendo construyendo. La mayoría de esto nunca va a ser producto, y está bien así.
- Interfaces embebidas
- Placas ESP32 y pequeñas interfaces físicas, donde los límites son físicos y la retroalimentación es inmediata.
- Modelos locales y agentes
- Corro modelos en mi propio hardware y conecto agentes a flujos reales para ver dónde se rompen.
- Herramientas de desarrollo
- Herramientas CLI y automatización para mi propio flujo de trabajo, donde el primer usuario soy yo.
- Linux
- Mi entorno diario, y donde corre todo lo anterior.
Notas
Un cuaderno de trabajo: decisiones, patrones, errores y lo que me enseñaron.
El sistema también es la organización
Una arquitectura tiene que convivir con equipos, presupuestos, regulación y plazos. Los diagramas que los ignoran son ficción.
La IA es una capa nueva
Los agentes y los modelos cambian qué es el proceso de ingeniería. Ese cambio merece el mismo rigor que cualquier arquitectura.
Sobre mí
Llegué a la arquitectura por los problemas de los que nadie se hacía cargo de punta a punta: un reporte que fallaba en algún punto entre dos sistemas, una plataforma demasiado vieja para no tocarla y demasiado crítica para apagarla. Alguien tenía que entender el todo, y yo seguí levantando la mano.
No soy el ingeniero que recibe un sistema y pregunta cómo modificarlo. Intento entender qué sistema debería existir.
Por eso la modernización me interesa más que la página en blanco. Las restricciones son reales y el conocimiento está enterrado. La recompensa es un sistema que conserva su historia sin quedar atrapado en ella.
Materiales de trabajo .NET · Java / Spring · Angular · React · REST APIs · microservicios · serverless · Docker · Kubernetes · Azure · sistemas distribuidos · ETL · RBAC / Entra ID · Linux · ESP32