Transact Architecture Overview

Este documento describe la arquitectura de Transact, incluyendo sus principios, evolución y componentes clave.

Principios Arquitectónicos:

  • Concepto: Los sistemas empresariales deben tener un propietario único. Se debe separar la interacción de la integración, y el enfoque debe ser el diseño centrado en el problema antes que en los requisitos. La calidad es primordial sobre la función, y la reutilización es preferible antes de comprar o construir. Los sistemas distribuidos deben ser asíncronos y autónomos.
  • Integración de datos: Se basa en tres reglas de oro: derivar de la demanda, alimentar con eventos y modelar la oferta y la demanda por separado. Se debe tener un único maestro de datos por dominio, gestionar los metadatos (linaje, descripción, impacto) y separar la elaboración de informes del mantenimiento de registros. El enfoque de migración de datos incluye modelar, probar, actualizar y migrar datos y reglas.

Evolución de la Arquitectura Transact:

  • Arquitectura Cliente-Servidor (GLOBUS): Las primeras implementaciones de GLOBUS (ahora Transact) utilizaban una arquitectura cliente-servidor con una base de datos uniVerse. Los clientes accedían a través de software de emulación de terminal. Más tarde, se introdujo una interfaz gráfica de usuario (GLOBUS Desktop) en Visual Basic.
  • Arquitectura de Múltiples Niveles (a partir de R04): Transact cambió drásticamente, permitiendo el uso de navegadores web como interfaz de usuario. Se introdujeron nuevas capas: servidor web, servidor de aplicaciones Transact (con TAFC) y capa de servidor de base de datos.
  • Java (TAFJ): Se introdujo TAFJ, un entorno de ejecución completamente basado en Java, lo que llevó a la Arquitectura de Marco Empresarial.
  • Preparado para la Nube, Nativo de la Nube y Agnosticismo: Transact se ha vuelto compatible con la nube, pudiendo implementarse en máquinas virtuales y siendo nativo y agnóstico de la nube.
  • Temenos Banking Cloud: La siguiente generación en SaaS, que combina servicios bancarios completos (minorista, gestión de patrimonio, corporativo, pymes) para escalar de forma instantánea y segura.

Componentes Clave de Temenos Banking Cloud:

  • Temenos Banking Capabilities (TBC): Funcionalidades empresariales autocontenidas (ej., préstamos, depósitos) que pueden existir solas o combinadas, con APIs y microservicios, agrupadas por dominio y actualizables independientemente.
  • Temenos Banking Services (TBS): Soluciones específicas compuestas por TBC y microservicios, diseñadas para un consumo rápido y oportunidades específicas (ej., "Compre ahora, pague después").
  • Temenos Enterprise Services (TES): Principales plataformas bancarias que ofrecen una solución estratégica para la innovación y las necesidades operativas (ej., Servicio Empresarial Minorista).

Opciones de Implementación y Capacidades:

  • Quién ejecuta el software: Temenos ofrece la opción de que Temenos ejecute el software (SaaS) o que el banco lo ejecute por sí mismo (en la nube o en las instalaciones). Se utiliza una única base de código para todos los modelos.
  • Arquitectura Componible: Permite a los clientes elegir capacidades granulares para tomarlas como soluciones completas o piezas individuales para ejecutarlas en su propio ecosistema. Los servicios de fabricación (Core Banking) y los servicios de distribución (Infinity) se integran a través de APIs abiertas.
  • Enfoque en Tecnología:
    • Plataforma Cloud-native y Cloud-agnostic: Diseñada para la banca digital, permite actualizaciones más rápidas, aprovisionamiento ágil y menores costos de infraestructura.
    • Contenerización y Microservicios: Utiliza la contenerización para la escalabilidad eficiente y desglosa el software en microservicios escalables de forma independiente.
    • APIs REST: Permiten patrones de integración estandarizados y son la base para construir ecosistemas de aplicaciones.
    • Marco de Extensibilidad: Ofrece soluciones impulsadas por el cliente y extensiones para integrar Transact con sistemas internos/externos.
    • Inteligencia Artificial Explicable (XAI): Permite a los bancos ofrecer experiencias personalizadas y automatizar procesos, proporcionando transparencia en la toma de decisiones de la IA.
    • Transmisión de Eventos y Análisis Incrustados: Facilita la integración de datos casi en tiempo real y la definición sin código de eventos.
    • Integración y Despliegue Continuos: Industrializa los servicios de desarrollo y pruebas, permitiendo a los bancos acelerar sus capacidades DevOps con herramientas como Temenos Workbench.

