La diferencia entre conocer el camino de un CIO y recorrerlo

Una de las máximas que todo CIO “debería tener” es la de buscar la alineación/integración de SI/TI con el negocio. Claro, que hay una diferencia sustancial entre conocer el camino y recorrerlo (esta frase la he hecho mía después de tener que utilizarla en más de 5 ocasiones en el último mes, así que no mencionaré que se la escuché a Morfeo en Matrix). Uno se centra en conocer los objetivos estratégicos de la empresa en la que está, identifica-estudia los procesos clave, y busca automatizar/transformar los mismos en la medida en que esto es posible (posible=f(equipo, tecnología, cultura, apoyo de la dirección … y un montón de cosas más)). Acuerdas con los directores funcionales los proyectos a abordar, elaboras conjuntamente el “as-is”, diseñas el “to-do”, se desarrolla e implanta siguiendo un método ágil, tienes tus baterías de test, haces pruebas de aceptación, y el equipo del proyecto está enormemente orgulloso de la labor realizada. Enhorabuena!!!.

Algunas veces, cuando consigues llevar a cabo semejante despliegue y crees que has satisfecho las necesidades de tu cliente interno (con el que se supone que tienes que estar alineado/integrado) te das cuenta de que no. De que no es suficiente. Falta algo más: un “informe nomina”, cambiar la posición del logo, multicolorear un grid, o lo que suele ser más grave, otro proceso tangencial que han convertido en “estratégico” recientemente (o que ya lo “era” y nadie lo identificó). Lo más curioso tiene lugar cuando, por vete tú a saber que razones (normalmente políticas), insisten con la implementación de un software cuyo objetivo subyacente es eliminar la estupidez humana (cómo que no lo habrá intentando durante años IBM). Si llegas aquí, es momento de parar (se tiene que disparar la misma alerta que cuando le has puesto un try-catch a un printf, has comenzado la implementación de un motor de bases de datos o de un hermano pequeño de Excel). Normalmente esto ocurre porque alguien no está haciendo bien su trabajo: las prioridades dependen de quien hable, hay una lucha de egos considerable, alguien está condicionando en exceso externamente, etcetera. Sin embargo he llegado a la conclusión de que esto sucede normalmente cuando no se pone un coste y un ROI a los proyectos de SI/TI. Cuando el cliente interno no percibe que lo desarrollado tiene un coste (sobre todo de oportunidad) y que sobre éste coste tiene una responsabilidad en el cumplimiento del ROI, tiende a minusvalorarlo.

Llegado este momento, que bajo mi experiencia indico que tiene carácter cíclico, el CIO tiene que obrar con tranquilidad y seguridad. Si no eres capaz de llegar a un acuerdo (puede que esté fuera de tu alcance o que no debas llegar a él para poder cerrar el ciclo) debes identificar el impacto en el núcleo de los servicios y procesos clave, dejando que el tsunami transcurra. Requiere mucha experiencia, templanza y seguridad. Si se hace bien provoca una “catarsis” en los afectados, algunas veces es el propio CIO el que lo necesita.

Empieza entonces el baile de alternativas: consultoras externas, desarrollos a medida con personal “cualificado” (cuidado con los informáticos externos a SI/TI ), hojas excel, bases de datos access, consultas sql cruzadas con … el universo. La posición del CIO debe ser la de preservar el núcleo de los SI/TI. Dejar que se hagan pruebas, si, pero con gaseosa.  Pasado un tiempo y un coste, se implantará el proceso.

Si es un éxito el CIO deberá replantearse su forma de gestionar. Se encuentra seriamente desalineado con el negocio lo que, desde una perspectiva constructiva, debe traducirse en un reciclaje en procesos de innovación o gestión, o en la identificación y gestión del talento dentro de su empresa. La máxima de “si funciona no lo toques” puede traer consigo estas consecuencias y no debemos alarmarnos si sucede. Simplemente tenemos que adaptarnos a las nuevas condiciones, analizar que es lo que ha pasado, y tener claro que en cualquier caso lo que tenemos que conseguir es la integración con el negocio.

Si por el contrario la implantación del proceso es insatisfactoria tenemos una oportunidad única de restablecer el aporte de valor al negocio de  SI/TI. Éste restablecimiento puede ser acumulativo, aprovechando lo desarrollado por el proyecto “externo” lo cual suele ser un poco infierno, o recomenzando, afrontando el desarrollo desde cero pero con la confianza mutua de los departamentos afectados.

Recuerdo una situación en la cual, por motivos de “por que lo digo yo”, se afrontó una implantación de una herramienta con carácter unilateral por parte del departamento de más peso de la empresa. Se llevaron a cabo reuniones indicando lo inadecuado del proceso y la solución adoptada, la dificultad en la obtención de información útil, los problemas de operativa, etc. Dio igual, se quería implantar “la herramienta” y se implantó. SI/TI dio cobertura a las necesidades de infraestructura. El entramado que se montó entre hojas excel, base datos access, ficheros compartidos en red y consultas sql fue tal que el sistema colapso en menos de 1 mes. Era como volver a los orígenes de la empresa. Entonces y sólo entonces se dio el OK al proyecto que SI/TI había propuesto para integrar los procesos de negocio y que posteriormente sirvió para escalar la solución.

