Un fenómeno común en todas las organizaciones, es la existencia de datos que atraviesan transversalmente todos o la mayoría de los sistemas de información de la compañía. Estos datos son en general información relacionada con clientes, proveedores, SKUs de productos u otras entidades que, por la naturaleza del negocio, es necesario mantener y/o consultar desde más de un sistema.

Contexto General

La evolución natural de la arquitectura de información de las compañías en general no considera el establecimiento de normas y políticas en torno al flujo, propiedad y coordinación de la información, dado que el común crecimiento de la arquitectura es un proceso acumulativo en el tiempo y reactivo a las necesidades que se van suscitando durante la existencia de ésta. Se incorporan sistemas con propósitos y tecnologías diversas, coexistiendo con los actuales aunque no necesariamente interactuando a nivel de datos con éstos. Esta facilidad representa un esfuerzo adicional que muchas veces se pasa por alto, redundando en un esquema de información en donde los datos similares deben ser sincronizados “a mano”, bajo la conocida regla del “alt-tab” donde el usuario debe replicar una misma operación de negocio en todos los sistemas que se vean afectados por ésta.
Cuando la coordinación de estos datos es una necesidad crítica para la normal operación del negocio, este aspecto de la arquitectura debe ser automatizado usando algunas de las ofertas tecnológicas que ofrecen los proveedores de TI’s. Estas soluciones se refieren desde la capacidad de ciertas bases de datos para sincronizar la información de distintos sistemas, hasta las más sofisticadas concepciones de EAI, pasando por productos ETL y capacidades de integración peer to peer. Es evidentemente que no existe una solución única a estas necesidades, lo que obliga a la empresa a determinar la solución idónea y específica a sus problemas particulares, enfrentándose a las siguientes interrogantes:

1. ¿Existe una definición formal y aceptada sobre la organización y propiedad de los datos?
2. ¿Cuan volátiles son los datos y cuan crítica es la necesidad de mantenerlos “frescos”?
3. ¿Existe un empuje fuerte y cohesionado para dar solución a la problemática?

La pregunta 1 es evidente, no se puede dar lugar a una iniciativa de integración “data to data” (D2D) sin una formal y aceptada definición sobre quién, cómo y cuándo se administra la información transversal. En caso de no existir dichas definiciones, ésta debe ser la primera actividad en una iniciativa de integración D2D. Usualmente se lleva a cabo mediante un comité (a veces llamado “comité de datos”), integrado por representantes de las distintas áreas de negocio, quienes definen cuáles componentes y de qué modo se debe estructurar la arquitectura de datos de la empresa.
La segunda pregunta tiene directa relación con la necesidad de mantener la armonía de los datos, y de su respuesta emanan los aspectos tecnológicos de la solución. Las implementaciones tecnológicas van desde sincronizaciones de “largo aliento” (mediante software ETL’s) hasta transacciones en línea o integraciones A2A (application to application) y P2P (process to process), las que necesariamente requieren de la intervención de todos los sistemas que participan en las operaciones de negocio.

La pregunta 3 es definitivamente la más importante. Tal como se ha expuesto anteriormente, aunque sea poco invasivo el método de integración, siempre requerirá de la aplicación de cambios en los sistemas circundantes y en la mayoría de los casos, cambios en la forma de llevar a cabo los procesos de negocio. Por ejemplo, si la solución define como sistema propietario de la entidad “cliente” a la solución de CRM, todo cambio que se requiera para clientes deberá pasar por este sistema y ser propagado al resto de la arquitectura; lo que implica cambios tecnológicos respecto al cómo, dónde y cuándo propagar estas transacciones y cambios en la operación, así como respecto de quién, dónde y cómo se ejecutarán estas transacciones por parte de los usuarios. Como el ejemplo lo demuestra, no sólo basta con que dichos desarrollos se coordinen para los sistemas circundantes, sino que también se necesita del apoyo, convencimiento y empuje de los gerentes de línea para impulsar el cambio en los procesos de negocio.

Este artículo profundizará en las aproximaciones de integración “data to data” o más concretamente, cuando la decisión de sincronizar la información transversal implique extraer, transformar y mover datos desde una aplicación a otra usando herramientas tipo ETL (Extract, Transform & Load), que representan una solución idónea para arquitecturas en las que se combinan diversos sabores en cuanto a tecnologías de almacenamiento de datos.

