Las trampas ocultas de la selección de la pila tecnológica: una guía para directores técnicos

La tasa de fracaso de los proyectos tecnológicos empresariales es bastante sorprendente, ya que aproximadamente el 70 % de ellos no tienen éxito debido a una mala elección de las pilas. Los líderes tecnológicos suelen sentirse atraídos por las nuevas arquitecturas y las herramientas de última generación, pero estas decisiones suelen generar una elevada deuda técnica y costosas reescrituras del sistema. Los errores más comunes son previsibles: centrarse en tecnologías de moda en lugar de en la alineación empresarial, ignorar la necesidad de mantenimiento a lo largo del tiempo y elegir herramientas que no se ajustan a los conocimientos del equipo. Estos errores provocan costosas modificaciones, cuellos de botella en el rendimiento y desmotivación en los equipos de desarrollo. El análisis presenta casos reales en los que los proyectos se vieron frustrados debido a decisiones tecnológicas erróneas, y se determinan las razones que motivaron el fracaso tecnológico. A partir de estudios de casos prácticos, ofrecemos marcos prácticos que pueden servir de guía a los líderes tecnológicos para tomar decisiones informadas que contribuyan a los objetivos de la empresa, aprovechen los puntos fuertes del equipo y permitan un crecimiento sostenible.

Los ejecutivos del sector tecnológico caen repetidamente en trampas reconocibles que socavan sus elecciones de pila. Las nuevas tecnologías son un tema de debate que suele oscurecer la visión de los impactos a largo plazo y las cuestiones relacionadas con la implementación práctica. La deuda técnica es acumulativa, ya que no hay ninguna advertencia de que una organización se encuentre en una trampa financiera de sistemas costosos e ineficientes que obstaculizan, en lugar de apoyar, el crecimiento del negocio.

El atractivo de las tecnologías en auge

Los directores técnicos suelen seleccionar tecnologías que están de moda en el sector y no aquellas que son necesarias desde el punto de vista estratégico. Este estilo genera enormes diferencias entre las necesidades empresariales y la expansión técnica. El atractivo de las nuevas estructuras tiende a sustituir a los criterios de evaluación prácticos. La validación social resulta ser una sustitución perjudicial de la toma de decisiones basada en pruebas. Las organizaciones están siguiendo las últimas tecnologías debido a la presión de parecer modernas como todo el mundo y porque esa iniciativa es ambiciosa y atractiva. La consecuencia de esta mentalidad gregaria es la introducción de soluciones complejas que requieren una gran cantidad de soluciones alternativas y mantenimiento adicional.

Conclusión sobre el mantenimiento tácito

Las organizaciones a menudo no ven el panorama completo de la inversión en tecnología, en el sentido de que el desarrollo inicial no es el final. El análisis de software empresarial demuestra que, en bases de código grandes, el mantenimiento representa aproximadamente el 75 % del esfuerzo total. Esta carga continua implica:

• Pruebas
• Detección y corrección de errores.
• Ajuste del rendimiento
• Pruebas de compatibilidad.
• Reestructuración
• Servicio de atención al cliente
• Documentación

Las suscripciones a software generan nuevos costes ocultos. Aunque al principio no son costosas, a largo plazo se incurren en gastos, especialmente con la ampliación de los equipos y la necesidad de comprar más licencias. Las funciones premium, los servicios de asistencia y las actualizaciones de almacenamiento suelen tener cargos ocultos que no eran evidentes en el momento de la evaluación.

Desalineación de las capacidades del equipo

La alineación de las habilidades del equipo es uno de los aspectos importantes que no deben pasarse por alto a la hora de seleccionar la tecnología. Al desarrollar nuevas estructuras, las organizaciones tienden a seleccionar marcos sin evaluar a sus desarrolladores para comprender cuánta experiencia tienen en el proceso adecuado de implementación y mantenimiento. Los equipos que desarrollan con tecnologías con las que no están familiarizados tienen que lidiar con:

• Curvas de aprendizaje pronunciadas.
• Ciclos de desarrollo más lentos.
• Mayores índices de defectos.
• Mala calidad de la implementación.

