EDA: eventos, tiempo real y desacoplamiento en SOA

por

Estamos entrando en la era del Internet de las Cosas, donde cada vez más objetos de uso cotidiano van a estar conectados entre sí, intercambiando información y respondiendo a nuestras necesidades y gustos. La integración de sistemas está dando el salto desde el lado empresarial y de los negocios al lado del ciudadano, y lo está haciendo de forma global. En ambos mundos, lograr que los sistemas y dispositivos se integren de forma ágil y eficiente es absolutamente clave. La estrategia SOA incluye un enfoque idóneo para lograrlo: EDA, donde los eventos de negocio, las integraciones en tiempo real y el desacoplamiento de los sistemas, van de la mano.

 

Integrar sistemas de información es algo complejo. Persiste aún el tradicional enfoque orientado a las áreas funcionales a la hora de definir y ejecutar un proyecto TIC, priorizando las funcionalidades internas del sistema, los requerimientos y peticiones del usuario responsable, la usabilidad, el rendimiento, sus informes, etc., infravalorando los requerimientos de interoperabilidad.

Todos esos requerimientos son importantes, por supuesto que sí. Pero ese enfoque vertical, local, está detrás de esa complejidad a la hora de integrar los sistemas de información en una organización.

 

Cuando surge la necesidad de integrar un sistema de información, básicamente caben cuatro escenarios posibles:

1. el sistema de información es antiguo, apenas se modifica, y está desarrollado en una tecnología obsoleta.

2. el sistema de información está en una fase avanzada de desarrollo.

3. el sistema de información es reciente, está operativo en producción, en mantenimiento, desarrollado en una tecnología vigente.

4. el sistema de información es nuevo, se va a desarrollar, y el correspondoente proyecto se está definiendo.

Evidentemente los escenarios más favorables son los dos últimos, pero tengamos en cuenta que es muy probable que estos sistemas deban integrarse con sistemas que están en los dos primeros escenarios.

Lo más probable es que todos esto casos compartan lo dicho anteriormente: están enfocados verticalmente, en el nicho de su área funcional. No están pensados ni diseñados para formar parte de una cadena de valor, de un flujo de procesos de negocio.

Sin embargo los procesos de negocio están ahí, y los eventos de negocio que los desencadenan y enlazan también existen en el mundo real.

El primer día laborable de cada mes se deben realizar ciertas actividades que implican a varias áreas funcionales.

Cada vez que un cliente presenta una reclamación deben sucederse una serie de validaciones en varias áreas funcionales.

Cada fecha de vencimiento de un seguro deben lanzarse una serie de procesos para emitir cartas, renovar contratos y cobrar primas.

Y así infinidad de casos. Todos estos eventos y procesos del mundo real existen aunque los sistemas de información parezcan obviarlos en su definición inicial y posterior construcción.

 

Esta forma de enfocar los sistemas de información se traduce en que cuando sucede un evento de negocio sobre una entidad maestra (por ejemplo clientes, facturas, contratos,…), los sistemas de información responsables de esa entidad ejecutan transacciones que resuelven toda la lógica funcional definida para esa entidad. Dichas transacciones normalmente se conforman con la persistencia en su modelo de datos, actualizando la entidad o entidades afectadas, y manteniendo informado al usuario del resultado local de ese evento.

¿Y nada más?

¿Qué efecto tiene ese evento de negocio en el resto de áreas funcionales?

 

Tradicionalmente este flujo transversal se ha resuelto mediante procesos batch nocturnos, semanales o mensuales. Grandes y complejas cadenas de procesos que se planifican cuidadosamente para tratar masivamente y en diferido toda esa información que en la operativa diaria de cada área funcional ha quedado registrada, pero sólo registrada.

Sin embargo esa información tiene que avanzar a lo largo de la cadena de valor de la organización para que aporte justo eso: valor. En una especie de cadena de montaje de información de negocio.

Los procesos batch como solucion global de integracion son ineficientes

 

Con la llegada y expansión de la informática distribuida y el avance de las comunicaciones, los sistemas de información de cada área funcional han ido incorporando nuevas formas de compartir información, conscientes de la necesidad de integrarse con otros sistemas: invocan procesos remotos, acceden a bases de datos remotas, ejecutan otras aplicaciones, o publican servicios web para ser consultados.

Sin embargo, estos avances ¿qué aportan realmente?.

De acuerdo, los sistemas de información están más integrados. Pero ¿así? ¿Encadenando unos sistemas a otros? ¿Compartiendo la información a demanda? ¿Obligando a los demás sistemas a conocer los detalles internos de diseño de mi sistema, para poder acceder a la información que tengo y que ellos necesitan?.

Además, este enfoque no elimina la necesidad de aquellos procesos batch. Quizá permite reducirlos un poco, pero siguen ahí.

 