Todo esto puede parece un “pelín” radical, pero hay muchos ejemplos en la vida cotidiana de lo que aquí he intentado describir cómo dejar que tu hijo tenga un pequeño susto mientras hace una trastada patinando/montando en bici/practicando algún deporte. Recuerdo una situación, un poco extrema,  siendo yo un niño en el que un gran maestro, no diré quien,  me dejó que tocase los cables de corriente para ver que pasaba después de mucho insistir y enredar por mi parte. No sólo aprendí porqué no se deben tocar los cables de tensión a la vez. También aprendí que hay una gran diferencia entre conocer el camino y recorrerlo

Virtualización y consolidación en la PYME (I)

Virtualización y consolidación

Este es el primero de unos cuantos post que tengo pensado escribir sobre virtualización y consolidación aplicadas a la PYME. Incluyo el matiz de la PYME por que calculo que escribir sobre virtualización a estas alturas de la historia, poco aportará a nadie. Más parecería un intento de aparentar controlar una tecnología actualmente de moda, que va más allá de lo que en unos pocos párrafos pueda escribir una persona como yo.

Quiero darle el enfoque de utilización de la virtualización como herramienta para reducir costes, ganar en tolerancia a fallos y seguridad, o dar soporte al crecimiento de la empresa sin que éste se vea comprometido por los sisemas de información. No voy a hablar aquí de la virtualización desde un punto de vista teórico o asociada a una determinada solución como los servidores blade o equivalentes. Me voy a centrar en los beneficios prácticos que esta tecnología proporciona a la PYME.

Mis primeros contactos con el mundo de la virtualización fueron en la universidad, allá por el año 2000. Corría el “rumor” de que algunos profesores enamorados de unix-linux, hacían correr máquinas virtuales en sus equipos para poder conectarse a los recursos de la red y demás como si tuviesen un Windows NT. Hasta esa fecha yo sólo conocía algo de la tecnología utilizada por Intel para la emulación de los procesadores 8086 derivados de los estudios que tuve que hacer para mi proyecto fin de carrera (PFC). Sin embargo ese “rumor” iba mucho más allá. Virtualizar todo un sistema operativo o plataforma, era todo un avance. Me interesó tanto que hasta realicé algunos ensayos para ver si hubiese sido aplicable al PFC.

Mi primer PFC trataba sobre el desarrollo de un prototipo de sistema operativo micronúcleo para la plataforma i386. Uno de los grandes retos con los que nos enfrentamos mis queridos Ángel, Roberto y yo, fue la realización de un cargador de SO desde disquete. Una vez arrancado el cargador, entrábamos en el famoso modo protegido de Intel, inicializábamos la memoria segmentada+paginada y dábamos paso al resto de módulos (el mío era el módulo de gestión de procesos y mensajes). Cuento todo esto por que las depuraciones del código que elaborábamos las realizábamos en una máquina que después de cada depuración debía ser reiniciada (cuanto tiempo perdimos). La virtualización nos hubiese ahorrado todo este proceso tan tedioso. Así que con más ganas que planificación realicé las pruebas. Tuve que dejarlas ya que debía continuar con mis estudios y el PFC de la superior tenía más prioridad en esos momentos.

La siguiente vez que me encontré con la tecnología de la virtualialización fue en Panda Software. Allí lo utilizaban para realizar las simulaciones de contagios de virus, creacion de entornos simulados, etc. La tecnología por aquel entonces, mucho más estable, ya empezaba a utilizarse de manera habitual, y el pasarse imágenes virtualizadas entre los apasionados de la tecnología era normal.

Hasta entonces había mirado la virtualización como una tecnología “curiosa” pero aplicable sólo en entornos concretos. No fue hasta el año 2005, justo después de haber defendido y aprobado una inversión en servidores fujitsu-siemens para un CPD de la empresa en la que trabajaba, cuando el proveedor del hardware, pasados 3 meses me dijo: “estos servidores son muy potentes … pero fujitsu dejará de desarrollarlos en un periodo de 3 meses. Van a pasar a utilizar una nueva arquitectura que …”. Yo pensé, “pero estos están locos, no hace ni 3 meses que mi empresa ha invertido miles de euros en estos servidores y en 3 meses se van a quedar obsoletos y no voy a poder ampliarlos”. Además tenía previsto actualizar un conjunto de servidores (por llamarlos de alguna manera ya que eran más bién unos agraciados clonicos que ya habían cumplido su cometido en la vida), pero claro, con esta perspectiva, quien se arriesgaba.

