Durante la última década, las plataformas de gestión de servicios de TI han surgido como herramientas de misión crítica que brindan servicios a la organización de TI y más allá.
Muchas plataformas, con una creciente demanda de los clientes, se están expandiendo a otras áreas de servicios compartidos, como recursos humanos, finanzas, CRM e instalaciones.
El artículo continúa a continuación.
CEO y cofundador de Dyna Software.
Sin embargo, cuando las organizaciones se mueven rápidamente para satisfacer las necesidades comerciales y se expanden a casos de uso más amplios sin controles arquitectónicos y de gobernanza adecuados, pueden introducir una deuda técnica que hace que sea más difícil y costoso innovar en su plataforma.
Esto se aplica principalmente a las plataformas de gestión de servicios, incluidas ServiceNow, FreshWorks, Evanti Neuron for ITSM y otras.
Aporte de préstamo técnico
Hay varios factores que contribuyen a la deuda técnica y una de las cosas más importantes que hay que entender es que las semillas se pueden plantar mucho antes de que la plataforma entre en funcionamiento.
Muchas organizaciones comienzan la implementación con años de conjeturas sobre el flujo de trabajo y el diseño del sistema. En un esfuerzo por acelerar el tiempo de generación de valor, algunos equipos intentan recrear los procesos existentes en los sistemas heredados exactamente igual.
En algunos casos, esto puede ser apropiado. Sin embargo, en muchos casos, esto introduce complejidad y personalización innecesarias. En lugar de evaluar críticamente los flujos de trabajo existentes, las organizaciones suelen volver a implementar soluciones antiguas como código personalizado.
La razón por la que los equipos adoptan este enfoque tiene menos que ver con desafíos técnicos y más con presiones organizacionales. Nadie quiere ralentizar a los equipos en función de su capacidad para ofrecer valor empresarial.
Las decisiones administrativas sobre lo que se debe reubicar, rediseñar o retirar pueden ser difíciles y a menudo se retrasan. Cuando las decisiones de desarrollo y configuración de la plataforma carecen de una supervisión adecuada, los equipos continúan construyendo sin una comprensión clara de lo que se debe introducir en el entorno.
La deuda técnica también se puede introducir después de que una plataforma entre en producción. Aunque puede haber múltiples enfoques técnicos para lograr un objetivo, no todos son sostenibles en el tiempo.
Uno de los mayores contribuyentes es la creación de código personalizado, reglas del sistema o scripts cuando se puede lograr la misma funcionalidad mediante la configuración.
Requiere inversión continua
Inicialmente, desarrollar código personalizado puede parecer útil, ya que ayuda a las organizaciones a alcanzar objetivos a corto plazo. Sin embargo, su mantenimiento requiere una inversión continua. Por ejemplo, cada script, aplicación o complemento personalizado desarrollado en ServiceNow debe analizarse, probarse y validarse continuamente con cada actualización de la plataforma.
A medida que se introduce más código personalizado, esto puede extender significativamente el plazo de actualización y limitar la capacidad de la plataforma para adoptar nuevas capacidades. Como regla general, si una plataforma de gestión de servicios de TI puede configurarse en lugar de personalizarse, debería hacerlo.
La dependencia es otro factor que complica la deuda técnica. La mayoría de las plataformas líderes han evolucionado a lo largo de los años para admitir componentes compartidos entre conjuntos de funciones y aplicaciones. Cambiar los componentes principales de la plataforma puede poner en peligro la funcionalidad tanto actual como futura.
En muchos casos, incluso la personalización de una aplicación específica puede plantear riesgos similares. El verdadero valor de las plataformas de gestión de servicios radica en su naturaleza interconectada, que permite una experiencia unificada tanto para los usuarios finales como para los empleados responsables de cumplir con las solicitudes y resolver problemas.
Una tendencia creciente en las grandes empresas es adoptar un modelo de desarrollo distribuido o federado. En este enfoque, los recursos de desarrollo están descentralizados y las capacidades de desarrollo se entregan directamente a diferentes unidades de negocios.
Si bien esto puede aumentar la agilidad, también aumenta significativamente el riesgo de deuda técnica y conflictos de desarrollo si no se gestiona a través de un marco coherente y gestionado.
Con el tiempo, la deuda técnica se acumula gradualmente en lugar de aparecer de una vez. Durante meses o incluso años, puede parecer que los sistemas funcionan como se esperaba, o que los problemas parezcan manejables. Sin embargo, con el tiempo, los equipos de gestión de TI responsables de la plataforma empezaron a notar que las actualizaciones tardaban más o que las nuevas funciones estaban bloqueadas.
A medida que aumenta la personalización, aumentan tanto la complejidad de la actualización como el esfuerzo necesario para resolver el problema. Esto a menudo genera dudas a la hora de adoptar nuevas características, capacidades o aplicaciones, especialmente cuando los recursos ya son limitados.
En casos extremos, las organizaciones pueden verse obligadas a reconstruir o cambiar la plataforma de sus entornos debido a la abrumadora complejidad causada por la deuda técnica. Por eso a menudo se compara la deuda técnica con la deuda financiera. Si no lo aborda desde el principio, con el tiempo se convierte en un problema mayor.
La inteligencia artificial llena la deuda técnica
La inteligencia artificial es el último desarrollo que ha puesto más de relieve la deuda tecnológica. La IA tiene el potencial de introducir deuda técnica a escala, pero también puede ayudar a reducirla si se aplica correctamente. Por un lado, la IA puede acelerar significativamente el desarrollo y simplificar muchas tareas de configuración de plataformas.
Los desarrolladores pueden trabajar más rápido y los procesos que antes llevaban horas ahora se pueden automatizar. Sin embargo, si las organizaciones comienzan a implementar código o configuración generados por IA sin controles arquitectónicos o de gobernanza adecuados, corren el riesgo de introducir dependencias complejas y posibles vulnerabilidades de seguridad.
Para evitar esto, las organizaciones deben implementar barreras de seguridad. Cualquier forma de desarrollo automatizado debe validarse según las mejores prácticas de la plataforma, y los sistemas de inteligencia artificial deben capacitarse según estos estándares antes de su implementación. Sin estos controles, la IA puede crear más problemas de los que resuelve.
A medida que más equipos adquieren la capacidad de crear sus propios flujos de trabajo y aplicaciones empresariales, la gobernanza y la visibilidad de la plataforma se vuelven cada vez más críticas. Las organizaciones deben establecer estándares arquitectónicos claros e implementar controles que proporcionen una supervisión adecuada en todos los entornos.
Sin un modelo de gobernanza bien definido, los equipos pueden seguir introduciendo soluciones rápidas que resuelvan problemas inmediatos y al mismo tiempo creen desafíos a largo plazo.
Centrarse en ejercicios básicos es fundamental. Las revisiones de código, la gobernanza arquitectónica, los procesos de desarrollo estructurados y el cumplimiento de las mejores prácticas han ayudado a las organizaciones a gestionar la deuda técnica durante décadas.
Las plataformas de gestión de servicios brindan a las organizaciones la capacidad de moverse rápidamente y ofrecer valor comercial. Sin embargo, ir demasiado rápido sin controles adecuados puede estresar las operaciones y afectar el desempeño a largo plazo.
Las empresas que tienen éxito entienden que la deuda técnica no es algo que deban evitarse por completo en el corto plazo. Más bien, es necesario gestionarlo de manera proactiva a lo largo del tiempo mediante una gobernanza sólida, una arquitectura disciplinada y prácticas de desarrollo disciplinadas.
Hemos clasificado las mejores herramientas de gestión de activos de software (SAM).
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
