En los últimos años, la nube se ha convertido en una estrategia clave para el desarrollo informático de las grandes empresas financieras, y no sólo.

El denominador común es la digitalización y esto requiere una infraestructura y una plataforma tecnológica altamente escalable, innovadora y resistente.

Al fundamentar esta estrategia tecnológica, uno de los principales retos se refiere a la arquitectura de datos de referencia, con el fin de explotar los activos de información de la mejor manera posible.

Para las grandes corporaciones de servicios financieros, el escenario al que se enfrentan es mayoritariamente híbrido: aplicaciones y datos on premise, porque son estratégicos o simplemente no están preparados para ser portados a la nube, coexistiendo con aplicaciones y datos en la nube, por lo que en la definición de esta arquitectura es necesario abordar una serie de cuestiones vinculantes: la latencia, el “teorema de la tapa” y la “gravedad de los datos”.

En cuanto a la latencia, se debe a la inevitable distancia física entre los sistemas locales y los servidores del proveedor de la nube. Cuanto mayor es la distancia, mayor es la latencia, lo que equivale a un mayor retraso en la transmisión de datos, que puede afectar a los tiempos de respuesta y, por tanto, a la experiencia del usuario. Por lo tanto, diseñar una arquitectura de datos para la nube significa también aprovechar la conectividad y la arquitectura de la red de telecomunicaciones.

Por otra parte, garantizar la velocidad y el rendimiento de los sistemas informáticos es fundamental para ayudar a las organizaciones a orientarse hacia los datos y, por tanto, a ser capaces de crear ideas casi en tiempo real, democratizando el uso del análisis de datos y optimizando los procesos empresariales, además de permitir nuevos productos y servicios digitales.

En cuanto al teorema de Cap o de la tapa (también conocido como teorema de Brewer), afirma que para los sistemas informáticos distribuidos no es posible satisfacer simultáneamente la Consistencia de Copia, la Disponibilidad Total y la Tolerancia de Partición, sino como máximo dos de ellas a la vez. En los escenarios híbridos que estamos tratando, conviene tener en cuenta que la presencia de latencia conduce inevitablemente a un efecto de partición de la red.

Aunque algunas bases de datos innovadoras (por ejemplo, newSQL) sortean las limitaciones del teorema de Cap mediante el uso de algoritmos de consenso de los nodos en los que se divide la base de datos, es necesario que quienes se encargan de desarrollar los componentes de escritura (transaccionales) y lectura (analíticos) de dichas bases de datos tengan una formación específica, para ser plenamente conscientes de cómo se organiza la infraestructura subyacente y cuáles son sus posibilidades y limitaciones (por ejemplo, índices, vistas, claves primarias, procedimientos de almacenamiento).

En referencia a la gravedad de los datos, este concepto implica la metáfora de que la masa de datos debe considerarse como un centro de atracción gravitatorio para los procesos informáticos pertinentes, de modo que querer trasladar la informática a la Nube implica en cierta medida trasladar los datos hacia dichos entornos. Este concepto se enfatiza hoy en día con el movimiento de algunos procesos computacionales y datos hacia los puntos finales (edge computing – IoT).

Este aspecto relacionado con el movimiento de los datos hacia los sistemas basados en la nube debe abordarse en primer lugar aclarando el contexto de los sistemas de información en el sector de los servicios financieros: existe, de hecho, una cierta distancia entre las ambiciones de democratización de la analítica, el uso avanzado de los datos en el entorno digital (incluida la inteligencia artificial) -que a menudo ofrecen las modernas soluciones de analítica basadas en la nube- y la situación estratificada y en silos de los sistemas heredados establecidos por los bancos a lo largo de una historia de hasta treinta años, que a menudo están incluso en contradicción con algunos fundamentos de la tecnología de la información.

La necesidad de modernizar los datos

Por tanto, es esencial actuar en dos vías paralelas: la modernización de los datos de los sistemas locales y la introducción de una capa de integración de datos hacia los sistemas en la nube, la llamada “capa de desacoplamiento”.

