El arte secreto de la mejora de la arquitectura técnica

Elija una palabra para describir la arquitectura técnica de su empresa. Probablemente sería "realmente complicada".

Vale, son dos palabras, pero la mayoría de las arquitecturas técnicas son realmente complicadas. ¿Cómo simplificarlas y mejorarlas? Tendremos que repetir "realmente" unas cuantas veces más: es muy, muy, muy complicado.

Por supuesto, cuando algo es tan complicado —o enrevesado— ayuda a desglosar las cosas antes de elaborar un plan de mejora. En este caso, le ayudamos a desmenuzar algunos de esos "realmente" para que pueda elaborar un plan práctico que garantice que la arquitectura técnica de su empresa está al servicio del negocio.

 

Desenredando la arquitectura técnica

En una entrega anterior de esta serie se proporcionó un marco para describir la arquitectura técnica, desglosándola en tres carteras y sus subcarteras:

· Aplicaciones: sistemas de registro, interfaces e integración, y aplicaciones satélite

· Datos: estructurados y no estructurados

· Tecnología: instalaciones, infraestructura y plataformas

La siguiente entrega añadía la idea de que la arquitectura técnica requiere dos perspectivas complementarias: la visión de la cartera y el diseño holístico. También proporcionó orientación para evaluar la salud de los componentes que conforman la arquitectura; y mostraba cómo conectar las arquitecturas técnica y de negocio, concretamente a través del "modelo de capacidad de negocio" (BCM), una taxonomía de funciones de negocio a la que se asocia cada aplicación de la arquitectura técnica.

Juntos permiten identificar, categorizar y clasificar lo que se tiene.

Pero para llegar a establecer un plan eficaz de mejora de la arquitectura técnica, hay que determinar, para cada componente de cada cartera y subcartera, su disposición —cómo tiene que cambiar— y la prioridad para que se produzca su disposición.

Los detalles dependen de la cartera y subcartera de que se trate. Aquí lo desglosamos, de abajo a arriba.

 

Instalaciones e infraestructuras

Para mejorar la arquitectura técnica, lo primero es establecer prioridades. Puntúe la salud de cada componente utilizando el proceso, el marco y los criterios descritos en la última entrega. Puntúe su importancia en función del número de aplicaciones que dependen de él. Multiplique la salud por la importancia para calcular un índice de prioridad para cada componente. Visualice el resultado como un mapa de calor, en el que cuanto más rojo sea el componente, mayor será su prioridad.

Las disposiciones vienen a continuación. En el caso de las instalaciones y la infraestructura, las opciones de disposición son las siguientes:

· Retirar: Aunque es poco probable, es posible que identifique instalaciones o infraestructuras que no estén en uso. Apáguelos, ciérrelos y cancele cualquier contrato de arrendamiento o soporte.

· Actualizar: es posible que encuentre componentes de sus instalaciones o infraestructuras que estén obsoletos, sin soporte o que necesiten ser actualizados a versiones más recientes del mismo producto. Actualícelos.

· Sustituir: es posible que encuentre un componente obsoleto, sin soporte, y que si hay una versión más actual disponible no lo considere viable. Deshágase de él e implante en su lugar una alternativa funcionalmente equivalente pero más saludable.

· Consolidar: no es raro que una arquitectura técnica tenga instalaciones o componentes de infraestructura redundantes. Especialmente tras una fusión o adquisición, varios centros de datos o redes suelen ofrecer oportunidades de consolidación.

Ahora ya sabe, en lo que respecta a las instalaciones y la infraestructura, qué es lo que necesita atención con mayor urgencia y qué hacer con la situación.

 

Plataformas

La determinación de las prioridades y disposiciones de las plataformas difiere de la determinación de las instalaciones e infraestructuras porque las plataformas tienen muchas más interdependencias. Una buena manera de abordar esta complejidad es definir pilas. Una pila es una combinación de plataformas utilizadas por al menos una aplicación, que incluye el sistema operativo del servidor, el entorno de desarrollo (incluidas las bibliotecas), el DBMS, el CMS (sistema de gestión de contenidos), el servidor web y los navegadores compatibles (suponiendo que la interfaz de usuario de la aplicación se exponga a través de un navegador), además de los sistemas operativos en los que se ejecutan las distintas plataformas.

