Eche un vistazo a la primera parte de este post donde exploramos qué es la deuda técnica, si siempre es mala y las estrategias para gestionarla.

¡Ahora, volvamos a sumergirnos! La deuda técnica adopta diversas formas, y las empresas pueden tener problemas con varios tipos de deuda al mismo tiempo. Analicemos los cuatro primeros tipos de deuda técnica y descubramos los dos últimos en nuestro próxima final post de la serie.

#1: Deuda de mantenimiento

¿Qué es?

La deuda de mantenimiento se genera cuando los datos, el software, los sistemas y el código quedan desatendidos con el tiempo, lo que genera una acumulación de actualizaciones, mejoras, lanzamientos de funciones o una acumulación de código «muerto».

Esta deuda puede acumularse debido a un cambio en las prioridades o al descuido del mantenimiento de los datos tras la partida de las personas o equipos responsables.

¿Qué aspecto tiene?

Se puede observar en las fallas inesperadas, la inflexibilidad en la integración, los riesgos de seguridad y la degradación del rendimiento. Estos problemas se deben a que los sistemas posteriores funcionan con datos, software y sistemas heredados desactualizados o a la falta de actualizaciones.

El principal impacto negativo; Sincronización. No es lo mismo aplicar soluciones siguiendo un cronograma planificado o una estrategia preventiva que tener que dejar de hacer lo que se está haciendo e incumplir los plazos para aplicar soluciones inesperadas.

#2: Deuda de decisión

¿Qué es?

Se produce cuando las decisiones miopes que se toman para lograr objetivos a corto plazo provocan problemas a largo plazo en los sistemas, las herramientas, la infraestructura, la arquitectura o la capacidad de escalar. Básicamente, se toman decisiones en favor de ganancias a corto plazo.

¿Qué aspecto tiene?

La deuda de decisión puede considerarse como conjuntos tecnológicos anticuados que pueden resultar difíciles de mantener o escalar en el futuro, la selección de proveedores o vendedores de nube con funciones limitadas, el lanzamiento de productos sin la documentación adecuada, la implementación de nuevas soluciones sin pruebas suficientes o la selección de sistemas más baratos a expensas de la seguridad y la autenticación para llegar al mercado más rápido.

Blockbuster y Blackberry son ejemplos de deuda por decisión técnica. Blockbuster se olvidó de invertir en una plataforma digital y Blackberry no pudo mantenerse al día con las innovaciones de su mercado. Ganancias a corto plazo en comparación con la capacidad de mantenimiento, la estabilidad y la escalabilidad a largo plazo.

#3: Deuda de estabilidad

¿Qué es?

Cuando la acumulación de diferentes deudas técnicas desestabiliza la infraestructura tecnológica de una empresa. Cuando la infraestructura subyacente quede obsoleta, sin soporte o inestable, todo el sistema será más propenso a sufrir errores, bloqueos y otros tipos de vulnerabilidades.

¿Qué aspecto tiene?

Muchas veces esto se hace visible al escalar, ya que, a medida que las empresas crecen y evolucionan, los sistemas se vuelven cada vez más complejos y más difíciles de mantener, lo que genera problemas.

#4: Deuda de eficiencia de los desarrolladores

¿Qué es?

Este tipo de deuda está directamente relacionada con los flujos de trabajo de ingeniería y las mejores prácticas. Básicamente, se refiere a los atajos relacionados con las mejores prácticas de desarrollo, como la contribución, las pruebas, la supervisión y las alertas, que pueden provocar problemas con los tiempos y procesos de implementación y construcción en el futuro.

¿Qué aspecto tiene?

La deuda por eficiencia de los desarrolladores puede acumularse de muchas formas diferentes. Las señales de este tipo de deuda técnica pueden incluir tiempos de implementación que van desde los minutos esperados hasta horas o incluso días. O prácticas de detección deficientes que permiten que los problemas pasen desapercibidos y aparezcan inesperadamente, a veces incluso después del lanzamiento. Por ejemplo, encontrar errores tras el lanzamiento de nuevas funciones es un claro indicio de este tipo de deuda.

Pagar la deuda técnica: un estudio de caso de EdTech

Profundicemos con un ejemplo real de una empresa que se enfrenta a varios tipos de deuda técnica simultáneamente y algunas medidas adoptadas por Mutt Data para abordar dicha deuda. He aquí una instantánea de nuestro trabajo reciente en la industria de la tecnología educativa.

Deuda de decisión

Las empresas emergentes priorizan la adaptación al mercado y el tiempo de comercialización por encima de un análisis cuidadoso de la arquitectura, las herramientas o los fundamentos de la práctica, lo que genera una deuda técnica. Este proyecto no fue la excepción, ya que el objetivo era poner las funciones en producción rápidamente con una opción de reversión si fuera necesario.

