archivo

Archivo de la etiqueta: sistemas de información

Manny Lehman se hizo muy conocido por haber formulado las 8 leyes de evolución del software, las cuales se fundamentaron en el estudio que realizó en IBM junto a Laszlo Belady basado en la evolución de los sistemas operativos OS/360 y OS/370.

Dentro de ese estudio, realizado en 1974, me parece muy interesante la clasificación que realizaron de los sistemas de información:

– S-type (Static type): Son aquellos que pueden especificarse formalmente. Por ejemplo, sistemas que devuelven resultados en base a fórmulas ya definidas (una calculadora).

– P-type (Practical type): Son aquellos que pese a que pueden especificarse formalmente, su solución no es ni aparente, ni inmediata, lo que provoca que sea necesario un proceso iterativo para encontrar una solución válida. Se sabe, por tanto, el resultado que se necesita (o el esperado), pero no se sabe describir cómo llegar a él.

La característica principal de esos dos tipos de sistemas es la estabilidad de sus requisitos o especificaciones (una vez encontrada la solución adecuada en el P-type).

– E-type (Embedded type): Son aquellos que tratan de modelar procesos del mundo real y como consecuencia de su uso forman parte del mundo que tratan de modelar, dando lugar a una situación en la que el sistema y su entorno evolucionan de manera conjunta. Este tipo de sistemas son los más comunes hoy día.

Las leyes de evolución del software están basadas en los sistemas de tipo E, en el sentido de que al ser dependientes del contexto, están siempre en continua evolución.

En 1974, Lehman, considera ya el cambio como algo inherente a determinados tipos de sistemas de información y como algo que resulta necesario para mantener el equilibrio con su contexto (su entorno).

Si una organización tiene decenas (o centenas) de aplicaciones o sistemas de información es un mal síntoma. Como es lógico se trata de solo un indicio, hay organizaciones y organizaciones y necesidades y necesidades, sin embargo incluso en situaciones donde podría justificarse algo así habría que pensarse muy seriamente en reducir el censo de sistemas de información, ya sea haciendo un esfuerzo por erradicar ciudades fantasma o por unificarlos.

Cuando nos encontramos en esta situación nos encontramos con un parque de aplicaciones fragmentado tecnológicamente y que requerirán distintas versiones de muchas cosas para funcionar y cuyo mantenimiento requerirá en muchos casos una cierta especialización (a esto se llega después de muchos años y en los sistemas, como si de un corte en el terreno se tratara, se ve reflejada la evolución “geológica” que ha tenido la organización).

A esta situación se llega porque lo fácil es asociar, salvo que sea algo evidente, necesidades a nuevos sistemas, en lugar de hacer un estudio previo que determine si tal vez lo mejor es evolucionar uno ya existente para recoger estas necesidades.

Como ese estudio no se hace, nos encontramos con un segundo problema, un parque de aplicaciones fragmentado a nivel de dato, gestionándose dominios comunes de datos como si fueran independientes y existiendo, en consecuencia, una falta total de coherencia entre los mismos como consecuencia de eso y en muchos casos (la mayoría) con serias dificultades de poder relacionar una misma entidad con otra en caso de que se vaya a abordar en un futuro la integración de los sistemas a nivel de datos.

El sobrepeso también afecta a las aplicaciones. La mayoría de ellas son como el mando a distancia de una televisión, un montón de botones de los que solo usas un 20 o un 30%.

El sobrepeso es dañino en varios sentidos: el esfuerzo de haber desarrollado funcionalidades que no se utilizan o que tienen un uso residual, no haber invertido ese esfuerzo extra en depurar y mejorar las funcionalidades que sí resultan esenciales, la deuda técnica que se arrastra con ese código adicional y el impacto en la experiencia de usuario.

Cuesta luchar contra el origen del sobrepeso: la creación de necesidades inexistentes por parte de proveedores de software, la creatividad de los desarrolladores (y de algunos usuarios), la creencia errónea de que el software resuelve problemas organizaciones (y por tanto asumen funcionalidades que pretenden conseguir ese orden o esa forma de funcionar), etc…

Los sistemas con muchas restricciones son una fuente continua de problemas sobre todo en aquellos casos donde los procesos están llenos de excepciones dando lugar a aplicaciones excesivamente rígidas e incómodas de utilizar que afectan a la experiencia y productividad del usuario y que al final provocan en términos de calidad del dato el efecto contrario al que se pretende.

