Gestión de la deuda tecnológica arquitectónica

Cuando pienso en deuda técnica, todavía recuerdo la primera aplicación que creé y que me hizo darme cuenta de las consecuencias de una arquitectura inadecuada. Sucedió a finales de la década de 1990, cuando comencé como consultor.

El cliente había solicitado el uso de la plataforma Lotus Notes para crear un sistema de adquisiciones para sus clientes. Utilizando el cliente Lotus Notes y una aplicación personalizada, los usuarios finales podrían realizar solicitudes que serían rastreadas por la aplicación y cumplidas por el equipo del propietario del producto. En teoría, era una idea realmente genial, especialmente porque las aplicaciones desarrolladas en la web no eran frecuentes y todo el mundo usaba Lotus Notes a diario.

El problema central es que los datos tenían un diseño muy relacional, y Lotus Notes no era una base de datos relacional. El diseño de la solución requería gestión de esquemas dentro de cada documento de Lotus Notes y se apoyaba en una serie de campos de valores múltiples para simular las relaciones entre los atributos de los datos. Fue un desastre.

No se habría requerido mucha lógica en la aplicación Lotus Notes si se hubiera recomendado una plataforma mejor. El código fuente era complicado de soportar. Las mejoras a la estructura de datos dieron como resultado una refactorización importante del código subyacente, sin mencionar la ejecución de trabajos basados en servidor para convertir los datos existentes. No me hagas hablar del esfuerzo detrás de la creación de informes.

Desde que comencé mi carrera, me he centrado en brindar la solución que el cliente quería en lugar de intentar ofrecer una mejor solución. Esta fue ciertamente una lección que aprendí al principio de mi carrera, pero en los años transcurridos desde ese proyecto, me he dado cuenta de que la consecuencia de la deuda técnica arquitectónica es una realidad desafortunada que todos enfrentamos.

Exploremos un poco más el concepto de deuda tecnológica arquitectónica a nivel macro.

Deuda tecnológica arquitectónica (ATD)

La Biblioteca de Deuda Técnica Arquitectónica (ATD) de la Universidad Carnegie Mellon proporciona la siguiente definición de ATD:

La deuda técnica arquitectónica es un enfoque de diseño o construcción que es conveniente en el corto plazo, pero que crea un contexto técnico en el que el mismo trabajo requiere reelaboración arquitectónica y cuesta más hacerlo más adelante de lo que costaría hacerlo ahora (incluido el aumento del costo con el tiempo). .

En la “Respuesta rápida: Cómo gestionar la deuda técnica de la arquitectura” (publicada el 22/09/2023), Gartner Group define ATD de la siguiente manera:

La deuda técnica de la arquitectura es ese tipo de deuda técnica que es causada por la deriva arquitectónica, decisiones arquitectónicas subóptimas, violaciones de la arquitectura del producto objetivo definido y las mejores prácticas arquitectónicas establecidas de la industria, y compensaciones de arquitectura realizadas para una entrega de software más rápida.

En ambos casos, los beneficios que a menudo generan celebraciones a corto plazo pueden enfrentarse a desafíos a largo plazo. Esto es similar a mi ejemplo de Lotus Notes mencionado en la introducción.

Para complicar aún más las cosas, faltan herramientas para ayudar a identificar y gestionar la deuda tecnológica para la arquitectura de software en comparación con otros aspectos del desarrollo de software:

Para la calidad del código, la observabilidad y SCA, existen herramientas probadas con productos como Sonarqube, Datadog, New Relic, GitHub y Snyk. Sin embargo, el segmento de arquitectura de software se ha quedado atrás sin soluciones probadas.

Esto es desafortunado, dado el hecho de que la ATD es consistentemente el tipo de deuda técnica más grande –y más dañina–, como se encuentra en el estudio “ ¿Medirlo? ¿Administrarlo? ¿Ignoralo? Profesionales de software y deuda técnica ” Estudio de 2015 publicado por Carnegie Mellon.

La siguiente ilustración resume la Figura 4 de ese informe, y concluye que las malas elecciones de arquitectura fueron el líder claro en fuentes de deuda técnica.

Si no se gestiona, el ATD puede seguir creciendo con el tiempo a un ritmo cada vez mayor, como se demuestra en esta sencilla ilustración:

Sin mitigación, la deuda de la arquitectura eventualmente llegará a un punto de ruptura para la solución subyacente que se está midiendo.

Gestión de ATD

Antes de que podamos gestionar ATD, primero debemos comprender el problema. Desmond Tutu dijo sabiamente una vez: "Sólo hay una manera de comerse un elefante: un bocado a la vez".

