Entrevistamos a César Camargo CEO de SNGULAR

A través de la siguiente entrevista podrás conocer la visión de César Camargo, CEO de SNGULAR One sobre la industria financiera.

¿Puedes hablarnos de tu experiencia trabajando en el desarrollo de tecnología para empresas financieras en Europa y América?

Es una práctica habitual en el sector bancario subcontratar algunos servicios críticos, como la creación de cuentas o la captación de clientes. Esto tiene consecuencias negativas, ya que se pierde el control sobre la incorporación de nuevos clientes, cómo es su experiencia o qué controles deben realizarse para asegurar si son aptos o no para un producto determinado. Todo esto ha provocado la pérdida de muchos clientes.

Para evitar este problema las empresas decidieron internalizar estos procesos. Ahí es donde nosotros hemos participado, ya que muchas empresas de este sector han confiado en nuestra experiencia y nuestro conocimiento construyendo este tipo de sistemas para diferentes bancos en Estados Unidos, en Europa y México.

Nuestro trabajo comienza con la definición de la arquitectura tecnológica que tenemos que desarrollar. Después, decidimos sobre las tecnologías de programación y desarrollo con las que vamos a trabajar, el proceso a seguir y la asociación con las diferentes áreas del negocio.

La externalización de sistemas críticos y de registros tiene una ventaja: permite llegar de forma mucho más rápida al mercado. Esto es algo que hacen muchos bancos en Estados Unidos, a diferencia de Europa. Sin embargo, tiene importantes inconvenientes, como no poder personalizar la experiencia del cliente de forma adecuada, no tener el control total de la hoja de ruta de desarrollo de la plataforma e incluso no poder conseguir algunos objetivos comerciales porque están limitados por los objetivos comerciales de los sistemas de terceros.

A este respecto, desde SNGULAR en Estados Unidos, estamos trabajando con un banco que quería internalizar esta plataforma y nos pidieron ayuda para acelerar su desarrollo.

Ahora esta plataforma está en funcionamiento, cumplimos con la fecha límite y están obteniendo nuevos clientes y nuevas cuentas, gracias a la gestión completamente interna en el banco. Gracias a todo esto, el control que tienen sobre la experiencia del cliente es mucho mejor que lo que tenían en el pasado.

En cuanto al aspecto tecnológico, estamos en una nueva era de la tecnología bancaria. Toda la infraestructura sobre la que desarrollamos está basada en contenedores. Trabajamos con Java y con Spring, tecnologías comunes en todos los bancos de Europa y EEUU. Hay dos formas de abordar este desarrollo: la forma tradicional usando un flujo de trabajo, con un sistema monolítico con el que tendríamos poca flexibilidad para implementar o entregar nuevas actualizaciones; o podemos usar un enfoque diferente, un modelo de coreografía, que es el que decidimos aplicar con el equipo de arquitectura empresarial del cliente, donde definimos el flujo de trabajo, la orquestación de la llamada, mediante un sistema impulsado por eventos y el uso de reglas comerciales para controlar cuál es la siguiente acción que se debe tomar. Todo implementado como un microservicio, para que podamos aprovechar el uso de la integración continua. Gracias a esto tenemos el control, la capacidad de personalizar la experiencia solo trabajando con reglas comerciales y no tenemos que codificar ninguna coreografía ni ninguna orquestación del servicio.

Desde el punto de vista del rendimiento, esto nos ha dado una gran ventaja porque no tenemos que lidiar con restricciones típicas del producto y podemos escalar tanto como sea necesario.

El mayor desafío que tuvimos que enfrentar en este caso fue que era nuestro primer proyecto. Por lo general, cuando comenzamos a trabajar con una empresa de este tamaño, y estamos hablando de uno de los 10 principales bancos de EE. UU, comenzamos con un proyecto pequeño, pero no algo tan grande ni tan crítico como lo es una plataforma de alta y onboarding.

Cuando comenzamos el proyecto, nos dimos cuenta de que no estaban listos para construir la plataforma tal y como la diseñamos. Tuvimos que construir la arquitectura desde cero utilizando tecnologías de código abierto, y ayudarlos a poner en marcha este nuevo entorno tecnológico dentro de la organización.

Ha sido muy satisfactorio ayudarles a actualizarse con tecnologías de código abierto, actuando como refuerzo. Ahora, todos los proyectos que están desarrollando se ejecutan con la misma arquitectura que creamos nosotros.

¿Cómo estamos construyendo esta plataforma de alta? Empecemos de arriba a abajo

En el front-end, estamos usando Angular 8. Estamos trabajando con el diseño atómico y estamos consumiendo todos los datos del sistema back-end a través de una puerta de enlace API. Bajando un poco, estamos construyendo puntos finales de API de descanso puro. Esta API de descanso se está implementando como contenedor en un motor de orquestación de Openshift. Estamos usando el Sprint Booth 2 y Java ARGS reactivo para construir los componentes reactivos. Estamos utilizando Kafka, no como una fuente de eventos pura, sino más como un agente de eventos.

Estamos implementando una coreografía, que es una forma de implementar una arquitectura impulsada por eventos. Lanzamos el evento a través de Kafka y utilizamos un motor de reglas de negocios de código abierto llamado Drools, muy conocido en el mundo de Java. Con estas reglas, estaríamos ocupando el lugar que normalmente ocuparía una VPN..

¿Por qué preferimos usar reglas comerciales en lugar de VPN?

Las VPN de los bancos son muy poco flexibles y necesitan 3 meses de preparación solo para obtener el primer borrador de un flujo de trabajo. , Simplemente, no es viable..

