Análisis del portfolio de integración y calidad de datos de los principales fabricantes (Introducción)

Hasta ahora en los artículos que he ido publicando en este blog me he centrado en las funcionalidades y los conceptos básicos de la integración de datos, no entrando a analizar las funcionalidades de cada producto, todo y que hemos comentado algunas de ellas cuando hemos hablado de anuncios de nuevas versiones, publicación de cuadrantes de Gartner, Forrester, etc. A partir de ahora me gustaría comenzar una serie de artículos donde podamos analizar el portfolio de soluciones de integración y calidad de datos que nos ofrecen los principales fabricantes.

Como bien me habéis sugerido en varias ocasiones, la última de ellas ha sido la del comentario de Antonio, lo ideal sería poder hacer una comparativa de productos, y lo cierto es que llevaba bastante tiempo trabajando en hacer esta comparativa, pero creo sinceramente que de poco o nada iba a servir. Desde mi punto de vista creo que las comparativas de producto normalmente suelen ser incompletas, poco objetivas y en la mayoría de ocasiones poco útiles para poder decidir que producto es el más conveniente para nuestro propósito.

No conozco a nadie que sea capaz de decidir una compra de un producto de integración basándose en los datos de una comparativa, creo que una buena elección se tiene que fundamentar en muchos otros valores y condicionantes como ya os comentaba en el artículo Elegir una herramienta de integración de datos.

Otro de los inconvenientes que creo que se producen en las comparativas de producto es que es muy difícil poder analizar y hacer las pruebas de cada producto de forma completa y objetiva, ya que es complicado disponer de la infraestructura de hardware necesaria para llevar a cabo todas las pruebas y luego el diseño de la batería de pruebas a realizar tiene que ser muy estudiado para que sea independiente del producto a analizar de tal forma que no destaquemos las ventajas o inconvenientes de uno u otro producto de forma partidaria. Por último, y esto es una de las principales quejas de los fabricantes, el equipo que realiza las pruebas puede tener un mayor conocimiento o desconocimiento de un producto y esto puede motivar que el diseño de la solución no sea el optimo. Este último paso creo que es un factor muy importante en las herramientas de integración y de calidad de datos ya que el diseño del proceso de integración debe ser optimizado dependiendo del funcionamiento de cada una de las herramientas analizadas, por ejemplo, no es lo mismo programar un proceso para hacer una join de 2 tablas y generar una tercera tabla, si estas tablas residen todas en el mismo servidor de base de datos o en servidores diferentes y también hemos de tener en cuenta si la herramienta que estamos probando posee un motor de integración propio o es capaz de utilizar el motor de la base de datos, es decir si ha de mover los datos al servidor de integración o bien podemos convertir nuestro proceso en PL/SQL y enviarlo para que sea ejecutado por el motor de la base de datos. Otro claro ejemplo es que un proceso de movimiento de datos con filtrado puede dar un rendimiento muy diferente si las tablas de origen están indexadas, si hacemos un sorter previo, etc.

Por todas estas razones y por muchas otras que no quiero enumerar para no hacerme pesado, creo que intentar hacer una comparativa de los productos existentes actualmente en el mercado sería un despropósito por mi parte, así que lo que creo más honesto es explicaros el portfolio de productos de cada fabricante con el mayor nivel de detalle posible para que podáis entender que herramientas pueden ser útiles para vosotros. Como iréis viendo y supongo que algunos de vosotros ya lo habéis sufrido, entender el portfolio de cada fabricante no siempre es fácil, así que espero hacerlo lo mejor posible.

Un saludo.

Elegir una herramienta de integración de datos