En ese momento comenté con mis compañeros, sobre todo con mi querido Iván, el propio proveedor local y demás gente cercana a mí las posibles soluciones al problema. Fue entonces, año 2005, cuando me decanté por la virtualización y comencé con un proyecto que a fecha de hoy sigue su curso. El objetivo era virtualizar toda la infraestrucutra que en ese momento se tenía en la empresa. La plataforma de virtualización escogida fue VMWare Server (por aquello del coste 0). Hicimos muchas pruebas y fue la que se demostró más estable. A fecha de hoy no sabría cual escoger. Seguramente VMWare ya que hasta la fecha se ha comportado de maravilla.

Asumimos el estudio de la tecnología y su aplicación. Nos llevo varios meses de pruebas, distanciadas en el tiempo ya que había que hacer informes y demás cosas, pero finalmente pusimos en producción un servidor virtualizado. Ese primer servidor contenía a nuestro querido, y odidado, Exchange. Hasta entonces había estado “incrustado” en la misma máquina que el servidor de ficheros y el active directory. Vamos, que si el servidor de más de 5 años fallaba por cualquier causa, como después de un año sucedió, parábamos la empresa y entonces todo dejaría de ser un problema para mi, al menos en la empresa .

La experiencia fue todo un éxito. Hoy sigue funcionando como si nada, guardamos copias integrales del mismo todos los años, además de las propias del Exchange. Lo más destacable desde mi punto de vista es que esa imagen que funciona perfectamente sólo tiene lo necesario para que funcione el Exchange, por lo que simplica terriblemente la gestión de actualizaciones. Los recursos asignados a la máquina virtual son los necesarios para su funcionamiento. Y si requiriese más, pues se los damos desde la consola de adminsitración y no pasa nada. Nunca fue tan facil ampliar la memoria o la capacidad de un servidor.

En el siguiente post comentaré cuales fueron los retos más importantes con los que nos enfrentamos, cómo los solucionamos, que problemas de escalabilidad tuvimos, etc. En post futuros trataré temas como:

• Consolidación de servidores
• Construcción de clusters virtualizados
• Arquitectura orientada a servicios (este tema es increible como encaja con la virtualización)
• Ventajas, inconvenientes y problemática de la externalización de un CPD
• Estrategia actual del proyecto de virtualización
• Novedades y tendencias en el segmento de la virtualización

Nos leemos.

Propuesta para abordar el desarrollo de informes dentro de una empresa I-II

Informes

Hace mucho tiempo que quería escribir sobre mi experiencia y forma de pensar respecto de un problema más que recurrente en el mundo del desarrollo de software “in-house”. En especial quería escribir sobre todo aquello relacionado con el mundo de los informes y el reporting en general dentro de la empresa.

En un departmanto de sistemas/informática donde el resto de departamentos funcionales de la empresa pueden realizar solicitudes (o imposiciones en función de quien lo pida) sobre informes y consultas, la gestión de dichas solicitudes puede convertirse en el verdadero cuello de botella que colapse el departamento. Las responsabilidades del departamento de informática o sistemas pueden ser muchas, pero la que considero más inutil de todas es la de mantener módulos de informes que ni la propia persona que lo solicitó se acuerda de su criterio o funcionalidad pasados 3 meses.

Se suele dar la situación, sobre todo cuando se trata de justificarse, de solictiar informes enrevesados que ni el mismo solicitante tiene claro su utilidad o incluso, si te descuidas, no tiene claro ni lo que quiere (en el fondo creo que sólo buscan dos cosas: maquillar la situación o adivinar el futuro). De hecho en muchos casos la demanda de un determinado informe es sólo un pretexto para aplazar una determinada actuación, decisión o simplemente ganar tiempo. Además, como el departamento de sistemas siempre está ocupado, la probabilidad de conseguir un plazo más que aceptable para desviar la atención real sobre el problema es tan alta, que justifica el inventarse cualquier tipo de informe. Amén de los informes que he venido en llamar “informes nómina” que básicamente tienen el objetivo de sustituir todo el trabajo que una persona realiza.

Entiendo que el caso de las empresas que se dediquen al desarrollo de software y que cobren por módulos, puntos funcionales o incluso horas, les interesa realizar cuantos más módulos mejor. Pero si hablamos de aportar valor al cliente o de priorizar las necesidades reales de un cliente, es entonces cuando tenemos que agudizar el ingenio y pensar en algo que desbloquee la situación. Este es el contexto en el que se mueven los equipos de desarrollo internos de la empresa y hacia este segmento está destinado este post.

A modo de ejemplo puedo decir que he visto sistemas en los que hay más de 100 informes. De esos 100 sólo se utilizan habitualmente unos 10. Otros 10 o 20 se utilizan cada mes, pero el resto tiene caracter anual, singular o “indeterminado”. Además en estos otros 70 informes de utilización reducida, el usuario cuando los va a utilizar, ni se acuerda de donde están, ni para que sirven o cosas peores. Normalmente la conversación que se mantiene con él va más orientada a que el desarrollador sepa donde, como y para qué funcionan los 100 informes. Ante tal imposibilidad, algunas debidas a la propia limitación humana, puede que dicha solicitud se traduzca en que se hace de nuevo el informe con caracter de urgencia. En resumidas cuentas, toda una pérdida de tiempo y productividad (tan necesaria en estos tiempos de crisis).