El liderazgo puede ser técnico y sobreestimar el costo de las especificaciones técnicas y subestimar el costo de la formación, la complejidad de la incorporación y las pérdidas de productividad. Las herramientas que no se ajustan a las capacidades del equipo dan lugar a una adopción deficiente y a un bajo rendimiento de la inversión. Piensa en la selección de Ruby on Rails: a menudo se elige por su rapidez en el desarrollo, su facilidad y su amplia variedad de bibliotecas que ayudan a crear prototipos rápidamente. Sin embargo, estas ventajas solo se hacen realidad cuando los equipos ya tienen conocimientos de Ruby. La curva de aprendizaje debe estar acorde con la experiencia de los desarrolladores, de modo que no se produzcan cuellos de botella en la productividad. La mejora forzada de las habilidades en mitad del proyecto puede destruir los beneficios obtenidos.

Cuando los proyectos tecnológicos fracasan, analizamos casos prácticos de diferentes sectores y empresas de distintos tamaños para comprender las razones. Ambas organizaciones se enfrentaron a graves problemas técnicos que pueden estar directamente relacionados con las decisiones sobre la pila tecnológica. Las causas fundamentales resultaron ser inesperadamente similares, entre arquitecturas demasiado complicadas y problemas de rendimiento y escalabilidad. En esta sección se señalan tres casos ilustrativos en los que se produce un desajuste entre las decisiones sobre la pila y los requisitos del producto o las capacidades del equipo.

Complejidad de los microservicios en aplicaciones simples

Una startup de SaaS sufrió las consecuencias de adoptar microservicios de forma prematura. En más de 18 meses, la empresa ha desarrollado diversas tecnologías dispares, lo que ha dado lugar a un debate sobre la fragmentación del sistema, cuya propiedad ha ido cambiando de manos entre los miembros del equipo. Al principio, este sistema parecía ser innovador, ya que dividía las aplicaciones en aplicaciones más pequeñas que, en teoría, eran escalables. Sin embargo, la falta de miembros del equipo con experiencia o atención para gestionar eficazmente la plataforma convirtió el sistema en uno caótico. El error fundamental fue introducir una arquitectura complicada antes de que el producto lo requiriera. Los microservicios son una forma de hacer frente a la complejidad, pero no son un privilegio gratuito. En lugar de facilitar el crecimiento, el enfoque de los microservicios resultó ser una losa para un producto que requería una iteración de alta velocidad, en contraposición a la sobrecarga de los sistemas distribuidos. En algún momento, la empresa no pudo añadir nuevos campos ni utilizar algunos activadores de API debido a las limitaciones de la plataforma, lo que provocó fallos en las funciones básicas. La solución compleja se descartó por completo debido a la frustración de los miembros del equipo, que pasaron a utilizar hojas de cálculo en lugar de la pila sobredimensionada.

Limitaciones de rendimiento en aplicaciones de juegos

Una empresa de videojuegos probó React Native para crear un juego móvil de alto rendimiento, lo que generó dificultades técnicas insuperables en experiencias con gráficos intensivos. Aunque React Native tenía ventajas de desarrollo multiplataforma, esencialmente carecía de la capacidad de rendimiento necesaria para soportar los requisitos altamente complejos de los videojuegos. El equipo de desarrollo descubrió que el rendimiento del hilo JavaScript estaba muy mermado. Por mucho que React Native afirme ser capaz de proporcionar al menos 60 fotogramas por segundo, la aplicación perdía fotogramas continuamente cuando se utilizaban animaciones e interacciones complicadas. El diagnóstico del rendimiento indicó que cualquier proceso que requiriera más de 100 ms creaba un retraso para el usuario. Estas restricciones eran desastrosas para los juegos que necesitaban una física o un renderizado más complejos. El equipo intentó optimizar los módulos nativos, pero la disparidad básica de la herramienta y la necesidad seguían persistiendo. Si bien React Native permite desarrollar en diferentes plataformas utilizando un solo conjunto de códigos, esto perdió importancia cuando el producto final ni siquiera podía cumplir con un estándar mínimo de rendimiento.

Vulnerabilidades de escalabilidad de bases de datos en aplicaciones financieras

