Table of Contents
En su presentación titulada «Pragmatic Approach to Architecture Metrics» (Enfoque pragmático de las métricas de arquitectura) en el GSAS’22 organizado por Apiumhub, Sonya Natanzon y Vlad Khononov aportaron valiosas ideas. Ofrecieron al público amplio material para la reflexión, haciendo hincapié en la importancia de considerar las métricas de arquitectura pertinentes y adoptar un enfoque pragmático que arroje luz sobre la comprensión de los objetivos de las métricas y la necesidad de tomar decisiones informadas sobre qué medir.
Enfoque pragmático de las métricas de arquitectura
La importancia de las métricas de arquitectura
Con las métricas, empezamos a pensar en términos de …
Lo que se mide, se gestiona -Peter Drucker
Pero quizá sea más apropiado reformularlo como…
Lo que se mide, se gestiona, incluso cuando es inútil medirlo y gestionarlo, e incluso si ello perjudica el propósito de la organización.
-Simon Caulkin sobre el artículo de V.F. Ridgeway «Dysfunctional Consequences of Performance Measurements», 1956
No todo lo que podemos medir tiene necesariamente una importancia significativa y, a la inversa, hay elementos cruciales que desafían una medición fácil. La clave está en encontrar un equilibrio entre los indicadores medibles y una comprensión global de la finalidad y los objetivos generales de la organización.
¿Qué queremos medir?
Queremos saber si la arquitectura de software tiene éxito
Todo el mundo quiere métricas cuantitativas que demuestren el éxito
La arquitectura de software es nebulosa y difícil de medir
Ralph Johnson afirma acertadamente: «La arquitectura trata de lo importante. Sea lo que sea».
El propósito de la arquitectura radica en su alineación con los objetivos empresariales, haciendo hincapié en que lo verdaderamente importante para la arquitectura es lo que apoya eficazmente esos objetivos
Determinar qué cualidades arquitectónicas son importantes para respaldar los objetivos empresariales.
A ver si puede medirlas. Éstas son sus métricas de arquitectura
Evolución (exitosa) del producto
El viaje de la arquitectura de software implica el inicio, la evolución, la adopción del mercado, la expansión y la ampliación. Es crucial reconocer que la Evolución y la Escala representan dimensiones distintas del cambio.
El éxito de la arquitectura de software depende de su capacidad de adaptación para satisfacer las necesidades cambiantes de la empresa. Por consiguiente, evaluamos la capacidad de la arquitectura para aceptar el cambio a través de diversas métricas. Es importante reconocer que las estrategias que nos han llevado a nuestro estado actual pueden no ser suficientes para el crecimiento futuro. Las métricas deben alinearse con la progresión de la empresa en lugar de estar sujetas a consideraciones arquitectónicas, lo que hace necesaria su evolución continua.
Pero ten mucho cuidado con las métricas, porque…
Cuando una medida se convierte en un objetivo, deja de ser una buena medida. – Ley de Goodhart
Por ejemplo:
1. Cobertura del código
2. Errores encontrados
3. Frecuencia de despliegue
4. Índice de colisiones
Algunas buenas métricas a tener en cuenta:
Cambiar Frecuencia
¿Con qué frecuencia podemos hacer cambios significativos?
Eficacia del cambio
¿El cambio ha aportado valor a los usuarios?
Cambio Coste
¿Qué hace falta para cambiar?
Del libro Accelerate
Complejidad
A medida que aumenta la complejidad, también lo hace el coste asociado al cambio. El coste del cambio está intrínsecamente ligado a la complejidad de las modificaciones necesarias. Por consiguiente, nuestro objetivo es comprender y evaluar la complejidad de la arquitectura. La complejidad, como bien dice Geoffrey West, «se conoce cuando se ve».
La complejidad en el modelo Cynefin
– Se caracteriza por la relación entre causa y efecto
– ¿Hasta qué punto es predecible el resultado de una acción?
– En situaciones complejas, el resultado sólo puede determinarse mediante la experimentación empírica.
Por ejemplo:
– ¿Qué pasará si cambio esta línea de código?
– Un cambio que rompe partes no relacionadas del sistema
– No saber a qué módulos afectan los nuevos requisitos empresariales
¿Qué causa la complejidad?
- La complejidad surge de la interacción entre el diseño del sistema y nuestras capacidades cognitivas. En ella influyen los entresijos de la estructura y el comportamiento del sistema, así como nuestra capacidad para comprender y navegar por sus complejidades utilizando nuestras facultades cognitivas.
– Capacidad estimada de tratamiento de la información en la década de 1950: 7 +/- 2
Miller, G. A. (1994). El número mágico siete, más o menos dos: Algunos límites de nuestra capacidad para procesar información. Psychological Review, 101(2), 343-352
– Capacidad estimada de tratamiento de la información en la década de 2000: 4 +/- 1
Cowan, Nelson. «El número mágico 4 en la memoria a corto plazo: Una reconsideración de la capacidad de almacenamiento mental». Ciencias del comportamiento y del cerebro 24.1 (2001): 87-114.
Evaluación de la complejidad
Las métricas desempeñan un papel crucial a la hora de abordar la complejidad de los sistemas, ya que nos permiten cuantificar y evaluar los intrincados aspectos del diseño de sistemas y las capacidades cognitivas.
- Métrica de abstracción
La relación entre el número de clases abstractas e interfaces en el paquete analizado y el número total de clases en el paquete analizado. (Wikipedia)
Abstracción (A) = número de tipos abstractos/número de tipos concretos
- Métrica de inestabilidad
Relación entre el acoplamiento eferente (Ce) y el acoplamiento total (Ce + Ca).
Esta métrica es un indicador de la resistencia del paquete al cambio.
I=0 indica un paquete completamente estable
I=1 indica un paquete completamente inestable.
Inestabilidad (I) = nº de tipos de los que depende / (nº de tipos de los que depende + nº de tipos de los que depende)
- Distancia de la secuencia principal (D)
Distancia perpendicular de un paquete a la línea idealizada A + I = 1. Esta métrica es un indicador del equilibrio del paquete entre abstracción y estabilidad. Un paquete situado en la secuencia principal presenta un equilibrio óptimo entre abstracción y estabilidad. Los paquetes ideales son completamente abstractos y estables (I=0, A=1) o completamente concretos e inestables (I=1, A=0).
D=|A+I-1|
EL COSTE DEL CAMBIO ES PROPORCIONAL A LA DISTANCIA ENTRE LOS COMPONENTES
El objetivo
El objetivo de la evaluación de la complejidad es identificar las decisiones de diseño que contribuyen a una mayor carga cognitiva, lo que en última instancia conduce a mayores niveles de complejidad.
En esta primera parte, hemos explorado la importancia de las métricas y evaluado la complejidad dentro de una arquitectura de software. Sin embargo, aún queda mucho por descubrir. Permanece atento a la segunda parte, en la que profundizaremos en las métricas para el éxito y en el concepto de fuerza de integración. Acompáñanos en este interesante viaje hacia un enfoque pragmático de las métricas de arquitectura.