Cansado de llegar a estas situacioens absurdas que generaban desánimo en mis compañeros, problemas con los usuarios y una mayor frustración por no poder dar servicio a las demandas, comencé el estudio de herramientas de reporting. Normalmente utilizábamos herramientas de reporting tipo active reports y crystal reports, origen de todos los problemas. Pensamos en hacer el módulo de reporting por nuestra cuenta (qué osados somos a veces), estudiamos la utilización de soluciones de BI como Pentaho o similares, etc. Sin embargo, una de las soluciones que se mostró más útil para el conjunto de usuarios fue la de generar los informes en Excel. De hecho había usuarios que dedicaban horas a copiar y pegar los datos de los informes de active reports a hojas excel (algunos incluso los imprimían y luego lo transcribían a Excel … demencial).

Durante un tiempo llegamos a utilizar componentes que permitían la consulta de datos multidimensionales como DynamicCube. En concreto ésta herramienta se mostro muy util para comenzar con el analisis multidimensional de los datos y nos marcó el camino a seguir para encontrar la solución a nuestras necesidades. Por aquel entonces conocí a dos compañeros (Juan y Francisco) que nos enseñaron la utilización de lo que en Excel se conoce como “Informes dinámicos” que no dejaban de ser una versión de Microsoft, más limitada, del componente que habíamos utlizado (DynamicCube). Tenían la gran ventaja de poder conectarse directamente a la fuente de datos ODBC, lo que la convertía en toda una herramienta genérica de reporting. Además no sé que tiene Excel que pone de acuerdo a todos los usuarios. Lo que sí tiene Excel es que aparece en los CV de todo el mundo, por lo que además tiene la ventaja de que no tienes que hacer manuales o ayudas para nadie (como diría Diego, “en teoría”).

Llegados a este punto conseguimos no volver a generar ningún informe más. Nos centramos en conocer perfectamente el modelo de tablas de la base de datos y a realizar consultas que abarcaban de un sólo golpe más de 10 informes, o más, de los de antes. Realmente lo que habíamos conseguido era pasarle al usuario toda la información que necesitaba y él, mediante el uso de Excel y las tablas dinámicas, se construía los informes que necesitaba. Tuvimos usuarios que se resistieron un poco, pero respondía más a carencias en la formación del uso de Excel que a la propia funcionalidad del sistema. La verdad es que con las tablas dinámicas se puede hacer casi de todo.

A nivel técnico lo que hacíamos era desarrollar las 10-20 consultas SQL que permiten gestionar prácticamente toda la información de la empresa, incrustarlas en sus respectivos ficheros Excel dentro de tablas dinámicas y ceder estos ficheros a los usuarios en una zona común. Tuvimos trabajo, como en toda implantación, pero el usuario se sentía atendido en sus necesidades. Él era quien tenía la pelota en su tejado, él se enfrentaba a la información y debía confeccionar los informes necesarios. Esto provocó la aparición de usuarios expertos y usuarios novatos, pero este ecosistema se automantenía sólo, curiosamente, con lo que el departamento de desarrollo podía centrarse en cuestiones que aportasen mayor valor.

Este planteamiento que parece no tener defectos, tenía uno y muy gordo. Los ficheros Excel, que tenían incrustados las consultas eran utilizados por todos los usuarios y estos hacían copias locales de los mismos, con sus propias configuraciones, filtros, etc. Si por cualquier causa, y eso sucedía y sucede a menudo, se necesitaba ampliar alguna consulta, mejorarla o corregirla, la labor era imposible de orquestar. Existían infinitos archivos dispersados por todos los equipos de todos los usuarios (era como volver a Panda y enfrentarme a un nuevo tipo de virus que esta vez, había ayudado a concebir).

Además teníamos la problemática de que ciertos usuarios avanzados creaban sus consultas SQL, sin conocer en detalle el modelo de información, índices y demás, y se lanzaban a la aventura. Consecuencia, bloqueos continuos en BD. Habíamos ahorrado tiempo en generación de informes que ahora lo gastábamos en perseguir usuarios que, además, “lo hacían por no molestarnos”. La paradoja del informático, todos te ayudan dandote más trabajo inútil.

Llegados a este punto, adoptamos una solución que a mi entender es muy potente, segura y que evita en muchos de los casos tener que invertir en herramientas BI que tienen un alto coste de implantación. La solución considero que es muy buena sobre todo por que está basada en más de 4 años de evolución intentando dar solución a toda la problemática anteriormente descrita.