Estrategias de Integración Data to Data.

Las aproximaciones a la integración Data to Data puede tomar varias formas dependiendo de los objetivos temporales y finales respecto a la problemática. Las más comunes se detallan a continuación:

Replicación Básica

La primera y la que se podría considerar la forma más básica de integración, es la basada en una herramienta ETL (Extraction Transformation & Loading) como coordinadora para la replicación de los datos transversales a la arquitectura. La principal característica es que no requiere de una definición formal de propiedad de datos, ya que no considera sincronizaciones “inteligentes” entre sistemas que comparten similares datos, sino que es un simple transportador de información en donde necesariamente debe existir una coordinación en el modo en que se mueven los datos con tal de evitar sobreescrituras.

[photopress:ETL1_1.JPG,full,centered]
Figura 1: Replicación Básica.

Ventajas:

• Idóneo para mover información que no necesariamente es mantenida en distintas aplicaciones.
• No requiere de implementaciones técnicas complejas.

Desventajas:

• No existe un único punto en donde obtener información actualizada, la información “fresca” se distribuye en toda la arquitectura.
• No reconoce propiedad de los datos.

Consolidación de Información

La segunda forma de integración y que se podría considerar como un paso lógico desde la estrategia previamente señalada, es la que incorpora un repositorio central definido de forma que es independiente de las estructuras de los sistemas operacionales. Técnicamente está implementado como “meta-representaciones de datos”, lo que comúnmente se conoce como “metadata”. El propósito principal de esta metadata es establecer un punto único y ergonómico de acceso para la información transversal, sin entrar en intricadas rutinas de interpretación de las estructuras de datos de los sistemas operacionales.
[photopress:ETL2.JPG,full,centered]

Figura 2: Consolidación de Información.

Ventajas:

• Existe un punto único de acceso a la información transversal de la compañía.
• El extraer la información desde la metadata evita el acceso a las complicadas estructuras de datos de los sistemas operacionales.

Desventajas:

• A pesar de existir un repositorio central para la información transversal, no se garantiza la precisión de los datos almacenados en ésta.
• Los esfuerzos técnicos de crear el repositorio y generar canales para la incorporación de información en éste, no se equiparan con el pobre beneficio de obtener información “no precisa”.

Armonización de Información

En la estrategia anterior los esfuerzos van dirigidos a hacer que la información fluya en forma coherente por la arquitectura. Esto se logra mediante la determinación de “sistemas propietarios”, es decir, autorizar la administración de las entidades transversales a los más por un sistema y así asegurar la consistencia de los datos transmitidos hacia la metadata y los restantes sistemas operacionales.

[photopress:ETL3.JPG,full,centered]

Figura 3: Armonización de Información.

Ventajas:

• La información transversal es consistente (dependiendo de la frecuencia de sincronización) a través de toda la arquitectura.
• El repositorio de metadata cobra relevancia para la consulta expedita de información, evitando costosas integraciones peer to peer.

Desventajas:

• Requiere de una reestructuración a nivel operacional que supone una amplia coordinación entre las unidades de negocio.
• Los usuarios de los sistemas no propietarios deben acudir al sistema propietario para administrar dichas entidades, adquiriendo el proceso potenciales interacciones burocráticas.

Administración Centralizada

El paso más importante y complicado hacia una administración coherente y confiable de la información transversal, es el definir el repositorio de metadata como el único punto de administración de las entidades comunes a los sistemas operacionales. Para ello se requiere que la metadata posea una interfaz ad-hoc para la consulta y administración de la información por parte de los usuarios y que el proceso de negocio coordine que este sea el único punto de administración.

[photopress:ETL4.JPG,full,centered]

Figura 4: Administración Centralizada.

Ventajas:

• Existe un único punto, confiable y abstraído de las complejidades funcionales de los sistemas operacionales para la administración de la información transversal a la arquitectura.
• Existe un solo sistema propietario (el repositorio de metadata) para todas las entidades, por lo que la información “fresca” es consultada en un solo sistema especialmente dispuesto para esto.

Desventajas:

• Se deben llevar a cabo cambios en los procesos tanto desde el punto de vista técnico como operativo con tal de prevenir que los sistemas operacionales realicen cambios inocuos en las entidades transversales.
• Se requiere de un considerable esfuerzo técnico para habilitar una interfaz de administración ergonómica para las entidades transversales.