Hola de nuevo,
Me quiero permitir un paréntesis en la serie de artículos que estaba escribiendo sobre los procesos de migración y fusión para hacer una reflexión sobre los típicos errores, prejuicios y omisiones que se dan a la hora de realizar la elección de una herramienta de integración de datos empresarial.
Cuando hablo de integración de datos empresarial es muy importante remarcar la palabra empresarial como una cualidad indispensable en este tipo de soluciones. La razón es muy sencilla, las necesidades de integración son necesidades que no se encuentran vinculadas a un solo proyecto, sino que son comunes a muchas tipologías de proyecto como pueden ser los proyectos de BI, en la parte de carga del Data Warehouse, los proyectos de M&A, los proyectos de BPM, B2B, ERP, CRM, Visión única de cliente, de producto, etc, por lo tanto es muy importante que este tipo de herramientas se plantean como una solución corporativa para las necesidades de integración de la empresa y no como una solución puntual para cubrir las necesidades de un proyecto específico.
Partiendo de esta aclaración o premisa me gustaría enumerar los 4 errores típicos o los 4 argumentos de resistencia que me he encontrado en el mercado a la hora de plantear soluciones basadas en productos de integración de datos.
La idea es plantearos el requerimiento o la necesidad que deberíamos considerar a la hora de elegir la herramienta y a continuación os explico los errores típicos, situaciones y consecuencias que se planean de una aproximación errónea.

Caso 1:
La herramienta ha de cubrir los requerimientos actuales y asegurar capacidades de crecimiento y adaptación a nuevos requerimientos.

• Error 1: Adquirimos la herramienta que se ajusta a las necesidades actuales sin valorar el crecimiento futuro.
• Posible situación: A los 10 meses aparece un nuevo requerimiento y no podemos hacer frente con la herramienta que escogimos.
• Argumento utilizado por IT: Era la más barata, su coste era reducido, de fácil implantación, etc.
• Punto de vista de dirección: Mala decisión por parte de IT ya que esta herramienta nos saldrá muy cara porque ahora debemos adquirir una nueva para cubrir las necesidades actuales y perdemos la inversión hecha en esa herramienta, el tiempo de implantación, la formación a los administradores y tenemos que volver a pasar por todas esas fases.

Caso 2:

La herramienta ha de tener capacidades de reutilización de procesos.

• Error 2: La herramienta que elegimos NO permite diseñar los procesos de ETL como módulos reutilizables entre los diferentes procesos de carga.
• Posible situación: Nos encontramos que muchos de los procesos de tratamiento de datos son repetitivos y tenemos que volver a generar cada uno de esos procesos.
• Argumento utilizado por IT: Es muy fácil volver a generar el proceso, al final es hacer un copy/paste entre diferentes procesos.
• Punto de vista de dirección: Mala decisión por parte de IT ya que sí mañana cambio la lógica de tratamiento de los datos he de volver a revisar todos los procesos donde se utiliza esa lógica y no dispongo de un punto centralizado donde realizar el cambio.

Caso 3:
La herramienta ha de poder realizar análisis de impacto y dependencia entre orígenes y destinos.

• Error 3: No consideramos esta funcionalidad como algo primordial ya que actualmente sólo tengo una base de datos con unas cuantas tablas y un solo destino.
• Posible situación: Después de varios meses de uso necesitamos cambiar un campo en una tabla, añadir un campo nuevo o cambiar la base de datos de SQL a Oracle ya que nuestro director ha firmado un acuerdo corporativo con Oracle.
• Argumento utilizado por IT: Esta situación era difícil de prever ya que llevamos años utilizando la misma tecnología de DDBB. No contemplamos el cambio en la orientación del negocio o los datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, nuestro negocio es dinámico y siempre se pueden producir cambios en la metodología o lógica que aplicamos, así que las herramientas han de ser capaces de adaptarse a esos cambios.

Caso 4:
Para reducir los costes de integración y anticiparse a los errores de calidad del dato o formato debemos tener capacidades de perfilado.

• Error 4: El perfilado no es necesario ya que conocemos muy bien el modelo de datos de nuestras bases de datos.
• Posible situación: Empiezan a aparecer errores de datos motivados por formatos no esperados o campos con contenido no esperado (Nulls, diferentes formatos de fecha, números no validos, etc).
• Argumento utilizado por IT: El problema reside en el Data Entry ya que las chicas que entran los datos en el Call Center no hacen caso de la normativa de entrada de datos.
• Punto de vista de dirección: Falta de previsión por parte de IT, el personal del call center es subcontratado y rota con mucha frecuencia, no podemos asegurar su formación para entrar los datos perfectos, cada persona escribe las fechas o los teléfonos de forma distinta, algunas no entienden el uso que podemos llegar a hacer de cada dato,…

