El sistema del que depende la operación de una empresa —el que gestiona los pedidos, las pólizas, los expedientes o los envíos— no se construye acumulando fragmentos generados sobre la marcha. Necesita un modelo de datos decidido, contratos entre módulos, un modelo de permisos y trazabilidad, y esas cuatro cosas son decisiones que alguien toma, no resultados que se obtienen.
La confusión aparece porque la generación asistida funciona muy bien en lo periférico, y eso genera la expectativa de que funcionará igual en el núcleo.
Criterio | Sistema core | Sistema periférico |
|---|---|---|
Si deja de funcionar | La empresa para | Alguien se molesta |
Vida útil esperada | 5-15 años | Meses o pocos años |
Número de integraciones | Muchas y críticas | Pocas o ninguna |
Coste de un error | Dinero, cliente o cumplimiento | Tiempo perdido |
Quién debe poder mantenerlo | Cualquier equipo competente | Quien lo hizo |
La primera fila es suficiente para clasificar el 90% de los casos. Si la respuesta a «¿qué pasa si esto deja de funcionar durante un día?» es que se detiene la facturación, la producción o el servicio al cliente, es core, y merece el tratamiento de core con independencia de su tamaño.
Un error frecuente es asumir que el core es lo grande. Hay sistemas pequeños de los que depende toda la operación, y sistemas enormes que nadie echaría de menos durante una semana.
El modelo de datos. Cómo se representan las entidades del negocio: qué es un cliente, un expediente, un envío; qué relaciones tienen; qué estados atraviesan. Es la decisión más costosa de revertir, porque todo lo demás se construye encima.
Las fronteras de propiedad. Qué módulo manda sobre qué información y cuál consulta. Sin esta decisión aparecen tres sistemas escribiendo el mismo dato y ninguna forma de saber cuál tiene razón.
El modelo de permisos. Quién ve qué y quién puede hacer qué, resuelto como una capa del sistema y no como condiciones repetidas por toda la aplicación. Es lo que determina si mañana se puede añadir un asistente, un portal de cliente o una API sin abrir un agujero.
La trazabilidad. Qué se registra de cada cambio y durante cuánto tiempo. Es irrecuperable hacia atrás: lo que no se guardó no existe.
Ninguna de las cuatro se puede delegar en una herramienta de generación, porque todas dependen de conocer el negocio y de anticipar cómo va a cambiar.
Sería absurdo renunciar a la velocidad disponible. Dentro de un core bien estructurado, la generación asistida rinde bien en:
La regla es sencilla: se delega la construcción, no la estructura. Y la revisión sigue siendo obligatoria, por la razón que expusimos en el código que nadie entiende es deuda
Existe un criterio operativo para saber si un sistema core está bien construido, y no requiere auditoría: ¿podría otro equipo hacerse cargo de este sistema en un mes, sin hablar con quien lo construyó?
Para que la respuesta sea sí hacen falta cuatro cosas: documentación de arquitectura, contratos de integración versionados, pruebas que expresen lo que el negocio espera y decisiones explicadas por escrito.
Un sistema que no pasa esta prueba tiene un riesgo operativo real, con independencia de su calidad técnica: la continuidad de la empresa depende de la disponibilidad de personas concretas. Y tiene además un efecto financiero, porque es exactamente lo que se penaliza en una due diligence tecnológica.
Porque la barrera de entrada para producir algo que funciona ha bajado mucho, y con ella la barrera para producir algo que funciona y no se puede mantener.
Los datos de GitClear sobre 211 millones de líneas de código muestran el patrón: el trabajo de refactorización cayó de alrededor del 25% del cambio total en 2021 a menos del 10% en 2024, mientras la duplicación se multiplicaba por ocho. Se construye más y se estructura menos, y en un sistema periférico eso es asumible; en un core es una hipoteca.
Cuando toque decidir cómo construir un sistema crítico, la conversación útil no es sobre metodología ni sobre herramientas. Es sobre tres compromisos:
Con esos tres compromisos, la velocidad de generación es una ventaja. Sin ellos, es la forma más rápida conocida de construir algo que nadie podrá cambiar.
Es el sistema del que depende la operación: si deja de funcionar un día, se detiene la facturación, la producción o el servicio al cliente. No se define por su tamaño —hay sistemas pequeños que son core y sistemas grandes que no lo son— sino por la consecuencia de su indisponibilidad.
Cuatro: el modelo de datos que representa las entidades del negocio, las fronteras de propiedad que determinan qué módulo manda sobre qué información, el modelo de permisos resuelto como capa del sistema, y la trazabilidad de los cambios. Ninguna puede delegarse en una herramienta de generación.
Sí, dentro de una estructura previamente decidida: implementación de reglas ya especificadas, capa de presentación, transformaciones con criterio de aceptación explícito y documentación de casos ya descritos. La regla es delegar la construcción, no la estructura.
Con la prueba del relevo: si otro equipo podría hacerse cargo en un mes sin hablar con quien lo construyó. Requiere documentación de arquitectura, contratos de integración versionados, pruebas que expresen lo que el negocio espera y decisiones explicadas por escrito.
Un riesgo operativo —la continuidad depende de personas concretas— y un riesgo financiero, porque es precisamente lo que se penaliza en una due diligence tecnológica cuando se valora la compañía o se busca inversión.
Porque la barrera para producir código que funciona ha bajado mucho. GitClear documentó que la refactorización cayó de ~25% del cambio total en 2021 a menos del 10% en 2024 y que la duplicación se multiplicó por ocho: se construye más y se estructura menos, lo que en un sistema crítico se convierte en una hipoteca.
¿Vas a construir un sistema del que dependerá tu operación? Definimos arquitectura, modelo de datos y contratos antes de escribir código, y te transferimos el código y la documentación por contrato. Hablemos → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