Se lanzó una aplicación financiera de tecnología financiera con una base de datos SQL monolítica más antigua y, al principio, funcionó bien. Sin embargo, a medida que aumentaba el volumen de transacciones, el sistema fue incapaz de rendir y escalar. La latencia y los retrasos en el procesamiento por lotes hacían prácticamente imposible el análisis en tiempo real. El principal error cometido por el director técnico fue no prever las necesidades de escalabilidad del procesamiento de datos financieros. El diseño de la base de datos no fue concebido para admitir:

• Escalado horizontal.
• Métodos de equilibrio de carga.
• Volúmenes máximos de transacciones.

El rendimiento se volvió muy deficiente y el tiempo de respuesta a la consulta se prolongó hasta varios minutos. Esta degradación fue desastrosa en aplicaciones en las que la velocidad de las transacciones es muy importante para el usuario y en aplicaciones financieras. Tras realizar una exhaustiva evaluación técnica, la empresa ha migrado a una base de datos distribuida con arquitectura HTAP (procesamiento híbrido transaccional/analítico). Este cambio ha permitido procesar miles de transacciones por segundo con baja latencia y, al mismo tiempo, realizar análisis en tiempo real.

En los casos prácticos, se observaron tres patrones de fallos que provocaban fallos en la pila tecnológica. Todos los patrones son indicadores de una grave desconexión en los enfoques de selección e implementación de tecnología en las organizaciones.

Desalineación de la complejidad empresarial-tecnológica

Uno de los errores más comunes en la elección de la pila tecnológica es cuando las organizaciones obtienen una arquitectura artificialmente complicada que no se ajusta a las demandas del negocio. La mayoría de las empresas presentan varias capas y subsistemas, cada uno de los cuales se supone que es el mejor del sector, pero el sistema en su conjunto es lento, poco fiable y caro. El resultado de esta práctica es:

• Aplicaciones más lentas debido a un gran número de capas.
• Complicado por múltiples traspasos.
• Poco fiable, ya que cada capa tiene diferentes modos de fallo.

En el caso de las empresas basadas en los clientes, cualquier elección inadecuada de la pila tecnológica tiene un efecto directo en la experiencia del cliente, en términos de tiempos de carga lentos e interrupciones del servicio, lo que aumenta las tasas de abandono.

Deuda técnica y refactorización

Invertir temprano en tecnología inadecuada genera una deuda técnica que cada vez es más difícil de resolver. De hecho, la mayor parte del presupuesto de TI de las empresas se destina al mantenimiento y soporte de software, y no a la innovación. Una vez que las organizaciones han realizado una gran inversión en pilas problemáticas, la falacia del coste hundido puede impedir que se produzcan los cambios necesarios. La refactorización debe ser valiosa y centrarse en abordar las necesidades reales, en lugar de en especulaciones. La refactorización a gran escala, que no puede acomodarse en los procesos de desarrollo normales, supone un reto para muchas organizaciones. La remodelación de los elementos arquitectónicos básicos suele implicar la eliminación y recreación de recursos, lo que expone a riesgos importantes datos empresariales.

Debilidades en la documentación y la incorporación

Las deficiencias y debilidades de la documentación de la empresa generan altos costos ocultos, ya que el proceso de incorporación es más largo de lo necesario cuando las prácticas de documentación son deficientes. Muchos departamentos de ingeniería se están quedando atrás en la producción de documentación interna de calidad, pero el precio de la inconsistencia es mucho más alto que el gasto que supone integrar la documentación en los procesos. Los nuevos miembros del equipo pierden mucho tiempo buscando y redescubriendo respuestas, o cometen errores que se podrían evitar si la información estuviera debidamente documentada. Esta situación provoca un alto nivel de retrasos en la productividad, ya que algunos desarrolladores no pueden trabajar de forma eficaz durante semanas e incluso meses.

Para evitar las trampas de selección de pilas, es esencial ir más allá de evitar las palabras de moda. Requiere que pienses detenidamente en lo que estás construyendo, en la persona que lo construye y en la forma en que tu sistema crecerá y se desarrollará.

Define el alcance del producto

Antes de comparar herramientas, determina el propósito y la vida útil prevista del producto. ¿Se trata de un MVP que se desarrolla rápidamente y tiene objetivos a corto plazo? ¿O una plataforma que se supone que crecerá progresivamente en cinco años? Además, anticipa la evolución. Cuando anticipes integraciones, análisis o la adición de roles de usuario, elige una pila que sea utilizable en esos escenarios sin tener que reconstruir toda la pila.

