Una estrategia bancaria o aseguradora termina convirtiéndose en decisiones operativas: quién atiende al cliente, quién toma una decisión de riesgo, quién ejecuta la instrucción y quién mantiene el registro. La arquitectura debe reflejar esas responsabilidades y hacer visibles sus costes y dependencias antes de comprometer la inversión.
Empieza por las responsabilidades del negocio.
Empieza por el servicio y por sus costes y valor. Una solicitud de préstamo debe llegar a una decisión crediticia autorizada, al desembolso y a la gestión posterior. Un siniestro debe conectar su comunicación con la revisión de cobertura, la liquidación y la conciliación. Front, middle y back office describen funciones de esos procesos; no son un organigrama fijo.
Pregunta qué reglas deben mantenerse juntas, quién puede decidir y qué sistema es responsable de cada registro. Incluye los datos de riesgo y actuariales cuando corresponda: su origen, las hipótesis, la versión del modelo y las evidencias de revisión deben poder entenderse al pasar entre sistemas.
Define cómo se conectan los sistemas.
Cada conexión crea una dependencia. Especifica los esquemas de API y eventos, los permisos, la compatibilidad entre versiones y el significado de cada estado. Define dónde se conserva el estado del proceso, cómo evitan los reintentos duplicar operaciones y cómo se concilian y recuperan los fallos parciales.
Demuestra estas decisiones con pruebas y evidencias de funcionamiento. Los casos de negocio, la conciliación de datos, las comprobaciones de acceso y los ensayos de fallo deben formar parte de la aceptación, junto con procedimientos documentados y responsables del servicio.
Decide qué necesita cambiar por separado.
La modularidad no obliga a dividirlo todo en microservicios. Cada separación añade trabajo de integración, supervisión y operación. Compara ese coste con la necesidad de cambiar un producto, una regla o un canal de forma independiente y con los medios del equipo para gestionarlo.
A veces basta con una aplicación bien organizada. Otras veces, una función necesita su propio servicio. Cada separación debe tener un motivo que puedas explicar; cuántas haya importa menos.
Deja margen para la próxima decisión.
Con la IA, las entidades pueden desarrollar más software a medida. La arquitectura determina si ese trabajo se convierte en un activo reutilizable: una regla que el negocio puede cambiar, un proceso que sirve a otro producto o una interfaz que conecta un nuevo canal. Separa esos activos de la infraestructura y de los proveedores de los que dependen.
En Firefly conectamos este diseño con una modernización progresiva. Empieza por un servicio útil, conéctalo con los sistemas existentes y conserva las reglas, el software y el conocimiento que se creen. Cada paso debe mejorar la operación actual y dar a la entidad más margen para su próxima decisión de negocio.