Por muchas restricciones que se pongan, la calidad del dato dependerá en última instancia del usuario, por ese motivo es exigible a los mismos un nivel de responsabilidad en el uso de los sistemas.

Sobre esto, hay una cita de Linus Torvalds que me parece muy apropiada para describir esta problemática: “Si piensas que tus usuarios son idiotas, solo los idiotas lo utilizarán”.

Hace poco iba en un tren y en el grupo de asientos de al lado una persona se quejaba de algo que llevo escuchando mucho tiempo. Resulta que en su empresa se había introducido un sistema de gestión centralizado que había sustituido a la forma tradicional de hacer las tareas mediante el uso de herramientas ofimáticas y claro, ya no había tanta libertad sobre cómo hacer las cosas y se quejaba de que de esta forma el trabajo iba más lento.

Si esto lo hubiera escuchado en el ámbito de mi organización o en otra similar no me hubiera extrañado lo más mínimo, de hecho ya he escrito sobre ello algún que otro artículo, sin embargo sí que me pareció curioso (aunque no por ello menos lógico) que alguien de otro continente pensase lo mismo que los usuarios de mi organización y es que como no podía ser de otra manera la mayor parte de las problemáticas y quejas de los usuarios no tienen fronteras. La ventaja que esto tiene es que la experiencia y buenas prácticas llevadas a cabo en un sitio pueden servir para otro, evidentemente habrá que matizar y realizar adaptaciones específicas, pero la base podría ser perfectamente válida.

Cuando se pone una aplicación en producción, no tiene acogida entre el grupo de usuarios y tampoco cuenta con el apoyo de la dirección, existen dos opciones principalmente, dejar que desaparezca por inanición o intentar que el producto se utilice.

Partiendo de la base de que la aplicación es para los usuarios y no para el departamento de informática (en el caso de que no sea una aplicación de uso interno), no tendríamos ningún tipo de obligación de promocionar el uso de la herramienta pero lo que pasa normalmente es que cuando participamos en un desarrollo lo sentimos como algo nuestro y por eso nos causa un cierto grado de satisfacción que el resultado de nuestro trabajo pueda ser útil a los demás.

Existen muchas causas por las cuales una aplicación no tiene buena acogida entre el grupo de usuarios, una de las principales suele ser un cambio en la forma de trabajar pero otra (totalmente compatible con la anterior) suele ser que el producto tiene muchos fallos o que no cumple las expectativas creadas.

Si un producto tiene muchas incidencias, se ha puesto en producción y no hay posibilidad de marcha atrás nos encontraremos con una situación que va a durar bastante en el tiempo, sobre todo si el sistema tiene una cierta entidad, por lo que vamos a tener los usuarios descontentos un largo período y muchos de ellos tendrán la tentación de abandonar el uso de la herramienta.

Ante esto podemos optar por consolidar el producto, es decir, dedicar los esfuerzos a la corrección de las incidencias o bien compaginar lo anterior con la inclusión de ampliaciones funcionales, cargas de datos, documentación, etc… que pueda hacer el sistema más atractivo y útil. La verdad es que la disyuntiva es complicada y habría que estudiar cada caso en particular antes de optar por una estrategia u otra. Yo he sido mucho de optar por estrategias orientadas a hacer la aplicación más útil, incluso dedicando un mayor esfuerzo o equivalente que la consolidación del producto, a día de hoy pienso que es mucho mejor dedicar más atención a consolidar el sistema que a incluir ampliaciones funcionales antes de tener una cierta base sólida ya que conforme se vayan reduciendo el número de fallos, se reducirá la presión y se tendrá el camino más despejado para ir incluyendo novedades poco a poco.

A lo largo de mi todavía corta experiencia profesional he tenido la oportunidad de vivir diversas migraciones, algunas de mayor y otras de menor calado. Entre las migraciones importantes destaco tres, por el impacto que tenían sobre el conjunto de sistemas de información de la casa, la migración de Oracle 8 a 9i, la migración de Oracle 9i a 10g y la subida de versión del sistema de autenticación y firma electrónica que utiliza mi organización.

De estas tres (y en general de todas las demás) puedo extraer las siguientes conclusiones:

