Durante evaluaciones de arquitecturanormalmente identificamos deuda técnica problemas dentro de un solo sistema o proyecto. Sin embargo, el impacto de la deuda técnica a menudo va más allá del alcance de un solo sistema o proyecto. En nuestro trabajo, nos referimos a esta forma de deuda técnica como deuda técnica empresarial. Como toda deuda técnica, la deuda técnica empresarial consiste en opciones convenientes a corto plazo, pero a menudo problemáticas a largo plazo. Ignorar la deuda técnica de la empresa puede tener consecuencias significativas, por lo que los arquitectos deben estar alerta y no deben dejar que se pase por alto o se ignore cuando la encuentren. En esta publicación, proporciono ejemplos de deuda técnica empresarial (y el riesgo que representa) tomados de proyectos del mundo actual.
Como evaluadores de arquitectura, tenemos la oportunidad única de ver los riesgos arquitectónicos desde una perspectiva más empresarial (a diferencia del nivel de proyecto), particularmente si participamos en evaluaciones para una cartera de proyectos. En los últimos años, el SEI ha aprovechado Investigación de la deuda técnica de SEI para institucionalizar las prácticas de deuda técnica en una organización con una gran cartera de sistemas valorada en más de $ 100 millones. Esta organización tiene una cartera de más de dos docenas de aplicaciones comerciales y sigue un modelo de gobierno de TI descentralizado. Los ejemplos en esta publicación provienen de nuestro trabajo como evaluadores de arquitectura en estos proyectos.
Para que la deuda técnica empresarial sea más concreta para los lectores, ofrezco tres ejemplos de partidas y consecuencias de la deuda técnica empresarial. En una publicación futura, entraré en más detalles sobre la documentación y la remediación de la deuda técnica empresarial.
Ejemplo 1: una solución de integración de sistemas frágiles
En este ejemplo (Figura 1), los requisitos del proyecto requerían el intercambio de datos entre las aplicaciones A y B. Los equipos del proyecto tomaron la decisión arquitectónica de utilizar un esquema de base de datos compartida como mecanismo de intercambio de datos. Este enfoque resultó atractivo para los equipos en ese momento, ya que period fácil de implementar, pero luego se hizo evidente que esta solución period frágil. En explicit, cuando el equipo A realizó un cambio independiente en el esquema compartido sin coordinarse con el equipo B, la aplicación B también tuvo que realizar cambios para adaptarse y viceversa.
Figura 1: Una solución de integración de sistemas frágiles
A los equipos se les ocurrió una solución que empeoró las cosas. Los desarrolladores copiaron datos en sus entornos locales para evitar cambiar el esquema. Los equipos creados extraer, transformar, cargar (ETL) trabajos para mantener sincronizados los datos que no eran fiables. Cuando fallaba un trabajo de ETL, los datos quedaban en un estado inconsistente. Por ejemplo, después de fallas, los usuarios obtendrían diferentes respuestas de consultas históricas de la Aplicación A y la Aplicación B. La entrega de características del proyecto también se ralentizó porque los cambios de esquema requerían un análisis que consumía mucho tiempo.
Ambos equipos estaban satisfechos con el esquema compartido, al menos a corto plazo. Sin embargo, a partir de nuestra evaluación de la arquitectura, que nos brinda una perspectiva externa y de nivel empresarial, pudimos ver que las consecuencias negativas de esta solución probablemente aumentarían con el tiempo a medida que aumentara la funcionalidad. Por esta razón, recomendamos reemplazar la frágil solución de esquema compartido con una Interfaz de programación de aplicaciones (API) para el intercambio de datos de aplicaciones.
Los equipos aceptaron de buena gana la solución técnica propuesta, pero la organización no actuó para solucionar el problema inicialmente por varias razones. En primer lugar, en este entorno de gobierno descentralizado, ningún equipo se sentía responsable del trabajo de refactorización. En segundo lugar, arreglar una solución de integración frágil no se consideró una prioridad para el negocio. Por lo tanto, los propietarios del producto no asignarían los fondos del proyecto al esfuerzo de rediseño. Aunque no se tomaría ninguna medida a corto plazo, creamos un elemento de deuda técnica—una descripción escrita del problema y la consecuencia. Documentar el problema como un elemento de deuda técnica permitió a la organización hacerlo seen y trabajar en una estrategia de mayor alcance para volver a trabajar en la solución. Proporcionaré ejemplos de estos elementos de deuda técnica que creamos en una futura publicación de weblog.
Ejemplo 2: soluciones de management de autenticación y acceso heterogéneo
Como evaluadores de arquitectura para esta organización, revisamos varias arquitecturas de proyectos en las que los equipos estaban implementando autenticación duplicada y capacidad de management de acceso. Capacidades duplicadas incluidas
- capacidad para almacenar información de roles y permisos
- capacidad administrativa para agregar, cambiar y eliminar permisos de usuario
- generación segura de tokens
- capacidad para establecer y hacer cumplir políticas de management de acceso para servicios de software program (llamadas API)
No se proporcionó una capacidad común de acceso y autenticación, por lo que los equipos individuales implementaron esta capacidad de manera heterogénea. La Figura 2 muestra tres estilos de implementación diferentes que observamos.
Figura 2: Soluciones de management de autenticación y acceso heterogéneo
- La aplicación A es una aplicación heredada desarrollada como un monolito, que está desactualizada y tiene varios inconvenientes. Por ejemplo, los equipos escribieron un código de autenticación personalizado en lugar de usar componentes de proveedores seguros y verificados. También descubrimos que las funciones y la información de permisos estaban codificadas de forma rígida y que se usaban credenciales de contraseña menos seguras en lugar de tokens para la certificación. Finalmente, no hubo verificación de seguridad a nivel de aplicación en la capa de acceso a datos.
- La aplicación B period una implementación más moderna con un estilo arquitectónico basado en componentes. En esta implementación, hubo una separación de la capacidad de autenticación y management de acceso en componentes (por ejemplo, administración de roles y permisos, autenticación, generación de tokens, management de acceso). Estos componentes eran compartibles por múltiples consumidores.
- La aplicación C tenía una arquitectura orientada a servicios. Los servicios utilizados fueron la administración de roles y permisos, la autenticación, la generación de tokens y el management de acceso.
Estas soluciones heterogéneas de autenticación y management de acceso dieron como resultado, en última instancia, un mayor riesgo de seguridad y mantenimiento. Por ejemplo, sin un módulo de administración común, las cuentas de usuario se desactivaron (en lugar de eliminarse), dejando a la organización expuesta a ataques de suplantación de identidad. Además, cambiar los permisos de usuario implicaba ejecutar scripts de base de datos manuales propensos a errores para actualizar varias bases de datos. En lugar de almacenar datos de identificación de usuarios en una única fuente de datos autorizada y segura, esos datos se almacenaron al azar en varias bases de datos de proyectos operativos.
Nuevamente, los equipos del proyecto no vieron problemas con esta situación. Sin embargo, visto desde la perspectiva de la empresa, los riesgos de seguridad y mantenimiento eran claros. Para visibilizar esta deuda, creamos un ítem de deuda técnica y trabajamos con la organización para priorizarla. Compartiré el elemento de deuda técnica que creamos para este ejemplo en la próxima publicación.
Ejemplo 3: problema de actualización del almacén de datos
Hace años, la organización invirtió en la construcción de un amplio almacén de datos. Durante las evaluaciones de la arquitectura, descubrimos que varios equipos no usaban los informes del almacén de datos. Más bien, estaban ejecutando muchas tareas complejas de bases de datos nocturnas para copiar datos históricos en sus bases de datos locales. Descubrimos que la causa principal de este enfoque period un retraso de 48 horas en la actualización de datos en el almacén de datos. Los usuarios no estaban satisfechos con la visualización de datos obsoletos, lo que dejaba el almacén de datos infrautilizado y añadía una complejidad innecesaria al ecosistema.
Una vez más, esta situación estuvo bien con los equipos del proyecto. Sin embargo, cuando se analizó desde la perspectiva de la empresa, los riesgos comerciales y de mantenimiento/costo quedaron claros. Por ejemplo, la copia de datos provocó una explosión en el uso del almacenamiento de datos. Cumplir con los requisitos de gestión de registros se convirtió en una pesadilla después de que las copias extensas hicieran que las fuentes de datos autorizadas fueran poco claras. El private de operaciones y mantenimiento se quejó de dedicar tiempo a monitorear y actualizar la compleja pink de trabajos de sincronización de ETL. Como resultado, creamos un elemento de deuda técnica que documenta el problema y recomendamos un rediseño para reducir el tiempo de retraso del almacenamiento de datos.
Mirando hacia el futuro
En esta publicación, describí tres ejemplos de deuda técnica empresarial. Ilustramos, a través del ejemplo, la naturaleza esquiva de la deuda técnica empresarial y el impacto potencial que la deuda técnica empresarial sin management puede tener en una organización. En nuestros ejemplos, el impacto de los elementos ETD no se sintió a nivel técnico. Sin embargo, ignorarlo resultó en riesgos para múltiples proyectos o para toda la organización. Estos, a su vez, aumentaron los costos, la eficiencia o los riesgos de seguridad para la organización. También discutí el papel del arquitecto en la aplicación de prácticas de deuda técnica para rastrear y remediar la deuda técnica. En mi próxima publicación, describiré cómo remediamos estos ejemplos y cómo guiamos a los equipos para aplicar prácticas técnicas de deuda y gobernanza para motivar la acción.