Software de Implementación de Temenos:

  • Despliegue: En la nube (gestionado por Temenos o por el cliente) o en las instalaciones.
  • Base de Datos: Agnosticismo de base de datos, compatible con SQL (Oracle, SQL Server, PostgreSQL) y NoSQL (MongoDB, Azure Cosmos DB).
  • Integración: Compatible con Open API, SOAP, Enterprise Service Bus (IIB, Biztalk, Mule, OSB), Camel routing y plataformas de transmisión de eventos (Kafka, Kinesis).
  • DevOps y Extensibilidad: Temenos Workbench acelera las capacidades DevOps y permite configurar módulos de Transact.
  • Seguridad: El Marco de Seguridad de Temenos proporciona identificación, autenticación y control de acceso seguros basados en estándares abiertos (OpenId, SAML, XACML).
  • Ecosistema: Basecamp para explorar y desarrollar productos Temenos, y Temenos Exchange para la colaboración con fintech.

Resumen de la Arquitectura de Transact:

  • Desacoplada: Componentes separados para una arquitectura débilmente acoplada y basada en eventos.
  • Incrustada: Posibilidad de implementar los mismos componentes y la misma base de código.
  • Híbrida: Una combinación de componentes incrustados y desacoplados.
  • Despliegues: Soporte para despliegues en la nube (pública/privada) con contenedores y Kubernetes, así como despliegues tradicionales en Java App Server.
  • Paquete: Funcionalidad lista para usar y capacidad de diferenciación, con actualizaciones continuas y seguras, modelos regionales y un marco de extensibilidad para extensiones seguras.

Marco Empresarial de Temenos:

  • Marco de Diseño (DSF): Proporciona un entorno de diseño basado en modelos con metadatos para crear configuraciones y personalizaciones. La implementación se realiza a través de Design Studio (antiguo) o Temenos Workbench (nuevo, >=R20), que simplifica la configuración y el empaquetado.
  • Ciclo de Vida de Desarrollo de Sistemas (SDLC): Proceso de planificación, creación, prueba y despliegue. Temenos Workbench facilita la personalización, colaboración (con control de código fuente) y despliegue automatizado.
  • Marco de Datos: Su objetivo es evitar el crecimiento de la base de datos Transact, mejorando el rendimiento y reduciendo el tamaño de la base de datos OLTP en vivo mediante la gestión del ciclo de vida de los datos (DLM). Transact Data Hub (TDH) es una solución de plataforma de datos empaquetada para transmitir, transformar, almacenar y distribuir datos de Transact.
  • Marco de Plataforma: Empuja funcionalidades como el manejo de hilos, la gestión de memoria, el almacenamiento en caché y la agrupación de bases de datos fuera de Transact hacia el servidor JEE/base de datos. Permite que el mismo código fuente se ejecute como una aplicación nativa en Java y C (TAFJ y TAFC). TAFJ es la capa abstracta entre Transact, el Sistema Operativo y la Base de Datos, soportando diferentes bases de datos (Oracle, SQL Server, PostgreSQL).
  • Componentes Comunes: Seguridad, verificación de estado, caché distribuida y monitoreo (registros, trazas, métricas). Utilizan UUID para el seguimiento y herramientas como Grafana y Splunk.
  • Marco de Seguridad: Proporciona identificación, autorización y control de acceso seguros y consistentes basados en estándares abiertos (SAML, Open ID Connect, JWT, XACML). Cumple con GDPR y tiene certificaciones para soluciones en la nube. El Policy Editor es la herramienta de diseño.

Principios de Integración:

  • Integración vs. Interacción: La integración implica la comunicación entre dos gestores de recursos o servidores, mientras que la interacción es entre un agente de usuario y un gestor de recursos.
  • Patrones de Integración Soportados: Open APIs (REST, estándares OAS), integración basada en eventos (XML/JSON en tiempo casi real), transmisión de eventos de datos, archivos (SFTP/FTPS) e interfaces de mensajería (JMS, Active MQ). El Marco de Adaptadores permite la integración entre sistemas, soportando agrupamiento, desagrupamiento, API a Evento y Evento a API.

Marco de API:

  • Crea una nueva capa de interacción para el enrutamiento de solicitudes, el mash-up del lado del servidor y las capacidades de llamada sincrónica. Permite a los bancos