1) La migración no es algo que se realiza en un día o en varios, sino que de por sí es un proyecto, por lo que debe tener una planificación, uno o varios responsables y un equipo que participe en ella.

2) Las migraciones afectan a varios departamentos dentro de informática, por lo que la comunicación entre todas las partes resulta esencial, así como la existencia de más de una persona que tenga una visión completa y general sobre lo que se está haciendo.

3) Las migraciones deben haberse simulado previamente en otros entornos y verificar el correcto funcionamiento de los sistemas de información en los mismos, es decir, previamente se deberán haber modificado todos aquellos sistemas de información que requieran un mantenimiento adaptativo al nuevo entorno y comprobar que tanto estos, como aquellos que no requieran cambio funcionan de manera adecuada. Todas las pruebas y modificaciones que se realicen sobre los sistemas deben estar perfectamente documentados.

4) Estos otros entornos deben ser idénticos al entorno de producción. Cuanto menos parecidos sean, más problemas nos encontraremos el día de la migración. La realización de la migración en estos entornos debe documentarse de manera detallada, destancándose todos aquellos problemas que se produjeron en el proceso de migración (ya que podrían aparecer el día de la migración).

5) Durante todo el proyecto de la migración es muy recomendable contar con el soporte de empresas expertas en los productos que se migran. Si ya es importante el soporte a lo largo del proyecto, es esencial que mientras se realice la migración, éste se encuentre presencialmente en la oficina en la que se realice la migración. Además de estos expertos, es importante contar con soporte sobre los sistemas de información más críticos afectados por la migración, valorándose si basta con que estén localizables o si es necesaria su asistencia presencial.

6) El proyecto de migración puede ser un proyecto de muy larga duración y eso es importante tenerlo presente, para evitar en precipitaciones que podrían dar lugar probablemente al fracaso de sucesivas intentonas de migración. Por tanto, sólo es recomendable migrar cuando se tenga muy clara la posibilidad de éxito de la misma.

7) Antes de realizar la migración, hay que tener claro que sistemas de información se van a ver afectados por la misma y por tanto no estarán disponibles una vez realizada la misma, ya que será necesario preparar los equipos de trabajo necesarios, para que una vez realizada la migración se pongan manos a la obra y adapten el sistema al nuevo entorno. Evidentemente dichos sistemas de información no deben ser críticos, y por tanto asumir una perdida de disponibilidad total o parcial sobre un conjunto de funcionalidades durante unos cuantos días. También como es lógico si hay algún sistema crítico que no va a funcionar tras la migración no es recomendable migrar hasta que este sistema se haya adaptado.

8) Si se espera a que todo esté perfectamente adaptado antes de realizar la migración, probablemente esta no se realice nunca. Por tanto, es esencial que los sistemas críticos estén adaptados y que la mayoría de los no críticos también lo estén, pero es necesario establecer un umbral a partir del cual la migración es realizable.

9) Es necesario documentar con detalle los diversos pasos que se van a dar el día o días de la migración y quiénes son las personas encargadas de realizar cada tarea. También es necesario que esté perfectamente documentada la posible vuelta a atrás. Dado que las migraciones cuentan con una ventana de tiempo para poder hacerse, con el objeto de disponer del mayor tiempo posible, es necesario que todas aquellas operaciones relacionadas con la migración que se puedan realizar previamente a la misma, se adelanten (siempre y cuando no afecten a los sistemas actualmente en producción).

10) Por muy bien que se haya realizado el proyecto de migración y se hayan tenido en cuenta buenas prácticas, del estilo de las que estoy comentando en mi artículo, probablemente se producirán imprevistos durante el proceso de migración, por lo que es importante saber de antemano que no va a ser un camino de rosas.

11) Desde mi punto de vista, la vuelta atrás debe ser siempre la última opción y sólo aplicarse cuando se tenga constancia de que la migración no se va a realizar con éxito. Esto no tiene por qué ser necesariamente tras horas y horas de intentar que todo quede perfectamente ajustado, sino incluso puede ser al principio de la misma. Por tanto, si surgen problemas que pueden intentar solventarse o al menos investigarse, hay que esforzarse por corregirlos y sólo volver atrás si dichos problemas son importantes y/o afectan a sistemas críticos y se llega a la conclusión de que no se van a resolver en la ventana del tiempo disponible para la migración.