Otras consideraciones:

• Necesidades de conocimientos de lenguajes de programación específicos (script, java, pl/sql,…)
• Falta de capacidades de autodocumentación de procesos
• Entornos de desarrollo y producción sin capacidades de despliegue guiado, versionado, roll-back, etc.
• Limitadas capacidades de crecimiento vertical, horizontal y optimización del rendimiento (grid computing, alta disponibilidad, particionado, pushdown, etc)
• Imposibilidad de extender el uso de la herramienta a entornos Saas y B2B. (EDI, SEPA, Swift, …)
• Imposibilidad de incorporar datos de formatos no estructurados (excel, pdf, word, etc)

Como resumen de todas estas experiencias que me he ido encontrando a lo largo de todos estos años, me gustaría hacer hincapié en que a la hora de analizar una herramienta de integración de datos no es quedéis sólo en el precio, el fabricante o las capacidades de conexión, porque a la larga pueden aparecer escenarios como los que hemos planteado donde quede claro que la elección no ha sido muy afortunada y en ese momento tendréis un problema sobre la mesa muy difícil de gestionar, creerme que no es grato averiguar al cabo de unos meses que te has equivocado con la elección de la herramienta y que el único argumento que puedes esgrimir ante tus jefes es que “era más barata” o que “para ese proyecto servía”, porque lo único que van a ver tus jefes es que tienes una gran falta de visión global del negocio, de previsión y por lo tanto de gestión de tus presupuestos o proyectos.

¿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.

Bienvenida

Hola a todos,

Viernes, 14 de marzo de 2008. Después de 20 años en el sector hoy me he decidido a crear este blog donde me gustaría compartir con todos vosotros las experiencias, consejos, información y comentarios que he ido recopilando durante los últimos años en los que me he dedicado a la consultoría y asesoría tecnológica, orientada principalmente a procesos de integración y calidad de datos.
En este primer artículo de bienvenida quiero explicaros un poco la orientación que me gustaría darle al blog, así como que os podéis esperar de él.
Lo primero de todo es destacar que este blog no pretende ser de un alto contenido técnico, todo y que por los temas que se tratan, deberemos recurrir en algunas ocasiones a cuestiones técnicas.
El tipo de artículos que os iré escribiendo se enfocan más a la consultoría o asesoría sobre soluciones de negocio y políticas de arquitectura y gestión de proyectos. Pretende ser una ayuda para que os podáis plantear nuevas soluciones tecnológicas, nuevos enfoques de negocio o bien simplemente como apoyo para justificar inversiones de proyecto o metodologías delante de vuestra dirección o superiores.
El objetivo es ambicioso, así que espero no fracasar en el intento. Aunque esto sólo el tiempo y vuestras visitas podrán responder a ese temor.
En cuanto a mi experiencia en el sector, os relataré brevemente. Llevo dedicándome a esto que genéricamente llamamos informática desde el 1989 y he pasado por integradores y distribuidores como Sermicro, Microblanc, Morse o PowerData, por algunos fabricantes como WordPerfect (que tiempos) y Informatica Corporation, he trabajado también como profesor en el ICT (Institut Català de Tecnología) y AulaDat, también estuve un tiempo ganándome el sustento como consultor autónomo.
En todo este tiempo he ido ejerciendo diversas tareas y especializándome en diversos ámbitos hasta llegar a la integración de datos, como os podéis imaginar he pasado por técnico de campo, de hardware, de sistemas, product manager y consultor y he pasado por las siguiente etapas CNE de Novell, MCSE de Microsoft, especialista certificado de IBM en xSeries, pSeries y soluciones SAN, especialista ATI-Router de Allied Telesyn, VMware, y alguna otra cosilla que seguro que me dejo en el tintero porque no debe tener gran importancia.
Bueno, para este mensaje de bienvenida creo que ya me he extendido demasiado, así que os dejo y espero que os guste el blog.
Un saludo.
David.