En este artículo vemos una descripción de lo que puede ser una arquitectura de referencia para cualquier banco. Aunque se menciona brevemente creo que se contemplan todos los elementos necesarios para exponer los servicios de negocio que necesitan la entidad de manera segura y controlada.

Está arquitectura consta de los siguientes elementos:

  1. Core banking:
    Los servicios bancarios core implementados en las últimas décadas
  2. 3rd Party Services / Servicios de terceros: Servicios consumidos de terceras empresas como Seguros y también servicios expuestos a proveedores y clientes con enfoque B2B
  3. Integration-Transformations / Integración-Transformación: adaptaciones necesarias de los servicios para poder ser consumidos y expuestos como cambios de formato (JSON/XML), estilo (REST/SOAP), etc.
  4. Backend-for-frontends (BFFs): servicios específicos para ser consumidos por aplicaciones de frontal. No son servicios de negocio reutilizables sino que se hacen para una aplicación en concreto. Se corresponden con la capa de Delivery de Forrester y también se les puede denominar mBaaS (Mobile Backend as a Service)
  5. API manager: es la pieza central del gobierno de las APIs, donde se aplican las políticas a las APIs, los API plan con la definición del uso, umbrales de invocaciones, monetización, etc.
  6. Dashboards / analytics: Cuadros de mando que proporciona información de negocio acerca de la salud de la plataforma.
  7. Gateways: Es otra pata de la gestión de las APIs. Aquí se aplican las políticas de seguridad y control de tráfico y evitación de ataques. Se encarga de garantizar que sólo los clientes autorizados puede invocar a los servicios. También mantiene un log de auditoría sobre quien ha llamado a qué servicios.
  8. Developer portals: la tercera pata de la gestión de APIs. Contiene la documentación y herramientas necesarias para facilitar la vida a los desarrolladores de tal manera que puedan consumir las APIs sin dolor, en el menor tiempo posible y con el menor esfuerzo. Suele tener autoservicio de APIs, sandbox para probar, ejemplos, SDKs para la construcción de clientes, etc.
  9. Identity Provider (IDP) and Single Sign-on (SSO) solutions: Proveedor de identidades y gestión de usuarios. Facilita la integración de la identidad y autenticación en las aplicaciones cliente mediante mecanismos de federación de identidades, de tal manera que un sistema externo se pueda validar con la identidad gestionada por el banco.
  10. Container runtime / PaaS / FaaS: Infraestructura basada en contenedores y Serverless, imprescindible para la implementación de aplicaciones modernas basadas en Microservicios. Proporciona flexibilidad de uso de diferentes lenguajes y middleware, continuous delivery de manera nativa, escalado bajo demanda, aprovechamiento de la infraestructura física, resiliencia y largo etcétera.
  11. Canales propios: Son los canales del propio banco implementados con diferentes tecnologías: webs, apps móviles, PWA, chatbots, etc. etc.  Es el punto de relación propio con el cliente.
  12. Canales de terceros: Canales de terceras empresas que utilizan los servicios que proporciona el banco mediante APIs

¿Y en seguros…?

La T.I. de la banca y de los seguros van normalmente de la mano porque tienen muchas similitudes, al fin y al cabo forman parte de lo que se denomina Financial Services. Ambos negocios están regulados (la banca lo está un poco más) y ambos también necesitan salvaguardar su solvencia y reputación empresarial por lo que son poco dados a las “aventuras” en su T.I. apoyándose para esto con frecuencia en startups externas.

En lo que a su informática se refiere, tradicionalmente se ponía el foco en una diferencia fundamental, en la banca los servicios de negocio son más atómicos pero se usan con mucha frecuencia (el caso paradigmático es la “consulta de saldo”). Por el contrario, en seguros teníamos servicios más gordos pero que se usan menos como el alta de una póliza o la apertura de un siniestro. En definitiva, se solía decir que el cliente de seguros interactúa con su aseguradora unas pocas veces al año mientras que el de banca lo hace casi a diario.

Y digo tradicionalmente, porque creo que esto está cambiando. No hay más que ver los seguros del tipo Pay as you drive, donde se está enviando continuamente información a la aseguradora para construir “un traje a medida” con la póliza.

Teniendo en cuenta las muchas similitudes y alguna que otra diferencia, creo que la arquitectura conceptual vista anteriormente aplica perfectamente en una aseguradora.

Es más, la parte pintada en rojo, con un gran peso en lo que a la integración se refiere, es un candidato ideal para implementarla en una nube pública. Personalmente apostaría por ello con servicios Serverless (FaaS), que creo que sin duda se convertirán en el único estándar a medio plazo.