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.

Migraciones, Fusiones y Adquisiciones (Segunda parte)

Hola de nuevo,

En la primera parte de este artículo enumerábamos los distinto perfiles y áreas que van a a intervenir en un proceso de fusión o adquisición de empresas y el proyecto de integración que de esa situación se deriva. A continuación me gustaría comentar que retos y consideraciones hemos de contemplar desde un punto de vista más técnico y práctico a la hora de abordar el proyecto.

Lo primero que deberemos analizar son las necesidades que se nos plantean a la hora de abordar este tipo de proyectos, para realizar este análisis hemos de tener presentes algunas de las preguntas que aparecían en la primera parte del artículo:

• Experiencia en proyectos similares

Lo primero que podemos plantearnos es sí tenemos alguna experiencia previa en este tipo de proyectos. Esta experiencia puede ser de gran utilidad para no empezar de cero ya que podemos recopilar la información sobre como ejecutamos esos proyectos y utilizarla como plantilla para elaborar el nuevo proyecto, aprovechando aquellos puntos que funcionaron como se esperaban y corrigiendo los errores de planteamiento y ejecución que se pudieran haber producido.

Por desgracia, la gran mayoría de empresas no sufren procesos de fusión cada año, posiblemente no dispongamos de información de proyectos anteriores porque no se han efectuado o bien el último proyecto de fusión se ejecuto hace bastante tiempo y gran parte de esa información ya no nos sirva, ya sea porque nuestros sistemas han cambiado o bien porque la forma de abordar ese proyecto ya no tenga vigencia a día de hoy.

• Conocimiento de los sistemas a migrar

Este suele ser el primer punto técnico del proyecto que nos planteamos, ¿conocemos los sistemas que vamos a migrar o integrar sobre nuestra plataforma?, este pregunta suele tener una respuesta negativa o bien podemos tener un conocimiento bastante limitado de esos sistemas, por lo tanto la primera necesidad que se nos planteará será recopilar la mayor información posible sobre esos sistemas.

• Definición de tiempos de ejecución y dependencias

Otro de los puntos clave será definir los tiempos de ejecución del proyecto. En esta primera definición no se trata de definir cuanto tardaremos en ejecutar la migración, ya que aún no tenemos toda la información necesaria para poder estimar un esfuerzo, sino que en esta fase deberemos analizar las dependencias de cada una de las fases del proyecto y crear un mapa de dependencias, tanto a nivel de procesos y aplicaciones como a nivel de datos. Esto nos servirá para tener un primera aproximación de cómo deberemos ejecutar nuestro proyecto a nivel lógico y a partir de ahí evaluar los requisitos técnicos de cada fase y por último estimar los esfuerzos necesarios.

• Disponibilidad de recursos

Por último, otra de las típicas preguntas que nos realizaremos será si disponemos de los recursos necesarios para abordar un proyecto de este tipo o bien si necesitaremos de recursos externos. Esta pregunta ya os la respondo yo, necesitaréis de recursos externos, sino es así os podéis considerar afortunados, son pocas las empresas que a día de hoy aún disponen de departamentos de IT lo suficientemente amplios como para abordar un proyecto de estas características sin necesidad de ayuda externa.

Estas son sólo algunas de las preguntas que nos planteamos antes de abordar el proyecto, una vez que nos ponemos manos a la obra se nos presentarán diversos retos que deberemos ir asumiendo:

Como comentábamos anteriormente, este reto responde a una de las preguntas que nos planteábamos, como consecuencia, deberemos ser capaces de superar las limitaciones de recursos que existan en nuestra organización, la falta de procesos de migración anteriores que nos doten de metodologías, métricas y buenas prácticas para plantear la migración, y por último, tendremos que intentar coordinarnos con otras áreas de la organización que participen de forma directa o indirecta en el proceso de migración.

El segundo reto se centra en la identificación de los datos a migrar. Tenemos que comprobar la existencia de los datos a migrar, es decir tenemos que disponer de hechos, no supuestos, que nos permitan asegurar que los datos que deseamos migrar tienen las características y se corresponden con lo que esperamos encontrar.

Tendremos también que verificar la procedencia de los datos, es decir las fuentes que deberemos manejar para extraer esos datos. Otro de los factores que tendremos que vencer es el conocimiento de las reglas o contexto del negocio donde se utilizan esos datos, así como las relaciones que existen entre ellos, por escenificar un poco este punto diremos que deberemos conocer en cuantas aplicaciones y soluciones de negocio se utilizan esos datos ya que si no nos podemos encontrar con la sorpresa de que al eliminar o migrar una base de datos, dejen de funcionar aplicaciones o áreas de negocio que no teníamos contempladas.