Además, no sólo estamos implementando una API de descanso. Estamos en una arquitectura impulsada por eventos, por lo que estamos construyendo algo que llamamos micro oyente. Estamos implementando microservicios, pero las interfaces es un listener de Kafka, por lo que reaccionan a los eventos que se lanzan y activan por diferentes sistemas. Entonces, cada microlistener tiene una responsabilidad única que envuelve un sistema bancario específico o un sistema de terceros, por lo que nos permite trabajar en el modelo ATDD de una mejor manera porque podemos aislar la complejidad o la funcionalidad y podemos probarlos independientemente de la parte restante del sistema.

A la hora de trabajar, estamos siguiendo el enfoque típico: gitflow, revisiones de código, pull request…. metodologías que ya son típicas en una empresa de tecnología de vanguardia, pero que no están tan extendidas como podemos creer.

Al final, la solución no solo ha sido apreciada por el equipo técnico, sino también por el product owner y el equipo del cliente.

¿Cuáles son las claves para un proyecto de desarrollo de software exitoso?

Estamos hablando del desarrollo de un tipo de plataforma que habíamos construido previamente. Esto hizo que nos otorgaran una mayor confianza, porque conocíamos cuáles eran los retos. En un primer momento,querían que entregáramos antes pero el margen de tiempo no era razonable y se lo hicimos entender. Podemos hacer muchas cosas, pero hay cosas que no podemos hacer..

Si tengo que resumirlo en un solo punto, creo que la clave del éxito fue la confianza. Confiaban en nuestro entendimiento del proyecto, confiaban en nuestro conocimiento de la tecnología que necesitábamos, y confiaban en nuestra experiencia trabajando o realizando este tipo de trabajos en diferentes bancos en diferentes lugares.

El otro valor importante que hemos demostrado es nuestra capacidad de entregar valor. Este es nuestro reclamo, que siempre cumplimos con nuestro compromiso. Los clientes confían en nosotros porque saben que cuando decimos que vamos a entregar algo, siempre entregamos aunque existan muchos obstáculos. Pero siempre encontramos la manera de de encontrar una solución alternativa. Y lo hacemos definiendo una solución personalizada que, en algunos casos, se convierte en la oficial.

¿Cuál ha sido el impacto de nuestra plataforma de originación interna en este gran banco?

Ahora el cliente cuenta con la plataforma internamente, por lo tanto pueden controlar totalmente la experiencia que se le está brindando al cliente. Esto es muy importante durante el proceso de onboarding porque al final un banco es un e-commerce. Cuando obtienes una nueva cuenta o te conviertes en cliente de un banco en un sitio web, al final estás en un embudo de conversión del típico canal de comercio electrónico. Si esto se hace internamente, se puede controlar cómo debería ser todo el proceso. Además se está construyendo una plataforma que es independiente del producto, lo cual es un tema muy complejo porque normalmente un banco tiene cientos de productos.

Recuerdo un banco en España que tenía 120 tipos de cuentas corrientes, por lo que hay que construir este tipo de sistemas de manera que se puedan agregar más y más productos en poco tiempo. Al final, lo que tendrás son cientos de productos originados o creados a través de esta plataforma.

La plataforma de originación es una plataforma de ingresos, que es tan importante para un banco porque es la parte de ventas del banco, por eso tiene más sentido tenerla internamente, controlarla internamente, monitorear su actividad y contar con KPIs que permitan medir tener una manera de mejorar.

En EE. UU. están muy orientados a la industria financiera. Si has trabajado para 3 bancos, lo más habitual es que el próximo cliente que te llame sea otro banco. Porque para ellos, la tecnología y la industria están muy relacionadas. Aunque en Sngular podemos construir cosas con la misma tecnología para muchas industrias completamente diferentes, el sector de la banca es difícil de convencer.

Un banco siempre te va a preguntar por tu experiencia previa implementando el tipo de soluciones concretas que necesitan e intentan asegurarse de que entiendes sus requisitos comerciales, a los propietarios de sus productos, a su equipo de negocio, etc. No confían en alguien que simplemente les dice que pueden desarrollarlo y ya está. . No tenemos que ser solo el equipo de entrega, sino que tenemos que ser el pegamento que conecta al equipo comercial con el equipo de entrega.

¿Cómo vendemos nuestros servicios a los bancos?

Para vender servicios de desarrollo tecnológico a los bancos es muy importante tener conocimientos de la industria. Tenemos que ser expertos en tecnología para bancos y tenemos que ser un equipo disruptivo porque si estamos trabajando con las herramientas tradicionales (usando VPN, ESB, una arquitectura orientada al producto, etc), normalmente no ganamos. Y no lo hacemos porque hay otras empresas que cuentan con personal certificado por el producto y tienen una larga experiencia en la implementación de una versión específica de ESB o en la implementación de una versión específica de una VPN que nosotros no tenemos y no queremos.

Entonces, la forma en que podemos hacerlo realmente de manera ágil en un banco, es pensando en cómo podemos reducir el tiempo de comercialización, cómo podemos acercarnos a las líneas de negocio, ahora que casi todos los bancos están trabajando de forma ágil. Esto es muy bueno para nosotros, porque Agile se entiende de manera diferente en diferentes bancos, algunos bancos son más maduros en la metodología, pero otros lo son menos. En todo caso para nosotros es una gran oportunidad porque los grandes jugadores tradicionales, no pueden transformarse a eso porque los ciclos de entrega son más largos y estamos en lo contrario, podemos entregar tan rápido como podamos o tan rápido como nos permitan hacerlo.