Todavía hay mucha gente a la que eso de arquitectura de integración de datos les suena algo raro. Casi como una contradicción. No están de acuerdo en que la integración de datos debe tener su propia arquitectura.

Muchos especialistas en integración de datos de hoy en día todavía construyen interfaces independientes. Una mala práctica que además es básicamente anti-arquitectónica. Otro error común es pensar que por utilizar el producto que proporciona un proveedor para la integración de datos ya tenemos asegurada automáticamente la arquitectura de integración.

¿Y cual es el problema de todo esto? Pues que si no asumimos la existencia de una arquitectura de integración de datos, no podremos abordar cómo afecta esa arquitectura a la escalabilidad de la integración, costes, personal, capacidad de soporte en tiempo real, gestión de datos, SOA, etc.

Veamos un poco más desglosado cuales son algunos objetivos de una arquitectura de integración de datos. Cómo ésta es capaz de imponer un orden dentro de la complejidad.

El modelo de arquitectura de integración servirá como norma de desarrollo

La mayoría de los componentes de una solución de integración de datos pertenecen a una de estas tres categorías: servidores, interfaces y elementos para transformación de datos. Teniendo esto en cuenta podríamos decir que una arquitectura de integración de datos no es más que el modelaje de servidores que se relacionan a través de interfaces.

El punto ideal de ese modelo de arquitectura es que proporcionen una visión integral de la infraestructura y de todo el desarrollo que se implemente por encima de ella. De esta forma todo el mundo tendrá claro lo que hay, y todos tendrán una visión común para poder colaborar en los desarrollos.

Además, si se siguen siempre estas normas de desarrollo y la arquitectura de integración se ha adecuado bien a ellas, un trabajo posterior que incluso tenga que ser heredado por otras personas, será mucho más rápido.

Simplicidad para reutilización y consistencia de datos

Como estas normas de desarrollo y los modelos arquitectónicos se pueden aplicar a múltiples proyectos de integración de datos, el resultado va a ser la simplicidad ya que se fomenta la reutilización de código y a la vez aumenta la coherencia en el tratamiento de los datos.

Proporciona armonía entre infraestructura común y soluciones individuales

El modelo de arquitectura de integración preferido para la mayoría de soluciones de integración es el conocido como hub and spoke. En esta arquitectura, la comunicación y transferencia de datos entre servidores pasa a través de un hub central, donde un servidor de integración gestiona las comunicaciones y realiza las transformaciones de datos. Si la solución de integración de datos se construye con la herramienta de un proveedor, ese servidor en el hub suele ser el servidor de integración de datos de ese proveedor. Si utilizas soluciones propias, el servidor del hub puede ser un sistema de gestión de base de datos propio o una colección de rutinas de programación hechas por tu propio equipo. Puedes elegir y todo sigue teniendo sentido.

Tal vez te interese leer: 
Los buenos propósitos de la arquitectura de integración

Algunas recomendaciones finales

• Reconoce que la arquitectura de integración de datos existe. A pesar de que se solapa con la arquitectura de almacenamiento de datos e interactúa con todo el resto de infraestructura de inteligencia empresarial, la arquitectura de integración de datos es una estructura autónoma que requiere una solución autónoma.

• Incorpora personal especialista en integración de datos. En lugar de traer especialistas en integración de datos desde tu equipo de data warehouse, considera crear un departamento especializado en integración de datos.

• Adopta la arquitectura hub and spoke para tus implementaciones de integración de datos. El hub reduce el número de interfaces necesarias y proporciona un modelo que todo el mundo puede comprender y con el que pueden ser productivos. Además es una arquitectura ideal para asegurar reutilización, productividad, colaboración y las estándares de desarrollo consistentes.

• No cargues todo el trabajo en ese hub central. Si no distribuyes un poco la carga de trabajo pronto colapsarás el hub. Cuando necesitas manejar grandes volúmenes de datos  es mejor distribuir la carga de trabajo más allá del hub a través de varios módulos de pre-procesamiento y post-procesamiento.