archivo

Archivos Mensuales: septiembre 2009

Hace un tiempo, nos hicieron una presentación de una herramienta software.

La persona que nos hizo la presentación, la cual no conocía de antes, aunque tenía referencias de ella, demostró en la misma una brillantez que muy pocas veces había visto. Sin embargo lo que más me llamó la atención no fue eso, sino su honestidad. A una reflexión que hice sobre lo que yo esperaba de herramientas de las características de la que nos estaba presentando, me contestó que tenía razón y que lo realmente importante no era la herramienta en sí, siempre que esta alcanzase unos mínimos, sino las personas que la utilizaban.

Evidentemente ni en lo que yo dije, ni lo que él me respondió, se descubrió nada que no se supiera, lo importante es que no se escudó en el producto, pese a ser excelente, sino que contestó realmente lo que pensaba y lo apoyó con razonamientos.

Anuncios

Unos de los principales inconvenientes que tengo en el desempeño de mi trabajo (y debo ponerle remedio algún día) consiste en la gran variedad de tareas que realizo, que van desde tareas muy operativas hasta tareas que están muy por encima de mi puesto de jefe de proyectos.

El inconveniente no trata de que no me guste realizar esas tareas, antes al contrario, tanto las operativas como las de alto nivel me gustan muchísimo, cada una me aporta cosas, las primeras me permiten no perder el pulso del trabajo del día a día, de estar inmiscuido en los procesos, en el trato con los usuarios, con mis compañeros y las segundas intentar llevar a la práctica mis esquemas mentales de cómo deben hacerse determinadas cosas. El inconveniente es que en demasiadas ocasiones ambas cosas me restan tiempo para mi trabajo como jefe de proyectos y también en demasiadas ocasiones la proporción de tiempo que dedico a tareas de carácter operativo supera con creces a las tareas de nivel táctico y estratégico. Por este motivo necesariamente y ya lo llevo aplicando desde hace un tiempo, voy desligándome poco a poco de las tareas de carácter operativo, lo que repercute en una mayor disponibilidad de tiempo para las tareas de jefe de proyectos y aquellas otras tareas que me tienen encomendadas en mi departamento.

Un aspecto importante, los que hayáis leído mi artículo sobre los roles de las personas en las organizaciones, podréis ver una contradicción entre el contenido del mismo y lo que comento en este post y en el caso personal que acabo de comentar. Sobre esto comentar algunas cosas:

– Aunque es cierto que la realización de otro tipo de tareas me quitan tiempo, la parte fundamental y nuclear de las tareas que realizo están relacionadas con la dirección de proyectos informáticos, siendo para mi prioritario la realización de las mismas.

– Entre el negro y el blanco, hay toda una escala de colores. Asumir un rol no debe implicar falta de flexibilidad para realizar o asumir otras tareas de forma puntual o con una mayor persistencia en el tiempo, sino el ser consciente que el nuevo rol debe ser la porción más importante de la jornada laboral.

– La organización a la que pertenezco tiene muy poca flexibilidad, por lo que muchas de las tareas que realizo, las hago para cubrir huecos no cubiertos en procesos y apoyar la realización de determinadas tareas para los que no existen puestos de trabajo específicos en mi organización.

Cualquier propuesta de diseño o implementación de un Datamart o de un Datawarehouse termina chocando con el concepto de calidad del dato. De nada vale hacer una implementación modélica de los modelos de datos del Datamart o el desarrollo de unos procedimientos ETL que permitan extraer la información de diferentes sistemas o fuentes de información y coloquen los datos en el repositorio listos para ser explotados haciendo uso de las herramientas correspondientes, si al final el problema está en la base, en la información de partida, ya que si el objetivo final de todo Datamart es la explotación de la información con un determinado propósito, el resultado final estará contaminado si los datos de partida están contaminados.

Hace unos días en una reunión volvió a salir este tema, ¿se debe parar el desarrollo de Datamarts sin que los datos de partida estén del todo bien? Mi respuesta a esto es que si el desarrollo de Datamarts es un objetivo de la organización (como es en este caso), no debe parar la iniciativa el recurrente problema de la calidad del dato, ya que entre otras cosas, los Datamarts y las distintas alternativas existentes para explotar la información, tienen la ventaja de que permiten descubrir datos incompletos, inexistentes y erróneos, y además, el problema de la calidad del dato, es un tema que no se soluciona de manera sencilla y que generalmente se afronta como un proceso de mejora continua (en la mayoría de los casos bastante lento).

