• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

David Palomar Saez

Diagnóstico de Arquitectura de Software con Escenarios de Uso

Introducción

Esta es mi segunda publicación sobre una serie dedicada al Diagnóstico de Arquitectura de Software. En la anterior, te introducía al concepto de arquitectura de software, revisábamos el valor para la organización de este activo y la importancia de evaluar los atributos cualitativos de su diseño.

En esta ocasión, quiero centrarme en la práctica del diagnóstico de arquitectura de software. Esta práctica es  fundamental para las organizaciones que basan su negocio en el uso intensivo de software. Sobre su evaluación vas a encontrar un corpus documental gigantesco. Las metodologías pueden seguir estrategias muy planificadas, propias a las aproximaciones analíticas de comienzo del siglo, o enfoques más empíricos, característicos de la más actual gestión ágil de proyectos. Pueden centrarse en qualities muy concretos (seguridad, estandarización, modificabilidad, etc.) o sobrevolar los aspectos generales de la arquitectura.

En este artículo y en el siguiente de la serie, te plantearé dos alternativas ágiles y generalistas para realizar el diagnóstico de arquitectura de software. Aquí nos centraremos en una estrategia basada en la colaboración entre el equipo de desarrollo y el analista. Se trata del diagnóstico dirigido por Escenarios de Uso.

Diagnóstico de Arquitectura de Software empleando Escenarios de Uso

Llevamos más de 15 años trabajando con metodologías basadas en escenarios. Son un marco de trabajo probado para conducir esto procesos. ATAM (Architecture Tradeoff Analysis Method) es el referente más destacado, pero existen numerosas variaciones para hacerlo más ligero y ágil. Diseñado originalmente con un enfoque waterfall, los principios son sólidos y lo podemos adaptar fácilmente a un proceso iterativo incremental.

Como su nombre ya te habrá sugerido, la principal herramienta que emplearemos son los escenarios de uso. Pero…

¿Qué son los Escenarios de Uso?

Se trata de descripciones muy concretas del uso que queremos darle al sistema.

Tomemos el caso de una compañía de distribución on-line. El Product Owner señala que la fluidez del proceso de pago del carrito de la compra es crucial para garantizar el éxito de la venta. Es más. La tasa de éxito en este proceso de checkout (porcentaje de clientes que confirman el pago del carrito, frente a los que abandonaron) es uno de los KPIs para evaluar el desempeño de toda el área de eCommerce.

Trabajando con el PO y el equipo de desarrollo, identificamos que, en el pasado, la falta de robustez de la pasarela de pagos fue una fuente recurrente de frustración para los clientes. Y, así, definimos uno de los escenario de uso como:

 “El tiempo máximo de pérdida de servicios de la pasarela de pagos no puede ser superior a 5 minutos para clientes de Francia y Países Bajos empleado MasterCard, Visa, Carte-Blue, iDEAL o  PayPal”

Partiendo de un aspecto muy relevante para el negocio, planteado excelentemente por el PO, llegamos a refinar varios Escenarios de Uso (el ejemplo anterior y varios más asociados al proceso de checkout) que nos permitieron definir objetivos muy concretos para la arquitectura y métricas para evaluar su cumplimiento.

Los escenarios de uso para el análisis de requerimientos cualitativos van a jugar el mismo papel que las historias de usuario en el análisis funcional.

De hecho, los escenarios de uso se pueden describir con la sintaxis de BDD (Given+When+Then), habitualmente empleada para las Historias de Usuario.  Siguiendo con el anterior ejemplo. Una forma de redactar este Escenario de uso es:

  • Given: Sistema funcionando en condiciones normales de Operación
  • When: Se produce una caída de servicio de la pasarela X de pagos para los clientes de Francia y Holanda.
  • Then: La pasarela alternativa Y debe asumir las operaciones en curso para los medios de pago compatibles (a,b,c..) en menos de 5 min sin que el cliente pierda el estado de checkout.

¿Cómo se crean los Escenarios de Uso?

Diseño de Escenarios de UsoLos escenarios de uso no surgen espontáneamente. Son consecuencia de la colaboración directa entre el analista, expertos de negocio (ej. Product Owner, Product Manager) y tecnología (ej. Lead Developer, Architect). En las sesiones de trabajo, se sigue un proceso de refinamiento progresivo. En cada iteración se revisa el trabajo anterior, surgen nuevos atributos cualitativos y escenarios de uso, los priorizamos y refinamos. Se obtienen objetivos concretos o aspectos técnicos y de negocio a aclarar para la siguiente reunión.