Otro posible enfoque es trasladar todo mi mapa de sistemas a una tecnología propietaria que me asegure una cobertura total de mi cadena de valor, abarcando todas mis áreas funcionales, y el flujo de información necesario.

Bien. ¿Cuánto cuesta la licencia?

¿Y qué coste tiene mantener ese mapa de sistemas?

¿Cuánto de lo que me cuesta es más de lo que necesito? ¿Cuánto de lo que necesito se tiene que adaptar a lo que me cuesta?

¿Y qué hago con mis inversiones de los últimos 10-20 años?

¿Cuánto me costará la próxima tecnología que sustituya a esta?.

La tecnologia propietaria como solucion de integracion es negativa a largo plazo

 

Bueno, afortunadamente tenemos la estrategia SOA. Y en esta ocasión su gran aliado es…

EDA: arquitectura conducida por eventos de negocio.

Si los eventos mueven el negocio en el mundo real ¿por qué no pueden mover la información entre los sistemas que tratan de dar soporte a ese negocio? ¿Por qué «a este lado» los eventos de negocio simplemente no se tienen en cuenta, difiriendo ese flujo de información a horas y días después de que ocurrieran esos eventos?

En una estrategia SOA los eventos de negocio juegan un papel fundamental. La identificación de los eventos y su orquestación son claves para maximizar el éxito de una implantación SOA en una organización.

La mayor dificultad que tiene el enfoque de EDA es que requiere un cambio importante de mentalidad y diseño de los sistemas de información, incluso desde su propia definición de requisitos. Dado que hablamos de eventos de negocio, se deben identificar éstos perfectamente en el negocio. Eventos de todo tipo: la llamada de un cliente, la llegada de una transferencia bancaria, el vencimiento de un determinado periodo de tiempo, el ingreso de un paciente, la apertura de un parte de siniestro, la llegada de una fecha determinada, etc, etc.

Conocer bien esos eventos de negocio, cuándo y dónde se producen, y qué flujo de procesos desencadena, se logra con el análisis de los procesos de negocio mediante BPM, el otro gran aliado de la estrategia.

 

El cambio de enfoque necesario implica, además, que los sistemas de información no deben conocer los detalles internos del resto de sistemas, ni internos ni externos. Deben tener prohibido conocer esos detalles. Únicamente deben conocer las especificaciones de los servicios SOA publicados por la organización para comunicar sus eventos de negocio, o para consumir los eventos disponibles.

 

Cuando se interioriza este modelo, el problema de la integración de sistemas se vuelve sorprendentemente sencillo, evidente y natural. Y sistemático. Y rentable.

Tremendamente rentable.

 

Orientar un mapa de sistemas a procesos de negocio desde una orientación a áreas funcionales, es un cambio cultural para la organización. Es complejo de asimilar por los responsables y equipos internos y externos que trabajan en la organización. Pero es necesario. Y además es una evolución natural, como veremos en próximas entradas donde usaré algunas analogías del mundo real para ver todo esto mucho más claro.

Con EDA la estrategia SOA promueve las integraciones en tiempo real como patron general

 

De las muchas ventajas que aporta EDA a la estrategia SOA, destacaría dos:

Por un lado, el flujo de información a través de la cadena de valor de la organización ya no es diferido en el tiempo, sino que se produce en tiempo real, tal como ocurre en el mundo real. En realidad ocurre más rápido que en el mundo real: la historia clínica digital de un paciente viaja más rápido que el propio paciente desde el mostrador de admisión hasta su cama.

Por otro lado, los sistemas de información dejan de ser islas, sino que se comportan como piezas encapsuladas de una cadena de montaje de información de negocio. El ecosistema funciona en tiempo real, con sistemas independientes, coordinados y orquestados por el propio negocio. Es decir: sistemas de información desacoplados. De forma que si la organización necesita revisar una pieza o cambiarla, el resto del mapa de sistemas no se ve afectado. Basta con garantizar que la nueva pieza tiene el mismo comportamiento para el resto de piezas.

 

Resumiendo: en nuestra vida, en el mundo real, estamos constantemente produciendo eventos y reaccionando a eventos externos. Las empresas y organizaciones exactamente igual. Pero sorprendentemente la inmensa mayoría de procesos de negocio parecen necesitar ciclos de horas, días o semanas para completarse. La estrategia SOA conducida por eventos (EDA) reorienta la forma de integrar los sistemas de información que participan en esos ciclos, y los implementa como reflejo fiel de los procesos de negocio, aportando inmediatez al flujo de información y desacoplando los sistemas entre sí, con el consiguiente beneficio en competitividad y ahorro para la organización.

 

¿No os parece que es así como deberíamos encarar la era del Internet de las Cosas?.

 

Te puede interesar

0 comentarios

Trackbacks/Pingbacks

  1. CEP, potenciando los servicios en la estrategia SOA - […] de los protagonistas de la Estrategia de Orientación a Servicios son los Eventos de Negocio. El enfoque EDA por…

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Sigueme en las redes

Share This