Los últimos tres puntos no son menos importantes, ya que necesitaremos establecer una temporización de migración en base a los accesos a los datos, los diferentes orígenes y las dependencias a nivel de aplicaciones, está claro que cuando migremos un silo de datos deberemos tener contemplada la migración de todas las aplicaciones y procesos que utilizan esos datos, o establecer unos periodos de sincronización entre origen y destino, si se produjera el caso de no poder migrar todas las aplicaciones y procesos dependientes del dato.
Por último, ¿Qué son los datos huérfanos?, son todos aquellos datos que presentan algún tipo de excepción o casuística que nos impide asociarlos dentro del proceso normal de migración, ya sea porque no responden a unos estándares o porque no contienen una integridad referencial o simplemente porque se encuentran descontextualizados. En este caso deberemos trabajar con tablas de excepciones para tratar cada una de las casuísticas que nos encontremos.
Este punto lo veremos un poco más en detalle más tarde.

Por desgracia, los procesos de migración o fusión entre empresas no se pueden ejecutar en un fin de semana, y suelen ser proyectos que se alargan durante meses hasta que se definen todos los escenarios y se ejecutan todos los procesos de migración, así que será muy importante responder a los retos que supone asimilar los cambios sobre los requerimientos iniciales, los modelos de datos o los interfaces, quien suponga que puede decirle a su organización que “pare máquinas” hasta que se ejecute la migración peca de inocencia, así que deberemos contemplar todos nuestros diseños de procesos teniendo en cuenta las capacidades de adaptación al cambio de los mismos.

Por suerte, podemos decir que, a día de hoy, este punto es mucho más fácil de administrar de lo que pueda parecer a priori.

El reto de la validación de los datos es un reto que nos encamina directamente hacía lo que conocemos como Calidad de Datos.
A la hora de realizar una validación de los datos que migramos no basta con comprobar que se han pasado el número de registros y tablas que había en el origen, una validación implica comprobar que en el destino se han grabado los datos que nuestras reglas de negocio y aplicaciones esperaban, comprobando su integridad, su formato y la idoneidad de los mismos. En este punto necesitaremos realizar no sólo validaciones de calidad a nivel de estandarización, conformidad o formato del dato, si no que deberemos realizar validaciones sintácticas, semánticas y de integridad. ¿de qué me servirá migrar un dato si en el destino se espera que el dato aparezca tratado en un formato específico?.

Por último una migración no acaba cuando se mueven los datos y las aplicaciones, sino que después deberemos realizar una revisión de todos los sistemas, procedimientos, aplicaciones y datos para comprobar que todo “ha ido bien”. En este punto nos pueden surgir varias necesidades para las que hemos de estar preparados, y responder de una forma rápida sí por ejemplo nos encontramos con problemáticas de datos, con problemas de integridad, de funcionamiento de las aplicaciones, etc.

Para solucionar estos problemas será muy importante disponer de trazabilidad de los datos, análisis de impacto sobre los cambios realizados y de procesos de sincronización entre entornos para asegurar capacidades de convivencia de entornos o bien de procesos de roll-back.

Hasta aquí hemos enunciado los retos que debemos tener en cuenta a la hora de plantear un proyecto de migración, o lo que es lo mismo, hemos definido algunas de los puntos sobre los que debemos estar alerta. Espero no haber generado muchos miedos, pero como veis un proyecto de migración no es sólo mover datos de un sitio a otro, sino que hay muchas cosas que controlar y contemplar.

En el siguiente artículo de esta “saga” pasaremos a definir la metodología para abordar estos procesos y hablaremos de algunas de las herramientas y funcionalidades que os pueden ayudar a realizar una migración sin morir en el intento.

Migraciones, Fusiones y Adquisiciones (Primera parte)

Hola de nuevo,
La situación económica actual y los movimientos empresariales están produciendo que cada día un mayor número de empresas planteen compras, fusiones, adquisiciones o escisiones de empresas. En la prensa y en Internet se suceden las noticias empresariales sobre los movimientos de compra y venta de empresas. Todos estos procesos son analizados desde la vertiente económica y nos reflejan las posibilidades de crecimiento, expansión, etc., de cada una de las empresas, en este artículo intentaremos desmarcarnos de esa visión y centrarnos en los procesos de migración, escisión o fusión de datos que se producen en las empresas como consecuencia de estos movimientos financieros.
El primer punto que debemos tener claro cuando nos encontramos en un proceso de migración o fusión (el acrónimo inglés utilizado es M&A), es que visión tiene cada uno de los estamentos de la empresa a la hora de afrontar este tipo de procesos, esta visión nos servirá para encontrar el interlocutor adecuado para cada situación e identificar porque se toman algunas decisiones y que espera cada departamento de nosotros.
Desde la dirección los procesos de compra o fusión se plantean siempre desde el punto de vista económico y en términos de oportunidad de negocio, crecimiento, posicionamiento, etc.