Cabe destacar que las pilas son recursivas: las plataformas pueden apoyarse en otras. También hay que tener en cuenta que algunas aplicaciones también pueden ser plataformas. SharePoint, por ejemplo, es una aplicación que también puede servir como entorno de desarrollo para crear aplicaciones personalizadas.

Prioridades: la salud de una pila es la salud media de sus componentes, puntuada mediante los criterios de proceso, marco y muestra documentados en la anterior entrega de esta serie.

¿Su prioridad? No hay una "mejor práctica" infalible para esto. Un enfoque que permite superar la complejidad es identificar la plataforma poco saludable que, si se remedia, mejora la mayor parte de las pilas. Para ilustrarlo, imagine que ha definido 60 pilas en su arquitectura técnica. Imagínese también que la plataforma menos saludable que tiene en producción es Windows Server 2003: póngale una puntuación de salud hipotética de -1,5.

En este ejemplo hipotético, imagine que al aumentar su puntuación a +2, 14 pilas pasan de -1 a 0 y otras 6 pilas pasan de 0 a +1. Es decir, 22 pilas mejoradas al arreglar Windows 2003 Server. El índice de prioridad de Windows 2003 Server es de 20 de las 60 pilas mejoradas: 0.33.

Repita la operación para cada componente de la plataforma y tendrá una forma útil de clasificar las prioridades de la plataforma.

Disposiciones: las disposiciones de la plataforma son similares a las definidas para las instalaciones e infraestructuras:

· Retirar: aunque es poco probable, es posible que identifiques plataformas que no están en uso. Apágalas, ciérralas y, de paso, asegúrate de cancelar los acuerdos de licencia y los contratos de soporte.

· Actualización: es posible que encuentres plataformas que no tienen soporte o que están obsoletas. Migrarlas a versiones más actuales del mismo producto.

· Sustituir: no es raro encontrar una plataforma obsoleta, sin soporte o, si hay una versión más nueva disponible, no la considera viable. Deshágase de ella, desplegando en su lugar una alternativa funcionalmente equivalente pero más saludable.

· Consolidar: es rara la arquitectura técnica que no tiene plataformas redundantes en uso. Entre los sistemas operativos de los servidores, los sistemas de gestión de bases de datos, los entornos de desarrollo integrados, etc., establecer como estándares de la empresa los que tengan los mejores índices de salud y migrar el resto a esos estándares puede ofrecer grandes oportunidades de simplificación y mejora.

 

Datos

En teoría, los repositorios de datos deberían considerarse objetivos independientes para mejorar las arquitecturas técnicas. En la práctica, se tratan como parte de la disposición de las aplicaciones, no como evaluaciones y planes independientes. Las disposiciones son similares a las definidas para las instalaciones y la infraestructura.

A excepción de los almacenes de datos de una organización y otros depósitos de análisis. Estos deberían tratarse como componentes separados de la capa de datos. Pero como son gestionados por las prácticas analíticas de la organización, son un problema de otros. Puede excluirlos con seguridad de su proceso de evaluación.

A no ser que una o varias disposiciones de la capa de plataforma afecten a un repositorio de análisis.

Ese es uno de esos casos en los que la arquitectura técnica se convierte en política.

 

Aplicaciones

Ahora se pone interesante.

Puede puntuar la salud de la aplicación de la misma manera que puntuó la salud de los componentes en las capas inferiores de su arquitectura técnica: sólo tiene que promediar las puntuaciones de los criterios de evaluación para obtener una puntuación global de la aplicación.