El enfoque de desplazamiento a la izquierda abarca el concepto de acercar un aspecto determinado al principio que al final de un ciclo de vida. Este concepto ganó popularidad con el cambio a la izquierda para las pruebas, donde la fase de prueba se trasladó a una parte del proceso de desarrollo y no a un evento separado que se completará una vez finalizado el desarrollo.

Shift-left se puede implementar de dos maneras diferentes en la gestión de ATD:

• Mayús hacia la izquierda para resiliencia: identificar fuentes que tienen un impacto en la resiliencia y luego solucionarlas antes de que se manifiesten en el rendimiento.
• Mayús hacia la izquierda para seguridad: detecta y mitiga problemas de seguridad durante el ciclo de vida de desarrollo.

Al igual que el cambio a la izquierda para las pruebas, un enfoque prioritario en la resiliencia y la seguridad durante la fase de desarrollo reducirá el potencial de incidentes inesperados.

Observabilidad arquitectónica

La observabilidad arquitectónica brinda a los equipos de ingeniería la capacidad de abordar de manera incremental la deriva arquitectónica dentro de sus servicios a un nivel macro. De hecho, el Wall Street Journal informó que el costo de arreglar la deuda técnica ascendía a 1,52 billones de dólares a principios de este año en el artículo “El problema invisible de los 1,52 billones de dólares: software antiguo y torpe”.

Para tener éxito, el liderazgo en ingeniería debe estar totalmente alineado con los siguientes objetivos organizacionales:

• Resiliencia: recuperarse rápidamente de incidentes inesperados.
• Escalabilidad: escalar adecuadamente con la demanda del cliente.
• Velocity: para ofrecer funciones y mejoras en línea con las expectativas del producto.
• Idoneidad de la nube: transformar soluciones heredadas en ofertas de servicios eficientes nativos de la nube.

Recientemente descubrí la plataforma de observabilidad arquitectónica impulsada por IA de vFunction , que se centra en los siguientes entregables:

• Descubra la arquitectura real de las soluciones mediante análisis estático y dinámico.
• Evite la deriva de la arquitectura mediante vistas en tiempo real de cómo evolucionan los servicios.
• Aumente la resiliencia de las aplicaciones mediante la eliminación de dependencias innecesarias y mejoras entre los dominios de las aplicaciones y sus recursos asociados.
• Gestione y remedie la deuda tecnológica mediante la observabilidad impulsada por la IA.

Además, la plataforma vFunction ofrece el beneficio adicional de ofrecer una ruta de migración para transformarse de soluciones monolíticas a soluciones nativas de la nube. Una vez que los equipos hayan modernizado sus plataformas, podrán observarlas continuamente para detectar cambios continuos. Si las empresas ya tienen microservicios, pueden usar vFunction para detectar la complejidad en aplicaciones distribuidas y abordar las dependencias que afectan la resiliencia y la escalabilidad. En cualquier caso, una vez implementado, los equipos de ingeniería pueden mitigar el ATD mucho antes de llegar al punto de ruptura.

En la ilustración anterior, los equipos de ingeniería pueden mitigar la deuda técnica como parte de cada versión, debido a la implementación de la plataforma vFunction y un enfoque subyacente de desplazamiento a la izquierda.

Conclusión

Mis lectores recordarán que me he centrado en la siguiente declaración de misión, que creo que puede aplicarse a cualquier profesional de TI:

“Concentre su tiempo en ofrecer características/funcionalidades que amplíen el valor de su propiedad intelectual. Aproveche los marcos, productos y servicios para todo lo demás”. - J. Vester

La plataforma vFunction cumple con mi misión al ayudar a los equipos de ingeniería a emplear un enfoque de desplazamiento hacia la izquierda para la resiliencia y seguridad de sus servicios a nivel macro. Esta es una distinción importante porque sin dichas herramientas, es probable que los equipos mitiguen a nivel micro, resolviendo la deuda tecnológica que realmente no importa desde una perspectiva organizacional.

Cuando pienso en esa aplicación que me hizo darme cuenta de los desafíos de la deuda tecnológica, no puedo evitar pensar en cómo esa solución generó más problemas que beneficios con cada característica que se introdujo. Ciertamente, el uso del desplazamiento a la izquierda solo para la resiliencia habría ayudado a sacar a la luz problemas con la arquitectura subyacente en un punto en el que el costo de considerar alternativas sería factible.

Si está interesado en obtener más información sobre la solución vFunction, puede leer más sobre ella aquí .

¡Que tengas un gran día!