Malas prácticas de arquitectura y cómo evitarlas

La arquitectura de software no vive aislada: se acopla a la metodología de desarrollo que use tu organización y a la forma en que los equipos entregan valor. Si eres arquitecto o aspiras a serlo, entender esta relación te permite diseñar sistemas que evolucionan, evitar bloqueos y comunicarte mejor con personas de otros saberes.

¿Cómo se relacionan las metodologías de desarrollo con la arquitectura?

Un arquitecto rara vez impone su propio método. Lo común es adoptar el estándar de la organización y, desde ahí, generar productos de valor agregado lo más rápido posible, dejando evidencia verificable de la ejecución mediante formas estándar como las fitness functions.

Históricamente, las metodologías en cascada entregaban valor después de muchos meses. El mercado migró hacia metodologías ágiles, que entregan valor en ciclos más cortos y enfatizan el feedback continuo con el cliente final. El arquitecto, entonces, debe evolucionar sus diseños para que sean compatibles con esa cadencia.

Existen también enfoques menos formales, como los spikes de arquitectura o tareas específicas de diseño. Y cuando no hay metodología definida, las compañías simplemente se sientan a codificar.

¿Qué es una fitness function en arquitectura de software? Es un índice compuesto que el arquitecto diseña y evalúa de forma continua para verificar que sus decisiones siguen alineadas con los objetivos de la arquitectura. Funcionan como pruebas unitarias, pero a nivel arquitectónico.

¿Cómo se entrega valor de forma cíclica en arquitectura?

Toda metodología implica entregar valor, y esa entrega es cíclica. No puedes desarrollar un sistema, entregarlo y dar por terminada tu interacción: los sistemas necesitan evolucionar y adaptarse.

Cada entrega tiene criterios de aceptación, una serie de chequeos que confirman si el producto es conforme con la especificación y con las promesas de valor del diseño. El periodo del ciclo es vital y varía según la cultura de la organización:

• Algunas compañías esperan un ciclo completo antes de dar retroalimentación.
• Otras buscan retroalimentación continua a lo largo del ciclo.
• Otras logran retroalimentación instantánea, como ocurre con herramientas de inteligencia artificial.

Los subproductos son los entregables de cada ciclo: tareas, spikes, definiciones, documentos. En metodologías clásicas, cada fase cerraba con un producto específico. En las iterativas, entregas varias versiones de los mismos subproductos cada vez que iteras.

La automatización influye además en la comunicación del equipo, que puede ser síncrona cuando coinciden en oficina, asíncrona, o asíncrona con periodos largos entre actividades.

¿Cuáles son las malas prácticas más comunes en arquitectura de software?

Como arquitecto, parte de tu trabajo es detectar bloqueos en el desarrollo o en la evolución de la arquitectura. Estos bloqueos suelen reconocerse por patrones de comportamiento o por una baja en la calidad de los entregables.

¿Qué es la ilusión de productividad?

Es la entrega continua de productos que no alcanzan el nivel necesario para llevarlos a producción. Genera iteraciones constantes sin avance real. Hoy, con herramientas de AI, esta ilusión es más frecuente: puedes entregar algo que parece completar la tarea, pero queda corto.

Antes de la AI existieron las herramientas de bajo código, y antes las herramientas CASE. El patrón se repetía: los desarrolladores entregaban automatizaciones del 80%, hacían hacks para alcanzar un 10% adicional, y nunca lograban modificar la herramienta para llegar al 100%.

¿Cómo evito caer en la ilusión de productividad con AI? Mantén un diseño cuidadoso, presta atención primaria a los detalles y evalúa cada entrega con métricas de calidad. No te quedes con el resultado superficial del bot.

¿Qué otras malas prácticas debes vigilar?

Más allá de la ilusión de productividad, estas son las trampas más recurrentes:

• Dependencias sobre proveedores o vendor lock-in: tu innovación y calidad quedan atadas a lo que te entrega el proveedor.
• Cargas analíticas en sistemas operacionales: calcular reportes agregados o información histórica usando sistemas que no fueron diseñados para eso.
• Resume-driven development: cuando los equipos o arquitectos priorizan lo que el trabajo aporta a su hoja de vida sobre los resultados reales.
• Parálisis por análisis: los equipos de desarrollo no avanzan porque los arquitectos demoran demasiado las decisiones.
• Sistemas infinitamente personalizables: intentar resolver problemas que aún no se presentan.

Después de identificarlas, necesitas un mecanismo sistemático para mantenerlas a raya.

¿Cómo usar fitness functions para mantener la calidad arquitectónica?

La forma más sólida de evitar malas prácticas es probar continuamente. Las fitness functions funcionan como pruebas unitarias del software, pero aplicadas a la arquitectura. Las construyes combinando varios elementos:

• Medidas y métricas de los componentes del sistema.
• Pruebas unitarias y de integración.
• Técnicas de ingeniería del caos, como fallas programadas en producción para validar la resiliencia ante eventos inesperados.
• Escaneos de seguridad.
• Monitoreos y observabilidad continua.

Con estos índices compuestos puedes verificar, decisión a decisión, que la arquitectura sigue cumpliendo los objetivos que prometiste cuando la diseñaste.

¿Qué ejercicio puedes aplicar hoy en tu organización?

Lista las modificaciones que tu organización hace a la metodología de desarrollo que sigue. Por ejemplo, en algunas no se cumplen todas las ceremonias ágiles; en otras se flexibilizan los criterios de aceptación o los niveles de pruebas.

Conocer estas adaptaciones es clave para entregar productos arquitectónicos con el nivel de calidad que tu organización exige. ¿Qué ajustes detectaste tú? Cuéntalo en los comentarios.