En cuanto al primer aspecto, para lograr una verdadera modernización de los datos, es necesario simplificar el “sistema de datos” de referencia, mediante: programas de rediseño/actualización de los pipelines de datos (series de fases sucesivas de procesamiento de datos) y de los modelos de datos; la dicción de términos técnicos y empresariales; la recuperación del conocimiento sobre los campos “calculados/derivados”; la eliminación de redundancias; la identificación de fuentes de oro unívocas. En otras palabras, se trata de reforzar los procesos de diseño de pipelines de datos, gobernanza de datos y marcos de calidad de datos. Se trata de un proceso complejo, valioso y que requiere mucho tiempo, que no siempre está disponible con respecto a los desafiantes objetivos de digitalización y estrategia en la nube de las empresas.

Por otro lado, la introducción de la capa de desacoplamiento tiene como objetivo acelerar la adopción de soluciones en la nube, permitiendo definir un nuevo “centro de masa” de datos para su integración en estos entornos. Está claro que esta capa debe estar dotada de una sólida solución de gobierno de datos híbridos y de la capacidad de albergar tipos de datos heterogéneos: estructurados y no estructurados. Su objetivo es hacer que los datos puedan ser utilizados por las aplicaciones modernas en la nube para permitir el procesamiento en tiempo casi real, la multiexperiencia y los servicios conscientes del contexto (por ejemplo, marketing, ventas y apoyo postventa). También es indispensable en un contexto multicloud donde es necesario garantizar la coherencia y una contra-actualización “ordenada” de las bases de datos maestras frente a los eventos procedentes de los canales.

Para poner en práctica esta solución, hay que abordar dos aspectos: la “distribución geográfica” de las diferentes áreas temáticas de los datos y las evaluaciones tecnológicas sobre las bases de datos y las herramientas (integración, monitorización, etc.) que se utilizarán para los verticales distribuidos en la nube.

En cuanto a la distribución geográfica, en el contexto de una estrategia multicloud, es concebible mantener algunas áreas de datos comunes, como los datos de los clientes, en las instalaciones, y trasladar la verticalidad específica utilizada por las aplicaciones distribuidas en los diferentes proveedores de servicios en la nube a las áreas de datos pertinentes en estos últimos.

En cuanto a las evaluaciones tecnológicas, prevalecen dos enfoques: el básico y el avanzado.

La primera implica el uso de bases de datos de terceros (las que se utilizan en las instalaciones, por ejemplo) en modo IAAS/autocontenido. Esta estrategia puede permitir un rápido levantamiento y cambio de las instalaciones a la nube y puede ser preferida por los usuarios finales con una experiencia consolidada y exitosa hacia la oferta de un proveedor de software independiente, pero puede ser penalizante desde el punto de vista del diálogo con el resto del ecosistema de la nube elegida, así como desde el aspecto del bloqueo hacia el proveedor de software independiente.

El segundo, el extremo opuesto, contempla una estrategia en la que cada proveedor de servicios en la nube elegido adopta soluciones de bases de datos nativas que aprovechan los numerosos y cada vez más potentes servicios que los CSP siguen desarrollando y que se centran, por supuesto, en las bases de datos soportadas de forma nativa.

La principal ventaja de este segundo enfoque es la plena integración “out of the box” con el entorno del proveedor de servicios en la nube y sus evoluciones, mientras que el bloqueo al propio proveedor de servicios en la nube y la mayor dificultad para integrarse con los datos que residen en otras nubes pueden ser factores críticos.

El doble enfoque se encuentra también en términos de integración: la elección entre el uso de herramientas ETL/ELT clásicas, frente a la posibilidad de utilizar herramientas nativas de los distintos proveedores de servicios en la nube construidas para garantizar un alto rendimiento y una baja latencia. Hay que recordar que también hay que pagar tasas de transferencia de datos por el uso de soluciones en la nube, por lo que es preferible optimizar las transferencias (por ejemplo, con la gestión de deltas).

Los diferentes proveedores de servicios en la nube proponen diferentes metodologías y soluciones (también de terceros) para facilitar la migración (por ejemplo, herramientas de conversión ETL/ELT).

En conclusión, para aprovechar al máximo las oportunidades que ofrecen las soluciones en la nube, se requieren varias acciones en términos de arquitectura de datos. A corto plazo, el diseño de una capa de interfaz de datos adecuada puede ser la mejor solución para maximizar los beneficios de la adopción y reducir al máximo los costes de uso actuales y potenciales. Sin embargo, es necesario abordar de inmediato las cuestiones relativas a la gobernanza de los datos, en un contexto híbrido y sin fisuras, y estratégicamente, con un horizonte sin duda más largo, proceder a una vía de “modernización de los datos” de los propios sistemas.