La labor del analista está en facilitar la colaboración entre negocio y tecnología en la definición de objetivos razonables en relación con su impacto en negocio. Así, buscamos cuantificar el coste para el negocio de la no conformidad con el requerimiento (pérdida de negocio, impacto en cualificación pública del servicio, falta de competitividad, etc.) versus el esfuerzo necesario para implementar su cobertura. En última instancia, el equipo de diagnóstico (negocio + tecnología) valorará los escenarios de uso atendiendo a los criterios de riesgo y coste para obtener una lista priorizada de acciones a desarrollar (un backlog).

¿Cómo priorizamos los Escenarios de Uso?

En mi anterior entrada sobre diagnóstico de arquitectura de software, hacía hincapié en que el diagnóstico debe tener unos objetivos concretos y limitados en tiempo. Por lo tanto, la elección correcta de los atributos cualitativos y de sus escenarios de uso es fundamental para el proyecto.

Para hacer más ágil el proceso de priorización, las estimaciones de riesgo y coste se realizan asignando valores de un conjunto se realizan asignando valores como “Alto, medio, bajo” o tallas de camiseta (M, L , XL).

Los árboles de utilidad son una herramienta visual que funciona muy bien en este proceso. Partiendo de las raíces con los atributos cualitativos, llegamos a los escenarios de uso en las ramas. Los escenarios de uso están etiquetados con (Valor de Negocio, Coste). Opcionalmente, podemos ir valorando cada subnivel, de forma que nos enfocamos rápidamente en los más prometedores.

Utility Map
Ejemplo de Árbol de Utilidad con los Escenarios de uso valorados en Alto, Medio y Bajo para (Valor,Coste)

Finalmente, es muy útil asignar un valor cuantitativo a las estimaciones. De esta forma, podemos acordar una ordenación basada en la puntuación final de cada escenario. Además, la suma de los pesos asignados a cada paso intermedio  del camino raíz->rama nos da una valoración más exacta de la prioridad del escenario.

Una técnica común consiste en distribuir un número limitado de puntos que cada miembro del equipo debe asignar a los escenarios. Para facilitar la toma de decisiones, se suele emplear una cuantificación de crecimiento rápido (como Fibonacci). Así, por ejemplo: B = 3, M=5 y A=8.

Otra alternativa que, personalmente, me gusta mucho por su claridad y porque obtiene rápidamente ganadores es el cálculo de Rank Ordered Centroids (ROC).

El analista como facilitador del proceso de Diagnóstico de Arquitectura de Software.

Arquitectura de Software
En un diagnóstico de arquitectura de software basado en escenarios, el analista debe poseer un conocimiento experto sobre estilos de arquitecturas y porfolio de herramientas. Pero, al mismo tiempo, debe poseer habilidades de gestión de personas y facilitación del trabajo en equipo. De esta forma, ayudará a  identificar los aspectos claves de la arquitectura y conducirá las dinámicas de trabajo para conseguir resultados significativos.

Con esta metodología, no es necesario que el analista sea un experto en el negocio y las tecnologías empleadas en el sistema. Su labor no va a ser a consistir en señalar las debilidades de la solución. Sino en emplear su experiencia profesional para hacer posible una reflexión crítica-constructiva de las oportunidades de mejora. Por otro lado, la presencia de un facilitador externo, no implicado directamente en las decisiones sobre la arquitectura, hace posible que el proceso de análisis se centre en sistema real y no el el “deseado” o idealizado por sus autores.

La dinámica de Escenarios de Uso aporta una gran ventaja. Las conclusiones del diagnóstico surgen como consecuencia de una reflexión interna de la organización. Por lo que sus miembros las asumen como propias.

Como consecuencia de esta labor, además de los habituales entregables (descritos en el artículo anterior), se obtienen unos resultados intangibles que aportan gran valor a la cultura de la organización. Así, el equipo técnico obtenemos una visión coherente con Negocio sobre objetivos de la organización. Y, en el sentido opuesto, los expertos en negocio adquieren conocimiento sobre los aspectos clave de la arquitectura y las decisiones técnicas tomadas para darles soporte.

Riesgos

El mayor inconveniente de esta estrategia basada en escenarios es la necesaria implicación de personas claves de la organización durante un prolongado periodo de tiempo. El impacto de esta dedicación pude diluirse empleando una aproximación iterativa-incremental, evitando secuestrar a los expertos durante un periodo continuado de tiempo. También es útil planificar las acciones coincidiendo con los ciclos productivos de la organización. Por ejemplo, al comienzo de las iteraciones de desarrollo, los miembros del equipo suelen disponer de más tiempo y pueden afrontar las reuniones con menos distracciones.

