Los CIO se encuentran atascados en una paradoja de prioridades que compiten entre sí en lo que respecta al desarrollo, la mejora y la modernización de las aplicaciones: por un lado, buscan la innovación, experiencias que satisfagan a los usuarios finales, y prácticas de desarrollo ágiles que permitan la rápida entrega de nuevas capacidades de negocio. Por otra parte, les preocupa aumentar la deuda técnica, garantizar que las aplicaciones pasen por las debidas validaciones de seguridad, y demostrar si los prototipos pueden funcionar y escalar en entornos de producción.

Sí, los directivos de TI quieren tener “su pastel” y comérselo también. Conocen todos los deseos, obligaciones y listas de deseos de sus desarrolladores y líderes de entrega. Es decir, más tiempo para desarrollar el código “de la manera correcta”, más gente en el equipo, mejor formación, una infraestructura de desarrollo más ágil, herramientas modernas de desarrollo de aplicaciones, mejor compromiso de las partes interesadas y prioridades bien definidas están en la lista de todos.

Los CIO están alineados con sus equipos en sus necesidades, pero también deben enfrentarse a las realidades empresariales para impulsar la transformación digital, trabajar con las limitaciones presupuestarias y cumplir los requisitos de cumplimiento.

Los directivos de TI quieren que los equipos de desarrollo de aplicaciones sepan cómo tomar decisiones prudentes en torno a las compensaciones, qué medidas tomar para garantizar que lo que se desarrolla es compatible, y por qué la colaboración con los usuarios finales, las partes interesadas, los arquitectos y las operaciones, es tan importante como la realización de la aplicación.

Para abordar estas paradojas, los CIO esperan que sus equipos de desarrollo entiendan los principios de desarrollo y las compensaciones. Aquí hay cinco que deben considerarse.

Equilibrar la deuda técnica y la innovación

Es muy fácil para los equipos de desarrollo entusiasmarse persiguiendo innovaciones o añadiendo picos en torno a las nuevas tecnologías. Los CIO y los líderes de TI quieren innovación, pero también se preocupan cuando los equipos de desarrollo no abordan la deuda técnica. Un retraso saludable y ágil debería mostrar a los equipos ágiles la necesidad de desarrollar una estrategia que contemple un balance de picos, la deuda técnica, nuevas funcionalidades y mejoras operativas.

La prioridad de los equipos ágiles debería recaer en el propietario del producto. Pero los líderes de TI pueden establecer principios si los propietarios de los productos no priorizan la deuda técnica, o si fuerzan las prioridades de las características sin considerar los picos de innovación recomendados por el equipo.

Los CIO y los líderes de TI también son realistas y saben que las nuevas implementaciones probablemente vienen con una deuda técnica adicional. Entienden que, a veces, los desarrolladores deben tomar atajos para cumplir con los plazos o identificar opciones de codificación más eficientes durante la implementación. Es razonable esperar que la deuda técnica recién creada se codifique en el código fuente y los atrasos ágiles, y que los equipos traten de resolverlos en función de las prioridades.

Siempre desarrolla un código seguro y mantenible

Los equipos de desarrollo están bajo una presión significativa para entregar rápidamente las características y capacidades a los usuarios finales. Esa es ciertamente una de las razones por las que los equipos crean una nueva deuda técnica, pero es una pobre excusa para desarrollar un código que no es mantenible, o que pasa por alto las normas de seguridad.

Los líderes de TI no quieren un código de “usar y tirar”, ni tampoco otro demasiado complejo que requiera un mantenimiento por parte de ingenieros avanzados. Son responsables del mantenimiento a largo plazo del código que entregan, sabiendo que los desarrolladores y los equipos son reasignados a nuevos proyectos. Esperan que el código siga los patrones de arquitectura, los estándares de codificación, las convenciones de nomenclatura, los patrones de registro y el manejo de excepciones.

