Gestión del ciclo de vida: deja que entre el sol

La arquitectura empresarial se trata del paisaje de su organización. Un panorama de personas y TI y del comportamiento de ambos. Estos paisajes se han vuelto muy complejos. En sí misma, esa complejidad y los problemas que conlleva han llevado a muchos esfuerzos de estandarización y racionalización. No demasiadas marcas de un sistema operativo, por ejemplo. No seis sistemas operativos diferentes, sino dos. No cinco motores de flujo de trabajo diferentes, sino uno. No hay muchas redes diferentes o tecnologías informáticas. Menos es mejor.

Incluso cuando está estandarizado, una complejidad adicional proviene de los ciclos de vida de TI. Poniéndolo enninguna TI, incluso estandarizado, no significa que haya terminado. Para el software, esto es lo más obvio: regularmente se lanzan nuevas versiones. Hay muchas razones para las nuevas versiones, una razón muy importante son las correcciones de errores, tanto en términos de la función principal, como también, por ejemplo, en términos de seguridad. Las plataformas que se utilizan para ejecutar aplicaciones se actualizan todo el tiempo con correcciones de seguridad y errores. Y luego hay un flujo constante de nuevas funciones, lo que en sí mismo también significa una nueva funcionalidad que puede tener errores.

Tener TI vieja en su entorno generalmente no es algo bueno. Las cosas viejas son una de las fuentes más importantes de problemas de seguridad. Si su paisaje todavía contiene Flash, versiones Java o dotNet muy antiguas, sistemas operativos obsoletos, es muy probable que no sea tan seguro.

Las empresas son conscientes de que deben administrar los sistemas y asegurarse de que estén actualizados. Esta es la gestión del ciclo de vida (LCM). LCM también se lleva a cabo con TI hardware. El hardware también envejece. Se desgasta. Puede fallar. El hardware tiene una vida útil de unos pocos a quizás diez años. Y luego, generalmente no puede reemplazarlo con exactamente lo mismo, ya que ya no está a la venta. La tecnología ha avanzado. Las nuevas versiones y productos son forzados a su entorno, incluso si no tiene nuevas demandas (pero en general, sí las tiene).

Todos estos productos a menudo dependen unos de otros. Un sistema operativo o un marco de aplicación parcheados pueden provocar que una aplicación ya no funcione correctamente. Una nueva versión de una plataforma puede ofrecer nuevas posibilidades, pero también perder las antiguas. Es posible que desee actualizar su servidor de Windows de Windows Server 2012 a Windows Server 2016, o de RedHat Linux 6 a 7, porque la versión anterior está fuera de soporte, pero ¿funcionará su aplicación que se ejecuta en ella?

O es posible que desee o necesite actualizar una aplicación, pero la nueva versión requiere una versión de plataforma diferente. Que aún no soportas. Y la mayor parte de su paisaje no se construye sino que se compra (o alquila) y los proveedores tienen el control sobre su LCM y lo que respaldan (y lo que no). ¿Utilizará ese viejo Windows Server 2003 que ya no se actualiza con parches de seguridad? ¿Existe una aplicación antigua que te obliga a seguir usándola?

El resultado es un mar espumoso de componentes, todos a un cierto nivel de "actualización" y todos en constante cambio. Esta es una fuente importante de por qué es difícil cambiar su panorama de TI y con eso el panorama de su empresa.

Es bastante difícil planificar un cambio tal como es, pero mientras realiza el cambio, muchas otras cosas también cambian simultáneamente. El paisaje es volátil. En "El ajedrez y el arte de la arquitectura empresarial ", esto se compara a jugar un juego de ajedrez donde, mientras haces un movimiento, cientos de otros jugadores también hacen movimientos.

No es de extrañar que la gestión del ciclo de vida sea una de las partes más difíciles de mantener una arquitectura o un paisaje saludables. Por extraño que parezca, los marcos de arquitectura parecen prestar poca atención a lo que la gestión del ciclo de vida le hace a su paisaje. Hablan sobre el ciclo de vida de tu arquitectura artefactos; no se trata de lo que los eventos del ciclo de vida le hacen a tu paisaje y cómo manejar eso.

Así que cómo poder te das cuenta de eso? He visto en varias organizaciones que los arquitectos administraban hojas de ruta (ahora estamos usando Windows 7, el próximo año nos trasladaremos a Windows 10). Pero fue difícil controlar todos los elementos y la selección de lo que es parte de la hoja de ruta y lo que no es bastante arbitrario ("¿Por qué mencionas las versiones de JBoss pero no las versiones de Tomcat o Hibernate? No sé, debería ¿YO?").

A menudo vi reglas más genéricas, como "Usamos dos versiones de cualquier cosa: si la última versión es N, usaremos las versiones N-1 y N-2". O: "Solo usaremos software que tenga ' soporte estándar 'y solo excepcionalmente use software en' soporte extendido '".

Esos genéricos Los principios generalmente no resolvieron el problema, el mundo real de las dependencias era demasiado complejo para ser gobernado por ellos. Debería actualizar cuando llegue una nueva versión N + 1, pero no puedo porque …

Una propuesta para controlar la gestión del ciclo de vida.

Primero, es importante entender lo que hay en tu el paisaje está al final tu elección. Existen algunos límites legales (por ejemplo, si no tiene la licencia para seguir usando algo, no está permitido legalmente). Pero por lo demás: tu paisaje (su arquitectura), tu elección. ¿Desea seguir ejecutando esa vieja pieza de software o hardware no compatible? Nadie te detiene.

Luego, para cada producto o sistema o plataforma o aplicación o servicio que utilice, usted define un conjunto de sus propio períodos en los que se puede usar. Para gestionar el uso de sistemas y su LCM completo, los períodos son:

  1. amanecer
  2. Sol
  3. Puesta de sol

Y hay un aspecto, llamado Cuarentena, que es independiente de él, pero generalmente puede jugar un papel durante Sunset.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *