BOA 1 . Flujo de trabajo centralizado

La filosofía de colaboración entre equipos tecnológicos DevOps está en auge, debido a las ventajas que ofrece para unir los departamentos de desarrollo y operaciones dentro del mundo tecnológico. No obstante, esta metodología no es suficiente, de hecho, ya hay términos como DevSecOps, dónde se integra la seguridad dentro de todo el ciclo de vida…

Compartir esta entrada:

La filosofía de colaboración entre equipos tecnológicos DevOps está en auge, debido a las ventajas que ofrece para unir los departamentos de desarrollo y operaciones dentro del mundo tecnológico. No obstante, esta metodología no es suficiente, de hecho, ya hay términos como DevSecOps, dónde se integra la seguridad dentro de todo el ciclo de vida del software.

En el mundo del rendimiento de las aplicaciones, no existe una estrategia que de forma continua y no intrusiva atienda las necesidades y objetivos de los departamentos de negocio de las empresas tecnológicas, que permitan relacionar sus objetivos con el código software, y cómo una mala programación sin un enfoque de rendimiento afecta a sus principales objetivos:

La metodología que soluciona este problema de falta de visibilidad se llama DevPerOps, y trata fundamentalmente de introducir el concepto del rendimiento, dentro del ciclo DevOps clásico, dotándolo de una visión de negocio y agregándose en el ciclo de vida de desarrollo de una organización, como una nueva fase.

Cuando los componentes software se encuentran en producción ejecutándose y completamente operativos, es el momento de capturar las métricas asociadas a los mismos para saber cómo estos elementos afectan a los objetivos de negocio a través de una monitorización continua.  En este punto es dónde BOA nos ayuda a centralizar todo el flujo de trabajo asociado a una Oficina Técnica de Rendimiento (OTR) continua.

Detección y análisis – Equipo OTR

Una vez se detecta un candidato o una ineficiencia en un elemento software (“Candidato Censado”) que afecta a cualquiera de los parámetros de negocio, de acuerdo con los criterios establecidos en los algoritmos y a partir de los ajustes en los umbrales, se asigna a un analista para su resolución, quién en función del origen y la información, descartará ese proceso o elaborará un diseño técnico (“Recomendación pendiente”).  Este diseño, contendrá toda la información necesaria para que la modificación sea realizada con éxito, se indicarán los cambios con el máximo detalle, a nivel de línea de código, el coste asociado para elaborar las modificaciones, junto con una estimación del ahorro a conseguir.

Aprobación – Responsable cliente OTR

Una vez el documento es elaborado, este se asigna al responsable de la OTR por parte del cliente, para la aprobación del diseño. Se trata de un paso intermedio, para que el cliente valide que el diseño va contra los objetivos del proyecto, y el ROI esperado (coste vs ahorro), es acorde según los estándares de la entidad.

Desarrollo – Aplicaciones (proveedores)

Una vez el cliente aprueba el diseño, este documento se envía a los responsables del aplicativo, quienes tienen que implantar las modificaciones propuestas en el mismo. Para ello, el proveedor de desarrollo cuenta con el apoyo de la OTR para cualquier duda o soporte que necesite de Orizon. Además, el aplicativo nos deberá notificar de la fecha prevista de implantación, así como de las horas finales que han sido necesarias invertir para poder llevar a cabo los cambios

Medición – Equipo OTR

Por último, una vez que los cambios en los elementos software sean promocionados a producción, se realizará una medición bajo las mismas métricas con las que se detectó el proceso al inicio de todo el flujo, para comparar el antes y después tras los cambios. Con estos datos se generará una gráfica de forma automática a través de BOA remitiéndose a todos los actores implicados en el circuito, equipo OTR, responsable cliente OTR y aplicación, para que todos sean conocedores de los resultados conseguidos.

Todas estas fases están perfectamente integradas con BOA, permitiendo conocer que candidatos o recomendaciones se encuentran en cada punto dentro entro de la vigilancia continua del rendimiento y posibilitando llevar un control en tiempo real sobre una Oficina Técnica de Rendimiento (OTR)

Expertise relacionados

  • ¿Cómo encontrar la “aguja en el pajar” de las ineficiencias en el software?

    ¿Cómo encontrar la “aguja en el pajar” de las ineficiencias en el software?

    Como responsable de tecnología, te enfrentas cada día al desafío de mejorar la eficiencia de tus sistemas y aplicaciones para…

  • Política de Post-implantación

    Política de Post-implantación

    En un anterior post, indicábamos que dentro del enfoque DevOps actual, es necesario incorporar una nueva fase al ciclo de vida…

  • Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle

    Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle

    Uso de “Hard Parse” vs “Soft Parse” BBDD Oracle Permite encontrar mejoras sencillas para la sustitución de constantes por “bind…

Suscríbete a nuestra newsletter y no te pierdas nada