La calidad del dato está relacionada con la visión que tenga el usuario sobre la información que está grabando en el sistema, es decir, si considera que el sistema de información como un instrumento a corto plazo, en el que introduce unos datos y le proporciona unos servicios (y la calidad del dato no resulta fundamental para obtener el servicio), los datos por regla general no serán buenos, ya que el usuario no tiene conciencia de la utilidad que tiene que los datos estén más o menos completos o más o menos bien.

También existen otros factores, como la usabilidad del sistema de información (cuanto menos usable sea un sistema de información, peores serán los datos), la flexibilidad del sistema (este caso es un poco paradójico, ya que la flexibilidad de un sistema está intimamente ligada a su usabilidad), pero resulta que en un sistema muy flexible (sin apenas controles) se deja prácticamente la responsabilidad de lo que se graba en el usuario y por tanto en la visión que él tenga de la necesidad de grabar datos con calidad.

Otro factor muy importante es la visión corporativa que tenga la organización de la información, es decir, si en la organización no existe conciencia de que una información consistente, coherente y de calidad sobre una determinada temática, requiere de un repositorio de información de procedencia (aunque sea alimentado por distintas fuentes (distintos usuarios)) y que esos repositorios se alimentan a través de sistemas de información, será mucho más difícil que los datos que se graben tengan calidad, ya que la gestión se centra en cumplir con las tareas del día a día y no existen unas instrucciones generales o normativa interna, que por un lado obligue a utilizar los sistemas de información corporativos y por otro que haga que los datos que se introduzcan en ellos sean los más completos y exactos posibles.

Lo que más puede llamar la atención es el concepto de portabilidad, un ejemplo sencillo, en casa utilizo la distribución Linux Ubuntu, en el trabajo Windows, si quisiera instalar Microsoft Office en mi PC doméstico (suponiendo que tuviera la licencia oportuna) no podría (quitando otras posibles soluciones como tener un sistema operativo Windows como máquina virtual, Wine, etc…), este ejemplo es extensible a una gran cantidad de software que funciona en unos sistemas operativos y que en otros no (salvo que se rehaga completamente). La portabilidad se puede ver desde diferentes puntos de vista, portabilidad a nivel de código fuente, es decir, tener una aplicación que sin tocar el código fuente pueda funcionar en diferentes sistemas operativos mediante su compilación en los mismos, portabilidad a nivel de ejecutable o de software interpretable, la están proporcionando las soluciones basadas en máquinas virtuales, como por ejemplo Java, Mono, etc…, portabilidad de datos, etc… La portabilidad es, a mi juicio, una de las causas que está afectando al impulso definitivo de Linux, ya que la cantidad de software disponible en Windows y Mac (sobre todo en el primero y sobre todo a nivel de diferentes opciones a elegir) es sensiblemente superior. No obstante, la orientación del uso de aplicaciones en la nube y la aparición de cada vez más software en Linux, puede romper esa tendencia.

La portabilidad de la información no es un concepto que debamos dejar de lado, ya publiqué hace un tiempo un artículo que lleva el mismo nombre que el documental que me inspiró el mismo “La oscura era digital”. Es muy importante, si queremos que la información persista en el tiempo que el formato lógico en que se almacena se base en un estándar abierto, de lo contrario si queremos persistir la información, necesitaremos tener una copia del programa que lo interpreta y si el sistema operativo en el que se ejecuta tampoco es abierto una copia de dicho sistema operativo y así sucesivamente hasta llegar al hardware más básico de la máquina en que se ejecuta el software.

En resumen, los sistemas abiertos surgieron como una necesidad, casi como un mecanismo de defensa ante una evolución de la industria de las TIC que no era coherente para sus organizaciones usuarias, esta necesidad cambió las reglas del mercado y propició una importante evolución en el mundo de la informática que no hubiera sido posible (o por lo menos hubiera sido mucho más lenta) de otra forma. La estandarización, las especificaciones abiertas, fueron la llave de todo.

En la actualidad, pese a que los sistemas abiertos es una filosofía aplicada de forma general en el mundo de las TICs, en la actualidad y en el futuro existirán muchos productos hardware y software de uso cotidiano que no tienen publicadas sus especificaciones. La tendencia estratégica de estos y otros fabricantes dependerá muy mucho de las reglas del juego que queremos los usuarios que existan.

Lo mismo que el software libre es libertad, los sistemas abiertos también son libertad, libertad de elegir productos hardware y software compatibles entre sí a través de especificaciones que son públicas y convertidas en estándar a través de los organismos correspondientes de estandarización (especificaciones que son controladas por un número reducido de empresas, no forman parte de un sistema abierto, ya que es el mismo problema que dió lugar a los sistemas abiertos, solo que ahora cada pastel se lo reparten entre unos cuantos).

