¿Qué es la integración de datos?

Hola a todos,
Considero que el primer artículo que he de escribir en este blog ha de estar dedicado a clarificar que entendemos por integración de datos o como mínimo que entiendo yo por integración de datos.
Para entender este concepto es necesario hacer un poco de historia. En los años 90 los departamentos de IT consideran que cualquier problemática que la empresa les plantea obtiene su solución a través del diseño, creación o adquisición de una nueva aplicación, son muchos los ejemplos donde vemos como van proliferando soluciones a medida o empaquetadas que resuelven problemas o necesidades específicas de unas áreas concretas del negocio, así surgen aplicaciones para la gestión de la producción, de la logística, del ciclo de vida del producto, aplicaciones de marketing, financieras, comerciales, etc. Ha nacido la era del Application-Oriented.
Cada una de estas aplicaciones llevan asociados sus propios datos que son almacenados en repositorios propios o bases de datos genéricas, creciendo así el número de repositorios donde existen datos almacenados en nuestra empresa, es lo que conocemos como silos de datos.
Pronto las necesidades del negocio nos obligan a compartir información entre estas aplicaciones y es necesario que nuestra aplicación financiera disponga de información de compras o logística, o que la aplicación comercial pueda ver cuando se emite una factura desde nuestro ERP, etc. Esta necesidad acabamos resolviéndola mediante la creación de procesos de intercambio de datos entre las aplicaciones, lo que en el sector conocemos como interfaces de integración o procesos de ETL.

Este modelo es utilizado por la gran mayoría de empresas y es muy rápido y efectivo si el número de aplicaciones de nuestra empresa es muy pequeño o bien no requieren intercambiar grandes cantidades de información.
Pero ¿Qué sucede cuando el número de aplicaciones o el número de datos crece?, la situación en esas circunstancias empieza a complicarse, lo que antes eran unos cuantos interfaces empiezan a crecer de forma exponencial y en muchas ocasiones nos encontramos con lenguajes de integración diferentes y necesidades de programación muy específicas. Os pongo algunos ejemplos muy típicos:
Empresas que necesitan extraer datos de su Mainframe o transaccional y pasarlo sobre sistemas medios o operacionales, en estos casos suele ser necesario disponer de programadores Cobol que permitan extraer la información del Mainframe y de programadores PL/SQL para poder volcar luego esa información sobre nuestras bases de datos operaciones, por ejemplo Oracle o SQL.
Procesos de comunicación mediante estándares tipo Swift, EDI, Sepa, etc. En estos casos es necesario disponer de un equipo de desarrolladores que extraigan la información de las cadenas swift o EDI y las conviertan a XML u otro estándar para luego ser descompuestas y enviadas a nuestras aplicaciones.
Y por último, el ejemplo que ha revolucionado el mundo de la integración de datos, la creación de un Data Warehouse para BI. En este caso es necesario recopilar información de varias aplicaciones o silos de datos, tratarla, transformarla y volcarla por un último en un repositorio donde luego será analizada por nuestra aplicación de Business Intelligence. Este proceso ha de ser automatizado y repetido periódicamente para refrescar los datos que luego serán analizados.
El tratamiento de todos estos procesos de integración ha motivado que las empresas tengan un número muy elevado de scripts o procesos de integración, en empresas medianas o grandes podemos hablar de más de 1000 o 1500 scripts, que a su vez conllevan un mantenimiento elevado y una falta de flexibilidad o agilidad a la hora de introducir cambios. Imaginemos un típico escenario donde nuestro repositorio de Data Warehouse se encuentra sobre una base de datos SQL, ¿Qué pasaría si la dirección decide reemplazar esta DDBB por Oracle o Teradata por motivos de coste, rendimiento, escalabilidad, etc?. Como os podéis imaginar deberemos cambiar todos los scripts para que ahora apunten a esta nueva base de datos y ¿que sucede sí cambiamos una tabla?, deberemos analizar todos los scripts que se ven afectados, ¿y si nuestra dirección nos pide un nuevo informe o modifica un informe de BI existente?, ¿podremos analizar el impacto sobre nuestros procesos de integración?.
Todas esta problemáticas son las que han hecho aparecer en el mercado lo que conocemos como herramientas de ETL (Extract, Tranform and Load), en su inicio y que a día de hoy han pasado a ser herramientas muy potentes pensadas para entender la integración como un concepto estratégico para la empresa y como una vía para mejorar nuestra agilidad, flexibilidad ante el cambio y la innovación y una forma de reducir costes de integración, desarrollo y mantenimiento.
Pues sobre estos temas y muchos otros relacionados con la integración como la calidad de datos iremos centrándonos en este blog.

Un saludo.