En este evento de Inetum, expertos en desarrollo de entidades financieras, aseguradoras y de servicios públicos exponen sus inquietudes y observaciones sobre el entendimiento entre negocio y TI en el desarrollo de aplicaciones empresariales.
En una jornada organizada por Inetum y CloudBees, la Informática ejerció de maestra de ceremonias, con la asistencia de técnicos de Acciona, Banco de España, BBVA, Cepsa, Mapfre y Sacyr, se puso sobre la mesa la vieja «batalla» existente para ser eficientes y un enfoque ágil para proyectos de desarrollo de aplicaciones, comunicación entre el mundo empresarial y técnico.
María Jesús Larraya, directora de Arquitectura de Desarrollo de Inetum, lo confirma: “Como integrador, en algunos casos nos sorprendía la gran diferencia entre negocio y tecnología dentro de una misma empresa”. Por ello, en este sentido, cree que “los equipos de desarrollo deben evolucionar continuamente para facilitar iniciar respuestas en función de las nuevas necesidades de los clientes. Establecer una cultura DevOps en una organización es necesario, pero es un camino largo y hay que buscar el entendimiento con el negocio; TI Tienes que ser un agente de ese cambio”.
El desafío es cómo lograr este entendimiento y cómo integrarlo en la organización. Se explica de esta manera: «El movimiento DevOps, nacido desde cero, a nivel técnico, tiene que ver con el cambio cultural. Pero reconocemos nuestras deficiencias como tecnólogos, a pesar de que estamos capacitados para ayudar a cumplir con las métricas, mejorar los procesos y adaptarnos a buenos patrones y buenas prácticas. «. Existen herramientas de desarrollo (por ejemplo, CloudBees) y modelos ágiles que impulsan este cambio y, en última instancia, entregan el producto «teniendo en cuenta la experiencia del desarrollador y del cliente final».
Un experto senior comentó: «Siempre vamos y venimos en el cambio cultural, pero no creo que el cambio cultural sea impuesto». Ninguna piedra de toque puede resolverlo todo. “Estas herramientas son habilitadoras, pero no resuelven problemas, y eso es algo que no interiorizamos a diario.” Concluyó que el cambio cultural debe afianzarse y no ser retenido por quienes desempeñan un papel “superior”. en una plataforma de seguridad o calidad. Para otro interlocutor, era importante “levantarse de la silla y facilitar la comunicación entre áreas”. Empuje los límites, especialmente si viene de una empresa tradicional con muchos silos: «Si tiene un departamento de seguridad, un departamento de desarrollo y un departamento de DevOps, ya tiene tres silos». Otro sugirió salir de la «zona de confort». , «Menos profesional y más horizontal».
Automatización y Normalización
Durante esta transformación, los asistentes vieron la necesidad de estandarizar, formalizar y demostrar el valor que representa, “no solo para los equipos de negocio, sino también para los equipos de desarrollo, donde pueden capturar valor medible y tangible”.
Una idea que se destacó fue que la tecnología tenía que ser la palanca que ayudara a simplificar DevOps y adoptar una forma diferente de colaborar, «No tienes DevOps porque tienes una herramienta que tiene que ser la base del mecanismo de lanzamiento y ser capaces de trabajar juntos.» Uno de una manera homogénea y sostenible.
DevOps no tiene un manifiesto como Agile, pero se basa en algunos supuestos fundamentales: colaboración, transparencia y comunicación, para que los equipos puedan adoptar el sistema de una manera más natural y proactiva.
Otro aspecto interesante es que DevOps es fácil de asimilar en entornos pequeños, pero en entornos de gran escala se vuelve complicado, por lo que algunas empresas prefieren comenzar con equipos pequeños maduros y ayudar a su vez a otros equipos. «Cuando la escala importa, importa una cultura industrial que abarque la automatización, la eficiencia y el inventario». La trazabilidad juega un papel importante especialmente en el área de cumplimiento, que es muy importante para las compañías financieras y de seguros. «No es inmediatamente obvio dónde está mi software, dónde están mis activos o cuántos piratas informáticos han entrado en mi centro de datos».
Para lograr este tipo de trazabilidad en el desarrollo de una aplicación, es importante tener colusión de dominio comercial. “Comercialmente cuesta entendernos porque usamos lenguajes y sensibilidades diferentes. Tratamos de involucrarlos en el ciclo de desarrollo y hacerles ‘sufrir’ para que entiendan para dar una vuelta más al proyecto y hacerlo con un mejor entendimiento”. del porqué El sentido de la decisión.” Tal y como explica un técnico de una entidad bancaria presente: “Este movimiento lo aplicamos en la primera fase del proyecto, desde cómo se concebía y cuantificaba, de la forma más transparente posible, de forma lenguaje que sea lo más fácil de entender posible para que la gente de negocios pueda entenderlo”.
La segunda etapa de búsqueda de comprensión consiste en trabajar juntos para «saber lo que quieres». Construir la solución de software correcta es una cosa, convertirla en la solución correcta es otra. Asimismo, hay algunas aplicaciones antiguas que se quedan en el camino y el negocio «no te permite ni tocarlas». Es en este modo de diálogo entre estos dos campos que se juntan las sensibilidades y se mejora una visión compartida de las cosas.
Al fin y al cabo, no todas las culturas se entienden de la misma manera. «DevOps es un concepto general que cada uno puede aplicar como quiera. Es importante darle autonomía a los proyectos para que puedan progresar y no nos perdamos en un ciclo de cambios y problemas constantes. Al final, algo tan positivo como DevOps es en última instancia, degenerará en un obstáculo para la organización”.
Fuente: computing.es
