Diagnóstico de Arquitectura de Software Basado en Experto

 La Arquitectura de Software es central en la estrategia de las organizaciones que basan su negocio en el uso intensivo de la tecnología. Sus atributos de desplegabilidad y testabilidad son fundamentales para una organización que se plantee la evolución hacia DevOps, son el foco de un diagnóstico de arquitectura de software. Por otro lado, el State of DevOps Report  2018 señala como fundamental la adaptación de la arquitectura para estandarizarla y ajustarla a las necesidades de negocio. 

 Cuales son los elementos de la arquitectura de software a mejorar y cómo priorizar los cambios es el objeto fundamental del Diagnóstico de Arquitectura de Software. En publicaciones anteriores hablé sobre el valor de arquitectura y su diagnóstico, así como la metodología basada en escenarios de uso. En esta entrada te introduciré al diagnóstico basado en experto. 

Casos de Aplicación del Diagnóstico basado en Experto

En el anterior artículo sobre diagnóstico con escenarios de uso, vimos como retornaba un gran valor a la organización en forma de activos tangibles y cambios culturales. Como inconveniente, tiene un coste elevado en términos de tiempo y dedicación de personas claves para la organización. Esto hace que la aproximación basada en escenarios no siempre sea la mejor. 

En algunos contextos, cultura de empresa o situaciones especiales, se prefiere limitar el número de personas implicadas sobre el proceso. Otro caso, es que se desee obtener una visión rápida e independiente sobre las características fundamentales de la arquitectura. En estos casos, una aproximación basada en el trabajo de un experto externo puede resultar más conveniente en su relación conste-resultados. Algunos ejemplos que me he encontrado en mi carrera profesional son: 

•     La evaluación de los activos IT de una compañía para su posible adquisición o como socios de negocio (ej, Due Diligence).
•     Procesos de acreditación de cumplimiento de estándares o normativas reguladoras (ej, RGPD, implementación de receta electrónica).
•     Reorganización del área tecnológica de la compañía (Ley de Conway). 
•     Valoración del estado para un nuevo ejecutivo a cargo del área de IT. 

En general, las metodologías basadas en escenario son ideales para conducir un diagnóstico interno. La incorporación de de un facilitador externo, ayuda a consolidar esta práctica en la organización. Por el contrario, si lo que se necesita es un resultado rápido realizado por un asesor externo, la aproximación basada en experto parece más adecuada.

Proceso de Diagnóstico 

El asesor realiza el diagnóstico recabando la información disponible por la organización sobre la arquitectura y con reuniones limitadas a un conjunto muy reducido de expertos en negocio y tecnología. El propio patrocinador del estudio y un arquitecto suele ser suficiente.

A diferencia de la aproximación colaborativa planteada por la estrategia de escenarios, los atributos de la arquitectura no emergen como consecuencia del debate, sino que son identificados por el asesor y confirmados por la organización. En este sentido, distintos trabajos ponen de manifiesto que es más productivo, cuando se dispone de un stakeholder con dedicación limitada, afrontar el proceso con una dinámica de refinamiento. 

En este proceso, el asesor presenta su visión sobre los requerimientos funcionales y atributos cualitativos de la arquitectura para que el representante de la organización confirme su apreciación o plantee correcciones. Este proceso, suele ofrecer mejores resultados que la alternativa por la que el propio stakeholder los elabora. 

No obstante, el analista no puede limitarse a recabar la opinión de los representantes de la organización. En el diagnóstico experto es fundamental que el asesor contraste esta información con el análisis de los artefactos reales del sistema: código funcional y test, registro de incidencias, plataforma de despliegue, operaciones en producción, métricas, etc. Ésta es la auténtica verdad sobre el sistema, no la idealizada por sus creadores. 

El código no miente. Ahí está la verdad sobre la arquitectura

 En este contexto es especialmente importante la figura del promotor del diagnóstico, quien debe plantear un objetivo claro para el análisis,  con preguntas/dudas específicas a las que dar respuesta. Además, debe disponer de suficiente nivel ejecutivo en la organización para garantizar la disponibilidad de los expertos y el acceso a los recursos del sistema a evaluar. 

Por su parte, el analista debe disponer de una sólida experiencia en la tecnología y el negocio de la organización para poder llevar a cabo su labor de forma, principalmente, autónoma. La confianza del promotor en su nivel de conocimientos es clave para afrontar el proceso y que las conclusiones sean asumidas y extendidas a toda la organización.

Iteraciones y Alcance:

El proceso se basa en una o varias iteraciones en las que el asesor genera y refina con los expertos asignado. Su visión del contexto del negocio, la vista de la arquitectura, las decisiones arquitectónicas claves para el negocio y la realidad de su implementación. Todo ello, lleva a una enumeración de riesgos y fortalezas que constituirán la base del informe final para el patrocinador del estudio. 

La ausencia de una documentación mínima razonable, previa al inicio de los trabajos, puede desviar el foco. Hacer que la dedicación se desvíe hacia su elaboración, limitando las conclusiones ejecutivas del trabajo. En un primer contacto, debemos evaluar esta situación y revisar el alcance del proyecto con el promotor. Debemos asegurar que podemos afrontar el objetivo principal o bien, deben realizarse labores previas de preparación. 

El diagnóstico basado en conocimiento experto tiene un alcance más limitado que el elaborado con la técnica de escenarios de uso. Debido a la falta de contexto cualificado sobre el negocio y el sistema, las conclusiones están basadas en el juicio del asesor. Por ello, el foco debe reducirse a los grandes aspectos estructurales de la arquitectura de software. 

Así, el informe final puede resultar más superficial que los generados mediante trabajo colaborativo. No obstante, en contextos en los que se desea obtener un referencia independiente, cualificada y rápida para tomar una decisión ejecutiva, esta aproximación puede resultar la más efectiva. 

Conclusiones:

En esta ocasión, te he presentado el diagnóstico de Arquitectura de Software basado en experto externo, como contraste a la metodología basadas en Escenarios de Uso, ventajas e inconvenientes. Hemos visto el papel que juega el patrocinador del diagnóstico y la calificación del experto. También, hemos tratado la importancia de contrastar la visión de los desarrolladores con la realidad reflejada en el código. 

En mi próxima entrada sobre Arquitectura de Software, quiero analizar algunas herramientas para modelar las distintas visiones de la arquitectura. Como dice mi compañera Laura Jiménez, “los desarrolladores estáis todo el día dibujando cajitas”. Bueno, pues veremos esas “cajitas”.