12) Si hay que volver atrás o interrumpir el proceso de migración, no hay que venirse abajo, son cosas que pasan y por tanto, que no haya salido a la primera o a la segunda, no quiere decir que no salga bien más adelante. Además se habrá ganado en conocimiento que permitirá incrementar la garantía de éxito de los siguientes intentos.

13) Es muy difícil que una migración salga limpia, por lo que además de los flecos previstos, surgirán flecos imprevistos que se tendrán que corregir los días siguientes a la migración.

14) Es en las migraciones cuando uno se da cuenta más de lo importante que resulta que las aplicaciones estén diseñadas con una tecnología y arquitectura homogénea, que estén bien organizadas en los diferentes servidores de aplicaciones y que tengan una documentación de calidad. Cuanto más de estos ingredientes se tengan más sencillo será el proyecto y el proceso de migración y, por tanto, se reducirán las posibilidades de imprevistos.

Algunos de los sistemas de información que gestiono dependen para su funcionamiento de su interacción con otros sistemas de información y componentes software. El problema con el que me estoy encontrando es que conforme se incrementa el número de elementos externos de los que depende más complicado me está resultando mantener un nivel de disponibilidad óptimo de los sistemas.

La explicación es sencilla, si la funcionalidad completa de la aplicación requiere de que otros n componentes software o sistemas de información funcionen a su vez correctamente, conforme ese n sea mayor, más posibilidades habrá de que alguno tenga algún problema e impacte sobre el sistema que interectúa con ellos. Y además hay que tener en cuenta otros factores que todavía complican la situación ya que cada uno de esos otros sistemas o componentes pueden necesitar la colaboración con otros sistemas para proporcionar su funcionalidad a lo que hay que sumar que además para que funcionen todo ese software serán necesarios a su vez otros tipos de software como servidores de aplicaciones, servidores de bases de datos, etc…, además de que toda la electrónica de red funcione adecuadamente. Es decir, al final, para que un sistema medianamente complejo funcione al 100% es necesario que otra cadena de elementos funcionen a su vez y puedo asegurar, por mi experiencia, que es difícil de mantener el equilibrio en la torre de naipes y que se producen, en demasiadas situaciones, circunstancias que afectan a la disponibilidad del sistema de información.

La solución más simple es que cada sistema sea una isla independiente con una infraestructura independiente (esto es un esquema de funcionamiento extremo, aunque hay otras combinaciones que pueden ser válidas para esta filosofía de funcionamiento), pero eso no es una solución, ya que aunque puede proporcionar una mayor disponibilidad a los sistemas, requiere mayores costes de mantenimiento de infraestructura (aunque siempre, y para ser justos, hay que valorar que cuesta más si estos costes adicionales de infraestructura o la pérdida de disponibilidad) y sobre todo tiene el inconveniente de que la información permanece aislada y no vinculada con terceros sistemas, lo que dificulta una visión, integración y una explotación global de la información, algo que no es natural al funcionamiento de una organización, donde los departamentos no son estanco, sino que por regla general para funcionar necesitan información de otros procesos de otros departamentos. Otro inconveniente es que el aislamiento de la información provocará muchas situaciones en las que se duplique, triplique, etc… un mismo tipo de datos, lo que dará lugar a incoherencias en los mismos, lo cual en muchas situaciones puede ser fuente continua de problemas al impedir incluso que exista una visión común sobre una determinada característica de la información. Por todos estos inconvenientes, no comparto una política de desarrollo basada en el aislamiento de sistemas que aunque permite afrontar con menos problemas el día a día, a nivel táctico y estratégico terminará haciendo aguas.

Por tanto y en base a lo anterior, se tiene que tender a buscar la interoperabilidad entre sistemas de información y componentes, pero para que la disponibilidad de los sistemas se vea afectada lo menos posible es necesario que se den una serie de premisas:

– Que la infraestructura hardware, software de base, software servidor y de comunicaciones sea lo más estable y óptima posible.
– Que los sistemas de información y componentes software (estando en este último grupo sistemas horizontales de servicios como por ejemplo, plataformas de firma y autenticación electrónica, gestores documentales, motores de tramitación, generadores de plantillas e informes, generadores de formularios, etc…) se encuentren lo más estables posibles y los cambios que se produzcan en los mismos provoquen el menor efecto posible tanto en el propio sistema como en el conjunto de sistemas con los que se comunica.
– Que se reduzca en lo posible el acoplamiento entre sistemas de información para evitar situaciones de pérdida de disponibilidad por efectos colaterales en los cambios que se produzcan en los mismos.