Para resolver esta deuda, aplicamos un proceso de descubrimiento exhaustivo, que investiga la industria, el negocio y la estrategia del cliente para brindar asesoramiento sobre las capacidades técnicas, lo que nos permite descubrir problemas y deudas más profundos. Luego clasificamos los problemas y las deudas, priorizamos y diseñamos un plan de acción. ¿Nuestros hallazgos? La disponibilidad de los datos estaba disminuyendo, las canalizaciones no eran rentables y los desarrolladores representaban un obstáculo para la analítica. Había varios tipos de deuda tecnológica que actuaban en conjunto.

TLDR: La empresa daba prioridad a la escalabilidad a corto plazo por encima de la escalabilidad a largo plazo. La elección de las herramientas se basó en la familiaridad y la comodidad, no en la capacidad de mantenimiento a largo plazo.

Deuda de eficiencia del desarrollador

El desarrollo se había vuelto ineficiente, no había una hoja de ruta clara para la propiedad, había demasiadas dependencias entre los empleados, lo que generaba fricciones, y la falta de una fuente de verdad única y egoísta era un problema claro.

TÍTULO: La falta de herramientas y mejores prácticas de gobernanza, calidad, detección de anomalías, monitoreo y prueba de datos estaba provocando retrasos en los tiempos de desarrollo y procesamiento, lo que afectaba a la operación de análisis de datos. No se sabía con certeza la calidad de los datos y los problemas pasaban desapercibidos.

Para resolver esta deuda hicimos lo siguiente:

• Flujo de aire (MWAA) se usó para administrar las canalizaciones de datos, reemplazando el programador de flujo de trabajo del cliente por una solución escalable.
• Se incrementaron las pruebas, el monitoreo, la detección de anomalías y la gobernanza de datos. Implementación nuestro proyecto de software libre SoAM, DBT, Grandes expectativas
• El CI/CD se configuró para probar automáticamente las cargas incrementales y los pasos de reversión.

Deuda por eficiencia de mantenimiento

Muchos de los cambios necesarios para corregir la deuda de los desarrolladores estaban bloqueados por la falta de actualizaciones en las herramientas o los sistemas actuales. Esto demuestra el efecto negativo que tener en cuenta las actualizaciones e implementar las correcciones oportunas puede tener sobre tu capacidad ágil de cambio, iteración, aplicación, etc. Para solucionarlo, nosotros:

• Airflow actualizado, su versión actual bloqueaba el proyecto.
• Cambiado MAWA por Astrónomo (¡nuestro socio tecnológico! 🚀) como nuestro proveedor de Airflow. MWAA generaba problemas durante la depuración. Esto también redujo significativamente los costos de mantenimiento práctico.
• Establezca las mejores prácticas para supervisar de cerca y realizar un seguimiento de las actualizaciones de las herramientas y mantener un registro de las posibles mejoras del código de una manera que los equipos de mantenimiento puedan ver.
• Creamos mapas claros de propiedad de los sistemas para facilitar la detección rápida de sistemas desatendidos y designamos a las personas responsables (DRI) aumenta la probabilidad de mantenimiento.

Deuda de estabilidad

La empresa había crecido, lo que hacía que los sistemas fueran complejos y difíciles de mantener. Una infraestructura anticuada, la falta de un lago de datos o una estructura centralizada similar y los sistemas no compatibles generaban problemas y consultas prolongadas con tiempos de ejecución prolongados.

• Implementamos un Lago de datos. Separe el consumo de datos en Redshift de la ingestión y la puesta en escena de las integraciones y fuentes de datos productivas, como las bases de datos transaccionales y los rastreadores.
• Optimice los procesos críticos relacionados con las canalizaciones de experimentación.
• Cree varios recursos para generar consultas que viajan en el tiempo y reducir la carga de trabajo de Redshift.
• Diseñe paneles para lograr la supervisión de los activos críticos de la arquitectura. Incluyendo el impacto simultáneo de las consultas, las tareas de Airflow, las canalizaciones programadas y el volumen de datos. Nos permite detectar canalizaciones o consultas que ponen en peligro la estabilidad de la pila.
• Genere una hoja de ruta para superar los puntos problemáticos de la infraestructura y prepárese para escalar adecuadamente.

Impacto final

• Permitió al cliente iterar el desarrollo de productos más rápido, confiando en su arquitectura para hacer crecer sus operaciones con datos.
• Los tiempos de ejecución de las consultas se redujeron de varias horas a minutos.
• Los desarrolladores se dieron cuenta de la importancia de la calidad de los datos y de las ventajas de usar herramientas de gobierno de datos, lo que los motivó a seguir de manera consistente las mejores prácticas.

El aprendizaje más importante que obtuvimos es la implementación de la calidad de los datos y la participación de los desarrolladores para que sean conscientes de ello y se preocupen por ello. Después de eso, las herramientas de gobernanza de datos (por ejemplo, DataHub) podrían ofrecer ventajas aún mayores si se combinan con las funciones de calidad y observabilidad de los datos.

No hace falta decir que este fue un estudio de caso abreviado para mantenerlo algo resumido. Puede consultar el estudio de caso detallado en El punto de vista de ClassDojo, desde Nuestro punto de vista o desde El punto de vista de Amazon Web Service.