Nmedia - Fotolia

Gestionar Aprenda a aplicar las mejores prácticas y optimizar sus operaciones.

Seis consejos para que los CIO manejen la deuda técnica

La gestión de la deuda técnica puede ser un desafío, pero dar un paso atrás y posicionar cada proyecto en el panorama general puede ayudar a minimizarlo en el futuro.

La mayoría de los CIO han escuchado al menos el término deuda técnica. Y si tiene experiencia en programación, es posible que sepa muy bien qué es la deuda técnica.

Pero para los CIO que no están familiarizados con el concepto, podría ser una fuente importante de tensión en sus departamentos de TI y conducir a grandes ineficiencias y pérdidas de oportunidades.

¿Qué es la deuda técnica?

La frase fue acuñada por Ward Cunningham, un programador que desarrolló la primera Wiki y que fue uno de los primeros defensores de la programación ágil.

Cunningham describió la deuda técnica como la compensación que hacen los programadores entre velocidad inmediata y eficiencia a largo plazo. Cunningham se refería al software, pero el concepto de deuda técnica se puede extrapolar a cada implementación de tecnología que priorice un resultado rápido sobre uno correcto, lo que significa que está construido de acuerdo con la seguridad, escalabilidad, compatibilidad y otros principios arquitectónicos clave.

La priorización sin control de la velocidad de implementación sobre la eficiencia tiene como consecuencia resultados que consumen más tiempo en sentido descendente para brindar soporte, reparar, mantener y asegurar. Esto, a su vez, conduce a un entorno en el que la mayoría de las horas del personal se dedican a "mantener el control", en lugar de desarrollar e implementar tecnología que ayude a la empresa a abordar las necesidades actuales y planificar los desafíos futuros.

Cunningham no se opone a que se implemente un producto rápido y funcional para demostrar una prueba de concepto o para satisfacer una necesidad inmediata. El Grupo de Trabajo de Ingeniería de Internet, una organización que desarrolla los protocolos de comunicaciones que sustentan internet, llama a este enfoque "consenso aproximado y código de ejecución".

En otras palabras, el problema de la deuda técnica no se deriva de recortar algunas esquinas para permitir una implementación rápida. Proviene de no volver atrás y modificar el resultado para alinearlo con las mejores prácticas.

Entonces, ¿por qué las organizaciones tienen dificultades para administrar la deuda técnica en primer lugar? Aquí hemos identificado cinco prácticas comunes que a menudo producen deuda técnica futura.

1. Falta la arquitectura

Es difícil adherirse a las mejores prácticas de arquitectura si no se tiene una arquitectura en primer lugar. Pero, a menudo, lo primero que se sacrifica en el camino hacia la velocidad es tener una arquitectura tecnológica.

Una arquitectura bien pensada incluye no solo las interfaces (qué componentes tecnológicos necesitan para conectarse con qué), sino también preocupaciones más amplias como la seguridad, la escalabilidad y la compatibilidad. Si los CIO se embarcan en una iniciativa tecnológica sin una arquitectura establecida, corren el riesgo de incurrir en deudas técnicas.

2. Implementaciones en silos

Si diferentes grupos están implementando tecnología sin un proceso robusto de colaboración, pueden encontrarse con incompatibilidades que generen deuda técnica. Por ejemplo, la infraestructura de escritorio virtual (VDI) no admite adecuadamente las tecnologías de colaboración de grupos de trabajo, como las videoconferencias de escritorio. Si una organización de escritorio se enfoca en implementar VDI y otra está implementando videoconferencias de escritorio, los resultados entrarán en conflicto, lo que requerirá complicadas soluciones.

3. Enfoque de proyectos a corto plazo

Los CIO con experiencia en software son particularmente propensos a este problema. Muchas aplicaciones se crean para resolver un problema empresarial específico que existe en el aquí y ahora, sin pensar en cómo evolucionará ese problema o a qué otras adyacencias pertenece.

Por ejemplo, un equipo de desarrollo podría lanzarse a resolver el problema de crear una base de datos para administrar las cuentas de los clientes sin tener en cuenta cómo se integra esa base de datos con la base de datos de ventas/prospección. Esto puede llevar a miles de horas de personal dedicadas a transformar contactos e importarlos de las ventas a la base de datos de clientes.

4. Desconexión entre desarrollo y operaciones