Como me está saliendo un post un poco denso, en el siguiente comentaré en qué consiste esta solución y cómo nos ha ayudado a todos, usuarios, desarrolladores y administradores. Espero que sea interesante.

Retomando Entity Framerork 1.0 (II): Problema de rendimiento

Recientemente he intentado retomar el estudio de Entity Framework. Soy un firme convencido de EF pero la verdad es que se me resiste por muy diversas causas. La primera fue problema de adoptar la beta 3, “error” mío aunque creo que eso nos ha colocado en una situación de ventaja en temas de desarrollo para plataforma .Net con respecto al futuro. El segundo y más reciente tiene que ver con un problema que aparenta tener EF a la hora de cargar entidades maestras y sus respectivas entidades de detalle cuando éstas son un número considerable (5.000 o más).

El primer ejemplo que realicé con EF fue la construcción de un modelo de dominio a partir de un esquema de base de datos. Funciono bastante bien y eso me animó bastante a seguir. Vengo de utilizar NHibernate como mecanismo de persistencia con la combinación de un framework propio, IRDM, basado en la tesis de Raúl Izquierdo que podéis ver aquí. En otro post contaré como desarrollamos esta plataforma que considero, bajo mi humilde punto de vista, merece la pena resaltar y que explica el por qué de mi convencimiento respecto de que EF debe triunfar (si MS hace las cosas bien, claro está).

Cuando comencé con NHibernate seguí la misma secuencia de aprendizaje que intento seguir con EF. Primero estudiar la plataforma, después construir mi primer modelo de dominio, después realizar la carga de una entidad maestra y finalmente realizar la carga de las entidades relacionadas (o de detalle). A partir de aquí el aprendizaje va más suelto (inserciones, borrados, actualizaciones, herencias …)

Pues bien, en cuanto he llegado a la fase de carga de las entidades de detalle y dado que tenía una aplicación finalizada que ya funciona con NHibernate, he intentado cargar datos reales con EF. La aplicación que tengo desarrollada con NHibernate+IRDM tiene una entidad de detalle con unos 90.000 registros donde cada registro representa una medición de una variable para la aplicación de un control estadístico de procesos (SPC). Esta entidad de detalle tiene unas cuantas entidades “maestras” con las que se relaciona. Entre ellas está la entidad “TipoVariable” que la clasifica. De momento sólo tenemos 3 típos de variables, aunque esto puede aumentarse a medida que implantemos el SPC en más procesos, por lo que de media le corresponden unos 30.000 registros de detalle por registro maestro (explico esto para situarlo en un contexto real de utilización).

La complejidad del código es nula, como se puede ver a continucación:

using (var context = new OCMEntities()) {
var ocmTypeList = (from ocmTypes in context.OCMType.Include(“OCMInstance”) select ocmTypes).ToList();
foreach (var ocmType in ocmTypeList) {
Console.WriteLine(“Id={0}, Instance Number={1}”, ocmType.Id, ocmType.OCMInstance.Count);
}
}

Este código tarda 5 minutos de reloj en ejecutarse. A todas vistas inaceptable para cualquier aplicación “decente”. Con NHibernate+IRDM tardaba cuestión de milisegundos. Convencido de que el error sería mío, revisé la consulta que EF lanzaba a la base de datos haciendo uso de un profiler de SQL. La consulta no tenía el problema. Observé que el consumo de CPU lo llevaba únicamente la materialización de un modelo. En ese momento se lo comenté a mi compañero Diego el cual se interesó por el problema y ha investigado y dedicado el tiempo que yo no le he podido dedicar (gracias Diego).

Para facilitar en la reproducción del problema, instalé la base de datos AdventureWorks disponible en codeplex. Para ello lo que hice fue asignar todos los pedidos de ventas a un único cliente mediante un script sql (es artificial, pero sólo quería reproducir el problema). A contiuación hice el siguiente código:

using (var context = new AdventureWorksEntities()) {
var customerList = (from customers in context.Customer.Include(“SalesOrderHeader”) select customers).ToList();
foreach (var customer in customerList) {
Console.WriteLine(“Id={0}, Date={1}, Order lines number={2}”, customer.CustomerID, customer.CustomerType, customer.SalesOrderHeader.Count);
}
}

Con esto conseguí que todo el mundo pudiese reproducirlo con facilidad.

Diego lanzó una consulta al equipo de EF y reconocieron algún tipo de problema aunque les chocaba la situación (como a nosotros). Nos dieron algunas soluciones, como se comenta en el post de Diego, pero la verdad es que no son muy aplicables a las necesidades de la aplicación de SPC. La última solución ha sido la siguiente:

context.SalesOrderHeader.MergeOption = System.Data.Objects.MergeOption.NoTracking;
var customerList = (from customers in context.Customer select customers).ToList();
foreach (var customer in customerList) {
if (customer.SalesOrderHeader.IsLoaded)
customer.SalesOrderHeader.Load();
Console.WriteLine(“Id={0}, CustomerType={1}, Sales Order Number={2}”, customer.CustomerID, customer.CustomerType, customer.SalesOrderHeader.Count);
}