Otro riesgo de esta metodología es que el equipo emplee la oportunidad del diagnóstico y a la figura del analista como canal de comunicación priorizado. Y, así, trate de promover iniciativas que en el contexto habitual no consigue justificar. El Analista debe emplear su experiencia profesional y personal para no situarse como intermediario de esta comunicación. Proporcionar su opinión, pero promover un diálogo debate entre los actores implicados en la arquitectura de software.

Conclusiones:

En esta ocasión te he presentado las prácticas basadas en Escenarios de Uso para la realización práctica de Diagnóstico de Arquitectura de Software. Hemos visto el papel que juegan los Escenarios de Uso en el refinamiento y priorización de los atributos cualitativos del sistema de software, el rol del Analista-Facilitador en este proceso y te he descrito algunas ventajas y riesgos de la aproximación. Sin duda, hay mucho más que profundizar, pero las bases están ahí. Si te interesa incorporar estas prácticas de Diagnóstico de Arquitectura de Software a tu organización, podemos acompañarte.

En mi próxima publicación, me centraré en una aproximación muy distinta. El diagnóstico basado en experto. Considero que esta dos estrategias son complementarias. Con ellas, afrontamos necesidades o escenarios muy distintos de la organización. Por lo que combinándolas cubrimos un abanico muy amplio de necesidades.

Cómo realizar un diagnóstico de Arquitectura de Software

¿Qué es la Arquitectura de Software?

Hoy en día, las tecnologías de la información (IT) están omnipresentes en la estrategia de las organizaciones. Se apoyan en ellas para ganar ventajas competitivas y perfiles como CIO o CTO tienen pesos significativos en los consejos de administración. El Diagnóstico de la Arquitectura de Software evalúa la capacidad de los sistemas IT para soportar los objetivos de negocio. Su atención ha pasado del contexto técnico a extenderse por todos los ámbitos de gestión. Pero ¿Qué queremos decir cuando hablamos de Arquitectura de Software?

La Arquitectura de Software o de Sistemas (vamos a emplear los dos términos indistintamente) es central al desarrollo de software. Así que vas a encontrar corpus documental gigante al respecto. Las definiciones son muy técnicas y llenas de contexto. Creo que una definición sencilla puede ser: El conjunto de piezas con los que está construido un sistema IT y la forma en la que se comunican entre sí para implementar los servicios de la organización. Si, ya sé que “piezas” no suena muy técnico. 

Para entenderlo mejor, déjame hacer un paralelismo con la arquitectura de un edificio. Sus espacios, distribución y atributos (capacidad, versatilidad, cumplimiento de normativas) definen lo bueno que es el edificio para los usos que la compañía le quiere dar. De la misma forma, en el ámbito de los servicios IT, sus componentes (orígenes de datos, servidores de aplicaciones, sistema de monitorización, …), la forma en la que se comunican (canales, protocolos, políticas, …) y sus atributos (capacidad de adaptarse a la demanda, modificabilidad, cumplimiento de estándares, …) nos informan sobre lo conveniente que es para el negocio.

Nota.- Esto es solo un ejemplo. Que me disculpen los miembros de la Architect Registration Board que defiende el uso del término “Architect” en exclusiva en el contexto de la edificación.

Descripción de la Arquitectura de Software

Las características de la arquitectura no siempre son evidentes y, desde luego, no son conocidas por todos los miembros de la organización. La documentación sobre la arquitectura puede ser costosa de mantener y suele estar expresada en un lenguaje muy técnico. Lo que nos va muy bien a los ingenieros para crear una barrera de protección. Pero, en organizaciones ágiles, basadas en equipos autosuficientes y multidisciplinares, esta distancia acaba siendo un gran problema. El objetivo de una descripción de la arquitectura es que toda la organización entienda la situación actual, y las decisiones de negocio y técnicas que están detrás de esa realidad. Con el objetivo de que toda la organización entienda su aplicación y límites.

Para describirla, debes crear visión de la arquitectura actualizada y real. Sin idealizaciones basadas en diagramas y opiniones (mánchate las manos, revisa código y la realidad de producción). Exprésala de forma que puede ser comprendida, en sus aspectos fundamentales (vamos, lo que de verdad importa),  y compartida por equipo técnico y de negocio (prioriza lenguaje natural y abstracciones de alto nivel cuando uses diagramas). Identifícala como los objetivos de negocio clave tienen su soporte (o no!) en las decisiones arquitectónicas y, finalmente, las soluciones técnicas para implementarlas.

¿Cuándo debemos realizar un diagnóstico de la arquitectura de software?

