Las áreas del banco · Episodio 4 de 7
El traductor frente al core
El core bancario lleva el registro oficial de las cuentas, y su modelo no es el del banco: habla de «contratos», «intervinientes» y «apuntes», con códigos de dos cifras. El proveedor saca una versión nueva cada año.
El punto de partida
En el episodio anterior el banco cortó su software en seis contextos, cada uno con su lenguaje. Pero los contextos no viven aislados: Cuentas lee del core bancario, Tarjetas recibe autorizaciones de la red de tarjetas, Operaciones envía los Bizum por una conexión que presta la matriz y varias áreas quieren enterarse de cada movimiento.
Entre dos contextos siempre hay una relación, aunque nadie la haya decidido. La pregunta es cuál: quién manda sobre el modelo, quién se adapta y quién traduce.
El mapa de contextos
Un mapa de contextos dibuja esas relaciones. En cada una hay un lado aguas arriba (U), el que publica su modelo, y otro aguas abajo (D), el que lo usa. Lo que cambia de una relación a otra es cómo se reparte el poder sobre el modelo.
En la simulación hay cuatro relaciones de New Capital Bank, cada una con su situación. Elige el tipo de cada una y mira si encaja.
Qué ha pasado
Cada relación pide un tipo distinto, y la razón es siempre la misma pregunta: ¿quién controla el modelo de arriba y cuánto cambia?
- Con la red de tarjetas, lo correcto es ser conformista: es el estándar del sector, casi no cambia y nadie va a negociar con un banco pequeño. Traducirlo sería pagar mantenimiento por nada.
- Con la conexión con Bizum de la matriz cabe una relación cliente-proveedor: es del grupo, y New Capital Bank puede pedir cambios y negociar prioridades.
- Hacia los consumidores de movimientos, Cuentas ofrece un servicio abierto: publica «MovimientoRegistrado» como contrato estable y quien quiera se suscribe.
- Con el core bancario, un modelo ajeno que cambia cada año y que el banco no controla, hace falta un traductor.
El traductor
Un anti-corruption layer es un traductor en la frontera. Cuentas habla con el core en el idioma del core (contratos, intervinientes, apuntes) y lo convierte al suyo (cuentas, titulares, movimientos). El resto del banco solo ve el modelo de Cuentas.
En la simulación, cinco contextos necesitan datos del core. En un caso los leen directamente; en el otro, a través del traductor de Cuentas. Saca la versión nueva del proveedor y después llega la cuenta conjunta.
La versión nueva lo deja claro: sin traductor, un cambio que el banco no ha pedido obliga a tocar y desplegar cinco contextos a la vez. Con traductor, se cambia una pieza.
La cuenta conjunta enseña algo más sutil. El core ya sabía de cuentas con varios titulares y, además, de «autorizados», que el banco no ofrece. Sin traductor, ese vocabulario aparece en Operaciones, Tarjetas y Fraude, y alguien acabará preguntando qué puede hacer un autorizado. El modelo del proveedor decide, sin querer, qué productos parece tener el banco. Con traductor, Cuentas expone lo que el banco ofrece: una cuenta con dos titulares.
Un traductor no es gratis
Hay que mantenerlo y alguien tiene que entender los dos modelos. Por eso no se pone en todas las fronteras: con la red de tarjetas sería un gasto sin beneficio. Se pone donde el modelo de fuera no se controla y cambia, que es justo lo que pasa con un core comprado o con un sistema antiguo.
Es, de nuevo, la lección del core que no usamos: el banco compró el core porque es genérico, y el traductor es lo que le permite seguir pensando en su producto y no en el del proveedor.
Para llevarse
- Un mapa de contextos dibuja quién está aguas arriba, quién aguas abajo y qué tipo de relación tienen.
- El tipo depende de quién controla el modelo y cuánto cambia: conformista con un estándar estable, cliente-proveedor con quien se puede negociar, servicio abierto hacia muchos consumidores.
- Un anti-corruption layer protege el modelo propio de uno que no se controla. Cuando el otro cambia, cambia el traductor.