He construido aplicaciones, servicios, procesos e integraciones desde la interfaz hasta los datos y la operación. Esa experiencia me permite decidir la arquitectura conociendo sus consecuencias en cada una de esas capas.
Criterio profesional
Trabajar de un extremo al otro da una ventaja: se ve el efecto de cada decisión en el lado contrario. También da la tentación de saltarse los límites, y ahí es donde hay que tener disciplina.
Cuando el mismo desarrollador hace la interfaz y el servicio, es fácil colar lógica de negocio en la pantalla porque va más rápido. Va más rápido hoy y lo paga el siguiente que necesite esa regla en otro sitio.
La interfaz y el servicio pueden sustituirse sin migrar todo el histórico, aunque el esfuerzo depende de su alcance y de los contratos existentes. Cambiar el modelo de datos suele exigir migraciones, compatibilidad, reconciliación y validación sobre información acumulada; por eso acostumbra a ser la decisión menos reversible. El plazo solo puede estimarse después de medir esos factores.
El frontal acumula la lógica que nadie prueba porque «se ve enseguida si falla». Se ve enseguida el día que se mira, no el día que se rompe.
La tecnología más adecuada sobre el papel es la peor decisión si el equipo que se queda no la conoce y no hay presupuesto para que la aprenda.
Dónde se concentra la complejidad
Se gestiona entre correos y hojas de cálculo, o entre dos aplicaciones que no se hablan, o dentro de algo heredado que ya nadie toca. Funciona hasta que crece el volumen o se marcha quien lo llevaba.
Un proceso se gestiona a mano entre correos y ficheros compartidos porque ningún sistema lo cubre. Funciona hasta que crece el volumen o se va la persona que lo llevaba.
Cada uno guarda una parte de la verdad y no se ha definido cuál manda sobre cada dato. Las discrepancias aparecen en el peor momento.
La información existe pero vive dentro de una aplicación que no la deja salir de forma consultable, así que nadie puede analizarla.
No hay equipo para separar frontal, servicio, datos y despliegue, y hace falta alguien que responda del conjunto sin dejar huecos entre capas.
Funciona, pero cualquier cambio rompe otra cosa. Hay que decidir si se estabiliza, se reescribe por partes o se sustituye.
Lo que se hizo para demostrar una idea ahora debe funcionar en producción, con seguridad, errores controlados y alguien que lo opere.
Qué miro y qué queda por escrito
Cuando la necesidad no cabe dentro del LMS, o no debe estar dentro, esto es lo que se acaba construyendo.
Herramientas internas para procesos que ningún producto cubre: seguimiento, coordinación, revisión, aprobación. Con sus roles, sus estados y su registro de quién hizo qué.
Servicios con contrato explícito, versión declarada y comportamiento definido cuando el otro extremo falla o tarda. Con autenticación y límites de uso donde hacen falta.
Lo que debe ocurrir sin que nadie lo lance: sincronizaciones, cálculos, envíos, cierres. Con estado visible, reintentos y capacidad para reanudar la ejecución desde el punto en que se interrumpió.
Estructuras pensadas para preguntar, no solo para guardar, con extracciones periódicas hacia donde se analiza y trazabilidad hasta el registro de origen.
Pantallas que usa gente que no eligió usarlas, así que tienen que ser rápidas, entendibles y accesibles. Con los estados de carga, error y vacío resueltos, que es donde se nota el oficio.
Entender qué hace algo que ya nadie toca, cubrirlo con pruebas antes de cambiarlo y sustituirlo por partes sin parar el servicio que presta.
Responsabilidades concretas
La interfaz, el servicio, el modelo de datos y el despliegue. Los fallos más difíciles de resolver no viven dentro de una capa: viven en el espacio que queda entre dos, donde nadie se siente responsable.
Qué hace el frontal, qué el servicio, qué la base de datos y qué queda fuera. Los fallos cuya responsabilidad queda sin asignar se cuelan en los huecos entre capas.
Interfaz utilizable y accesible por delante, servicios y procesos por detrás, con la misma exigencia de calidad en ambas capas, algo que no siempre ocurre.
Pensar el modelo desde el principio para que alguien pueda hacerle preguntas después, en lugar de descubrir a los dos años que la información está pero no se puede extraer.
Qué se expone, con qué versión, qué ocurre cuando el otro extremo no responde y quién se entera. Una integración sin contrato es una avería aplazada.
Despliegue repetible, errores que se ven, capacidad de volver atrás y suficiente información para diagnosticar sin adivinar.
Documentación, pruebas y decisiones explicadas para que el equipo que se queda pueda seguir sin depender de quien lo escribió.
Cómo trabajo
Empiezo por lo que más riesgo tiene, porque dejar lo incierto para el final es la manera habitual de descubrir tarde que el diseño no servía.
Lo que se pide suele ser una solución ya imaginada. Vuelvo al problema antes de aceptar la forma en que llega.
Qué hace cada capa, qué guarda cada sistema y por dónde se hablan. Antes de escribir código.
Primero lo que puede invalidar el diseño. Dejar lo incierto para el final es la forma habitual de descubrir tarde que no funcionaba.
Las reglas de negocio y los recorridos completos, no solo las funciones fáciles de probar. Y comprobar que las pruebas fallan cuando deben.
El trabajo no termina con la entrega, sino cuando el sistema funciona con personas que lo usan y el equipo puede operarlo sin mí.
Experiencia y trabajo propio
Trabajo propio relacionado
Colas, eventos, trazas, contratos y pruebas: lo que hace falta para recuperar el estado y continuar desde un punto seguro después de un fallo. El trabajo hecho para otras organizaciones no aparece por confidencialidad.
Una aplicación propia con telemetría, auditoría y operaciones remotas acotadas.
Ver la ficha de Gobierno de ecosistemas multi-LMS ↗Plataforma y operaciónUna pasarela para gobernar, asegurar y observar las integraciones.
Ver la ficha de Capa de API e integraciones ↗Conocimiento y contenidosBúsqueda textual y vectorial, API para agentes, herramientas y evaluaciones.
Ver la ficha de Centro de conocimiento y operaciones ↗Conocimiento y contenidosOrquestación por fases, estado fuera del modelo y trazas de cada ejecución.
Ver la ficha de Sistema de automatización editorial con IA ↗Blog
Sobre cuándo conviene una aplicación propia y cuándo no, cómo se define un contrato entre sistemas que aguante el cambio, y qué hacer con el código heredado que funciona pero que nadie se atreve a tocar.
Ir a blog.albertolarah.comHablamos
Los procesos que se sostienen con hojas de cálculo y correos son los que más cuesta llevar a un sistema, y los que más se agradecen cuando se hace. Si tienes uno así, escríbeme.