Facilita la labor, ensucia un poco el código, pero te obliga a atachear posteriormente las entidades para poder operar con ellas. No es la solución adecuada, desde luego, pero es mejor que las otras.

Nos comentan que lo revisarán y nos dirán algo (espero que no lo retrasen a la versión 2.0, por favor) lo cual espero ansioso. No obstante debo decir que de confirmarse éste problema, EF aún está “verde” para afrontar el desarrollo de aplicaciones en el entorno empresarial. Aún así seguiré probando el resto de funcionalidades de EF como el modelado de la herencia, los inserts, deletes y updates, así como otras cuestiones más complejas que con NHibernate nos surgireron: acoplamiento de modelos de dominios desconectados procedentes de capas cliente, CRUDs para entidades involucradas en herencias, combinación de entidades equivalentes pero pertenecientes a EDMX distintos, etc.

Error invocando objetos COM desarrollados en .Net desde Excel

Recientemente hemos tenido que migrar toda una batería de aplicaciones de unos servidores físicos a otros virtuales. Estamos en pleno proceso de virtualización y consolidación y todo parece ir bien salvo por pequeños problemas imprevistos de distinta naturaleza.

Uno de estos problemas ha aparecido con la utilización de una librería desarrollada en C# bajo el Framework 2.0. Se invoca a un objeto COM desde el código VBA para acceder a un servicio intermedio de acceso a datos que básicamente lo que hace es servir recordset serializados. Estos recorset pueden tener un tamaño de varios MB por lo que la utilización inicial de MS SOAP Toolkit tuvo que ser descartada. Escribiré un post sobre cómo hemos afrontado la utilización de tablas dinámicas y la elaboración de informes complejos sin recurrir a potentes paquetes de Business Intelligence (el componente que ha provocado este post es parte de la infraestrucutra utilizada).

El código VBA instanciaba el objeto mediante la función CreateObject. Para que esto funcionase la dll debía de ser registrada con el comando RegAsm y posteriormente subida a la GAC con el comando GACUtil. Hasta aquí todo correcto. El problema surgió cuando pasamos a ejecutar el código VBA y nos indicaba que el objeto no se podía encontrar. En los servidores antiguos esto funcionaba sin problemas.

Teniendo experiencia en este tipo de cuestiones, probamos a poner la dll en el directorio donde residía el ejecutable de Excel. Una vez puesto allí, desregistramos la dll, la sacamos de la GAC (haciendo uso de los mismos comandos anteriores) y procedimos a realizar la prueba. En este caso el error dado fue que no reconocía el formato del assembly (HRESULT -2146234105). Buscando en google parecía indicar que el problema estaba en que Excel utilizaba la versión 1.1 del framework. Intentamos forzar a utilizar la versión 2 del framework mediante un fichero Excel.config.exe (en un intento desesperado, la verdad) y nada funcionó.

Finalmente el problema lo solucionamos gracias a este sitio en el que se indica que para solventar el mismo problema se tiene que instalar las Visual Studio Tools For Office. Lo hicimos y todo pasó a funcionar como la seda. Gracias a René e Iván por haberme ayudado con el problema y espero que por lo menos sirva para que David tenga un mejor regreso de vacaciones. Estoy convencido de que no se había enfrentado a esto cuando desplegó la criatura

Recomenzando con el Entity Framework

He dirigido dos proyectos pequeños en los que se ha utilizado Entity Framework (EF) beta 3. No voy a contar en este post cuales han sido los problemas y la desesperación que EF nos ha provocado, pero la verdad es que hemos tenido que cambiar toda la arquitectura de la aplicación debido a problemas como la serialización de grafos.

Hasta la fecha, abordar el desarrollo de una aplicación con EF era como mínimo, una actividad de riesgo. Yo tenía experiencia en este tipo de “actividades de riesgo” ya que cuando adoptamos NHibernate ésta se encontraba en su versión 0.9. A fecha de hoy NHibernate está muy por encima, en mi opinión, de EF pero es sólo cuestión de tiempo que esto cambie drásticamente para entornos Microsoft. La cuestión es que ya ha sido liberada la versión 1 de EF a través del SP1 de Visual Studio y voy a replantearme el desarrollo de proyectos con EF.

La primera acción que he tomado, asumiendo que la versión 1 tiene todo lo necesario para echar a andar una aplicacíon multicapa, es seguir los mismos pasos que seguí con NHibernate. Una vez entendida la arquitectura y su filosofía, he pasado a estudiar la sintaxis de los ficheros EDMX (csdl, ssdl, msl). Para ayudar en esta labor el siguiente documento Entity Framework Mapping es muy útil. Trata los tipos de mapeo más habituales entre el mundo de objetos y el mundo relacional. Aborda con más detalle el modelado de la herencia, lo cual se agradece para alguien que viene del mundo NHibernate.