El foco en la arquitectura de software debe ser constante en cualquier proyecto IT. La abordamos desde las primeras iteraciones de desarrollo y nos preocupamos de que sus líneas directrices sean familiares a todos los miembros de la organización. Los equipos realizan diagnósticos de la arquitectura de software como parte normal de su proceso de evaluación y adaptación.  Revisan los atributos clave, sus implementaciones y posibles alternativas. En el caso de equipos Scrum, el Product Owner y el Equipo de Desarrollo hablan de la arquitectura como parte de la retrospectiva, es evolucionada como contenido del Backlog y el mantenimiento de su documentación se incluye en la Definition of Done.

El diagnóstico de la arquitectura de software puede también iniciarse como un proceso ad-hoc, a demanda de un interesado en el sistema (ej. CTO, Product Owner, Development Team). En este artículo, Grady Booch, presenta algunas motivaciones frecuentes. Debajo te dejo algunos ejemplos de momentos en los que deberíamos realizar este ejercicio. Sobre todo en situaciones en los que efectuamos cambios significativos en el negocio o en la plataforma tecnológica de la organización:

  • Migración a la nube
  • Cambio de Monolito a SOA
  • Organización DevOps
  • Lanzamiento en nuevos mercados
  • Ampliación de servicios

El error es parte del aprendizaje, así que también es común realizar el diagnóstico cuando el sistema tiene problemas concretos conocidos por la organización. En este caso, el análisis tendrá un foco muy concreto, con ejemplos como:

  • Elevado coste de mantenimiento o adaptación de los servicios.
  • Incumplimiento de normativas.
  • Un prolongado time-to-market
  • Percepción de baja calidad por los clientes

diagnostico de arquitectura

¿Quién debe realizar el diagnóstico de arquitectura?


Lo puede realizar internamente la organización. Evidentemente, los equipos que han venido trabajando en el sistema son los que mejor lo conocen. Además, tiene la ventaja de que las conclusiones van a emanar de forma natural y son asumidas como propias. El riesgo estará en que el diagnóstico esté condicionado por nuestra vinculación con decisiones pasadas y acabe reflejando el status quo de la organización.

Frecuentemente, recurrimos a una tercera parte que aporte un nuevo enfoque y cierta distancia sobre la historia y las relaciones de influencia establecidas. La llegada de un consultor externo puede percibirse como una amenaza por el equipo. Por ello es importante aclarar los objetivos del diagnóstico e implicar a las personas clave en la elaboración de las conclusiones.

El análisis comienza con una sesión de presentación a interesados. Y, uno de los primeros objetivos consiste, en obtener una definición consensuada sobre el alcance. Cuando iniciamos el diagnóstico para resolver preguntas o problemas concretos, el alcance está relativamente claro. Con proyectos más abiertos, puede necesitar algún refinamiento. En cualquier caso, es importante entender que no todos los interesados sabrán o querrán expresar abiertamente sus expectativas. Hay una labor muy importante de facilitación, comunicación y transparencia para hacer emerger posibles agendas ocultas.  

El diagnóstico debe contar con un patrocinador a un nivel ejecutivo.  De esta forma se asegurará la disponibilidad de los miembros clave del equipo (siempre ocupados) y el acceso a recursos restringidos de la compañía (código fuente, entorno de producción, etc.)

¿Cuál es el objetivo del diagnóstico?

Los sistemas basados en software son construcciones muy complejas, con multitud de interrelaciones y dependencias. Sería irrealista esperar que en una o dos semanas de trabajo (duración típica de un proyecto de diagnóstico) se alcancen conclusiones detalladas sobre un sistema que puede llevar años en evolución. El diagnóstico de la arquitectura de software debe centrarse en sus aspectos menos volátiles y el alcance del mismo de limitarse a uno o dos atributos prioritarios para el negocio. Este es el enfoque que recomendamos en nuestro servicio de Diagnóstico de Arquitectura de Software

La limitación en su duración controla el coste (interno y externo), facilita que nos enfoquemos en generar resultados concretos y adelanta el feedback.

Los componentes más estables de la arquitectura son los más viejos, los que han acumulado durante su vida más dependencias. También lo puedes ver al revés. Los componentes con más dependencias son los más difíciles de modificar (por los cambios en cascada que generan) y, por lo tanto, son los más estables. Sea como sea, están en en el centro de la red de dependencias de la arquitectura y, como tal, son los que tienen mayor peso en sus características. La lógica de negocio y, especialmente, la gestión de entidades maestras, suele jugar este rol central en la arquitectura.