También esperan que los equipos de desarrollo colaboren en la definición y evolución de los estándares. A medida que la tecnología, las plataformas y las mejores prácticas continúan evolucionando, las organizaciones no pueden confiar en que los arquitectos sean los dueños y especifiquen todas las pautas.

Crear experiencias de usuario encantadoras que funcionen y se escalen

En los primeros días del desarrollo de la Web, los equipos de software tenían difíciles compensaciones en la arquitectura y el diseño de las aplicaciones.

Uno de los enfoques tenía el proceso de desarrollo iniciado con los equipos de ingeniería de la base de datos del back-end y la codificación de la lógica de negocio. Los ingenieros crearon soluciones reutilizables y escalables, pero la implementación a menudo limitaba la experiencia del usuario y los diseños.

En el otro enfoque, los equipos de desarrollo de la Web comienzan con los diseños del front-end y entregan grandes experiencias a los usuarios finales. Pero estos diseños, a menudo, implementaron la lógica de negocios dentro de plantillas del lado del servidor o hicieron frecuentes llamadas de servicio cuyo resultado fue aplicaciones que no cumplieron su función, o no se escalaron como se requería.

Los CIO necesitan ofrecer una gran experiencia y rendimiento. Hoy en día, los equipos de desarrollo pueden utilizar, entre otras cosas, plataformas de bajo código, capacidades de marcado de características, patrones de diseño de microservicios, mejores prácticas de desarrollo, automatización de pruebas y arquitecturas en nube para ofrecer ambas cosas.

Evitar la codificación para resolver los problemas de la tecnología por el bien de la tecnología

La mayoría de los equipos de desarrollo deberían evitar crear aquellas capacidades tecnológicas que resuelvan problemas tecnológicos. Las soluciones sólidas a los problemas técnicos suelen estar disponibles a través de bibliotecas de código abierto, servicios públicos de computación en nube, capacidades de código bajo y servicios de software comercial. Los arquitectos y los equipos de desarrollo deberían evaluar estas opciones antes de inscribirse para desarrollar soluciones que sean beneficiosas para el desarrollo de la propia tecnología.

Adherirse a las normas de gestión de datos

Lo último que los CIO y los líderes de TI quieren ver cuando los equipos de desarrollo construyen o mejoran las aplicaciones son más silos de datos, fuentes de datos duplicadas o estructuras de datos mal diseñadas. Para la mayoría de las organizaciones, el tamaño de la deuda de datos a menudo excede la deuda técnica, y eso impacta de manera significativa en el negocio. Simplemente pídale a cualquier científico que le dé sentido a la expansión urbana de las fuentes de datos que tiene a su alrededor.

Hoy en día es increíblemente fácil crear nuevas bases de datos relacionales, almacenes de datos NoSQL y lagos de datos. Eso es tanto una bendición como una maldición, y la cuestión es cómo ayudar a los equipos de desarrollo a saber qué fuentes de datos están disponibles y la mejor manera de interactuar con ellas. La revisión de los catálogos de datos, los portales API y las fuentes de datos maestros debería ser el primer paso de los equipos de desarrollo antes de crear nuevas estructuras de datos.

Si se necesitan nuevas estructuras de datos, los equipos deben utilizar herramientas de modelado de datos y seguir los estándares de gobierno de datos como prácticas no negociables.

En resumen, los CIO y los líderes de TI quieren innovación, velocidad, usuarios finales satisfechos y equipos de desarrollo entusiasmados con la solución de los desafíos empresariales. Pero también necesitan confiabilidad, rendimiento, eficiencia, escalabilidad, seguridad y aplicaciones que puedan mantenerse a largo plazo. Estos no son objetivos excluyentes entre sí, pero en cada lanzamiento, en cada sprint y en cada historia de usuario, surgen compensaciones prácticas. Las organizaciones de TI deben definir los principios de ingeniería y debatir sus implementaciones como parte de su proceso de desarrollo.