Mi primer objetivo es poder realizar un modelo de información de la base de datos de producción que tenemos en la empresa donde trabajo. Para ello es fundamental poder modificar el fichero edmx manualmente y adaptarse a la falta de relaciones explícitas entre las distintas tablas, falta de claves primarias y demás lindezas.

Otro sitio muy interesante para comenzar con EF y donde he podido ver un Profiler para Sql Express Open Source es este. Con el profiler que aquí mencionan, que funciona sobre Sql Server Express, se puede ver fácilmente las consultas T-SQL que EF genera. Algo muy útil cuando tienes algun problema de eficiencia en el uso de EF (al principio es lo habitual, lo puedo garantizar)

Iré informando de cómo va el proceso.

SQL Server 2000 y el espacio libre asociado a las tablas

Con motivo de la realización de tareas de mantenimiento de sistemas en la empresa en la que trabajo, me encargué de llevar a cabo un estudio sobre el estado de la base de datos. Debido a distintas razones estamos obligados a utilizar la SQL Server 2000 como base de datos de producción (estamos en fase de migración a SQL Server 2005-2008 pero los DTS que tenemos creados nos dificultan tremendamente esta labor).

Una de las herramientas que utilicé para llevar a cabo el estudio de ocupación y aprovechamiento de disco fue la ejecución diaria de la función sp_spaceused sobre todas las tablas de la base de datos de producción. El resultado de estas ejecuciones lo dejaba en una tabla en la que, además de los campos que proporciona la función sp_spaceused, tenía un campo fecha a modo de snapshot del estado de ocupación de las tablas. Después desde excel elaboré una tabla dinámica que, entre otras cosas, me daba la tasa de crecimiento de cada tabla, el porcentaje ocupado por cada tabla con respecto al total de la base de datos, la tasa de ocupación de los índices y la tasa de ocupación del espacio asignado a la tabla. Estos indicadores me permitieron, con ayuda del formato condicional de Excel y la ordenación de las tablas dinámicas, localizar las tablas e índices donde centralizar todos nuestros esfuerzos de optimización de la base de datos. La herramienta es muy poderosa en este sentido.

El equipo de sistemas al que pertenezco interpretó los datos que en la hoja Excel salían convirtiendolo en conocimiento y en un plan de actuación para las siguientes optimizaciones. Todo parecía maravilloso y todos teníamos claro como actuar. El problema fué que SQL Server actualiza los datos de ocupación de las tablas acorde a una política que nosotros no teníamos implementada (desde hace más de 4 años, imperdonable).

Resumiendo, después de investigar como reclamar el espacio libre asociado a cada una de las tablas en sitios como aquí, seguir los pasos, y comprobar que nada surtía efecto encontré que en 2005 no es necesario pero en 2000 si, ejecutar el siguiente comando:

DBCC UPDATEUSAGE (0)

Este comando actualizó todos los indicadores que la función  sp_spaceused proporciona y resultó ser que SQL Server 2000 sí que aprovecha muy bien el espacio libre asociado a las tablas (no así la actualización de los indicadores de ocupación) y que ciertas acciones que llevarón considerable tiempo como regenerar el índice clusterizado de la tabla o trasladar la tabla a otro sistema de archivos distintos de primary, no sirvieron para mucho. Aprendimos mucho de comandos como DBCC CLEANTABLE, etc., pero nos desvió de nuestro objetivo en la parada.

Menos mal que nos dimos cuenta de esto ya que habíamos realizado un shrink de toda la base de datos con la esperanza de recuperar todo el espacio que la función sp_spaceused nos indicaba y habíamos dejado a la base de datos sin espacio real (que no figurado) libre. Esto se hubiese traducido en que el primer día de arranque de los sistemas, en cuanto el primer compañero hubiese insertado un pedido, SQL Server habría identificado que no tenía espacio para la inserción, hubiese hecho un ampliación de los ficheros de BD y problema generado. Tenemos una base de datos de 100 GB que ante cada ampliación de espacio en disco tarda del orden de 1 hora (esto no sucede en la SQL 2005) lo cual equivale a parada de fábrica (inadmisible)

Necesitamos cuanto antes migrar a SQL Server 2005 donde todos estos problemas están solucionados, pero de momento aquí queda explicado el problema y espero que le sirva a alguien para no tropezar con la misma piedra.

La socialización de las tecnologías de la información en la empresa

Actualmente trabajo como director de sistemas de información en una empresa de fabricación. Hasta no hace mucho, estimo que motivado por la situación de bonanza de la economía y el consumo en general, las funciones principales de mi trabajo giraban en torno al desarrollo de proyectos software, análisis, diseño e implantación de la arquitectura de servicios y servidores TIC así como su mantenimiento. Esto, que parece lo “normal” para un departamento de sistemas o informática, se está viendo modificado por la necesidad de dar respuesta a la situación actual (de cambio).

