¿Cómo documentar una estrategia para actualizar el software comercial?

No hemos actualizado nuestro RDBMS o el sistema operativo del servidor en casi una década. Otro paquete de software de misión crítica tiene casi dos décadas de antigüedad y su proveedor no lo ha respaldado durante gran parte de ese tiempo. Algunos de nuestra gerencia parecen pensar que esto es algo bueno: ¡ahorramos toneladas de dinero al no comprar las actualizaciones! Ahora, una pieza crítica de software necesita una actualización, pero la nueva versión no admitirá las cosas de hace una década. Ahora, un puñado de nosotros está perdiendo el pelo tratando de descubrir cómo actualizar todo a la vez con un tiempo de inactividad mínimo.

En un esfuerzo por evitar esto en el futuro, algunos de nosotros estamos considerando la creación de un documento de plan estratégico de TI (que se ajustará al plan estratégico de la organización, desarrollando los elementos en el documento más grande relacionado con TI ... tal vez eso hace que el documento de TI sea tácticoplan?) con la esperanza de que podamos adoptarlo como parte del plan estratégico general de la agencia. Me ofrecí como voluntario para tratar de armar la sección "Administración del ciclo de vida del software" (o algo así) para abordar el problema mencionado anteriormente (con las tachuelas en un documento separado del plan estratégico). Casi todos los proveedores de software publican ciclos de vida y planes de desuso para sus productos, y es bastante fácil determinar un "punto óptimo" para cada pieza de software considerando esa información junto con las necesidades de nuestra organización. La parte difícil (para mí de todos modos) es unir el plan para cada pieza en algo más coherente.

¿Cómo puedo documentar que los clientes de escritorio A, B, C ... dependen del sistema operativo de escritorio X y RDBMS Y, que a su vez depende del servidor OS Z, y luego así es como los mantenemos a todos en sus "puntos clave"? Debe haber libros, pero todas mis búsquedas en Google solo me han llevado a cosas sobre las tácticas de actualizar una sola pieza de software en lugar de la estrategia para determinar cuándo implementar esas tácticas.

Parece que está intentando resolver muchos problemas a la vez (y no parece una buena idea).

Por lo que leí:

• SO y aplicaciones obsoletas
• sin estrategia a largo plazo
• problemas para documentar su infraestructura
• necesidad urgente de actualizar una pieza crítica de infraestructura

Actualización de "pieza crítica de software"

Su infraestructura está desactualizada debido a la decisión de alguien es fácil de entender. Probablemente parecía una buena idea en algún momento del pasado. Esto se reduce a lo que Michael Hampton escribió en los comentarios: para la administración, usted está hablando de pros y contras (riesgos). Entonces, si la gerencia está dispuesta a arriesgarse, entonces está bien (lo que usted piense personalmente al respecto), y es su responsabilidad de ahora en adelante. Pero alguien de los chicos de TI tiene que decirles cuáles son los riesgos.

Entonces, lo primero que buscaría es: ¿Sabían los gerentes acerca de los riesgos del software obsoleto? ¿Se les dijo?

Honestamente, siento que probablemente no encontrarás nada útil al respecto, por lo que no pasaría demasiado tiempo en ello. Es simplemente algo que puede ayudarlo en la línea de "le estuvimos diciendo durante los últimos cinco años".

Simplemente haría un análisis de lo que realmente significa realizar esa actualización. Prepare una hoja de cálculo simple con actividades y cuánto tiempo tomarán (si no sabe, adivine mejor y explique explícitamente que no lo sabe con certeza). Pero recuerde que esta "tarea de actualización" no está bien especificada, es imposible hacerlo como tiempo fijo / precio fijo.

Hacer tales listas también lo ayudará a profundizar en todo el problema. Lo siguiente es crear un registro de riesgos y una lista de recursos que necesita.

Al final, debe tener una lista de actividades, una lista de riesgos, una lista de materiales / personas que necesita. En una palabra, no maneje la actualización como un problema cotidiano, hágalo como un PROYECTO. Esto le permitirá tener al menos algo de control sobre la necesidad aguda de su empresa.

Si tiene problemas para analizar qué actividades deben realizarse, puede probar un mapa mental (mi sw favorito es xMind) y luego convertirlo en un documento más formal.

Tenga en cuenta que cuando tenga algunas opciones sobre cómo realizar la actualización, debe proporcionar a sus gerentes un resumen de las posibles soluciones (si hay más), resumidas en unas pocas oraciones, incluidos el costo, el resultado y el riesgo; idealmente mencionando la opción que recomienda y por qué. Debido a que la decisión final es suya, son gerentes después de todo.

Tal vez en este caso particular: Mencione que la actualización puede no ser posible en absoluto.

Sin estrategia a largo plazo.

Crear un plan estratégico no te ayudará ahora. No lo ayudará en absoluto si se trata de un documento elaborado dentro de su departamento de TI. El plan estratégico es algo que debe estar vinculado a las necesidades del negocio.

Ejemplo de necesidad comercial: en dos años abriremos nuevas oficinas en China y Australia.

Tareas de TI derivadas: prepárese para que sus nuevos empleados tengan sus estaciones de trabajo, cree infraestructura en oficinas en el extranjero, brinde capacitación para nuevos empleados (posiblemente utilizando su idioma nativo), brinde conectividad segura desde esas oficinas a la central, ...

Si las cosas van bien, puede tener una estrategia tal vez ... ¿en unos meses? Entonces, ¿aproximadamente medio año hasta que todo esté acordado?

Mantener y documentar su infraestructura.

Esta es una herencia del pasado y ahora tienes que cambiar las cosas. Priorizar Haga una lista de las cosas que desea / debe hacer ahora para actualizar la mayoría de las cosas. Elija cuál puede esperar, haga una hoja de ruta cruda. (Esta hoja de ruta debe ser parte de su estrategia de TI cuando tenga una).

Si está actualizando algo que salió bien, trátelo como un negocio cotidiano. Si está manejando algo que puede salir mal (es "grande" en términos de tiempo dedicado, personas asignadas, etc.), trátelo como un proyecto.

Existen herramientas que pueden ayudarlo con la documentación y las dependencias de servicio: CMDB (iTop, por ejemplo). Pero lograr que funcione puede llevar algún tiempo y aún necesita alguna herramienta de documentación. La mejor idea es configurar un wiki para la documentación donde todos puedan comenzar a documentar / hacer notas a partir de ahora. Puede configurar un wiki en media hora, por lo que es una forma muy efectiva de comenzar las cosas.

Nota personal: actualizar el sistema operativo tan antiguo sería una gran PITA, sin mencionar la documentación (probablemente mala / faltante). ¿No es más fácil instalar servidores de nuevo, migrar aplicaciones y documentar todo desde el principio?