Evidentemente conseguir los tres factores que acabo de indicar (hay algunos más) resulta prácticamente utópico y de ahí los problemas de disponibilidad que nos encontramos con entornos de estas características. Que diga que es utópico no digo que sea imposible, pero el proceso para conseguirlo requiere un nivel importante de madurez en la organización en general en lo que a la gestión TIC se refiere (y digo en la organización, porque ésta debe ser consciente de la importancia de las TIC en su funcionamiento y que la gestión de las mismas debe planificarse con el mismo nivel de atención que cualquier otro proceso de la organización y que hay que dedicarle la atención y presupuesto acorde a lo crítico que resulta que esta actividad se ejecute correctamente) y además que los departamentos TIC y los sistemas de información alcancen también ese nivel de madurez. Para adquirir esos niveles se requieren tiempo, esfuerzo, dinero y paciencia. La principal ventaja es que si se consiguen alinear estos factores veremos cómo lentamente se van mejorando los resultados, pero mientras tanto toca sufrir en el día a día, los múltiples fuegos que provoca esta manera de concebir la estrategia de sistemas de información de una 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.

Un problema común que tenemos todos los que trabajamos en un Departamento de Informática en una organización que no se dedica a la Informática, es que al final todo, no sabemos cómo, ni por qué termina en Informática.

Los que nos dedicamos a esta profesión somos todos un poco encantadores de serpientes, lo cual sumado a la sensación de magia que todavía dan los ordenadores y las aplicaciones seguro que tiene mucho que ver con que se crea que tenemos la solución a todo lo que se ejecuta en ellos.

Si la incidencia es del equipo, de las comunicaciones o de la aplicación es lógico que se contacte con Informática, el problema está cuando se confunde lo anterior con el todo, es decir, cuando se confunde lo que es la instrumentación, con los datos y los procesos. ¿Cuántas veces os habrá pasado que un determinado usuario os pregunte si una determinada tarea de su departamento que se realiza de tal manera se pueda realizar de tal otra? o si ¿es válida la Ley a la que hace referencia el documento?.

Una cosa es que para hacer el sistema de información hayamos tenido que entender cómo funciona un determinado proceso y otra es que nos convirtamos en exégetas o expertos de ese proceso y todo lo que le rodea.

Os comento una anécdota, como podría contar decenas y decenas de ellas. Esta es de hace unos meses, resulta que a un amigo que trabaja en un Departamento de Informática en otra organización le llega un día un señor externo a la misma indicando que le habían dado sus datos de contacto ya que le habían dicho que él iba a ser la persona que le solucionaría los problemas con un determinado trámite que no terminaba de cerrar. Este señor había ido previamente a diferentes centros de la organización y fuera de ella (que por cierto eran los adecuados para resolverle el trámite) y le habían enviado de un sitio a otro, como una pelota de ping-pong en varias ocasiones. Este señor, como es lógico, harto de que lo tuvieran de acá para allá, pidió que por favor le dieran una solución y ¿qué es lo que hicieron? Pues darle los datos de contacto de la persona de la organización responsable del programa informático. Con esos datos, el señor se presentó en el Departamento de Informática y le comentó a mi amigo toda la historia, afortunadamente era una persona educada y de buen trato, pero podía haber sido todo lo contrario. Mi amigo entró en el sistema de información y vió que el trámite no se había podido completar por las personas que eran competentes para hacerlo, porque éstos no habían grabado un dato en el programa. En cinco minutos mi amigo realizó las tareas necesarias para que a este señor se le atendiera adecuadamente su demanda. Por lo que al final, un problema que se hubiera resuelto en menos de cinco minutos llamando al Centro de Atención a Usuarios y consultando la duda, provocó que una persona estuviera dando vueltas durante un mes, con la consiguiente pérdida de tiempo de la misma (y la consiguiente pérdida de imagen de la organización).

El problema del Todo a Informática no es de fácil solución, ya que implica un cambio de la visión que tienen muchos de los usuarios sobre las TICs. Para ellos es un todo y la clave para solucionarlo es hacerles entender las partes.