Deuda técnica a escala: cómo evitar la quiebra

La encrucijada es lo mismo por lo que tiene que pasar inevitablemente toda empresa de software que tenga éxito. No se trata de un MVP malo que haya superado la prueba de adecuación al mercado, sino de un sistema multifacético que da servicio a miles o millones de usuarios. Pero hay algo bajo la superficie. Las nuevas versiones tardan en llegar. Se dedican semanas al desarrollo de cambios sencillos. La velocidad a la que se corrigen los errores es mayor que la de los problemas antiguos. El código base hace que los ingenieros dediquen más tiempo a luchar que a crear nuevas funcionalidades. Este escenario se repite con alarmante frecuencia en el ámbito tecnológico. Empresas que parecían destinadas a convertirse en titanes se ven asfixiadas por su propio éxito inicial y deben elegir entre quedarse estancadas en un estado de indulgencia o reanudar su desarrollo con costosos esfuerzos de reingeniería. Los culpables no son los desarrolladores incompetentes ni la falta de recursos. Más bien, el origen se encuentra en las decisiones arquitectónicas básicas que se tomaron durante esos fatídicos meses iniciales, cuando la rapidez de comercialización era más importante que la mantenibilidad a largo plazo. Aprender cómo se mantienen las decisiones técnicas a lo largo del tiempo es una de las áreas de conocimiento más importantes para cualquier líder que dirija una organización tecnológica en crecimiento. Las decisiones que se tomen hoy acelerarán el crecimiento en el futuro o supondrán un lastre invisible que frenará todas las demás iniciativas. La diferencia entre las empresas que crecen y las que fracasan suele radicar en la sabiduría arquitectónica aplicada de manera adecuada y oportuna.

Hay atajos entre el prototipo y el software listo para la producción que están pensados para ser de corta duración, pero que tienen períodos de amortización muy largos. El desarrollo en las etapas iniciales se centrará inherentemente en la creación rápida de prototipos y la funcionalidad directa, en lugar de en cuestiones abstractas como la modularidad o la extensibilidad. Este método es absolutamente racional cuando el objetivo principal es la confirmación de las hipótesis, así como la captura de las oportunidades de mercado antes de la entrada de los competidores. Sin embargo, estas victorias tácticas pueden generar debilidades estratégicas. Las arquitecturas monolíticas que parecían atractivas para grupos pequeños resultan ser un obstáculo a medida que las organizaciones crecen. Los esquemas de bases de datos que son óptimos en un primer momento son difíciles de modificar para adaptarse a nuevas funciones. Cientos de sistemas de autenticación de usuarios se colapsan ante miles de usuarios. Los patrones de integración que eran eficaces con unos pocos servicios de terceros resultan incontrolables debido a la escala del ecosistema.

Una API ineficiente puede gestionar sin problemas la carga de tráfico actual, pero colapsará estrepitosamente cuando la utilización se duplique. Un código base muy compacto puede permitir un desarrollo rápido de funciones al principio, pero el desarrollo paralelo puede resultar aún más difícil a medida que aumenta el tamaño del equipo. Las empresas suelen malinterpretar estos síntomas como dificultades temporales y no sistémicas que requieren una corrección arquitectónica. Los directivos pueden creer que un mayor número de ingenieros acelerará el proceso de desarrollo, solo para darse cuenta de que la sobrecarga de coordinación y los conflictos de código ralentizan el desarrollo. Los problemas que surgen con el rendimiento se resuelven aumentando la potencia de los servidores en lugar de realizar una mejora básica de la eficiencia. Los problemas de seguridad se resuelven con una solución puntual en lugar de una revisión del sistema. Las ramificaciones económicas y el alcance van mucho más allá de la productividad en ingeniería. La experiencia de los clientes se ve afectada porque los sistemas son menos estables y receptivos. Cuando la plataforma no es capaz de dar cabida a posibles clientes empresariales, se pierden oportunidades de venta. Las ventajas competitivas se reducen porque las funciones se desarrollan lentamente. Esto dificulta el proceso de contratación, ya que los ingenieros no quieren trabajar en organizaciones que tienen disfunciones técnicas.

Creación de una arquitectura modular

Para desarrollar una arquitectura eficaz, es necesario conocer los principios que ayudan a crear un buen diseño, así como las limitaciones prácticas que deben tenerse en cuenta a la hora de decidir si implementar algo o no. La base comienza con la modularidad y la separación de funciones. Los sistemas desarrollados estructuran la funcionalidad en elementos discretos, interfaces definidas y responsabilidades. Esta estrategia permite a los equipos crear y realizar cambios o sustituir partes individuales sin alterar el sistema en su conjunto. Las arquitecturas orientadas a servicios son una buena representación de este concepto en general. En lugar de desarrollar aplicaciones monolíticas con todas las funcionalidades utilizando el mismo código base e implementándolas de manera similar, las organizaciones pueden dividir los sistemas en servicios dedicados que interactúan a través de API coherentes. Los servicios son independientes y pueden ser desarrollados, probados e implementados por diferentes equipos simultáneamente sin interferir entre sí.

El truco consiste en definir contratos distintos entre las diversas secciones del sistema y no tener un acoplamiento estrecho que provoque que los cambios se propaguen en todas direcciones a lo largo de todo el código base.

Consideraciones sobre la arquitectura de datos