Lo que va a valorar Dirección siempre va a ser la ventaja competitiva que supone la compra de otra empresa, ya sea en términos de cartera de clientes, productos, posicionamiento en el mercado, imagen de marca, oportunidad de expansión a otros mercados u otras áreas de negocio, diversificación de la inversión, etc.
Una vez que se plantea la migración o la fusión desde Dirección, ¿Cómo se ven afectados los otros departamentos de la organización?. Desde el resto de la organización se plantean básicamente los impactos que se van a producir en la forma de trabajar, en la organización y en los procesos a partir de ese momento. Desde estos departamento la visión suele ser algo más catastrofista que desde Dirección, se suelen ver los inconvenientes en cuanto a cambios organizativos, problemáticas de aplicación y adaptación a la nueva estructura, los procesos y recursos necesarios para asumir todas las tareas necesarias para llevar a cabo el proceso de migración y un largo número de inconvenientes asociados a los trabajos que se derivarán de este proceso iniciado por dirección.
Por último cabe destacar que existen otros condicionantes que nos van a afectar a la hora de platear un proyecto de integración. Estos condicionantes son los que se producen motivo de la desconfianza que genera un proceso de este tipo dentro de los profesionales que comprenden nuestra organización. En estas situaciones siempre hay una resistencia al cambio, ya que es normal que se genero un miedo sobre los nuevos procesos y como estos van a afectar a la operativa diaria de cada persona, también es típico que se genere una ola de pesimismo sobre el futuro de la compañía y sus puestos de trabajo, que conlleva asociado un ocultismo de información como herramienta para conservar su puesto de trabajo y un cierto inmovilismo para no favorecer los cambios que puedan afectar a esas personas de forma directa o indirecta.

Todas esta premisas respecto a la dirección, a la organización y a las personas son las que deberemos tener en cuenta a la hora de plantear cualquier paso, reunión o decisión respecto del proyecto de integración. Por lo tanto, ¿que debemos hacer con cada interlocutor?.
Cuando hablemos con Dirección para exponer una problemática o sugerir ciertas acciones hemos de tener presente que su objetivo es mejorar los beneficios de la empresa y que para ellos lo más importante es que el proceso de fusión se haga de la forma más rápida y menos costosa posible. Así las preguntas que se plantean desde dirección son:

• ¿Cuánto tiempo tardaremos en tener operativos los datos y procesos migrados?
• ¿Cuánto nos va a costar?

Teniendo en cuenta esas preguntas nuestros argumentos siempre han de estar dirigidos a resolver esas preguntas, por lo tanto deberemos utilizar argumentos del tipo:

• Para reducir los costes de migración deberíamos….
• Para reducir el tiempo de migración necesitamos disponer de…

Si nos centramos en esas dos variables Dirección siempre va a ser más receptiva y va a entender perfectamente la problemática o necesidades que estamos exponiendo.
Por otra parte, si queremos hablar con otros departamentos o dentro de nuestro propio departamento de IT con otras áreas, deberemos realizar el mismo ejercicio y ver que problemáticas o preguntas se plantean en esta área, así nos surgirán cosas como:

• ¿Poseo documentación de los sistemas origen?
• ¿Conozco como están organizados los datos?
• ¿Conozco las dependencias entre datos y aplicaciones?
• ¿Existen técnicos en mi organización que dominen todas las aplicaciones que he de integrar y los lenguajes y protocolos necesarios (Cobol, PL/SQL, XML, Java, EDI, Swift, etc ?

Están son algunas de las preguntas que deberemos responder dentro de nuestro departamento para poder plantear los pasos y procesos que demos realizar en la fusión.
Por último, no debemos olvidarnos que cuando hablemos con cualquier persona de nuestra organización podemos encontrar reticencias a colaborar o facilitar información que pueda ser sensible a su trabajo. La forma más eficaz para evitar esas barreras es informar a esa persona del porqué necesitamos esa información, que vamos a hacer con la información y demostrar en todo momento que no estamos intentando recoger información para eliminar o degradar a esa persona dentro de la organización. Es muy importante que todos se sientan una parte importante del proceso de migración o fusión y que su colaboración es necesaria y que de ella depende la marcha de la compañía y en parte su futuro en ella.
Bueno, en esta primera parte hemos sentado las bases para saber donde nos vamos a mover y como debemos plantear nuestras conversaciones en base de nuestro interlocutor. En la segunda parte de este artículo nos centraremos en la parte más práctica de la migración, donde veremos los procesos de integración de datos, que pasos son importantes, requisitos previos, etc.

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