• En productos a corto plazo, los sistemas de desarrollo rápido (por ejemplo, MEAN o Firebase) proporcionarán velocidad y flexibilidad.
• Para sistemas a largo plazo, céntrate en arquitecturas modulares y fáciles de mantener que no necesiten reescribirse en gran medida.

Sobre el papel, una pila puede parecer perfecta, pero cuando nadie en tu equipo es capaz de depurar nada en producción, ni siquiera de ajustar la pila para que funcione mejor, se convierte en un lastre.

• Selecciona tecnologías con las que tus ingenieros ya estén familiarizados en caso de que haya presión por los plazos de entrega.
• Planifica con antelación el uso de una pila compatible con el futuro, pero reserva tiempo para auditar el código, incorporar nuevos miembros y formar al personal.

Ten en cuenta los requisitos externos.

Las selecciones de pila no se realizan en el vacío. Las necesidades de cumplimiento, presupuesto e integración, entre otras, son necesidades del mundo real que deben reflejarse en todos los niveles de tu arquitectura. Cumplimiento normativo y seguridad: en el ámbito de la tecnología financiera o la asistencia sanitaria, asegúrate de que tu pila sea compatible con los registros de auditoría, el control de acceso basado en roles y el cifrado siempre compatible con versiones posteriores. Presupuesto: Ten en cuenta las licencias, la infraestructura, los servicios gestionados y el coste de otros gastos ocultos, como el uso de API de terceros o incluso el bloqueo. Integración: Tu pila podría fallar si no se integra con otros sistemas. Acumula el flujo de datos hacia arriba y hacia abajo.

Medir la sostenibilidad a largo plazo

Lo que ahora es sostenible puede que mañana sea débil. Busca:

• Actualizaciones estables: las actualizaciones inestables o la falta de apoyo de la comunidad pueden convertirse en un problema.
• Ecosistema bien documentado y consolidado: esto facilitará la incorporación y reducirá la dependencia de los conocimientos especializados internos.
• Simplicidad operativa: cuando tu pila necesite ajustes o mantenimiento de DevOps, es posible que no se adapte a un equipo pequeño.

Rendimiento y complejidad operativa

Elegir una pila implica una compensación:

• Modelo de escalabilidad: ¿Puedes escalar horizontalmente con la adición de más instancias, o estás limitado a escalar verticalmente con un monolito?
• Rendimiento bajo carga: ¿Algunas pilas son mejores para realizar transacciones simultáneas y ligeras (por ejemplo, Node.js), o son mejores para ejecutar transacciones con procesadores transaccionales pesados (por ejemplo, Spring Boot)?
• Complejidad de la operación: ¿Tu equipo se despliega y mantiene de forma fiable o se trata de una operación precaria que estás poniendo en marcha?

Toma decisiones sobre la pila que faciliten el crecimiento y no la deuda técnica.

No hay ninguna pila que sea a prueba de futuro, pero hay algunas que son más flexibles. La decisión correcta debe estar en consonancia con tu visión empresarial, la misión de tu producto y las competencias y requisitos de escala de tu equipo. Esto permite un rápido crecimiento en nuestro tiempo y no supone una carga en el futuro. Los directores técnicos más eficaces no se limitan a seleccionar herramientas. Crean sistemas que perduran.

Crear una pila tecnológica es una de las decisiones más importantes que toman los directores técnicos a lo largo de su carrera. Si se hace correctamente, la hace escalable, eficaz y capaz de ofrecer resultados más rápidos. Si se hace mal, provocará deuda técnica, estancamiento de la innovación y frustración en los equipos de trabajo. Ten cuidado de no tomar decisiones al principio que te frenen en el futuro. Piensa antes de actuar, planifica e invierte en una pila que se amplíe a medida que tú lo hagas. Se trata de encontrar el equilibrio entre:

• Demandas a corto plazo y perspectivas a largo plazo.
• Habilidades del equipo y necesidades de la empresa.
• Innovación y sostenibilidad.

Los líderes tecnológicos pueden tomar decisiones estratégicas que faciliten el desarrollo organizativo en lugar de obstaculizarlo, evitando los escollos y utilizando marcos estratégicos.