Si nos centramos en aspectos que cambian con facilidad o que, de hecho, deben ser fácilmente modificables sin necesidad de consenso, generará resultados que se volverán rápidamente obsoletos. Un ejemplo son los patrones o frameworks empleados en la construcción de interfaces de usuario. Con esto no quiero minusvalorar, ni mucho menos, estos componentes tecnológicos. Pueden aportan un valor diferencial al servicio y, de hecho, suelen ser objeto de trabajos de diagnóstico específicos. Solo digo que no suelen ser objeto prioritario de un diagnóstico general.

La arquitectura representa las decisiones significativas de diseño que dan forma al sistema, donde significativas se mide por el coste de su modificación.
Grady Booch

Los requerimientos no funcionales suelen ser los marginados de los proyectos IT. Tanto en análisis como en documentación. Frecuentemente, nos centramos en los la funcionalidad del sistema y los atributos se limitan a una WishList del estilo “las interfaces de usuario deben ser fluidas y atractivas”.  Sin embargo, los requerimientos no funcionales, alias, atributos cualitativos, alias, ilities (de usab-ility, deployab-ility, etc), son el principal motor de las decisiones sobre arquitectura.

A la hora de explorarlos puedes usar mapas. Las taxonomías de atributos cualitativos se pueden emplear como referencia y se encuentran fácilmente en Internet (aquí te dejo un ejemplo). Las hay especializadas en aspectos como seguridad o robustez y en ámbitos tecnológicos como operaciones y desarrollo.  Algunos atributos muy habituales son:

  • Prestaciones, medida en tiempo de respuesta (mean response time) o capacidad para atender peticiones por segundo (throughput).
  • Resistencia, medida en tiempo de medio de recuperación ante errores (Mean Time to Restore).
  • Modificabilidad entendida como el tiempo necesario para llevar un nuevo servicio a producción (Change Lead Time), o la tasa de errores tras un cambio (Change Fail Percentage).

¿Cuál es el objetivo del diagnóstico?

El objeto del diagnóstico de la arquitectura de software será identificar los atributos cualitativos de la arquitectura que tiene mayor impacto en el negocio y las decisiones de técnicas que los soportan. Por ejemplo, en organizaciones enfocadas a mercado, la capacidad de reaccionar rápidamente es fundamental. Vemos que la modificabilidad es un atributo clave y el diagnóstico se centrará en los aspectos técnicos que lo facilitan: desacoplamiento, arquitecturas de servicios, test automáticos, independencia de despliegue, etc. Una empresa centrada a la gestión de maestros priorizará la veracidad y coherencia, o el cumplimiento de estándares. Más en general, los atributos de Testabilidad y Facilidad de Despliegue son objeto de especial atención en las organizaciones DevOps y se han demostrado claramente correlacionados con el éxito de las compañías basadas en uso intensivo de IT.

Como ves, las opciones son ilimitadas. Si te limitas a preguntar, todos queremos que nuestros sistemas tengan todas las -ilities: seguro, modificable, interoperable, usable, … Como responsable del análisis tienes que limitar su alcance. Para ello, hay que concretar el significado de los atributos con definiciones claras (implementables y mensurables). Poniendo sobre la mesa la relación coste-beneficio de su análisis. Debe realizar un esfuerzo de facilitación para alcanzar un consenso sobre uno o dos atributos claves para la organización. De otra forma, se corre el riesgo de que la diagnóstico se quede en la superficie y no llegue a conclusiones accionables.

¿Qué resultados genera el Diagnóstico?

El principal objetivo del diagnóstico de la arquitectura de software es generar conocimiento sobre la arquitectura real del sistema y su adecuación a los objetivos de la compañía. Las conclusiones se deben reflejar en documentación que los equipos puedan mantener tras la finalización del proyecto. Aunque su contenido puede variar en función de los objetivos concretos del diagnóstico, es habitual que se genere un informe recogiendo los siguientes puntos:

  • Vista de la arquitectura de software: Modelo del estado actual de la arquitectura.
  • Puntos sensibles, Riesgos y Fortalezas del sistema. Elementos de la arquitectura que hay que vigilar para mantener los niveles de calidad;  decisiones arquitectónicas que no están claramente definidas o que no soportan convenientemente los atributos de calidad en los niveles esperados y; finalmente diseños que se demuestran como sólidos activos de la solución.
  • Acciones Recomendadas. Lista priorizada de oportunidades que pueda llevarse a un plan de acción o roadmap para su desarrollo.

Además de la documentación detallada para los equipos, es común crear un resumen ejecutivo con las conclusiones más relevantes.

En futuros artículos te hablaré sobre ámbitos en la Arquitectura de Sistemas, formas de visualizar la arquitectura y metodologías para su diagnóstico Diagnóstico de Arquitectura.

  • « Ir a la página anterior
  • Ir a la página 1
  • Ir a la página 2

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad