Pues hoy, ¡ al fin ! he asistido a la Happy Hour en Red Hat. Y digo por fin ya que ayer me presenté a la charla y me quede planchado cuando me dijeron que era hoy. Ayer estaba con el underground-lag y pensaba que era 22.

Se trataba de una presentación del producto Metamatrix Enterprise Dataservice Platform de cara a gente con perfil técnico para partners y clientes.

A pesar de ser tener un perfil puramente de sistemas la charla ha sido amena y me ha dejado bastante claro lo que hace el producto. Aunque alguien de desarrollo y conocedor del mundillo de SOA y servicios distribuidos habrá sacado en claro más que yo.

¿Para que vale esto?

Supongamos un organismo que posee varios sistemas de los que es necesario sacar y cotejar información en tiempo real:

• Los juzgados tiene BBDD locales e independientes que estan distribuidas geográficamente. Muchas veces las tecnologías difieren.
• Un negocio como tiendas, centros comerciales que tienen sedes u oficinas distribuidas por varios sitios.

Resumiendo si tenemos diferentes fuentes de información distribuidas utilizando variopintas tecnologías para el acceso a la información:

• Colas MQ.
• Diferentes BBDD.
• FTP.
• Correo electrónico.
• P2P.
• Web Services.
• ERP.
• CRM.
• …

el extraer información en tiempo real y/o insertarla y que cualquiera de la organización tenga acceso a ella es bastante complicado y las soluciones que había hasta hace no mucho:

• Aplicaciones a medida muy costosas de hacer y mantener y que sólo valen para un entorno. Y eso mientras no se modifique.
• Datawarehose. Que implicaría el recoger cada cierto tiempo la información de las diferentes fuentes y replicarla en una única fuente de datos. No es viable cuando el modelo de negocio de la empresa requiere el acceso a la información actualizada y en tiempo real.

El producto del que estoy hablando lo que hace, de forma muy simplificada, es crear una BBDD virtual que encapsula a todas las fuentes de datos y accedemos a esa BBDD. El producto se encargar de recuperar, en tiempo real, la información de las diferentes BBDD y/o modificarla de modo que los datos sean consistentes. Sin necesidad de replicar las diferentes BBDD con los problemas que eso conllevaría, no sólo de tiempo, si no de marchas atras con la consiguiente perdida de datos debido a una corrupción de datos en una de las fuentes. Todas las fuentes permaneceran sincronizadas y consistentes.

Una cosa muy importante es que las aplicaciones que teníamos hasta ahora, seguirán funcionando para las sedes locales y no será necesario prescindir de ellas si no queremos/podemos. Teniéndo una nueva aplicación para acceder a todos los datos de la empresa en tiempo real y con toda la información actualizada.

Hemos visto un ejemplo práctico. Y se lo han currado he de decir.

Han simulado un proceso de negocio de una entidad bancaría. Basicamente se trata de ver como funciona el proceso de que un banco determine que somos un cliente potencial para que nos envie SPAM, perdón publicidad. Las fuentes de datos en este caso eran tres BBDD (un MySQL y dos PostgreSQL) de la organización y una BBDD interbancaria ajena a la organización (el registro de morosos).

El funcionamiento, de forma muy resumida, es que cuando el sistema detecta un posible cliente consulta sus fuentes de datos para ver si el cliente tiene capacidad de ahorro (se le puede exprimir). Si tiene capacidad de ahorro (no está suficientemente endeudado) se le considera un posible “target” (esta es la forma cool de decirlo). Pero que no esté endeudado según nuestro sistema no significa que en realidad sea así. Puede ser cliente de otras entidades bancarias y estar endeudado con ellas, hipótecas, créditos y demás.

Lo primero que el sistema tendrá que hacer es ver el nivel de endeudamiento de un cliente. Podemos considerar como potenciales “targets” a clientes que tengan ingresos periódicos, como la nómina, y tomar la decisión según sea la nómina o utilizar cualquier otra métrica. Una vez determinado cómo posible “target” será necesario acceder a diferentes fuentes de datos dentro de nuestra organización. Teniendo en cuenta, por ejemplo, que los productos de bolsa pueden estar almacenados en un sistema UNIX con una determinada BBDD, los datos referentes a otros productos bancarios pueden estar en un mainframe, … Es decir diferentes fuentes de datos, en este caso un MySQL y dos PostgreSQL. Cotejamos los datos para ver el nivel de endeudameinto y determinar si es un posible “target” según la información que tiene nuestra organización.

Si esta comprobación determina que el cliente es un “target”, lo siguiente será comprobar el registro de morosos para saber si el posible “target” no está endeudado con otras entidades bancarias. De no estarlo se activará un proceso que avisará a un teleoperador, por ejemplo, que será el que llamará al primo, perdón al “target” para informarle sobre algún producto y ver si de verdad está interesado. En caso de que el “target” esté interesado el teleoperador lo registrará en su aplicación y esto hará saltar un proceso que le indicará a un asesor comercial de la oportunidad y este especialista se pondrá en contacto con el “target”.

Para ver el funcionamiento de esto, vimos el flujo del modelo de negocio definido en Eclipse y para simular la activación del proceso y ver que es independiente de la aplicación que nos están presentando se simuló la modificación de las fuentes de datos por una aplicación externa. Es decir una de las aplicaciones anteriores a implantar este sistema. Una aplicación que sólo maneja una fuente de datos y no interacciona con las otras. Se simuló lanzando un “update” en una de las tablas de una de las BBDD y vimos la activación de los sucesivos procesos, como en la consola del operador en un CRM se le decía que había un posible “target” y como el teleoperador informaba a través de su aplicación del interes del “target” por el producto para que a continuación se informará al asesor comercial a través la correspondiente aplicación. Es una obviedad que las BBDD y las aplicaciones que utilizan tanto teleoperador como el asesor comercial son diferentes, utilizan diferentes bases de datos y no podían interactuar entre ellas.

Existen otros productos como el de Oracle, que lo da gratis, que no se si libre y otras alternativas. ¿Cúal es mejor? Pues no me voy a pronunciar ya que en este campo soy un anafabestia. Espero que a los que lo lean les resulte tan interesante como para mí lo ha sido la charla que hemos tenido hoy.

Mas información aquí y aquí.