Uno de los problemas más conocidos en las grandes organizaciones es la desconexión entre el desarrollo y las operaciones, donde los ingenieros diseñan un producto sin considerar primero cómo lo apoyarán sus pares en operaciones, lo que da como resultado procesos de soporte que son engorrosos, propensos a errores e ineficientes.

Toda la disciplina de programación de DevOps existe en gran parte para resolver este problema al incluir representantes del equipo de operaciones en el equipo de desarrollo, pero la división DevOps existe fuera de la programación. Los ingenieros de infraestructura pueden implementar enrutadores, computadoras de borde o dispositivos SD-WAN sin saber cómo se parcharán o actualizarán los dispositivos. Los equipos de ciberseguridad pueden implementar ofertas de respuesta y detección de puntos finales sin comprender cómo encajan en los servicios de soporte de escritorio.

5. No tener visión del ciclo de vida completo

Las tecnologías se retiran cuando se ha desarrollado algo mejor o cuando un proceso empresarial ha mejorado hasta el punto en que la tecnología ya no es necesaria. Tener una estrategia de fin de vida (EOL) implementada cuando el equipo lanza una iniciativa tecnológica es un acierto: la falta de un EOL es una señal de alerta para la existencia de deuda técnica.

La tecnología obsoleta, pero que aún no se ha retirado, aún necesita mantenimiento y parches para garantizar que no suponga un riesgo de seguridad. Si hay datos almacenados dentro de esa tecnología, extraerlos y usarlos puede volverse cada vez más difícil a medida que la tecnología envejece.

Y a medida que las regulaciones de privacidad y cumplimiento cambian y se hacen más estrictas, los datos almacenados pueden hacer que una organización no cumpla con las nuevas regulaciones; la información que se almacena en texto sin cifrar, por ejemplo, puede necesitar ser encriptada.

Seis estrategias para gestionar la deuda técnica

Las cinco prácticas enumeradas anteriormente son un buen indicador de que una organización puede estar incurriendo en deudas técnicas. La buena noticia es que eliminar estas prácticas puede contribuir en gran medida a la gestión de la deuda técnica.

En pocas palabras, una estrategia de seis puntos para administrar la deuda técnica debe incluir lo siguiente:

1. Implementar una arquitectura

Cada vez que un CIO o líder empresarial inicia un proyecto, debe adherirse a una arquitectura que incluya explícitamente mecanismos para asegurar, administrar y respaldar la tecnología, así como para integrarla en tecnologías adyacentes. Esto acelera el proceso de desarrollo y ayuda a evitar la deuda técnica asociada con las correcciones posteriores a los hechos.

2. Coordinar entre equipos

Las organizaciones deben tener una visión holística de todos los proyectos en curso y cada equipo debe tener una comprensión de alto nivel de en qué están trabajando otros equipos, su período de tiempo y el impacto potencial de esos proyectos.

3. Estar atento al panorama general

Los proyectos a corto plazo están muy bien, pero debe haber personas dentro de la organización autorizadas a asegurarse de que los proyectos no se superpongan o entren en conflicto entre sí.

4. Adoptar un enfoque DevOps (y DevSecOps) para todo

La primera, segunda y tercera preguntas asociadas con cualquier iniciativa tecnológica propuesta deberían ser: "¿Cómo soportaremos esto?". Las organizaciones deben asegurarse de que una tecnología propuesta tenga una estrategia incorporada para el apoyo operativo, incluida la seguridad.

5. Empezar con el final en mente

Los CIO y otros líderes de TI dentro de la organización deben tener una comprensión clara de cuándo una tecnología se está volviendo obsoleta y diseñarla desde el principio para que se retire sin problemas.

6. Revisar sus proyectos con miras a reducir la deuda técnica.

Siga el ejemplo del escritor Michael Crighton, quien dijo: "Los libros no se escriben, se reescriben". Incluso el proyecto mejor planificado puede conllevar cierto grado de deuda técnica. Vale la pena revisar los proyectos existentes periódicamente para ver cómo se pueden revisar para minimizar y administrar la deuda técnica en el futuro.

Investigue más sobre Gestión del centro de datos

Inicie la conversación

Envíenme notificaciones cuando otros miembros comenten sobre este artículo.

Por favor cree un Nombre de usuario para poder comentar.

Close