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.