En el caso de una empresa esto se debería traducir en que toda acción o proyecto que se realice tiene que tener su impacto positivo en el valor que el cliente recibe. Esto puede ir desde que el cliente consiga vender más y/o mejor con herramientas de gestión o acciones de marketing, hasta que el cliente reduzca los costes derivados de su actividad gracias a la mejora en los productos o procesos que realiza. En definitiva y como recientemente me sintetizaron en un curso sobre dirección, debemos hacer que trabajar con nosotros sea “fácil y divertido”.

Para conseguir estos objetivos los perfiles “técnicos”, entre los que se incluye todo el departamento de sistemas de cualquier empresa, tienen serias barreras para desarrollar su labor. Estas barreras son variadas en naturaleza y solución (de todos es conocido la inercia que tenemos los técnicos en converger hacia la “ultima tecnología”). Esto que hasta ahora se ha interpretado en muchos casos como el interés personal del técnico por mejorar su CV, está dando un giro de 180 grados.

La sociedad actual está en pleno y continuo proceso de transformación. Tecnologías como el blogging, google, twitter, youtube, rss, redes sociales, p2p … en definitiva lo que se viene llamando la Web 2.0 ha cambiado la forma en la que la gente se relaciona, accede y comparte la información. Cómo aplicar todo esto en el mundo de la empresa no sólo se enfrenta con retos técnicos o de conocimiento de la propia tecnología sino que además debe afrontar cómo se lleva a cabo el proceso de socialización de las mismas dentro de la empresa.

Si la empresa estuviese formada únicamente por gente joven este proceso se vería acelerado, pero esa no es la realidad (afortunadamente). La realidad es que no sólo tienes que identificar, por ejemplo, que youtube puede ser utilizado como un canal propio de televisión con una audiencia potencial equivalente a todo internet, si no que tienes que explicar y vender la idoneidad de la tecnología a un foro de personas que vivió durante mucho tiempo con un único canal de televisión, o que piensa que escribir un blog es más un acto de exhibicion que un acto de generación de contenido y conocimiento a la par que proyectas sobre la red una forma de ver y entender un área, producto o tecnología.

Me gustaría poder contar como afrontar este proceso de socialización de las TIC de una manera perfecta. Ni que decir tiene que si existe esa manera no soy consciente ella. Todas las técnicas y métodos para la gestión del cambio son aplicables en este contexto. La forma de afrontarlo, desde mi punto de vista, debe ser poco a poco, permitiendo que la organización interiorice los cambios. Sin embargo nunca debe perderse el ritmo ya que el dinamismo existente en la sociedad actual es vertiginoso. Creo que explicar la utilidad de una herramienta como twitter puede resultar “duro” en primera instancia (pese a que los políticos actuales han comenzado a utilizarlas en sus campañas y con gran éxito por cierto), pero con un pequeño esfuerzo por parte del receptor de la propuesta, pueden vislumbrarse múltiples aplicaciones. Sin embargo la generación de contenido de calidad, la transparencia e imagen que esto proyecta con su publicación en canales rss abiertos, el posicionamiento en buscadores y youtube, o la mera aparición en la Web corporativa, puede ser fácilmente defendible en un comité de dirección o equipo de marketing. Aún así, la figura del “gurú” que experimenta con las nuevas tecnologías y corrientes en Internet, quien pone en práctica a título personal la utilización de las mismas y quien comparte dichas experiencias con el resto de la organización, puede y debe existir.

¿Que pensáis sobre el cambio de roles que está existiendo en la empresa para los profesionales de las TIC? ¿Cual es el camino adecuado para afrontar esta “revolución” en la empresa? ¿Cómo crees que se puede socializar las TIC actuales en la empresa? ¿Has comenzado a aplicar la Web 2.0 en tu empresa?

Primera entrada, primera novatada

Pues eso, hoy he dado el paso definitivo en mi apuesta personal por la utilización de la bien llamada Web 2.0. Hasta la fecha he sido fiel “consumidor” de otros blogs, contenidos y demás información que se está compartiendo hoy en día.

En lo personal esto supone una apuesta por un modo de vida, de comunicación y sobre todo de relación con el resto del mundo. Muchas de las personas de mi entorno, tanto personal como profesional, están lejos de utilizar estas herramientas y formas de comunicación. Para mí supone un cambio en la inercia que mi entorno lleva, lo cual nunca esta exento de dudas, preguntas, incertidumbres … pero bueno, sólo es un blog.

Por otro lado me parece un pelín “vergonzoso” que, siendo un profesional de la informática, no predique con el ejemplo. Soy un firme convencido que la Web 2.0 tiene una perfecta adaptación al mundo empresarial. Por supuesto no es sólo ese nombre tan marketiniano (Web 2.0) lo que motiva su aplicabilidad. Más bien está relacionado de forma directa con la compartición de información y contenido con transparencia. Creo que estas son las claves, compartir y no mentir.

Lo dicho, espero poder aportar algo con mis historias, opiniones e intereses