La actualización es una decisión de diseño, no una función
Cada fuente publica en sus propios términos. Algunas exponen una interfaz que puede consultarse a demanda, algunas producen un archivo durante la noche, y algunas requieren que una persona exporte un informe. Una arquitectura viva registra lo que cada fuente puede realmente hacer y diseña el flujo de trabajo en torno a esa realidad.
Por eso una promesa genérica de actualizaciones cada hora no es creíble. Lo creíble es mostrar la antigüedad de cada cifra en la interfaz y definir, por fuente, cuál es una antigüedad aceptable.
La conciliación debe evidenciar el desacuerdo
Cuando dos fuentes están en desacuerdo, la respuesta incorrecta es elegir una. Una arquitectura viva conserva ambos valores, registra de dónde proviene cada uno y dirige la diferencia a alguien que pueda resolverla.
Con el tiempo, el patrón de discrepancias es en sí mismo información. Si una fuente llega sistemáticamente tarde o se equivoca sistemáticamente en el mismo campo, se trata de un problema de integración que vale la pena corregir, no de una tarea de conciliación que valga la pena automatizar.
Los permisos viajan con los datos
Las reglas de acceso no pueden aplicarse únicamente en la pantalla. Si un paso de recuperación puede leer un documento, entonces una respuesta generada a partir de ese documento puede filtrar su contenido a alguien que no debería verlo. Los permisos deben aplicarse en la recuperación, no en la presentación.
Esa restricción moldea el modelo de datos. Las entidades, las carteras de clientes y la propiedad de los casos no son solo dimensiones de reporte; son los límites que el sistema hace cumplir.
Las fechas de fuente pertenecen a la pantalla
Un número sin fecha es una afirmación. Un número con una fuente y una fecha es evidencia. Mostrar ambas cosas, incluido un estado explícito de desactualización cuando una fuente no se ha actualizado, es una de las formas más económicas de hacer confiable a un sistema.
Retroalimentación y control de cambios
Las correcciones de los revisores son valiosas, pero no deberían alterar el sistema de forma silenciosa. Una corrección se convierte en un cambio propuesto: se registra, se evalúa frente a las medidas de aceptación, la aprueba un responsable designado y se lanza como una versión que puede revertirse.
Esta es la distinción que más importa. La vigencia de los datos significa que el sistema está observando información actual. El reentrenamiento del modelo significa que el comportamiento del sistema cambia. Lo primero debe ser rutinario y continuo. Lo segundo es un lanzamiento controlado con sus propias pruebas y aprobación, y nunca debería ocurrir como efecto secundario del uso diario.
El retiro forma parte del ciclo de vida
Los flujos de trabajo dejan de ser útiles con el tiempo. Una fuente se reemplaza, una normativa cambia, un equipo se reorganiza. Una arquitectura viva incluye una forma de retirar un componente: retirarlo del flujo de trabajo, conservar sus registros conforme a las reglas de retención acordadas y eliminar el acceso que ya no tiene propósito.
Un sistema que solo puede crecer no está vivo. Se está acumulando.