Prioridades: no es raro que incluso una empresa mediana tenga cientos o miles de aplicaciones en su cartera, por lo que establecer prioridades de una aplicación a la vez es poco práctico. Tampoco es una buena idea establecer prioridades en las aplicaciones. Es mucho mejor considerar la prioridad como una propiedad de las funciones de negocio y los mapeos de aplicaciones que ya ha documentado utilizando el modelo de capacidad de negocio.

En la mayoría de las arquitecturas técnicas, cada función de negocio está soportada por una, o posiblemente dos, aplicaciones centrales, a menudo módulos de un paquete ERP u otra suite amplia.

Las aplicaciones centrales están rodeadas de aplicaciones satélite que proporcionan la funcionalidad que falta en la aplicación central. Las aplicaciones satélite y las centrales comparten y sincronizan los datos entre sí.

Además, muchas funciones empresariales hacen uso de utilidades, es decir, aplicaciones que son independientes y que no necesitan integrarse con otras aplicaciones que apoyan la función empresarial en cuestión.

Para determinar las prioridades, comience por calcular un índice de salud de las aplicaciones de la función empresarial como la media ponderada de la salud de las aplicaciones que la soportan, asignando un factor de ponderación de 10 a las aplicaciones principales, de 3 a 7 a las aplicaciones satélite, dependiendo del tamaño y el alcance de cada una, y 1 para las utilidades.

Ya debería tener registrada la salud de la función empresarial que le proporcionó el equipo de arquitectura empresarial como parte de su BCM.

Su máxima prioridad es la función empresarial con la peor combinación de salud de la función empresarial y salud de la aplicación.

Disposiciones: los arquitectos técnicos tienen más alternativas disponibles para tratar con las aplicaciones que con las capas inferiores de la arquitectura técnica. En concreto, para cada aplicación pueden:

· Conservar: seguir utilizando la aplicación, manteniéndola y mejorándola a medida que cambian las necesidades del negocio.

· Reemplazar: deshacerse de la aplicación, sustituyéndola por una alternativa funcionalmente equivalente pero globalmente más saludable.

· Reemplazar la plataforma: "levantar y trasladar" la aplicación a un conjunto de plataformas de menor coste pero equivalentes.

· Refactorizar: reescribir la aplicación para que se ajuste a los estándares de ingeniería de su arquitectura técnica.

· Adaptar: si una plataforma va a cambiar (ver disposiciones de la plataforma, arriba), algunas aplicaciones tendrán que cambiar con ella.

· Consolidar: si una aplicación es redundante, es decir, si se utiliza una aplicación funcionalmente equivalente pero superior en otra parte de la empresa, migre a esa aplicación, especialmente si se ha considerado el estándar de la empresa para el futuro.

· Retirarse: desenchufe la aplicación y cancele sus licencias. Si la situación lo requiere, archive primero los datos de la aplicación.

¿Qué pasa con la nube? La nube no es irrelevante ni importante para este análisis hasta que haya terminado de asignar las disposiciones de la aplicación.

Una vez que haya hecho esto, si su estrategia tecnológica incluye migraciones a la nube, ésta podría ser la opción correcta para reemplazar, refactorizar o replantear una aplicación.

 

De las prioridades y disposiciones a un plan

Muchos arquitectos técnicos, impregnados del enfoque en cascada, consideran que una hoja de ruta, con una visión tipo carta de Gantt de un calendario de disposiciones, es el artefacto más importante a la hora de planificar las mejoras de la arquitectura técnica.

Pero una hoja de ruta es una reliquia del pensamiento en cascada. No tiene mucho sentido planificar los cambios de la arquitectura técnica más allá de la plataforma o función empresarial de máxima prioridad, hasta que el plan de disposición de máxima prioridad esté bien encaminado. Como hemos aprendido en el desarrollo ágil de aplicaciones, un plan hecho con demasiada antelación es un plan que quedará obsoleto mucho antes de que llegue el momento de ponerlo en marcha.

Gestionar la planificación de la arquitectura técnica mediante un backlog de estilo ágil es muy superior a una hoja de ruta clásica.