La necesidad de la existencia de sistemas abiertos provocó, por ejemplo, que las administraciones públicas tomasen cartas en el asunto y establecieran normativa en lo que respecta a la contratación pública, evitándose salvo en circunstancias excepcionales la adquisición de sistemas basados en especificaciones cerradas.

Conceptos íntimamente relacionados con los sistemas abiertos son los de interoperabilidad, portabilidad y escalabilidad. La interoperabilidad es la posibilidad de que máquinas (y el software que funciona sobre ellas) de diferentes fabricantes puedan comunicarse entre sí. La portabilidad se refiere a la posibilidad de que un software pueda ejecutarse independientemente de la máquina en la que se ejecute (con las limitaciones de los requerimientos que necesite la aplicación para funcionar). La escalabilidad hace referencia a la posibilidad de adecuar la infraestructura hardware y software a unas necesidades específicas, pudiendo ampliar o reducir dicha infraestructura conforme sea necesario, con los productos que en cada momento se consideren convenientes.

La no existencia de sistemas abiertos provocaba, como es lógico, una incertidumbre muy grande en las organizaciones, ya que la adquisición de una solución hardware resultaba toda una apuesta, ya que suponían una inversión importante y estaban a merced del fabricante. Imaginemos la siguiente situación, una empresa contrata una infraestructura hardware que con el software adecuado permite almacenar las compras y ventas que realiza, la empresa está muy contenta con dicha infraestructura ya que soporta perfectamente los requerimientos que se necesitan, además también está contenta con el fabricante porque tiene un servicio de atención al cliente excelente. Sin embargo resulta que un buen día el fabricante decide que deja de dar soporte a dicha infraestructura ya que ha sacado dos o tres familias de equipamiento más avanzado y conviene promocionarlo. La empresa si quiere reducir riesgos (ya que si falla algún componente hardware no va a encontrar recambio) tendrá que realizar una inversión en una nueva infraestructura que sí se encuentre soportada por el fabricante.

Esto creaba de forma totalmente evidente una auténtica cautividad ante el proveedor, ya que la evolución de las infraestructuras informáticas de una organización estaban totalmente supeditadas a la estrategia comercial del proveedor. En el ejemplo que he puesto por lo menos existía la posibilidad de migrar a una versión superior, imaginemos que el fabricante hubiera declarado quiebra y cerrado la línea de producción, esto hubiera obligado en aquella época a cambiar de proveedor, a cambiar el software y a una costosa y compleja migración de datos.

Esta situación de poder de los fabricantes (que interesaba, como es lógico a aquellos a los que les iba bien) minaba absolutamente la competencia, la posibilidad de componer una infraestructura de servidores, comunicaciones y demás componentes hardware y aplicaciones con productos de diferentes proveedores, lo que permitiría reducir costes y conducir a una situación más lógica, en la que los departamentos TIC decidieran con mayor libertad cuál debía ser su estrategia.

El concepto de sistemas abiertos surgió como una respuesta al crecimiento desorganizado que tuvieron las TICs desde poco antes de la aparición de los ordenadores personarles, época en el que el coste de tener una infraestructura informática se redujo lo suficiente para que se popularizase su uso en el ámbito corporativo. Este concepto pese a que apareció a finales de la década de los setenta y principios de los ochenta y que propició una estabilidad en el sector en la década de los noventa y en la actual, es algo que sigue siempre de actualidad, ya que choca contra los intereses de determinadas compañías del sector.

¿Cuál fue la causa que dió origen a los sistemas abiertos? Pues la existencia de múltiples soluciones hardware y de software cada una de las cuales era incompatible con las demás. Por ejemplo, si una empresa disponía de un software de contabilidad que le resultaba óptimo para su gestión, además de tener almacenada la información de mucho tiempo y sin embargo el equipamiento físico que daba soporte a ese software empezaba a quedarse obsoleto (o se estropeaba), si quería seguir utilizando ese software, tenía que comprarse un hardware compatible con el anterior que sería de la misma marca, aunque existiesen soluciones en el mercado más competitivas en cuanto a funciones y/o precio. Otro ejemplo podría ser al revés, es decir, la empresa utiliza un software de contabilidad que no se ajustaba a las necesidades de la empresa, pero había hecho una inversión importante en infraestructuras y equipos informáticos que todavía estaba lejos de amortizarse y resulta que tras un estudio descubren que la mejor solución la proporciona otro software que es incompatible con la infraestructura hardware instalada.

Esta situación que hoy en día puede resultar un tanto chocante (no tanto si nos ponemos a pensar en ejemplos que suceden hoy día), era el día a día con el que tenían que enfrentarse las organizaciones en aquella época y no solo eso, ya que me he centrado en dos ejemplos muy concretos, cuando podía contar muchísimos más.