archivo

Archivo de la etiqueta: disponibilidad

Su enunciado es el siguiente: “La calidad de los sistemas comienza a disminuir a menos que se mantengan de forma rigurosa y se adapten a los cambios en su entorno de funcionamiento (operacional)”.

En esta ley, Lehman trata el problema de la disminución de la calidad desde diferentes puntos de vista:

– El usuario tiende a ser más exigente conforme mayor sea la inversión dedicada a la evolución del producto y conforme se den cuenta (independientemente de que sepan interpretar su complejidad o no) de la maleabilidad del software.

– La calidad del software se ve afectada por en incremento de la complejidad del sistema conforme se va evolucionando y eso afecta a diferentes escalas: codificación/arquitectura (deuda técnica), usabilidad, etc…

– Por otro la propia convivencia del sistema con su entorno tecnológico (software y hardware), el cual evoluciona de la misma forma que los sistemas y en muchos casos con características muy similares. En esa evolución se tratan de corregir fallos de seguridad, se trata de dar una mayor estabilidad, a la par de incluir nuevas funcionalidades que puedan resultar de utilidad (y distinguirla de otras opciones del mercado).

Si un sistema no se adapta a esos cambios y las características de los nuevos entornos operacionales que se estén montando no son compatibles, estamos acotando el sistema a seguir subsistiendo con versiones en muchos casos sin soporte de los mismos y que además, se irá quedando marginada porque el esfuerzo central del Departamento de Sistemas se centrará en los entornos en los que se encuentre el grueso de los sistemas de información de la organización, además de aquellos que sean considerados críticos.

El alcance de esta séptima ley se puede extender al propio framework de desarrollo del producto y al conjunto de librerías dependientes que utilice, de manera que surgen nuevas versiones de las mismas que mejoran las anteriores a la vez que corrigen defectos en las mismas.

También puede ser extensible a una menor calidad como consecuencia de no aplicar medidas conforme se incrementa la complejidad del producto (en este caso se asimilaría a la segunda ley de Lehman).

Las expectativas del usuario y la calidad del software están muy por encima de las especificaciones funcionales, por eso que el producto final termine satisfaciendo el catálogo de requisitos funcionales (por mucho que se hayan refinado) no asegura ni el éxito del producto ni su calidad final.

Si solo pensamos en requisitos funcionales estamos limitando nuestra visión sobre lo que debe ser el producto final. Cada uno puede tener una definición de lo que considera calidad del software, en la mía no es condición suficiente la verificación de los requisitos funcionales (y probablemente muchos de vosotros estéis de acuerdo conmigo). Son importantes, no digo lo contrario, pero no es lo único.

Por un lado tenemos las expectativas que, si bien podría englobar los aspectos funcionales, contiene ingredientes adicionales como son la experiencia de usuario y la productividad en el uso de la herramienta (muy ligado a la anterior).

Y por otros los requisitos no funcionales (algunos de ellos serán detectados de manera temprana por los usuarios y podrían afectar a las expectativas del usuario sobre el producto), como por ejemplo, la mantenibilidad (deuda técnica), la disponibilidad, el rendimiento, los recursos que requiere y consume, etc…

O infierno de los artefactos (en general). Se produce cuando en una organización o en un departamento de desarrollo o TIC no se gestionan de manera adecuada los artefactos de los que hacen uso las aplicaciones (gestionados, generalmente, a través de un repositorio de artefactos), lo que implica que se pueda sustituir un artefacto por otro que se llame de la misma manera y tenga un comportamiento distinto, que hagamos uso de uno que no es el oficial de una solución concreta, etc…

Al final, problemas y más problemas.

Esto, además de provocar problemas de disponibilidad cuando se tiene que generar una nueva versión de una aplicación, dificulta la reutilización de artefactos entre diferentes sistemas.

Se entiende por disponibilidad de los sistemas como la capacidad de ofrecer los servicios desarrollados en los mismos a unos niveles soportables por sus usuarios finales, es decir, un sistema puede no estar caído y sin embargo no ser considerado disponible si el rendimiento que ofrece lo hace inmanejable o hay aspectos de la aplicación que no funcionan correctamente (por ejemplo, porque algún módulo dependa de un componente externo que le proporciona datos o servicios).

En este artículo no vamos a hablar de ese tema, aunque he hecho una breve referencia a él para no confundirlo con otro término que es el de la continuidad de los servicios de desarrollo y mantenimiento de los sistemas de información que sí es el objeto central que quiero tratar en esta ocasión.

Los sistemas de información de una organización (sobre todo aquellos hechos a medida) pueden requerir en cualquier momento de servicios de mantenimiento, ya sea por errores detectados en el mismo (fuera de garantía), por necesidades de mejoras o ampliaciones demandadas por los usuarios, por tareas de mantenimiento adaptativo o por actividades de mantenimiento perfectivo.

Si multiplicamos este hecho por el total de sistemas de información que maneja una organización, la complejidad de cada uno de ellos y el número de departamentos distintos al que prestan servicio, nos encontramos con que resulta necesario tener contratado un servicio que cubra estas necesidades y permita darles una rápida respuesta.

Cuando hablo de un servicio, hablo en general, ya que se podrían tener contratados varios, cada uno de ellos especializado en determinados sistemas de información, aspectos funcionales y/o aspectos técnicos.

Este servicio trataría de contener las peticiones urgentes y que pueden tener impacto en el negocio, ahora bien, en función de las posibilidades presupuestarias de la organización, podría asumir una mayor cantidad de tareas.

Soy de la opinión de que es necesario garantizar la realización de modificaciones en el sistema de información (independientemente del tipo de mantenimiento que la origine) que en el caso de que no se realicen, provocará una disminución de la eficiencia en el trabajo de las usuarios o el incumplimiento de algún aspecto de carácter legal, pero que tenga un presupuesto lo suficientemente holgado, para poder aguantar momentos donde se superpongan diferentes peticiones. Si en la ejecución del contrato, vemos que va sobrando dinero, siempre existirá la posibilidad de ir modulando el tamaño del equipo de trabajo y alargar su finalización o encargar otro tipo de tareas necesarias pero no tan urgentes.

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.