La gestión del ciclo de vida debería evitar las crisis en ciernes, pero no lo hace. En su lugar, considere la ‘administración de la moneda de la versión’ (version currency management) y evite la catástrofe siendo táctico para mantener los sistemas actualizados.

A menudo, el área de TI se equivoca mucho en la gestión del ciclo de vida.

Si usted busca una definición de administración del ciclo de vida (lifecycle management) encontrará algo similar a: Un enfoque estratégico para administrar el ciclo de vida de una aplicación o plataforma desde la concepción hasta el final de la vida, desde el aprovisionamiento, pasando por las operaciones, hasta el retiro.

Según esta definición, la gestión del ciclo de vida no parece hacer nada.

No ayuda a implementar una nueva plataforma o aplicación; para eso están las metodologías de desarrollo de aplicaciones y gestión de cambios. No ayuda con las operaciones diarias, para eso está ITSM. No ayuda a retirar una aplicación o plataforma, aparte de detectar un evento o condición que hace necesaria la retirada. El evento puede ser externo, como la quiebra de un proveedor o el retiro gradual del producto. Pero, ¿retirar la aplicación o la plataforma? Para eso están el archivado, el desmantelamiento y, una vez más, la gestión de cambios.

Además, administrar el ciclo de vida de una aplicación o plataforma desde su concepción hasta el final de su vida no es algo en lo que TI deba invertir tiempo y energía.

Gestión de divisas de versiones: la gestión del ciclo de vida que necesita TI

Sin embargo, existe una práctica de gestión del ciclo de vida que es esencial, frecuentemente ignorada, pero esencial. 

La administración del ciclo de vida que necesita TI es un conjunto de métodos tácticos confiables para mantener actualizadas las plataformas y las aplicaciones comerciales, es decir, no más de una o dos versiones por detrás de lo que el proveedor está vendiendo actualmente.

Llámelo “gestión de moneda de versión”.

Para contrastarlo con la administración habitual del ciclo de vida, imagine por el bien del argumento que algunas de sus aplicaciones se ejecutan sobre EnGarde Secure Linux.

EnGarde está mucho más allá del final de la vida. Tomando prestado de los Munchkins, no está simplemente muerto; es realmente más sinceramente muerto. Es posible que sus servidores no hayan escuchado las noticias, pero el hecho de que continúen funcionando no significa que se encuentre en una situación satisfactoria.

Que EnGarde se ejecute en un servidor al final de su vida útil no significa que se instalará en el nuevo hardware que no tiene opción de comprar cuando su servidor al final de su vida útil se convierta en un servidor caducado. No significa que funcionará con una actualización de una de las plataformas que se ejecutan en él, o con una actualización de una aplicación que depende de él.

EnGarde, al igual que cualquier otra tecnología obsoleta y sin soporte, seguirá funcionando hasta que deje de hacerlo funcionar. Y cuando no lo haga, TI tendrá una crisis en sus manos.

Eliminar EnGarde de su cartera de plataformas no es una gestión del ciclo de vida, porque en ningún momento del procedimiento hubo un ciclo de vida qué gestionar. Después de todo, cuando EnGarde presentó su distribución de Linux, no había fijado una fecha de retiro en sus planes comerciales y de productos. Tampoco TI cuando lo seleccionó. Cuando TI incorporó EnGarde a su cartera de plataformas, su disposición habría sido Retener o Extender.

No, desde la perspectiva de los arquitectos de TI, la interrupción de EnGarde fue un evento, un evento desafortunado que cambió el puntaje de viabilidad del producto y del proveedor de EnGarde de lo que había sido la última vez que los arquitectos de TI lo visitaron a -2 (el peor puntaje posible), y su disposición a Reemplazar, si aún se necesitaba su funcionalidad, o Retirar si ya no se ejecutan aplicaciones o plataformas en él.

Compare eso con una empresa que confió en BizTalk 2016 como su plataforma de integración de aplicaciones. Mucho antes del retiro de BizTalk 2016, Microsoft anunció que su sucesor, BizTalk 2020, se lanzaría a mediados de 2019 y que la fecha de finalización de la vida útil de BizTalk 2016 (bueno, el mes) sería noviembre de 2022.

Después de estos anuncios, con una práctica de administración de divisas de la versión adecuada, los arquitectos de TI habrían cambiado la disposición de BizTalk 2016 a Update y, con eso, habrían agregado un proyecto de actualización de BizTalk al programa maestro y al presupuesto del proyecto de la empresa, programado para evitar el gasto y el riesgo. de continuar utilizando tecnología fuera de soporte en la cartera de la plataforma.

De manera sinóptica, la gestión del ciclo de vida que necesita TI incluye:

• Carteras de aplicaciones y tecnología que realizan un seguimiento de la versión en uso de sus componentes, aunque sin una gestión efectiva de la moneda de la versión, “versión en uso” sería “versiones en uso”.
• Para cada componente, la actualización de la versión anunciada por el proveedor y los programas fuera de soporte.
• Programaciones y presupuestos de proyectos derivados algorítmicamente para actualizar los componentes a las versiones actuales.
• Revisión de alternativas, para asegurarse de que Update sea la disposición óptima, en lugar de reemplazar el componente con una alternativa funcionalmente equivalente pero superior en general.
• Principios y políticas de la arquitectura técnica para mantener los componentes actualizados, revisados ​​y aprobados a nivel del equipo de liderazgo ejecutivo o de la junta directiva, por lo que TI tiene que pelear esta batalla presupuestaria solo una vez.

Trampas

La gestión de moneda de versión no es particularmente complicada en concepto. Pero hay algunos obstáculos para los que prepararse.

En primer lugar, cuando actualiza una plataforma, necesita saber dónde afectarán los efectos dominó. Es raro que una actualización sea perfectamente compatible hacia abajo con la versión anterior.

Lo que también significa asegurarse de que su equipo de control de calidad del software mantenga actualizadas sus pruebas de regresión automatizadas.

En segundo lugar, la actualización de una aplicación a su versión actual a veces puede requerir la actualización de algunas de las plataformas en las que se basa. Lo que significa volver a los errores de actualización de la plataforma.

Y tercero, especialmente para la gestión de divisas de la versión de la capa de aplicación, el escalado levanta su fea cabeza.

Tener cientos (y, en algunas carteras, miles) de aplicaciones en producción, mantener actualizada la base de datos de los programas de actualización de la versión del proveedor en el sistema de gestión de la arquitectura técnica es un desafío. Enfrentados a la magnitud de este desafío, muchos departamentos de TI se dan por vencidos y siguen adelante hasta que la obsolescencia de la versión de un componente genera una crisis. Esta es una decisión terrible, porque cuando pateas la lata por el camino suficientes veces, finalmente te quedas sin camino.

No, la gestión de moneda de versión de capa de aplicación es tan esencial como laboriosa. Lo que funciona mejor, o tal vez “menos peor”, es dividir y conquistar, asegurándose de que cada aplicación en la cartera tenga un administrador de productos de TI asignado que sea responsable de la salud, el cuidado y la alimentación de las aplicaciones asignadas a ellos. Eso incluye mantener actualizada una base de datos de planes de versiones de proveedores.

La gestión de moneda de versión no va a cubrir de gloria a sus practicantes. En su mayoría, serán tratados de la misma manera que se trata a todos los portadores de malas noticias.

La buena noticia es que llevar estas malas noticias es mejor que las malas noticias que soportaría si no las hiciera.

Bob Lewis, CIO.com