Se debe prestar especial atención a la arquitectura de datos, ya que estas decisiones pueden ser las más costosas de revertir en el caso de las bases de datos. El esquema de optimización de casos de uso puede suponer un serio obstáculo a la hora de cambiar los requisitos. Las empresas eficaces invierten en modelos de datos lo suficientemente flexibles como para soportar el crecimiento sin tener que realizar migraciones a gran escala. Esto podría tener la siguiente forma:

• La selección de bases de datos de documentos en lugar de bases de datos relacionales en función de tus necesidades.
• El uso de una estrategia de control de versiones de datos.
• La creación de API que ocultan las implementaciones de almacenamiento subyacentes.

Equilibrar las necesidades presentes y futuras

Los requisitos de escalabilidad deben encontrar un equilibrio entre los requisitos actuales y las oportunidades futuras. Cuando se diseñan soluciones excesivamente complejas para problemas que tal vez nunca lleguen a existir, se desperdician recursos y se complican las cosas más de lo necesario. Las soluciones insuficientemente diseñadas para adaptarse al crecimiento previsible provocan una deuda técnica que crece exponencialmente. La mejor solución es reconocer los cuellos de botella de escalabilidad en las primeras etapas e implementar una arquitectura que pueda escalar con elegancia bajo carga.

Observabilidad y seguridad

La observabilidad es otro factor arquitectónico fundamental que no suele tenerse en cuenta en las etapas iniciales del desarrollo. Cualquier sistema que carezca de funciones completas de registro, supervisión y depuración se vuelve más difícil de mantener a medida que aumenta su complejidad. Es mucho más económico incorporar la observabilidad en toda la arquitectura desde el principio que hacerlo posteriormente, pero la experiencia adquirida es muy valiosa para la optimización y la resolución de problemas. Lo mismo se aplica a la arquitectura de seguridad, que también es una inversión inicial. La adopción de los componentes básicos de autenticación, autorización y protección de datos permitirá desarrollar funciones rápidamente sin incurrir en deuda de seguridad. Por otro lado, el enfoque de la seguridad como algo secundario tiende a ser costoso de rediseñar en los casos en que se modifican las necesidades de cumplimiento o los modelos de amenazas.

Toma de decisiones técnicas

Las empresas que quieran evitar las trampas arquitectónicas deben implementar modelos de toma de decisiones técnicas que sopesen de manera equilibrada el ritmo a corto plazo y la resistencia a largo plazo. Esto incluye:

• Desarrollar procedimientos de revisión arquitectónica sobre las principales decisiones técnicas.
• Documentar las compensaciones.
• Evalúa con frecuencia la deuda técnica incurrida en relación con la prioridad empresarial.

Pruebas e integración

La inversión en pruebas automatizadas e integración continua también tiene su recompensa, ya que permite refactorizar con confianza y realizar inversiones arquitectónicas. Cuando los equipos pueden confirmar rápidamente los cambios, tienen más probabilidades de implementar ajustes proactivos en lugar de posponer indefinidamente el proceso de mantenimiento. El desarrollo paralelo también es posible gracias a conjuntos de pruebas completos que identifican los problemas de integración en una fase temprana.

Revisión de código e intercambio de conocimientos

La revisión de los códigos debe comprobar tanto las implicaciones arquitectónicas como la corrección en el funcionamiento. Las revisiones que solo se centran en la funcionalidad inmediata no permiten detectar y solucionar los problemas estructurales antes de que se arraiguen. Se puede mejorar la calidad de las decisiones en toda la organización formando a los ingenieros para que identifiquen y comuniquen las compensaciones arquitectónicas.

Las frecuentes presentaciones técnicas y reuniones de arquitectura permiten mantener un entendimiento común en el contexto de los equipos de ingeniería en expansión.

Revisiones periódicas de la arquitectura

Las evaluaciones arquitectónicas periódicas brindan la oportunidad de tomar cierta distancia del desarrollo diario y analizar el estado de los sistemas a mayor escala. Dichas revisiones deben determinar hacia dónde se ha dirigido la deuda técnica, si las arquitecturas actuales satisfacen las necesidades del negocio y qué se puede hacer para mejorarlas con el fin de ofrecer el máximo rendimiento de la inversión en ingeniería.

El proceso posterior al inicio para alcanzar la escala está ligado a la evolución arquitectónica, pero no tiene por qué implicar costosas reescrituras o incluso un estancamiento en el desarrollo. Las empresas que toman decisiones arquitectónicas prudentes desde el principio están en mejor posición para alcanzar la sostenibilidad, mientras que las que pasan por alto los aspectos estructurales suelen acabar quedando desamparadas por sus propios logros. La mayoría de las empresas tecnológicas que presumen de modelos exitosos no consideran la arquitectura como una decisión, sino como una disciplina continua. Desarrollan sistemas capaces de evolucionar con elegancia, invierten en las herramientas y los procesos necesarios para que puedan realizar cambios con confianza y tienen los conocimientos de arquitectura necesarios para tomar buenas decisiones cuando realmente importa. El coste de la disciplina arquitectónica no es nada en comparación con el coste de la quiebra técnica. Al darse cuenta de que las decisiones tomadas en una fase temprana se multiplican con el tiempo y mediante la aplicación coherente de principios arquitectónicos probados, las organizaciones podrán desarrollar software que solo aumentará su éxito a largo plazo. La cuestión no es si surgirán problemas arquitectónicos, sino si se detectarán y se abordarán antes de que se conviertan en problemas aparentemente insuperables.