Características de la Arquitectura del Software Software Craftsman Solution Architect @ AVANADE GitKraken Ambassador Arquitectura de Soluciones Versión 1.0.0, Diciembre de 2024

2 2 Motivo de la elaboración de este documento (1/2) Hablar sobre las características de la arquitectura del software es esencial porque estas características determinan en gran medida la calidad y la sostenibilidad del software a largo plazo. Entender y aplicar correctamente estos conceptos no solo ayuda a crear sistemas más robustos y eficientes, sino que también facilita la adaptación y evolución del software en respuesta a nuevos desafíos y oportunidades. La atención a los detalles arquitectónicos es lo que diferencia el software mediocre del excelente, y garantizar que estas características estén bien definidas y gobernadas es una inversión en el éxito continuo de cualquier proyecto de desarrollo de software. En matemáticas, los axiomas son proposiciones aceptadas como verdaderas sin necesidad de pruebas y son la base de las teorías. En arquitectura de software, aunque el entorno es más flexible y cambiante que en matemáticas, los axiomas también son fundamentales. El ecosistema de desarrollo de software está en constante cambio, influenciado por nuevas tecnologías y prácticas.

3 3 Motivo de la elaboración de este documento (2/2) Los arquitectos de software deben cuestionar constantemente los axiomas del pasado debido a la continua evolución de los ecosistemas operacionales, los procesos de desarrollo y las nuevas infraestructuras. Esto requiere la adopción de nuevas prácticas, herramientas, mediciones y patrones. A diferencia de una situación predecible y rutinaria, que podría describirse con la expresión "sota, caballo y rey", la arquitectura de software es dinámica y requiere innovación continua. No sigue un patrón fijo y estática; en cambio, se adapta y evoluciona con los cambios tecnológicos y las necesidades del negocio. Este documento busca proporcionar una visión analítica de la arquitectura de software, centrándose en las características arquitectónicas esenciales para el éxito y la sostenibilidad de los sistemas de software. Nota del autor La frase "sota, caballo y rey" es una expresión coloquial en español que se utiliza para describir una situación que es muy predecible o rutinaria, sin sorpresas ni variaciones. La frase proviene del juego de naipes, específicamente del juego de la brisca, donde las cartas de sota (también conocida como "jota"), caballo y rey son figuras que tienen un valor específico y que suelen aparecer con frecuencia en las manos de los jugadores. Cuando alguien dice que algo es "sota, caballo y rey", está indicando que la situación es siempre la misma, siguiendo un patrón fijo, sin lugar para la improvisación o la novedad. Por ejemplo, si en una empresa siempre se toman las mismas decisiones de manera predecible y sin innovación, se podría decir que su forma de operar es "sota, caballo y rey".

4 4 ¿A quién va dirigido este documento? Este documento está dirigido a todos los profesionales involucrados en el diseño y desarrollo de software dentro de la organización. Esto incluye a arquitectos de software, desarrolladores, gerentes de proyectos, y cualquier otra persona que participe en la planificación y ejecución de proyectos de software. Además, es un recurso valioso para aquellos que aspiran a convertirse en arquitectos de software, proporcionando una comprensión profunda de cómo las características de la arquitectura pueden mejorar la calidad y sostenibilidad del software a largo plazo. El propósito de este documento es doble: servir como una guía práctica para implementar y utilizar las características arquitectónicas en tu organización, y actuar como un recurso educativo para presentar y contextualizar los beneficios de una buena arquitectura de software a tu equipo y partes interesadas. Al entender y aplicar correctamente estos conceptos, los profesionales pueden crear sistemas más robustos y eficientes, facilitando la adaptación y evolución del software frente a nuevos desafíos y oportunidades.

5 5 ¿Cómo está organizado este documento? (1/2) Definición de Características de la Arquitectura • Introducción. • Las características de la arquitectura especifican criterios de diseño no relacionados con el dominio. • Influencian aspectos estructurales del diseño. • Son críticas para el éxito de la aplicación. Características de la Arquitectura • ¿Por qué ISO/IEC 25010 es un buen punto de partida? • Cómo completar y adaptar la lista. • Desde otro punto de vista. • Compromisos y la Arquitectura Más Adecuada. • Son críticas o importantes para el éxito de la aplicación. Importancia y Criterios de las Características de la Arquitectura • Diferencian la arquitectura del software del código y diseño • Extracción de características arquitectónicas • Caso de Uso: Sistema de Gestión de Eventos en Línea

6 6 ¿Cómo está organizado este documento? (2/2) Medición y Gobernanza de Características de la Arquitectura • Importancia de definir medidas objetivas para las características. • Caso de Uso. • Sobre la Gobernanza. Identificación de las Características Arquitectónicas • Proceso iterativo de identificación y refinamiento. • Extracción de características del dominio y de las preocupaciones de los stakeholders. Granularidad de los Componentes de Características de la Arquitectura • Importancia de encontrar el nivel adecuado de granularidad. • Riesgos de una granularidad incorrecta: demasiada comunicación entre componentes o acoplamiento interno alto. Resolver Problemas, por Características Arquitectónicas vamos a tener que tomar una decisión • Teoremas que nos ayudan. • Características y como medirlas contra el estilo de una arquitectura. Más Información: Amplia tus Conocimientos • Otras ISO/IEC para tener en cuenta. • Enlaces para que continues tu investigación.

7 7 Definición (1/14) Introducción: ¿Qué son las Características de la Arquitectura? Las características arquitectónicas, también conocidas como atributos de calidad del sistema, son las prioridades de tu sistema o producto. Identificarlas permite diseñar una arquitectura que cumpla con las prioridades de los interesados. Documentarlas de manera efectiva asegura que se puedan utilizar para cumplir dichas prioridades. Las características arquitectónicas pueden ser creadas y aplicadas independientemente del método utilizado para analizar y crear la arquitectura del sistema. Estas incluyen tanto requisitos funcionales como no funcionales, aunque suelen estar más relacionadas con los requisitos no funcionales, que son aquellos relacionados con la operación del sistema más que con su comportamiento. Definir y documentar características arquitectónicas efectivas puede guiar las decisiones de diseño y proyecto. No existe una lista de estas características, ya que dependen de cada situación específica, pero se puede crear una lista adecuada para cada empresa o producto. Algunos ejemplos de características arquitectónicas incluyen accesibilidad, disponibilidad, configurabilidad, continuidad, extensibilidad, portabilidad, privacidad y escalabilidad. Es aconsejable limitar las características arquitectónicas a un máximo de siete para facilitar una priorización eficaz. Algunas características implícitas que siempre son importantes incluyen viabilidad, mantenibilidad, seguridad y simplicidad. Además, el costo puede considerarse como una característica implícita separada de la viabilidad.

8 8 Definición (2/14) Las características arquitectónicas deben ser revisadas y ajustadas a medida que el producto o sistema evoluciona, pasando por fases de producto inicial, crecimiento y optimización. Esta revisión puede ser desencadenada por hitos comerciales definidos o programada periódicamente. Una vez definidas, las características arquitectónicas deben ser utilizadas para respaldar el resto del diseño del sistema. Es importante documentar las áreas del sistema a las que se aplican, las fuentes de las que provienen, asignarles una identidad y mantener un registro histórico de las mismas. Identificar las tres principales prioridades entre las características seleccionadas también puede ayudar en la toma de decisiones. Un ejemplo de cómo registrar características arquitectónicas efectivas incluye indicar las áreas del sistema a las que se aplican, registrar las fuentes, asignarles una identidad, listar todas las características consideradas y mantener un historial con fechas relevantes. También es útil identificar las tres prioridades principales para facilitar la toma de decisiones. Nota del autor ¿Por qué 7? A menudo se interpreta que el número de objetos que un humano promedio puede tener en la memoria de trabajo es entre 5 y 9, es decir, 7 ± 2. Esto se conoce como Ley de Miller o el mágico número siete, más o menos dos.

9 9 Definición (3/14) Una forma habitual para registrar las características: • Identificación de Características: cada característica arquitectónica debe tener un identificador único para facilitar su referencia en la documentación y las decisiones de diseño. • Área Aplicable: Indica las áreas específicas del sistema a las que se aplica cada característica. Esto puede ser un subconjunto del sistema, como servicios específicos, almacenes de datos o componentes. ID Característica Área de Aplicación Precursor Fecha de Creación Última Actualización Próxima Revisión Prioridad AC001 Privacidad Información de usuarios REQ035: La información debe estar encriptada 11/15/2024 11/19/2024 12/10/2024 Alta AC002 Extensibilidad Agregación de nuevas fuentes de pagos REQ016: Trabajan con distintos bancos y cada dos meses suelen añadir un nuevo proveedor 11/15/2024 11/18/2024 12/10/2024 Alta AC003 Auditabilidad Logs de uso REQ058: Registro de usuarios y accesos granularidad completa 11/15/2024 11/18/2024 12/10/2024 Alta AC004 Tolerancia a Fallos Disponibilidad del API de Pagos REQ009, REQ011 y REQ101. 11/18/2024 11/19/2024 12/10/2024 Media AC005 Privacidad GDPR Legislación de Protección de Datos 11/18/2024 11/19/2024 12/10/2024 Baja

10 10 Definición (4/14) • Fuente: Registra la fuente de cada característica arquitectónica. Puede ser un requisito documentado, el resultado de un análisis, o derivado de sesiones de storytelling o EventStorming. Documenta también cualquier razonamiento adicional que no esté incluido en las fuentes indicadas. • Historia y Fechas: Mantén un historial de cada característica, incluyendo la fecha de creación, la última actualización y la próxima revisión programada. Esto asegura que las características estén actualizadas y sigan siendo válidas con el tiempo. • Priorización: Identifica y documenta las tres características arquitectónicas principales (aquellas que indicamos Alta) para ayudar en la priorización de decisiones basadas en estas características. Trabaja con los stakeholders para determinar estas prioridades y documenta las razones detrás de la selección. Decisiones Técnicas Características Arquitectónicas Ingeniería Software Arquitectura Software Construir Aplicaciones Involucrado activamente en el ciclo de vida del desarrollo del software Requerimientos No Funcionales Alinear Negocio y Tecnología Interacción de aplicaciones Visión general de las aplicaciones como un todo

11 11 Definición (5/14) Introducción: ¿Características Implícitas? Las características arquitectónicas implícitas son aquellos atributos de un sistema que siempre son importantes y necesarios para su correcto funcionamiento, independientemente del contexto específico o de las prioridades del proyecto. Estas características no suelen contarse dentro de las siete principales, ya que se asume que siempre deben estar presentes y ser consideradas. Sin embargo, si alguna de estas características se vuelve crítica para el éxito del sistema, puede incluirse entre las siete principales. Ejemplos de Características Implícitas: • Viabilidad: La capacidad de implementar la solución dadas las restricciones presentes, como el presupuesto, el tiempo y los recursos disponibles. • Mantenibilidad: La facilidad con la que el sistema puede ser mantenido y actualizado eficientemente a lo largo del tiempo. • Seguridad: La capacidad del sistema para protegerse contra accesos no autorizados y asegurar la integridad y confidencialidad de los datos. • Simplicidad: La medida en que el sistema es simple y no complicado, lo que facilita su comprensión y uso. • Costo: Aunque relacionado con la viabilidad, el costo se considera separadamente porque casi todas las empresas buscan minimizar gastos y optimizar el retorno de inversión.

12 12 Definición (6/14) Razones para No Contar las Características Implícitas en las Siete Principales • Presencia Constante: Las características implícitas son fundamentales y se espera que siempre estén presentes en cualquier sistema. No requieren una priorización explícita porque se asume su inclusión de manera predeterminada. • Enfoque en lo Específico: Al no contar las características implícitas dentro de las siete principales, se permite a los equipos enfocarse en atributos específicos y únicos que son críticos para el éxito del sistema en su contexto particular. Esto ayuda a gestionar mejor las prioridades y a tomar decisiones de diseño más informadas. • Evitar la Sobrecarga: Limitar las características principales a siete permite a los equipos evitar la sobrecarga de información y facilita la toma de decisiones. Incluir características implícitas, que ya se consideran esenciales, podría desviar la atención de otras prioridades críticas. Inclusión de Características Implícitas como Principales Aunque no se cuentan generalmente dentro de las siete principales, las características implícitas pueden elevarse a este nivel si su importancia crítica lo requiere. Por ejemplo, si un sistema comienza a manejar datos sensibles debido a cambios en la legislación, la seguridad puede convertirse en una de las principales prioridades a considerar explícitamente en el diseño y desarrollo del sistema.

13 13 Definición (7/14) Introducción: ¿Cómo se integra en el Ciclo de Vida? Fases del Ciclo de Vida del Producto • Producto Inicial: Esta es la fase donde el producto está siendo concebido y desarrollado por primera vez. • Crecimiento: En esta fase, el producto está siendo adoptado y utilizado por más usuarios, y puede estar experimentando mejoras y adiciones de funcionalidades. • Optimización: En esta etapa, el producto está maduro y se enfoca en mejorar su eficiencia, rendimiento y otras características de calidad. Producto Inicial • Crea características de arquitectura. • Usa las características de arquitectura Crecimiento • Usa características de arquitectura. • Revisa las características de arquitectura Optimización • Usa características de arquitectura. • Revisa las características de arquitectura

14 14 Definición (8/14) Uso de las Características Arquitectónicas • Crear: En la fase de producto inicial, se deben crear las características arquitectónicas. Esto implica identificar y documentar las características clave que el sistema debe cumplir para satisfacer los requisitos de los interesados. • Usar: En las fases de crecimiento y optimización, las características arquitectónicas deben ser usadas continuamente. Esto significa que deben guiar las decisiones de diseño y desarrollo a medida que el sistema evoluciona y se adapta a nuevas necesidades y desafíos. • Revisar: Tanto en la fase de crecimiento como en la de optimización, es crucial revisar periódicamente las características arquitectónicas. Esto asegura que sigan siendo relevantes y adecuadas a medida que cambian las circunstancias del negocio, las tecnologías y los requisitos del sistema.

15 15 Definición (9/14) Las características de la arquitectura especifican criterios de diseño no relacionados con el dominio Cuando se diseña una aplicación, los requisitos especifican qué debe hacer la aplicación; sin embargo, las características arquitectónicas especifican los criterios operativos y de diseño necesarios para el éxito, enfocándose en cómo implementar los requisitos y por qué se tomaron ciertas decisiones. Por ejemplo, una característica arquitectónica común e importante puede especificar un cierto nivel de rendimiento para la aplicación, algo que a menudo no aparece en un documento de requisitos. Es decir, mientras los requisitos se centran en las funcionalidades del sistema, las características arquitectónicas se centran en cómo esas funcionalidades deben ser implementadas de manera efectiva y eficiente. Más aún, ningún documento de requisitos suele incluir una declaración como "prevenir la deuda técnica", pero esta es una consideración de diseño común para arquitectos y desarrolladores. Por eso es importante diferenciar entre: Características Explícitas • Definición: Son aquellas características claramente especificadas y documentadas durante el diseño del sistema. • Ejemplo: Nivel de rendimiento esperado, escalabilidad, capacidad de respuesta, etc. • Importancia: Estas características proporcionan criterios claros y medibles que deben ser cumplidos para que el sistema sea considerado exitoso.

16 16 Definición (10/14) Características Implícitas • Definición: Son aquellas características que, aunque no estén siempre especificadas en los documentos de requisitos, son críticas para el diseño estructural del sistema. • Ejemplo: Seguridad, mantenibilidad, prevención de la deuda técnica. • Importancia: Estas características son inherentes al buen diseño del sistema y se espera que estén presentes, aunque no se mencionen explícitamente. Son esenciales para asegurar que el sistema sea sostenible y eficiente a largo plazo. Importancia de la Distinción La distinción entre características explícitas e implícitas es crucial porque ayuda a las arquitectas y a los desarrolladores a asegurarse de que todos los aspectos importantes del diseño del sistema se tengan en cuenta, incluso aquellos que no están formalmente documentados. Es decir, esta distinción asegura que el sistema no solo cumpla con sus requisitos funcionales, sino que también sea robusto, mantenible y eficiente a lo largo del tiempo. Nota del autor En otras palabras y para que quede suficientemente claro: Las características de la arquitectura especifican criterios de diseño no relacionados con el dominio porque se enfocan en aspectos operacionales y técnicos, como el rendimiento y la mantenibilidad, que son esenciales para el éxito del sistema, independientemente de la funcionalidad específica del dominio.

17 17 Definición (11/14) Influencian aspectos estructurales del diseño Las características arquitectónicas influyen en ciertos aspectos estructurales del diseño del sistema. Los arquitectos intentan describir estas características porque son cruciales para las consideraciones de diseño: ¿requiere esta característica arquitectónica una consideración estructural especial para tener éxito? Ejemplo de Escalabilidad en el Diseño La escalabilidad es una preocupación importante en muchos proyectos, ya que todos los sistemas deben ser capaces de manejar un aumento en la carga de trabajo. Sin embargo, se convierte en una característica arquitectónica relevante cuando el arquitecto necesita diseñar algo especial para abordar esa preocupación. Consideremos dos casos en un sistema de ejemplo relacionado con el manejo de datos de usuarios: Sistema con Base de Datos Centralizada • Descripción: Si el sistema utiliza una base de datos centralizada para almacenar todos los datos de usuarios, la arquitectura no debería requerir consideraciones estructurales especiales para la escalabilidad. • Detalles: El diseño debe incorporar prácticas estándar como la indexación y optimización de consultas, pero no necesita una estructura especial. • Implicación: La característica de escalabilidad se maneja con medidas estándar de optimización de base de datos sin necesidad de cambios estructurales significativos en el diseño.

18 18 Definición (12/14) Sistema con Base de Datos Distribuida • Descripción: Si la aplicación en diseño debe manejar grandes volúmenes de datos de usuarios y necesita escalar horizontalmente, el arquitecto puede diseñar una base de datos distribuida. • Detalles: Este diseño específico ayuda a distribuir la carga de trabajo a través de múltiples servidores, mejorando así la capacidad de manejar grandes volúmenes de datos y solicitudes. • Implicación: Ahora, la característica arquitectónica de escalabilidad tiene un impacto tanto en la arquitectura como en el diseño, requiriendo una estructura específica para abordar la escalabilidad de manera efectiva. Consideraciones Adicionales Por supuesto, estos dos criterios (base de datos centralizada y base de datos distribuida) no son suficientes en muchos casos para tomar una determinación completa. Factores como la naturaleza de los datos, patrones de acceso y requisitos de consistencia pueden influir en la decisión de diseño. Importancia de las Consideraciones Estructurales Este ejemplo muestra algunas de las consideraciones que los arquitectos deben tener en cuenta al determinar cómo diseñar ciertas capacidades. La necesidad de una estructura especial para abordar características arquitectónicas como la escalabilidad puede influir significativamente en el diseño general del sistema. Es decir, no solo se trata de implementar funcionalidades, sino de cómo esas funcionalidades se integran de manera escalable y eficiente en la arquitectura del sistema.

19 19 Definición (12/14) Son críticas para el éxito de la aplicación Las aplicaciones pueden soportar una gran cantidad de características arquitectónicas... pero no deberían. Cada característica arquitectónica que se añade aumenta la complejidad del diseño. Por lo tanto, una tarea crucial para los arquitectos es elegir la menor cantidad de características arquitectónicas necesarias en lugar de intentar incluir la mayor cantidad posible. Importancia de Seleccionar Características Arquitectónicas Críticas o Importantes Complejidad del Diseño: • Descripción: Cada característica arquitectónica adicional implica una capa extra de consideraciones y posibles complicaciones en el diseño. • Detalles: Incluir demasiadas características puede hacer que el sistema sea más difícil de mantener, probar y extender, y puede introducir más puntos de falla. • Implicación: La complejidad del diseño puede aumentar de manera exponencial con cada característica adicional, lo que puede afectar negativamente la eficiencia y la robustez del sistema

20 20 Definición (13/14) Enfoque en lo Esencial • Descripción: En lugar de tratar de soportar todas las posibles características arquitectónicas, los arquitectos deben centrarse en aquellas que son realmente críticas para el éxito de la aplicación. • Detalles: Esto significa identificar las características que tienen el mayor impacto en el rendimiento, la seguridad, la escalabilidad y otras prioridades clave del sistema. • Implicación: Al centrarse en un conjunto reducido pero esencial de características, los arquitectos pueden diseñar un sistema más eficiente y manejable, que cumpla con los objetivos principales sin innecesarias complicaciones. Ejemplo Práctico: Consideremos el caso de una aplicación de comercio electrónico: Características Críticas • Seguridad: La seguridad es fundamental para proteger la información de los clientes y las transacciones financieras. • Escalabilidad: La capacidad de manejar un gran número de usuarios simultáneos es crucial para el éxito durante eventos de alta demanda, como las ventas flash. • Rendimiento: La velocidad de carga de las páginas y la rapidez de las transacciones son esenciales para una buena experiencia del usuario y para mantener a los clientes en la plataforma.

21 21 Definición (13/14) Características Menos Críticas • Personalización Extrema: Aunque la personalización puede mejorar la experiencia del usuario, no es tan crítica como la seguridad o el rendimiento inicial. • Integración con Redes Sociales: Si bien es útil, no es esencial para el funcionamiento básico del sistema y puede añadirse en fases posteriores. Decisiones de Diseño • Selección: Las arquitectas deben priorizar las características críticas como seguridad, escalabilidad y rendimiento, ya que estas son fundamentales para el éxito de la aplicación. • Optimización: Al centrarse en un conjunto reducido de características esenciales, los arquitectos pueden optimizar el diseño para asegurar que estas se implementen de la manera más eficiente posible. • Evolución: Las características menos críticas pueden planificarse para fases posteriores del desarrollo, permitiendo una evolución gradual del sistema sin comprometer su estabilidad y eficiencia inicial. La clave del éxito en el diseño arquitectónico de una aplicación radica en la selección cuidadosa de las características arquitectónicas que realmente importan.

22 22 Definición (14/14) DISEÑO Críticas para el Éxito de la Aplicación CARACTERÍSTICAS ARQUITECTÓNICAS

23 23 Características (1/15) ¿Por qué ISO/IEC 25010 es un buen punto de partida? La norma ISO/IEC 25010 es un estándar internacional que define un modelo de calidad para sistemas y software. Es un excelente punto de partida para identificar características arquitectónicas porque proporciona una visión integral de los atributos de calidad que son esenciales para el éxito de un sistema. A continuación, se presentan algunas de las características clave según ISO/IEC 25010 y para que comencéis a diferencia que una característica y que no es una característica con respecto a la definición del apartado anterior también lo ponemos: Funcionalidad • Adecuación funcional: La capacidad del software para proporcionar funciones que satisfacen las necesidades específicas del usuario. ¿Es una característica de arquitectura?: No. Es una característica funcional que se enfoca en qué hace el software más que en cómo está estructurado para hacerlo. • Exactitud: La capacidad de entregar resultados correctos y precisos. ¿Es una característica de arquitectura?: No. Esta característica se refiere a la calidad de los resultados generados por el software, no a su estructura. • Interoperabilidad: La capacidad del software para interactuar con otros sistemas o componentes. ¿Es una característica de arquitectura?: Sí. Requiere decisiones de diseño arquitectónico sobre cómo los sistemas se comunicarán y compartirán datos.

24 24 Características (2/15) Fiabilidad • Madurez: La capacidad del software para evitar fallos debido a defectos. ¿Es una característica de arquitectura?: No. Se relaciona más con la calidad del código y el proceso de desarrollo. • Disponibilidad: La capacidad del software para estar operativo y accesible cuando se necesita. ¿Es una característica de arquitectura?: Sí. Implica decisiones sobre redundancia, balanceo de carga y otros aspectos estructurales. • Tolerancia a fallos: La capacidad del software para mantener un nivel especificado de rendimiento en caso de fallos. ¿Es una característica de arquitectura?: Sí. Requiere decisiones sobre cómo manejar fallos y mantener la operación continua. • Recuperabilidad: La capacidad del software para recuperarse de fallos y restaurar los datos afectados. ¿Es una característica de arquitectura?: Sí. Implica decisiones sobre estrategias de backup y recuperación. Eficiencia de Desempeño • Comportamiento temporal: La capacidad del software para proporcionar tiempos de respuesta y procesamiento adecuados. ¿Es una característica de arquitectura?: Sí. Requiere decisiones sobre cómo estructurar el sistema para optimizar el rendimiento. • Utilización de recursos: La capacidad del software para utilizar recursos de manera eficiente. ¿Es una característica de arquitectura?: Sí. Implica decisiones sobre la gestión de recursos como CPU, memoria y almacenamiento.

25 25 Características (3/15) Usabilidad • Capacidad de ser comprendido: La facilidad con la que los usuarios pueden aprender a usar el software. ¿Es una característica de arquitectura?: No. Es una característica de diseño de interfaz de usuario. • Capacidad de ser operado: La facilidad con la que los usuarios pueden operar y controlar el software. ¿Es una característica de arquitectura?: No. También se relaciona más con la interfaz de usuario. • Protección contra errores de usuario: La capacidad del software para proteger a los usuarios contra errores. ¿Es una característica de arquitectura?: No. Se relaciona más con el diseño de la experiencia del usuario. Mantenibilidad • Capacidad de ser modificado: La facilidad con la que el software puede ser modificado. ¿Es una característica de arquitectura?: Sí. Implica decisiones sobre modularidad, separación de preocupaciones y otros aspectos que facilitan la evolución del sistema. • Capacidad de ser analizado: La facilidad con la que los defectos pueden ser identificados y diagnosticados. ¿Es una característica de arquitectura?: Sí. Requiere decisiones sobre cómo estructurar el sistema para facilitar el análisis y la depuración. • Capacidad de ser probado: La facilidad con la que el software puede ser probado para asegurar que cumple con los requisitos. ¿Es una característica de arquitectura?: Sí. Implica decisiones sobre la estructura del código y la implementación de pruebas automatizadas.

26 26 Características (4/15) Portabilidad • Capacidad de ser adaptado: La facilidad con la que el software puede ser transferido de un entorno a otro. ¿Es una característica de arquitectura?: Sí. Requiere decisiones sobre la abstracción y la independencia de la plataforma. • Capacidad de ser instalado: La facilidad con la que el software puede ser instalado en un entorno especificado. ¿Es una característica de arquitectura?: No. Se relaciona más con el proceso de instalación y despliegue. Características Relacionadas Directamente con la Arquitectura Características No Relacionadas Directamente con la Arquitectura • Interoperabilidad • Disponibilidad • Tolerancia a fallos • Recuperabilidad • Comportamiento temporal • Utilización de recursos • Capacidad de ser modificado • Capacidad de ser analizado • Capacidad de ser probado • Capacidad de ser adaptado • Adecuación funcional • Exactitud • Madurez • Capacidad de ser comprendido • Capacidad de ser operado • Protección contra errores de usuario • Capacidad de ser instalado

27 27 Características (5/15) Cómo Completar y Adaptar la Lista Una vez identificadas estas características de partida, los arquitectos pueden completar y adaptar la lista considerando los siguientes pasos, algunos ya lo vimos en el capítulo anterior: • Análisis de Requisitos Específicos: Realizar un análisis detallado de los requisitos específicos del proyecto para identificar cualquier característica adicional que sea relevante. • Priorizar Características: No todas las características tienen el mismo nivel de importancia para todos los proyectos. Es crucial priorizar las características en función de los objetivos del negocio, las necesidades del usuario y las restricciones del proyecto. • Evaluación de Riesgos: Identificar y evaluar los riesgos asociados con cada característica. Algunas características pueden ser esenciales para mitigar riesgos críticos, lo que puede influir en su priorización. • Feedback de Stakeholders: Involucrar a los stakeholders clave (clientes, usuarios finales, equipo de desarrollo, etc.) para obtener su feedback y asegurarse de que las características seleccionadas satisfacen sus necesidades y expectativas. • Iteración y Revisión: La arquitectura del sistema no es estática. A medida que el proyecto avanza, es importante revisar y ajustar las características arquitectónicas según sea necesario, basándose en nuevos conocimientos y cambios en los requisitos. • Documentación Detallada: Documentar claramente cada característica arquitectónica, incluyendo su propósito, requisitos de implementación, y cualquier consideración especial. Esto asegura que todos los miembros del equipo tengan una comprensión común y pueden seguir las directrices establecidas.

28 28 Características (6/15) Ejemplo de Adaptación de Características Supongamos que estamos desarrollando una aplicación de salud móvil que debe manejar datos sensibles de los pacientes y proporcionar recomendaciones de salud basadas en esos datos. A partir de la lista basada en ISO/IEC 25010, podríamos adaptar y priorizar las siguientes características arquitectónicas: Interoperabilidad • Relevancia: Es crucial para permitir la comunicación entre la aplicación y otros sistemas de salud, como dispositivos médicos y sistemas de gestión hospitalaria. • Implementación: Diseñar APIs bien definidas y utilizar estándares de comunicación como HL7 o FHIR. Disponibilidad • Relevancia: La aplicación debe estar disponible en todo momento, especialmente en situaciones de emergencia. • Implementación: Utilizar estrategias de alta disponibilidad como balanceo de carga y replicación de servidores. Tolerancia a fallos • Relevancia: Es vital para asegurar que la aplicación continúe funcionando incluso si algunos componentes fallan. • Implementación: Implementar mecanismos de failover y redundancia en los componentes críticos del sistema. • Recuperabilidad Relevancia: La aplicación debe ser capaz de recuperarse rápidamente después de un fallo para minimizar el impacto en los usuarios. • Implementación: Diseñar sistemas de backup y recuperación automatizados y robustos. • Comportamiento temporal • Relevancia: Las recomendaciones de salud deben proporcionarse rápidamente para ser útiles. • Implementación: Optimizar el rendimiento mediante el uso de cachés, bases de datos de alto rendimiento y técnicas de optimización de código.

29 29 Características (7/15) Utilización de recursos • Relevancia: La aplicación debe ser eficiente en el uso de recursos del dispositivo, como batería y datos móviles. • Implementación: Implementar técnicas de optimización de recursos, como la compresión de datos y la gestión eficiente de la memoria. Capacidad de ser modificado • Relevancia: La aplicación debe ser fácil de actualizar para incorporar nuevas funcionalidades y adaptarse a cambios en los requisitos. • Implementación: Utilizar una arquitectura modular y principios de diseño como la inyección de dependencias para facilitar las modificaciones. Capacidad de ser adaptado • Relevancia: La aplicación debe poder ser desplegada en diferentes entornos y plataformas. • Implementación: Utilizar tecnologías multiplataforma y contenedores para facilitar la adaptación a diferentes entornos.

30 30 Características (8/15) Desde otro punto de vista Podemos optar por agrupar características en función de operaciones, que se definen como las actividades y procesos necesarios para mantener el sistema funcionando de manera eficiente y efectiva. • Disponibilidad: Se refiere al tiempo que el sistema debe estar operativo. Si se requiere disponibilidad continua (24/7), es esencial tener medidas para que el sistema se recupere rápidamente en caso de falla. • Continuidad: Esta característica se enfoca en la capacidad del sistema para recuperarse de desastres y mantener la operación continua. • Rendimiento: Involucra pruebas y análisis para asegurarse de que el sistema pueda manejar la carga esperada, incluyendo pruebas de estrés y análisis de tiempos de respuesta. Aceptar el rendimiento puede ser un proceso largo y detallado. • Recuperabilidad: Se refiere a la rapidez con la que el sistema debe volver a estar operativo después de un desastre. Esto influye en las estrategias de respaldo y la necesidad de hardware redundante. • Fiabilidad/seguridad: Evalúa si el sistema debe ser a prueba de fallos y si es crítico para la misión, afectando vidas o finanzas significativamente si falla. • Robustez: La capacidad del sistema para manejar errores y condiciones adversas, como caídas de conexión a internet o fallos de energía. • Escalabilidad: La capacidad del sistema para seguir funcionando eficientemente a medida que crece el número de usuarios o solicitudes.

31 31 Características (9/15) Podemos optar por agrupar características en función de la estructura, que se define como la organización y calidad interna del código, incluyendo aspectos como modularidad, acoplamiento controlado entre componentes y legibilidad del código. • Configurabilidad: Se refiere a la facilidad con la que los usuarios pueden cambiar la configuración del software a través de interfaces amigables. • Extensibilidad: Evalúa la importancia de poder añadir nuevas funcionalidades al sistema. • Reutilización: Se refiere a la capacidad de reutilizar componentes comunes en diferentes productos. • Localización: Implica el soporte para múltiples idiomas en pantallas de entrada y consulta de datos, así como en informes, y la capacidad de manejar caracteres de distintos alfabetos y distintas unidades de medida o monedas. • Mantenibilidad: Mide lo fácil que es aplicar cambios y mejorar el sistema. • Portabilidad: Evalúa si el sistema necesita operar en más de una plataforma. • Capacidad de actualización: Evalúa la facilidad y rapidez con la que se puede actualizar de una versión anterior a una más nueva en servidores y clientes.

32 32 Características (10/15) Podemos optar por agrupar características en función de los aspectos transversales, que se definen como restricciones y consideraciones de diseño importantes que no encajan fácilmente en categorías específicas. • Accesibilidad: Se refiere a garantizar que todos los usuarios, incluyendo aquellos con discapacidades, puedan acceder y utilizar el sistema efectivamente. • Retención de Datos: Evalúa la necesidad de archivar o eliminar datos después de un cierto período, afectando cómo se gestionan los datos a lo largo del tiempo. • Autenticación: Asegura que los usuarios son quienes dicen ser, proporcionando una capa esencial de seguridad. • Autorización: Garantiza que los usuarios solo puedan acceder a funciones específicas dentro de la aplicación, protegiendo así los datos y funcionalidades críticas. • Legales: Implica cumplir con las restricciones legislativas y regulaciones que afectan cómo se debe construir y desplegar la aplicación. • Privacidad: Capacidad para proteger las transacciones y datos sensibles de ser visibles incluso para empleados internos, mediante el uso de encriptación. • Seguridad: Abarca la necesidad de encriptar datos tanto en la base de datos como en la comunicación en red, y define los requisitos de autenticación para el acceso remoto. • Soportabilidad: Determina el nivel de soporte técnico necesario, así como las facilidades de registro y depuración de errores. • Usabilidad: Evalúa el nivel de formación que los usuarios necesitan para utilizar la aplicación y alcanzar sus objetivos, destacando la importancia de los requisitos de usabilidad.

33 33 Características (11/15) Por lo tanto, estas agrupaciones de características del software pueden interpretarse como una adaptación o una perspectiva alternativa a los puntos de vista establecidos en la norma ISO/IEC 25010. Sin embargo, mientras que la ISO/IEC 25010 proporciona una estructura más formal y estandarizada, las agrupaciones mencionadas anteriormente ofrecen un enfoque más práctico, orientado al diseño y a la operación del sistema. A continuación, se presenta una comparativa: Experiencia del Usuario • Interfaz de Usuario (UI): Esto se relaciona con la sub-característica "Usabilidad" de ISO/IEC 25010, que incluye "Atractivo" y "Facilidad de uso". • Experiencia de Usuario (UX): También encaja bajo "Usabilidad", incluyendo "Satisfacción del usuario" y "Comprensibilidad". • Accesibilidad: ISO/IEC 25010 incluye "Accesibilidad" como una sub-característica de "Usabilidad". • Personalización: Esto puede estar relacionado con "Adaptabilidad" en el contexto de "Funcionalidad" y "Usabilidad". • Receptividad: Encaja bajo "Rendimiento" y "Eficiencia temporal". Seguridad • Autenticación y Autorización: Estas son parte de la sub-característica "Seguridad" en ISO/IEC 25010, que incluye "Confidencialidad", "Integridad", "Autenticidad" y "Responsabilidad". • Encriptación: Relacionado con "Confidencialidad" y "Integridad". • Auditoría: Esto cae bajo "Responsabilidad" en "Seguridad". • Gestión de Vulnerabilidades: Relacionado con "Protección de ataques" en "Seguridad".

34 34 Características (12/15) Mantenibilidad • Documentación: Esto se relaciona con "Mantenibilidad", particularmente con "Capacidad de ser analizado". • Modularidad: Directamente relacionado con "Modularidad" en "Mantenibilidad". • Testabilidad: Esto se encuentra bajo "Mantenibilidad", específicamente "Capacidad de ser probado". • Refactorización: Relacionado con "Modularidad" y "Capacidad de ser modificado". • Gestión de Configuración: Esto puede estar en "Mantenibilidad" y también en "Portabilidad". Escalabilidad • Elasticidad y Distribución: Estas características pueden estar bajo "Rendimiento" y "Eficiencia temporal". • Balanceo de Carga: Relacionado con "Capacidad de respuesta" en "Eficiencia". • Capacidad de Almacenamiento: Relacionado con "Capacidad de carga" en "Eficiencia". • Optimización de Rendimiento: Directamente relacionado con "Rendimiento" y "Eficiencia". Integración • Interoperabilidad: Esto es una característica principal en ISO/IEC 25010, específicamente bajo "Compatibilidad". • APIs y Conectividad: Relacionado con "Interoperabilidad". • Compatibilidad: Directamente en línea con "Compatibilidad" en ISO/IEC 25010. • Sincronización: También relacionado con "Interoperabilidad" y "Compatibilidad".

35 35 Características (13/15) Compromisos (trade-offs) y la Arquitectura Más Adecuada Las aplicaciones solo pueden soportar algunas de las características arquitectónicas que hemos listado por diversas razones. Primero, cada una de las características soportadas requiere esfuerzo de diseño y, quizás, soporte estructural. Segundo, el problema más grande radica en el hecho de que cada característica arquitectónica a menudo tiene un impacto en las demás. Por ejemplo, si un arquitecto desea mejorar la seguridad, casi con certeza impactará negativamente el rendimiento: la aplicación debe realizar más cifrado en tiempo real, redireccionamientos y otras actividades que potencialmente degradan el rendimiento. Por ejemplo: imagina que estás construyendo una casa. Si decides usar materiales muy pesados para garantizar la durabilidad, esto podría requerir cimientos más fuertes y, por ende, más costosos. Además, queremos añadir ventanas grandes para mejorar la iluminación natural, pero esto podría comprometer la eficiencia energética. De manera similar, al diseñar un sistema, cada decisión arquitectónica puede impactar otras áreas, creando un constante ejercicio de equilibrio. Por lo tanto, los arquitectos rara vez se encuentran en la situación de poder diseñar un sistema que maximice cada una de las características arquitectónicas. Más a menudo, las decisiones se reducen a compromisos entre varias características. Nota del autor La arquitectura de software es muy ambigua. La falta de definiciones claras lleva a las empresas a crear sus propios términos, causando aún más confusión. Se recomienda usar un lenguaje común, como el lenguaje ubicuo de DDD, para evitar malentendidos.

36 36 Características (14/15) Cuando tomas decisiones en el desarrollo de software, cada una de ellas lleva implícitos ciertos compromisos. Estos compromisos pueden no ser evidentes a primera vista, pero están presentes y pueden impactar en el proyecto de manera significativa. Ejemplos de compromisos • Elección de Tecnología ▪ Compromisos Evidentes: Elegir una tecnología popular como ReactJS puede facilitar la contratación de desarrolladores debido a la amplia comunidad y documentación. ▪ Compromisos No Evidentes: Sin embargo, esta elección puede implicar una curva de aprendizaje para el equipo actual si no están familiarizados con la tecnología. • Arquitectura de Microservicios vs. Monolítica ▪ Compromisos Evidentes: Optar por una arquitectura de microservicios puede mejorar la escalabilidad y la gestión de dependencias. ▪ Compromisos No Evidentes: Puede aumentar la complejidad del despliegue y la necesidad de una infraestructura más robusta.

37 37 Características (15/15) Consejos Prácticos • Identificación de Compromisos: Antes de tomar una decisión, haz una lista de posibles compromisos asociados. Por ejemplo, si decides implementar una nueva funcionalidad, ¿cómo afectará esto al rendimiento del sistema? ¿Qué impacto tendrá en la experiencia del usuario? • Evaluación de Importancia: No todos los compromisos tienen el mismo peso. Evalúa cuáles son críticos para el éxito del proyecto y cuáles pueden ser mitigados o gestionados de manera efectiva. Utiliza técnicas como el análisis de impacto y la matriz de priorización. • Requisitos No Funcionales (NFR) ▪ Identificación: Haz un esfuerzo consciente para identificar los NFR de tu aplicación. Estos pueden incluir rendimiento, escalabilidad, seguridad, mantenibilidad y usabilidad. ▪ Coordinación: Trabaja en estrecha colaboración con el negocio y otros interesados para asegurarte de que estos requisitos estén alineados con las expectativas y necesidades del proyecto. Por ejemplo, si el tiempo de carga es un NFR crítico, asegúrate de que todos los involucrados comprendan su importancia. • Documentación y Comunicación: Documenta todos los compromisos identificados y sus posibles impactos. Comunica esta información a todo el equipo y a los stakeholders para que todos estén al tanto y puedan tomar decisiones informadas. Y esto nos lleva irremisiblemente a los Architectural Decision Records (ADRs): una herramienta eficaz para mitigar los problemas asociados con los compromisos en el desarrollo y la arquitectura de software. Os recomiendo leeros el monográfico: Registros de Decisiones Arquitectónicas (ADR), publicado en mi blog.

38 38 Importancia y Criterios (1/10) Diferencian la arquitectura del software del código y diseño La identificación de las características arquitectónicas es fundamental en la creación o validación de una arquitectura de software. Este proceso permite diferenciar claramente la arquitectura del software del código y del diseño detallado. Las características arquitectónicas son propiedades importantes que determinan la estructura y el comportamiento del sistema a nivel macro. Para identificar correctamente estas características, la persona encargada de la arquitectura debe comprender profundamente el problema del dominio y colaborar estrechamente con las personas interesadas para determinar lo que es realmente crucial. Quien diseña la arquitectura descubre las características arquitectónicas de tres maneras principales: extrayéndolas de las preocupaciones del dominio, de los requisitos explícitos y del conocimiento implícito del dominio. Por tanto La arquitectura del software se diferencia del diseño y del código en varios aspectos clave. La arquitectura se centra en las decisiones estructurales y de alto nivel que afectan a todo el sistema, mientras que el diseño se ocupa de los detalles de implementación dentro de esa estructura. El código es la implementación concreta de los diseños

39 39 Importancia y Criterios (2/10) Extracción de características arquitectónicas De las preocupaciones del dominio El arquitecto debe traducir las preocupaciones del dominio en características arquitectónicas adecuadas. Por ejemplo, si la escalabilidad es una preocupación principal, el arquitecto debe diseñar una arquitectura que pueda manejar un gran número de usuarios concurrentes sin degradar el rendimiento. Es esencial mantener la lista de características lo más corta posible para evitar una arquitectura excesivamente compleja. De los requisitos Algunas características arquitectónicas provienen de declaraciones explícitas en los documentos de requisitos. Por ejemplo, los números esperados de usuarios y la escala suelen aparecer en los requisitos del dominio. Otras características se derivan del conocimiento implícito del dominio, que es beneficioso para los arquitectos. Por ejemplo, al diseñar un sistema de registro para estudiantes, el arquitecto debe considerar que los estudiantes pueden intentar registrarse en el último momento, lo que requiere una arquitectura capaz de manejar picos de carga.

40 40 Importancia y Criterios (3/10) Ejemplo Consideremos un sistema de pedidos en línea para una cadena de tiendas de on-line. Los requisitos incluyen: • Permitir a los usuarios hacer pedidos en línea. • Proveer tiempos estimados de recogida y direcciones a las tiendas. • Integrarse con servicios de mapeo externos. • Ofrecer promociones diarias tanto a nivel nacional como local. • Aceptar pagos en línea, en persona o a la entrega. Desde una perspectiva arquitectónica, el arquitecto debe identificar características como: • Escalabilidad: Para manejar miles de usuarios. • Integrabilidad: Para conectarse con servicios de mapeo externos. • Seguridad: Para las transacciones de pago. Estas decisiones estructurales afectan cómo se organiza y se comporta el sistema en su conjunto.

41 41 Importancia y Criterios (4/10) Por inferencia Las características arquitectónicas comprenden elementos cruciales del sistema que no están directamente relacionados con los problemas específicos del negocio (los requisitos funcionales) o el dominio que la aplicación pretende resolver. Estas características se enfocan en aspectos técnicos y de diseño que son esenciales para el funcionamiento global, la calidad y la eficiencia del sistema, independientemente del contexto particular del dominio de la aplicación. Ejemplo • Escalabilidad: La capacidad del sistema para manejar un aumento en la carga de trabajo sin comprometer el rendimiento, independientemente del tipo de negocio. En el caso de la tienda online, debe escalar bien en un evento como Black Friday para no perder ventas. • Disponibilidad: Asegurar que el sistema esté operativo y accesible en todo momento, sin importar el problema específico que resuelve. • Seguridad: Implementación de medidas para proteger los datos y las operaciones del sistema contra accesos no autorizados y amenazas, aplicable a cualquier tipo de aplicación. • Mantenibilidad: Facilidad con la que el sistema puede ser actualizado y corregido, relevante para todos los sistemas sin importar su propósito específico. • Rendimiento: La eficiencia con la que el sistema realiza sus funciones, crucial para cualquier aplicación independientemente del dominio.

42 42 Importancia y Criterios (5/10) Caso de Uso: Sistema de Gestión de Eventos en Línea Descripción Una empresa de organización de eventos quiere desarrollar una plataforma en línea que permita a los usuarios crear, gestionar y asistir a eventos de manera virtual o presencial. La plataforma debe integrar funciones de registro, programación, y notificaciones en tiempo real. Usuarios • Organizadores de eventos • Asistentes a eventos • Administradores de la plataforma Requisitos • Los organizadores deben poder crear y gestionar eventos, incluyendo la configuración de detalles como fecha, hora, ubicación (virtual o física), y capacidad. • Los asistentes deben poder registrarse para eventos, recibir confirmaciones y recordatorios, y acceder a detalles del evento. • La plataforma debe soportar notificaciones en tiempo real para actualizaciones de eventos y comunicaciones entre organizadores y asistentes. • Debe ser accesible desde dispositivos móviles y de escritorio. • Integración con herramientas de videoconferencia para eventos virtuales. • Gestión de pagos para eventos que requieran entradas de pago.

43 43 Importancia y Criterios (6/10) Contexto Adicional • La plataforma debe ser capaz de manejar múltiples eventos simultáneamente. • La empresa planea expandirse internacionalmente, por lo que el sistema debe soportar múltiples idiomas y zonas horarias. • La seguridad es una prioridad debido a la gestión de datos personales y pagos. • Identificación de Características Arquitectónicas Identificación de Características Arquitectónicas Características Explícitas • Escalabilidad: La plataforma debe manejar múltiples eventos y usuarios concurrentes sin degradar el rendimiento. • Integrabilidad: Necesidad de integración con herramientas de videoconferencia y sistemas de pago. • Seguridad: Protección de datos personales y transacciones financieras. Características Implícitas • Disponibilidad: El sistema debe estar disponible en todo momento, especialmente durante los eventos. • Fiabilidad: Garantizar que las notificaciones y actualizaciones se entreguen de manera consistente y oportuna. • Usabilidad: La plataforma debe ser fácil de usar tanto en dispositivos móviles como en escritorio. Nota el autor Como podéis observar entre características implícitas y explicitas tenemos solamente 7. Recordar la Ley de Miller o el mágico número siete, más o menos dos. Además hemos marcado como máximo 3 características importantes, las explícitas.

44 44 Importancia y Criterios (7/10) Diferenciación entre Arquitectura y Diseño Arquitectura La arquitectura del sistema se centrará en la estructura de alto nivel que permite la escalabilidad, la integrabilidad y la seguridad. Por ejemplo, se puede optar por una arquitectura basada en microservicios para facilitar la escalabilidad y la integración con herramientas externas. Diseño El diseño detallado abordará cómo se implementarán las funciones específicas dentro de la arquitectura establecida. Por ejemplo, el diseño de la interfaz de usuario para la creación y gestión de eventos, o el flujo de trabajo para el proceso de registro y notificación. Código El código será la implementación concreta de las decisiones de diseño, como la programación de los formularios de registro, las llamadas a las API de videoconferencia y las funciones de notificación en tiempo real. Priorización y Colaboración Es crucial priorizar las características arquitectónicas más importantes y colaborar con desarrolladores, gerentes de proyecto y otros interesados para tomar decisiones informadas. No todas las características son igualmente importantes, y parte del trabajo del arquitecto es equilibrar las necesidades del dominio con la simplicidad y la viabilidad del sistema. Por ejemplo, en este caso, la seguridad y la disponibilidad pueden ser priorizadas por encima de la usabilidad en la primera fase del proyecto, para asegurar que los datos de los usuarios y las transacciones financieras estén protegidos desde el inicio.

45 45 Importancia y Criterios (8/10) Pasos para la Priorización • Revisión de Requisitos: ▪ Reunir a todos los interesados clave para revisar y validar los requisitos del sistema. ▪ Asegurarse de que todas las necesidades críticas del negocio y de los usuarios estén claramente documentadas. • Identificación de Características Críticas: ▪ Trabajar con los interesados para identificar las tres características arquitectónicas más importantes. ▪ Discusión y consenso sobre por qué estas características son prioritarias. • Evaluación de Compromisos: ▪ Analizar los posibles compromisos entre diferentes características arquitectónicas. ▪ Por ejemplo, priorizar la seguridad puede requerir compromisos en términos de rendimiento o usabilidad. • Iteración y Feedback: ▪ Implementar un enfoque iterativo donde las decisiones arquitectónicas se revisen y ajusten continuamente con base en el feedback recibido. ▪ Realizar pruebas y validaciones tempranas para detectar y corregir posibles problemas. En base a los anteriores pasos, os muestro unos ejemplos de Priorización En el caso del sistema de gestión de eventos en línea, se podría priorizar de la siguiente manera: • Seguridad: ▪ Implementación de medidas de seguridad robustas para proteger los datos personales y financieros de los usuarios. ▪ Integración con proveedores de pago seguros y cumplimiento de normativas de protección de datos.

46 46 Importancia y Criterios (9/10) • Escalabilidad: ▪ Diseño de una arquitectura que permita manejar un gran número de usuarios y eventos concurrentes. ▪ Uso de tecnologías y patrones de diseño que faciliten la escalabilidad horizontal. • Disponibilidad: ▪ Garantizar que la plataforma esté disponible y funcional en todo momento, especialmente durante los eventos. ▪ Implementación de estrategias de alta disponibilidad y recuperación ante desastres. Colaboración en la Implementación • Reuniones Regulares: ▪ Establecer reuniones regulares con todos los equipos involucrados para discutir el progreso, los desafíos y las soluciones. ▪ Utilizar herramientas de gestión de proyectos para mantener a todos informados y alineados. • Feedback Continuo: ▪ Fomentar una cultura de feedback continuo donde los desarrolladores, diseñadores y otros interesados puedan aportar sus perspectivas y sugerencias. ▪ Realizar revisiones de código y sesiones de prueba para garantizar que las decisiones arquitectónicas se implementen correctamente. • Documentación y Comunicación: ▪ Mantener una documentación clara y actualizada de todas las decisiones arquitectónicas y los razonamientos detrás de ellas. ▪ Utilizar diagramas y visualizaciones para comunicar la arquitectura de manera efectiva a todos los miembros del equipo.

47 47 Importancia y Criterios (10/10) En base a los anteriores pasos, os muestro unos ejemplos de Colaboración Reuniones Diarias (Dailys), a las 10:00h • Objetivo: Sincronizar el equipo y resolver impedimentos. • Formato: 15 minutos, cada miembro responde: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay impedimentos? • Frecuencia: Diaria. Reuniones Semanales (Weeklys), todos los lunes a las 11:00h • Objetivo: Revisar el progreso y planificar la semana siguiente. • Formato: 1 hora para discutir logros, ajustar prioridades y resolver problemas estratégicos. • Frecuencia: Semanal. Reuniones de Comité de Arquitectura, el primer y tercer miércoles del més Objetivo: Discutir y validar decisiones arquitectónicas. Formato: 1-2 horas con arquitectos y líderes técnicos. Frecuencia: Bimensual o mensual. Foros de Discusión en Línea: • Objetivo: Facilitar la comunicación continua y resolver problemas rápidamente. • Formato: Uso de herramientas como Microsoft Teams. • Frecuencia: Continua. Y puedes también poner “Sesiones de Revisión de Código” para asegurar la calidad del código y alineación con la arquitectura, etc. Esto dependerá mucho de la forma de comulación de tu empresa o del cliente al que estés destinado/a.

48 48 Medición y Gobernanza (1/10) Importancia de definir medidas objetivas para las características Las personas encargadas de una arquitectura de software deben gestionar una amplia variedad de características arquitectónicas en distintos aspectos de los proyectos de software. Estas características pueden ser operacionales, como el rendimiento, la elasticidad y la escalabilidad, o estructurales, como la modularidad y la capacidad de despliegue. A continuación, voy a definir concretamente algunas de las características arquitectónicas más comunes y en establecer mecanismos de gobernanza para ellas. Medición de las Características de la Arquitectura Existen varios problemas comunes en la definición de características arquitectónicas en las organizaciones: • Vaguedad: Muchas características arquitectónicas tienen significados vagos. Por ejemplo, ¿cómo se diseña para la agilidad o la capacidad de despliegue?. • Definiciones Variadas: Incluso dentro de la misma organización, diferentes departamentos pueden tener definiciones distintas de características críticas como el rendimiento. • Composición Compleja: Muchas características deseables se componen de otras más pequeñas. Por ejemplo, la agilidad puede descomponerse en modularidad, capacidad de despliegue y capacidad de prueba.

49 49 Medición y Gobernanza (2/10) Definir objetivamente las características arquitectónicas resuelve estos problemas al crear un lenguaje común y permitir la descomposición de características compuestas en aspectos medibles. Medidas Operacionales Muchas características arquitectónicas tienen medidas directas evidentes, como el rendimiento o la escalabilidad. Sin embargo, incluso estas pueden tener interpretaciones matizadas. Por ejemplo, medir solo el tiempo de respuesta promedio puede ocultar condiciones límite donde el 1% de las solicitudes tarda 10 veces más que otras. Es importante también medir los tiempos de respuesta máximos para capturar estos casos atípicos. Rendimiento El rendimiento tiene múltiples definiciones matizadas. Por ejemplo, muchos proyectos se enfocan en ciclos de solicitud y respuesta para aplicaciones web. Las organizaciones pueden investigar el comportamiento del usuario y determinar métricas críticas, como el tiempo óptimo para el primer renderizado de una página, y establecer presupuestos de rendimiento para partes específicas de la aplicación.

50 50 Medición y Gobernanza (3/10) Medidas Estructurales Algunas medidas objetivas no son tan evidentes como el rendimiento. Por ejemplo, la complejidad ciclomática (CC) es una métrica de nivel de código que proporciona una medida objetiva de la complejidad del código. Un código excesivamente complejo puede perjudicar características deseables como la modularidad, la capacidad de prueba, la capacidad de despliegue y comprensión de las características funciones (por ejemplo, este es un punto extremadamente importante para una migración a un leguaje más moderno). Prácticas de Ingeniería Prácticas como el desarrollo guiado por pruebas (TDD) pueden generar métodos menos complejos, ya que los desarrolladores escriben el código más pequeño posible para pasar una prueba, fomentando métodos bien estructurados y cohesivos. Medidas de Proceso Algunas características arquitectónicas están relacionadas con los procesos de desarrollo de software. Por ejemplo, la agilidad puede descomponerse en características como la capacidad de prueba y la capacidad de despliegue. Estas pueden medirse mediante herramientas de cobertura de código y métricas de despliegue, respectivamente.

51 51 Medición y Gobernanza (4/10) Caso de Uso Definición de Medidas Objetivas para las Características Es crucial definir medidas objetivas para las características arquitectónicas para crear un lenguaje común y permitir la descomposición de características compuestas en aspectos medibles. Esto facilita la gobernanza y la comunicación dentro de los equipos de desarrollo. Pruebas de Integridad Arquitectónica Las pruebas de integridad arquitectónica son mecanismos que proporcionan una evaluación objetiva de la integridad de alguna característica arquitectónica. No se trata de un nuevo marco de trabajo para descargar, sino de una nueva perspectiva sobre herramientas existentes. Por ejemplo, una prueba de integridad arquitectónica puede ser una prueba automatizada que asegura que no existen dependencias cíclicas entre módulos, garantizando así a modularidad. Ejemplo para realizar pruebas de integridad arquitectónica arquitectónicas en proyectos de software en C#, puedes utilizar varias bibliotecas y herramientas. En este caso voy a usar NetArchTest.

52 52 Medición y Gobernanza (5/10) NetArchTest es una biblioteca en C# que permite realizar pruebas automatizadas para verificar la arquitectura del software. Esta herramienta está inspirada en ArchUnit de Java y proporciona una manera de definir y comprobar reglas arquitectónicas. Características de NetArchTest • Definición de Reglas Arquitectónicas: Puedes definir reglas que las clases y namespaces de tu proyecto deben cumplir. • Verificación de Dependencias: Verifica que las dependencias entre módulos sigan las directrices establecidas. • Integración con Pruebas Unitarias: Puedes integrar las reglas arquitectónicas como pruebas unitarias utilizando frameworks como Xunit o NUnit. Instala la librería: Install-Package NetArchTest.Rules

53 53 Medición y Gobernanza (6/10) En este ejemplo, se definen dos pruebas: • NoCyclicDependencies: Verifica que no existan dependencias cíclicas entre los namespaces especificados. • LayeredArchitecture: Asegura que el namespace Presentation no dependa directamente del namespace Data, respetando así la arquitectura en capas. Otras Herramientas Además de NetArchTest, existen otras herramientas y bibliotecas que pueden ser útiles para la integridad arquitectónica en proyectos de C#: • NDepend: Es una herramienta avanzada para análisis estático de código y evaluación de métricas de calidad de software. Permite definir reglas personalizadas y verificar la adherencia a las mismas. • SonarQube: Aunque es una herramienta general de análisis de código, también ofrece capacidades para verificar ciertas reglas arquitectónicas y de calidad del código.

54 54 Medición y Gobernanza (7/10) Ejemplo para realizar definición de medidas objetivas para características Arquitectónicas en proyectos de software en C#, puedes utilizar varias bibliotecas y herramientas. En este caso continúo usando NetArchTest. Modularidad Definición: La modularidad se refiere a la capacidad de dividir el software en módulos o componentes independientes y reutilizables. Medidas Objetivas: • Número de Dependencias Cíclicas: Utilizar herramientas como NetArchTest para asegurar que no existan dependencias cíclicas entre módulos. • Complejidad Ciclomática: Medir la complejidad ciclomática de los métodos utilizando herramientas como NDepend. Un valor aceptable puede ser menor a 10 para métodos individuales. • Acoplamiento entre Módulos: Evaluar el acoplamiento entre módulos. Por ejemplo, medir el porcentaje de métodos públicos que son utilizados por otros módulos. Un valor objetivo puede ser mantener el acoplamiento por debajo del 20%.

55 55 Medición y Gobernanza (8/10) Rendimiento Definición: El rendimiento se refiere a la rapidez con la que el sistema responde a las solicitudes y realiza sus funciones. Medidas Objetivas: • Tiempo de Respuesta: Medir el tiempo promedio de respuesta de las solicitudes HTTP utilizando herramientas de monitoreo como Application Insights. Un valor objetivo puede ser menos de 500 ms para el 95% de las solicitudes. • Tasa de Errores: Medir la tasa de errores (por ejemplo, errores 500 en una API). El objetivo podría ser mantener la tasa de errores por debajo del 1%. • Uso de CPU y Memoria: Monitorear el uso de CPU y memoria durante las operaciones pico. Objetivo: Uso de CPU por debajo del 70% y uso de memoria por debajo del 80%. Escalabilidad Definición: La escalabilidad se refiere a la capacidad del sistema para manejar un aumento en la carga de trabajo sin comprometer el rendimiento. Medidas Objetivas: • Rendimiento bajo Carga: Realizar pruebas de carga utilizando herramientas como JMeter y Azure Load Testing. Objetivo: El sistema debe manejar 1000 usuarios concurrentes manteniendo un tiempo de respuesta por debajo de 1 segundo. • Elasticidad: Medir la capacidad del sistema para escalar automáticamente en función de la carga. Objetivo: Tiempo de escala hacia arriba o hacia abajo no debe exceder los 2 minutos. • Latencia de Red: Medir la latencia de red entre diferentes componentes del sistema. Objetivo: La latencia de red debe mantenerse por debajo de 100 ms en la mayoría de las interacciones críticas entre componentes.

56 56 Medición y Gobernanza (9/10) Sobre la Gobernanza de la Arquitectura La gobernanza de la arquitectura es crucial para asegurar que las características arquitectónicas se mantienen a lo largo del ciclo de vida del proyecto. A continuación, se presentan algunos consejos y mecanismos de gobernanza para asegurar la integridad y el cumplimiento de las características arquitectónicas definidas: Consejos de Gobernanza Definir Políticas Claras: Establecer políticas claras sobre cómo deben ser implementadas y medidas las características arquitectónicas. Documentar estas políticas y asegurarse de que todos los miembros del equipo las entienden. Revisiones de Código y Arquitectura: Implementar revisiones periódicas de código y arquitectura para asegurar que las implementaciones cumplen con las políticas y medidas objetivas definidas. Automatización de Pruebas: Integrar pruebas automatizadas en el pipeline de CI/CD para verificar que las características arquitectónicas se cumplen continuamente. Utilizar herramientas como NetArchTest, NDepend y SonarQube para realizar estas verificaciones.

57 57 Medición y Gobernanza (10/10) Monitoreo Continuo: Utilizar herramientas de monitoreo como Application Insights para medir continuamente el rendimiento, uso de recursos y latencia de red. Configurar alertas para detectar desviaciones de los valores objetivos. Formación y Capacitación: Asegurarse de que todos los miembros del equipo están capacitados y entienden la importancia de las características arquitectónicas y cómo medirlas. Proveer formación continua sobre las herramientas y prácticas de gobernanza. Documentación y Comunicación: Mantener una documentación actualizada sobre las características arquitectónicas, sus medidas objetivas y las políticas de gobernanza. Fomentar una comunicación abierta y continua entre todos los stakeholders.

58 58 Identificación (1/9) Identificación de las Características Arquitectónicas • Proceso Iterativo: La identificación y refinamiento de las características arquitectónicas se realiza mediante un proceso iterativo. • Extracción de Características: Estas características se extraen del dominio del problema y de las preocupaciones de los stakeholders. Alcance de las Características Arquitectónicas Tradicionalmente, se asumía que las características arquitectónicas se aplicaban a nivel de todo el sistema. Esta suposición era válida en sistemas monolíticos. Sin embargo, con la llegada otros estilos arquitectónicos como los microservicios, el alcance de estas características se ha reducido considerablemente. Esto ha llevado a la necesidad de definir un método para medir la "evolvabilidad estructural" de ciertos estilos arquitectónicos, resultando en la introducción del concepto de quantum arquitectónico.

59 59 Identificación (2/9) Evolvabilidad Evolvabilidad se refiere a la capacidad de un sistema de software para adaptarse y evolucionar con el tiempo. Es una medida de cuán fácilmente se pueden realizar cambios y mejoras en el sistema sin introducir errores o comprometer su integridad. Evolvabilidad implica varios aspectos, como: • Facilidad de Mantenimiento: Cómo de fácil es entender, modificar y actualizar el código. • Adaptabilidad: La capacidad del sistema para adaptarse a nuevos requisitos o cambios en el entorno. • Escalabilidad: La facilidad con la que el sistema puede crecer en términos de capacidad y funcionalidad. • Resiliencia: La capacidad del sistema para resistir y recuperarse de fallos. Quantum Arquitectónico El concepto de quantum arquitectónico se introdujo para abordar la necesidad de medir y gestionar la evolvabilidad en arquitecturas modernas, como los microservicios. A medida que las arquitecturas se han fragmentado en componentes más pequeños e independientes, como es el caso de los microservicios, se hizo evidente que las características arquitectónicas ya no podían ser aplicadas de manera uniforme a todo el sistema. Aquí es donde entra en juego el quantum arquitectónico.

60 60 Identificación (3/9) • Artefacto Desplegable Independientemente: ▪ Independencia: Un quantum arquitectónico incluye todos los componentes necesarios para funcionar de manera autónoma. Esto significa que puede ser desplegado y operado sin depender directamente de otros componentes del sistema. ▪ Ejemplo: En una arquitectura de microservicios, cada servicio puede tener su propia base de datos y lógica de negocio, permitiendo que funcione independientemente de otros servicios. • Alta Cohesión Funcional: ▪ Cohesión: La cohesión se refiere a cuán bien los elementos dentro de un componente trabajan juntos hacia un propósito común. Alta cohesión implica que el quantum arquitectónico realiza una tarea específica y bien definida. ▪ Ejemplo: Un servicio de "Gestión de Usuarios" en una arquitectura de microservicios tiene alta cohesión si todas sus funciones están relacionadas con la gestión de usuarios (registro, autenticación, actualización de perfiles, etc.). • Connascence Sincrónico y Asíncrono: ▪ Lo veremos más adelante.

61 61 Identificación (4/9) Connascence y Acoplamiento Antes de profundizar en el concepto de quantum arquitectónico, te recomiendo entender los conceptos de connascence y acoplamiento. Connascence se refiere a la interdependencia entre componentes de software. Meilir Page-Jones introdujo este concepto en 1996, y lo dividió en dos tipos: • Connascence Estático: Puede ser descubierto a través del análisis estático del código. Esto incluye dependencias que se pueden ver directamente en el código fuente, como el uso de una clase o una función en particular. • Connascence Dinámico: Relacionado con el comportamiento en tiempo de ejecución, puede ser sincrónico o asincrónico. Incluye interacciones que ocurren mientras el programa está en ejecución, como llamadas a servicios o la comunicación entre procesos.

62 62 Identificación (5/9) Por tanto, Connascence en el Contexto del Quantum Arquitectónico Otra forma de explicar el quantum arquitectónico se basa en la idea de que ciertos componentes del sistema están estrechamente interconectados y deben ser tratados como una unidad cohesiva. El quantum arquitectónico se define como un artefacto desplegable de manera independiente con alta cohesión funcional y connascence sincrónica. Para entender mejor cómo se aplica la connascence en el contexto de un quantum arquitectónico, consideremos los siguientes puntos: • Connascence Sincrónica: Dentro de un quantum arquitectónico, las llamadas sincrónicas entre componentes implican que estos deben tener características operacionales similares. Por ejemplo, si un servicio en una arquitectura de microservicios llama a otro servicio de manera sincrónica, ambos servicios deben mantener una coherencia en términos de escalabilidad, rendimiento y disponibilidad durante la duración de la llamada. Esta connascence sincrónica asegura que cualquier cambio en uno de los componentes requerirá modificaciones en el otro para mantener la integridad del sistema. • Connascence Asincrónica: En arquitecturas donde se utilizan comunicaciones asincrónicas (como en arquitecturas orientadas a eventos), los componentes pueden operar de manera más independiente. Por ejemplo, si un servicio de subasta envía información de pago a un servicio de pagos a través de una cola de mensajes, esta comunicación asincrónica permite que los servicios difieran en sus características operacionales sin causar fallos inmediatos. Esta connascence asincrónica proporciona flexibilidad y desacoplamiento en el diseño de la arquitectura.

63 63 Identificación (6/9) Identity Value Timing Execution Order Position Algorithm Convention Type Name Dynamic Static Strong Weak Asynchronous Ssynchronous Quantum Connascence

64 64 Identificación (7/9) Extracción de características del dominio y de las preocupaciones de los stakeholders Aunque ya lo hemos visto en anteriores apartados, prefiero hacer hincapié en este punto en concreto por que la extracción de características arquitectónicas es un proceso crucial que se basa en el entendimiento profundo del dominio del problema y en las preocupaciones de los stakeholders (partes interesadas). Este proceso se puede dividir en varios pasos clave: • Entrevistas y Reuniones con Stakeholders: Uno de los primeros pasos es realizar entrevistas y reuniones con los stakeholders, incluyendo usuarios finales, clientes, desarrolladores, y otros actores clave. El objetivo es comprender sus necesidades, expectativas y cualquier preocupación específica que puedan tener sobre el sistema. • Análisis del Dominio del Problema: El análisis del dominio del problema implica estudiar el contexto en el que el sistema operará. Esto incluye entender los procesos de negocio, las reglas y restricciones del dominio, y cualquier requerimiento específico del sector. Herramientas como los diagramas de flujo de procesos y los modelos de dominio pueden ser útiles en esta etapa. • Identificación de Requisitos Funcionales y No Funcionales: Los requisitos funcionales describen lo que el sistema debe hacer, mientras que los requisitos no funcionales (o características arquitectónicas) describen cómo el sistema debe comportarse. Las características arquitectónicas típicas incluyen escalabilidad, rendimiento, seguridad, mantenibilidad, y disponibilidad. Estos deben ser claramente identificados y documentados.

65 65 Identificación (8/9) • Análisis de Trade-offs: A menudo, las características arquitectónicas pueden entrar en conflicto entre sí. Por ejemplo, mejorar la seguridad puede afectar negativamente el rendimiento. Es importante realizar un análisis de trade-offs para entender las implicaciones de priorizar ciertas características sobre otras y tomar decisiones informadas. • Prototipos (POC) y Pruebas: En algunos casos, puede ser útil construir prototipos o realizar pruebas para validar ciertas características arquitectónicas. Esto puede proporcionar retroalimentación valiosa y ayudar a refinar los requisitos antes de la implementación completa. • Documentación y Comunicación: Finalmente, las características arquitectónicas identificadas deben ser bien documentadas y comunicadas a todos los stakeholders. Esto asegura que todos tengan una comprensión clara y compartida de los objetivos y restricciones del sistema. Nota del autor En el desarrollo de software, los términos Spike, PoC (Proof of Concept) y MVP (Minimum Viable Product) se refieren a enfoques y técnicas diferentes que se utilizan en distintas etapas del ciclo de vida del desarrollo de un producto. Cada uno de estos conceptos tiene un propósito y un uso específico. A continuación, se detallan las diferencias y para qué sirve cada uno de ellos: Spike y Características Arquitectónicas • Propósito del Spike: Un spike se utiliza para explorar y reducir la incertidumbre técnica. Puede enfocarse en entender mejor cómo implementar una característica arquitectónica específica o en evaluar el impacto de diferentes decisiones arquitectónicas. • Relación con Características Arquitectónicas: • Exploración de Opciones: Un spike puede ayudar a explorar diferentes opciones arquitectónicas antes de tomar una decisión final. Por ejemplo, un spike podría investigar diferentes patrones de escalabilidad o enfoques de seguridad. • Validación Técnica: Permite validar la viabilidad técnica de ciertas características arquitectónicas, como la interoperabilidad entre componentes o la integración con tecnologías externas. • Mitigación de Riesgos: Ayuda a identificar y mitigar riesgos asociados con la implementación de características arquitectónicas complejas.

66 66 Proof of Concept (PoC) y Características Arquitectónicas • Propósito del PoC: Una prueba de concepto se utiliza para demostrar la viabilidad de una idea o enfoque técnico, incluyendo características arquitectónicas. • Relación con Características Arquitectónicas: • Validación de Hipótesis: Un PoC puede validar que una característica arquitectónica puede ser implementada de manera efectiva. Por ejemplo, demostrar que un sistema puede manejar un cierto nivel de concurrencia o que una arquitectura de microservicios puede soportar la escala requerida. • Pruebas de Rendimiento: Permite realizar pruebas de rendimiento iniciales para características como la escalabilidad, la latencia y la capacidad de respuesta. • Evaluación de Integración: Un PoC puede evaluar cómo diferentes componentes o servicios se integran y funcionan juntos, asegurando que las decisiones arquitectónicas no introduzcan problemas de compatibilidad o rendimiento. Minimum Viable Product (MVP) y Características Arquitectónicas • Propósito del MVP: Un producto mínimo viable se lanza con las características esenciales para obtener retroalimentación de los usuarios reales y validar la viabilidad comercial del producto. • Relación con Características Arquitectónicas: • Implementación Inicial: En la fase del MVP, solo se implementan las características arquitectónicas esenciales que son críticas para el funcionamiento básico del producto. Esto permite enfocarse en lo más importante y evitar sobrecargar el sistema con funcionalidades innecesarias desde el inicio. • Iteración y Mejora: Basándose en la retroalimentación de los usuarios, se pueden identificar necesidades adicionales y ajustar las características arquitectónicas en iteraciones futuras. Esto permite refinar aspectos como la escalabilidad, la seguridad y el rendimiento de manera incremental. • Priorización: La creación de un MVP obliga a priorizar las características arquitectónicas más críticas y a diferir aquellas que pueden ser mejoradas o añadidas en futuras iteraciones. Esto ayuda a gestionar mejor el alcance del proyecto y a enfocarse en entregar valor rápidamente. Identificación (9/9)

67 67 Granularidad (1/9) Importancia de encontrar el nivel adecuado de granularidad Encontrar la granularidad adecuada para los componentes es crucial en la arquitectura de software. La granularidad se refiere al tamaño y la cohesión de los componentes dentro de un sistema. Una buena granularidad asegura que los componentes sean lo suficientemente pequeños para ser manejables y reutilizables, pero lo suficientemente grandes para encapsular una funcionalidad coherente. Estrategias para encontrar la granularidad adecuada Para evitar estos problemas, los arquitectos deben considerar varios factores al definir la granularidad de los componentes, tales como: • Responsabilidades claras y definidas: Cada componente debe tener una responsabilidad claramente definida que lo haga coherente y autónomo en su funcionalidad. • Interacciones mínimas: Los componentes deben estar diseñados para minimizar las interacciones innecesarias entre ellos. • Facilidad de prueba y mantenimiento: Los componentes deben ser lo suficientemente pequeños para ser fácilmente probados y mantenidos, pero lo suficientemente grandes para no fragmentar excesivamente el código. • Escalabilidad y rendimiento: La granularidad debe permitir que el sistema escale de manera eficiente y mantenga un buen rendimiento.

68 68 Granularidad (2/9) Caso de Uso Uno de los problemas más habituales en la arquitectura de software actual es la tendencia a decidir una granularidad excesivamente fina, optando por microservicios e incluso nanoservicios. Esta decisión, aunque bien intencionada, puede llevar a una complejidad operativa significativa. La comunicación excesiva entre componentes pequeños puede incrementar la latencia y aumentar la probabilidad de fallos, complicando la depuración y el mantenimiento del sistema. Además, la gestión de múltiples servicios independientes puede resultar en una sobrecarga operativa y altos costos de infraestructura, haciendo que los beneficios iniciales de escalabilidad y autonomía se vean eclipsados por los desafíos de manejar una arquitectura tan distribuida. En este contexto, muchos equipos han comenzado a reconsiderar su enfoque y a moverse hacia una granularidad más grande, optando por monolitos modulares. Esta estrategia combina la simplicidad operativa de un monolito con la modularidad interna, permitiendo encapsular dominios de negocio específicos en módulos bien definidos. Al consolidar servicios que se comunicaban frecuentemente en un solo módulo, se reduce la latencia de la red y se simplifican las operaciones. Esto no solo mejora el rendimiento y la eficiencia del sistema, sino que también facilita la depuración y el mantenimiento, ya que todo el código se ejecuta en el mismo proceso. En resumen, encontrar el nivel adecuado de granularidad es crucial para equilibrar la modularidad y la simplicidad, evitando los extremos de una granularidad demasiado fina o demasiado gruesa. Os recomiendo leer: El Retorno al Monolito Modular: Mi Experiencia

69 69 Granularidad (3/9) Técnicas para Lograr una Granularidad Equilibrada • División Basada en Dominios Utiliza principios de Domain-Driven Design (DDD) para identificar y dividir los componentes según los dominios de negocio. Esto ayuda a mantener los componentes cohesivos y alineados con las funcionalidades del negocio. Bounded Contexts: Define límites claros para cada módulo, asegurando que cada componente encapsule una parte específica del dominio de negocio. • Principios SOLID Aplica los principios SOLID para el diseño de componentes: ▪ Single Responsibility Principle (SRP): Cada componente debe tener una única responsabilidad o razón para cambiar. • Técnicas de Descomposición • Evaluación de Dependencias Mapa de Dependencias: Crea un mapa de dependencias para visualizar las interacciones entre los componentes. Esto ayuda a identificar áreas donde la comunicación puede ser excesiva y permite ajustes en la granularidad. Acoplamiento y Cohesión: Evalúa el acoplamiento (cómo de interdependientes son los componentes) y la cohesión (cómo de relacionadas están las funcionalidades dentro de un componente). Busca minimizar el acoplamiento y maximizar la cohesión

70 70 Granularidad (4/9) • Pruebas y Validación Pruebas Unitarias y de Integración: Diseña componentes de manera que sean fáciles de probar de forma aislada (unitarias) y en conjunto (integración). Esto ayuda a validar que los componentes funcionan correctamente tanto individualmente como en el contexto del sistema completo. Pruebas de Carga: Realiza pruebas de carga para asegurar que los componentes pueden manejar el tráfico y las cargas esperadas sin degradar el rendimiento. Nota del autor Os he puesto unos cuantos links a mi blog, ya que trato en artículos y monográficos estos aspectos de forma más profunda y no tiene sentido hablar de ellos aquí.

71 71 Granularidad (5/9) Ejemplos Prácticos de Ajuste de Granularidad • Proyecto de Comercio Electrónico: ▪ Problema: Un sistema de comercio electrónico con microservicios para cada funcionalidad (carrito de compras, procesamiento de pagos, gestión de inventarios) enfrenta latencia debido a demasiadas interacciones de red. ▪ Solución: Agrupar estos microservicios en módulos más grandes basados en dominios de negocio, como "Gestión de Pedidos" y "Gestión de Pagos", reduciendo la latencia y simplificando la comunicación. • Aplicación de Reserva de Viajes: ▪ Problema: Microservicios para la reserva de vuelos, hoteles y alquiler de coches tienen una alta dependencia entre sí, causando problemas de consistencia de datos. ▪ Solución: Crear un módulo único de "Gestión de Reservas" que encapsule todas las funcionalidades relacionadas con las reservas, asegurando la consistencia de datos y reduciendo la complejidad operativa.

72 72 Granularidad (6/9) Riesgos de una granularidad incorrecta Demasiada comunicación entre componentes Si los componentes son demasiado pequeños (granularidad muy fina), puede haber un exceso de comunicación entre ellos para completar tareas. Esto puede llevar a un aumento en la latencia y la complejidad de las interacciones, haciendo que el sistema sea menos eficiente y más difícil de mantener. Además, un exceso de llamadas entre componentes puede aumentar el riesgo de fallos y complicar la depuración. Acoplamiento interno alto Por otro lado, si los componentes son demasiado grandes (granularidad muy gruesa), pueden terminar con un alto grado de acoplamiento interno. Esto significa que las partes internas del componente están demasiado interdependientes, lo que puede dificultar la modificación o la reutilización de partes del componente sin afectar a otras. Un alto acoplamiento interno también puede hacer que el componente sea difícil de entender y probar, lo que complica la evolución del sistema.

73 73 Granularidad (7/9) Otros Riesgos • Disminución del Retorno de la Inversión (ROI): Una granularidad incorrecta puede reducir el ROI de un proyecto. Si el sistema es demasiado complejo de mantener y operar debido a una granularidad demasiado fina, los costos operativos pueden superar los beneficios, afectando negativamente el ROI. • Sobrecarga de Gestión: Gestionar un gran número de microservicios puede resultar en una sobrecarga administrativa y operativa. Las tareas de monitoreo, despliegue y orquestación pueden volverse extremadamente complejas y costosas. • Problemas de Escalabilidad: Una granularidad incorrecta puede afectar la escalabilidad del sistema. Los componentes demasiado grandes pueden no escalar eficientemente, mientras que los componentes demasiado pequeños pueden necesitar una coordinación excesiva para escalar. • Redundancia y Duplicación de Código: Con una granularidad muy fina, puede haber redundancia y duplicación de código, lo que aumenta la complejidad y el esfuerzo de mantenimiento. • Incoherencia en la Gestión de Datos: La granularidad incorrecta puede llevar a problemas de coherencia en la gestión de datos, especialmente en sistemas distribuidos donde la sincronización de datos puede ser un desafío.

74 74 Granularidad (8/9) Técnicas Directas para Mitigar Riesgos • Pruebas de Concepto (PoC): Antes de comprometerse con una arquitectura específica, realiza PoCs para validar la viabilidad de la granularidad propuesta. Las PoCs permiten experimentar con diferentes niveles de granularidad y evaluar su impacto en la latencia, el rendimiento y la mantenibilidad del sistema. • Producto Mínimo Viable (MVP): Desarrolla un MVP para probar la granularidad en un entorno real. El MVP debe incluir componentes clave del sistema para evaluar cómo se comportan en términos de comunicación, acoplamiento y escalabilidad. Técnicas Indirectas para Mitigar Riesgos • Principios Lean-Agile: Desarrollo Incremental e Iterativo: Promueve el desarrollo incremental, permitiendo ajustar la granularidad de los componentes de manera iterativa basada en la retroalimentación. Gestión de la Cadena de Valor: Focaliza en la entrega de valor continuo, lo que ayuda a identificar y eliminar componentes innecesarios o excesivamente granulares.

75 75 Granularidad (9/9) • TOGAF (The Open Group Architecture Framework) es un marco de trabajo integral para desarrollar arquitecturas de software y sistemas empresariales. Aunque TOGAF no se centra específicamente en la granularidad de los componentes, proporciona varias metodologías y herramientas que pueden ayudar a mitigar problemas relacionados con la granularidad. Componentes Clave de TOGAF que Ayudan con la Granularidad: • Metodología ADM (Architecture Development Method): − Fase de Arquitectura de Negocio: Define los dominios de negocio y las necesidades organizacionales. Esto ayuda a identificar la granularidad adecuada basada en las funcionalidades del negocio. − Fase de Arquitectura de Sistemas de Información: Desarrolla arquitecturas de datos y aplicaciones, asegurando que los componentes estén alineados con los requerimientos de negocio y datos. − Fase de Arquitectura Tecnológica: Define la infraestructura tecnológica necesaria para soportar la arquitectura, lo que puede influir en la granularidad de los componentes. − Fase de Oportunidades y Soluciones: Identifica posibles soluciones y evalúa su impacto, lo que permite ajustar la granularidad según sea necesario. • Catálogos, Matrices y Diagramas: − Catálogo de Aplicaciones y Servicios: Documenta las aplicaciones y servicios, permitiendo una visión clara de las interdependencias y facilitando el ajuste de la granularidad. − Matrices de Interacciones: Visualiza las interacciones entre componentes, ayudando a identificar áreas de alta comunicación que podrían beneficiarse de una granularidad más gruesa. − Diagramas de Arquitectura: Proporcionan una representación visual de los componentes y sus relaciones, facilitando la identificación de problemas de granularidad.

76 76 Resolver Problemas (1/11) Teoremas que nos ayudan Los teoremas CAP y PACELC, así como los algoritmos de consenso como Paxos y Raft, o protocolos de enrutamiento como BGP, son fundamentales para entender y diseñar arquitecturas de software distribuidas. A continuación, se explica cómo cada uno de estos conceptos puede ayudar a identificar y definir características clave de la arquitectura de software. Teorema CAP El Teorema CAP establece que, en un sistema distribuido, es imposible garantizar simultáneamente Consistencia, Disponibilidad y Tolerancia a Particiones. Solo se puede garantizar dos de estas tres propiedades a la vez: • Consistencia (C): Todos los nodos ven los mismos datos al mismo tiempo. • Disponibilidad (A): Cada solicitud recibe una respuesta, ya sea éxito o fallo. • Tolerancia a Particiones (P): El sistema sigue funcionando a pesar de particiones de red. Cómo ayuda el Teorema CAP: • Diseño de Sistemas Distribuidos: Ayuda a los arquitectos a tomar decisiones informadas sobre qué propiedades priorizar en función de las necesidades del negocio. • Identificación de Compromisos: Permite identificar los compromisos necesarios, por ejemplo, si un sistema debe ser altamente disponible y tolerante a particiones, la consistencia puede verse comprometida.

77 77 Resolver Problemas (2/11) Teorema PACELC El Teorema PACELC extiende el Teorema CAP al añadir una dimensión adicional: • P: Particiones • A: Disponibilidad • C: Consistencia • E: Else (En caso de no partición) • L: Latencia El teorema se puede expresar como: "Si hay una partición (P), el sistema debe elegir entre Consistencia (C) o Disponibilidad (A); de lo contrario (E), el sistema debe elegir entre Latencia baja (L) o Consistencia (C)". Cómo ayuda el Teorema PACELC: • Determinación de Estrategias: Ayuda a determinar estrategias de diseño no solo durante las particiones de red, sino también bajo condiciones normales. • Optimización de Latencia: Permite optimizar la latencia en situaciones donde no hay particiones, mientras se mantiene la consistencia o disponibilidad según sea necesario.

78 78 Resolver Problemas (3/11) Algoritmos de Consenso: Paxos y Raft Paxos y Raft son algoritmos de consenso utilizados para garantizar que los nodos en un sistema distribuido acuerden un valor único, incluso en presencia de fallos. • Paxos: Un algoritmo basado en roles (proposer, acceptor, learner) para alcanzar consenso. • Raft: Un algoritmo más comprensible y de implementación más sencilla que Paxos, basado en la elección de líderes y la replicación de logs. Cómo ayudan Paxos y Raft: • Garantía de Consistencia: Permiten garantizar la consistencia fuerte en sistemas distribuidos, crucial para aplicaciones que requieren datos coherentes en todos los nodos. • Gestión de Fallos: Ayudan a manejar fallos de nodos y particiones de red, asegurando que el sistema pueda seguir operando y recuperándose de fallos. • Facilidad de Implementación (Raft): Raft, en particular, es más fácil de entender e implementar, lo que facilita su adopción en proyectos.

79 79 Resolver Problemas (4/11) Protocolo de Enrutamiento: BGP BGP (Border Gateway Protocol) es un protocolo de enrutamiento utilizado para dirigir paquetes de datos entre sistemas autónomos en Internet. Cómo ayuda BGP: • Resiliencia de la Red: BGP es esencial para la resiliencia de la red, ya que permite la configuración de rutas alternativas en caso de fallos o congestión en la red. Esto es crucial para sistemas distribuidos que dependen de la conectividad continua entre nodos. • Optimización de Tráfico: Ayuda a optimizar el tráfico de red, seleccionando las rutas más eficientes para el enrutamiento de paquetes, lo que puede mejorar el rendimiento y la latencia de los servicios distribuidos. • Escalabilidad y Gestión de Redes Grandes: Permite manejar grandes redes distribuidas de manera eficiente, asegurando que las políticas de enrutamiento se apliquen correctamente y que el tráfico se distribuya adecuadamente. Solo os doy una muestra, pero existen más teoremas, principios, algoritmos o protocolos que nos pueden ayudar: Teorema BASE, Ley de Amdahl, Ley de Conway, Teorema de Brewer, Practical Byzantine Fault Tolerance (PBFT), Algoritmo Gossip, Algoritmo de Elección de Líder (Bully Algorithm, Raft), Algoritmo Two-Phase Commit (2PC), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Consistent Hashing, MapReduce, Modelo de Actores, etc.

80 80 Resolver Problemas (5/11) Aplicación de Estos Conceptos en la Arquitectura de Software • Diseño de Sistemas Distribuidos: ▪ Utilizar el Teorema CAP para decidir entre consistencia, disponibilidad y tolerancia a particiones según los requisitos del sistema. ▪ Aplicar el Teorema PACELC para optimizar la latencia y consistencia bajo condiciones normales y durante particiones de red. • Mecanismos de Consenso: ▪ Implementar Paxos o Raft para asegurar que todos los nodos en el sistema distribuido acuerden sobre el estado del sistema, garantizando la consistencia de los datos. ▪ Elegir Raft para una implementación más sencilla y comprensible, facilitando el desarrollo y mantenimiento del sistema. • Optimización de Red y Enrutamiento: ▪ Configurar BGP para asegurar rutas de red resilientes y optimizadas, mejorando la conectividad y el rendimiento del sistema distribuido. ▪ Utilizar las capacidades de BGP para gestionar grandes redes distribuidas de manera eficiente, asegurando una alta disponibilidad y rendimiento. Nota del autor Lo que quiero transmitir en este capítulo es que, al analizar los requerimientos funcionales e identificar características, muchos de tus problemas ya están resueltos mediante teoremas, protocolos y otros conceptos, de manera similar a cómo los patrones de programación abordan problemas comunes de diseño.

81 81 Resolver Problemas (6/11) Ejemplos Prácticos • Sistema de Bases de Datos Distribuidas: ▪ Teorema CAP: Decidir entre consistencia y disponibilidad. Por ejemplo, una base de datos de transacciones bancarias puede priorizar la consistencia sobre la disponibilidad. ▪ Algoritmo de Consenso (Raft): Utilizar Raft para replicar logs de transacciones y asegurar que todos los nodos tengan una vista coherente del estado de las cuentas. • Red de Entrega de Contenidos (CDN): ▪ Teorema PACELC: Optimizar la latencia en condiciones normales (sin particiones), mientras se asegura la disponibilidad durante particiones de red. ▪ BGP: Configurar BGP para dirigir el tráfico de usuarios a los nodos más cercanos y menos congestionados, optimizando la entrega de contenido. • Aplicaciones de Microservicios: ▪ Teorema CAP: Decidir la granularidad de los microservicios y cómo manejar las particiones de red. Por ejemplo, un sistema de comercio electrónico puede priorizar la disponibilidad para el servicio de catálogo de productos, mientras prioriza la consistencia para el servicio de procesamiento de pagos. ▪ Algoritmo de Consenso (Paxos): Utilizar Paxos para coordinar la consistencia de datos críticos entre microservicios.

82 82 Resolver Problemas (7/11) Características y como medirlas contra el estilo de una arquitectura Voy a centrarme en el caso de uso de un sistema distribuido, dado que se han convertido en una parte esencial de la infraestructura informática moderna. Con el auge de la computación en la nube y el internet, los sistemas distribuidos han ganado una creciente importancia al proporcionar servicios escalables y fiables a usuarios de todo el mundo. Sin embargo, diseñar y operar estos sistemas presenta desafíos significativos debido a factores como la necesidad de consistencia, disponibilidad, tolerancia a particiones y baja latencia. Además, atributos como la escalabilidad, durabilidad, fiabilidad y tolerancia a fallos son requisitos fundamentales para cualquier aplicación empresarial que atienda a una demografía amplia y diversa. Comprender estos atributos es esencial para diseñar sistemas grandes y complejos que satisfagan las necesidades del negocio. A partir de estas características: Consistencia, Disponibilidad, Tolerancia a particiones, Latencia, Durabilidad, Fiabilidad, Tolerancia a fallos y Escalabilidad, voy a realizar un estudio mediante ILUO. Nota del autor La técnica ILUO (Illustrative Line Use Optimization) es una herramienta de visualización que se utiliza para evaluar y optimizar la eficiencia y especialización de operadores en diversas tareas de manufactura, como perforado, corte, doblado, soldadura y formado. Al representar gráficamente las competencias de los operadores en estas tareas, ILUO facilita la identificación de fortalezas y debilidades en el equipo, permitiendo una asignación más eficiente de recursos y la mejora de procesos. Esta técnica es útil para tomar decisiones informadas sobre la estructura y organización de sistemas, ya sea en contextos de manufactura o en la arquitectura de software.

83 83 Resolver Problemas (8/11) Sin perder de vista nuestro caso de uso de un sistema distribuido: Característica Arquitectura Monolítica Arquitectura Modular Microservicios Arquitectura en Capas (Layers) Arquitectura Event-Driven Consistencia O U L U L Disponibilidad L U O U O Tolerancia a particiones I L O I O Latencia U L I L U Durabilidad O O U O U Fiabilidad O U U U U Tolerancia a fallos I L O L O Escalabilidad I U O L O

84 84 Resolver Problemas (9/11) Esto no se trata simplemente de asignar un peso numérico del 1 al 5 o de sumar estrellas para determinar un ganador. La clave es identificar qué arquitectura cumple con más requisitos críticos, representados por la puntuación O. A partir de ahí, debemos considerar otras características importantes, como la experiencia del equipo, para tomar una decisión informada. Aunque a veces una arquitectura puede destacarse claramente con muchas O, es posible que una opción con menos O pero más U sea más adecuada si nuestro equipo tiene mayor experiencia y eficiencia en trabajar con esos requisitos. En resumen, aunque una arquitectura con cinco O puede parecer la mejor opción, si nuestro equipo está mejor preparado para manejar una arquitectura con tres O y muchas U, esta última podría ser la elección óptima debido a la mayor velocidad y eficiencia en la entrega de valor en nuestro contexto específico. En nuestro caso existen 3 características que debemos cumplir por restricción del cliente (en la realidad es que es el negocio quien marca estas características): Característica Microservicios Arquitectura Event-Driven Disponibilidad O O Fiabilidad U U Escalabilidad O O

85 85 Resolver Problemas (10/11) Nos pone en el dilema de escoger entre Microservicios y Arquitectura Event-Driven (EDA). Si revisamos el resto de las puntuaciones: Característica Microservicios Arquitectura Event-Driven Consistencia L L Disponibilidad O O Tolerancia a particiones O O Latencia I U Durabilidad U U Fiabilidad U U Tolerancia a fallos O O Escalabilidad O O Claramente observamos que EDA es la mejor opción: Microservicios: • O: 5 • U: 2 • L: 1 • I: 1 Arquitectura Event-Driven: • O: 5 • U: 2 • L: 1 • I: 0

86 86 Resolver Problemas (11/11) Aunque inicialmente la Arquitectura Event-Driven (EDA) parecía ser la mejor opción debido a su alta puntuación en los requisitos críticos, la complejidad adicional de manejar una arquitectura EDA y la separación de las bases de datos de lectura y escritura no nos aporta beneficios significativos, sino que añade una complejidad innecesaria. Además, considerando una de las características más importantes: las capacidades y experiencia de nuestro equipo, queda claro que sería más adecuado optar por una arquitectura de microservicios. Esta arquitectura no solo se ajusta mejor a las habilidades de nuestro equipo, sino que también permite una entrega de valor más rápida y eficiente en nuestro contexto específico. Por otro lado, si uno de los requisitos clave es mantener un historial completo de todas las transacciones, una Arquitectura Event-Driven (EDA) sería la mejor opción, ya que esta característica está integrada por defecto. Sin embargo, está claro que optar por una arquitectura en capas (layers) sería un error, ya que comprometería las características necesarias que nos pide el cliente, como la capacidad de manejar grandes volúmenes de transacciones de manera eficiente y mantener un historial detallado. La decisión final debe basarse en un equilibrio entre los requisitos técnicos y las capacidades del equipo. Si la complejidad adicional de una EDA no justifica los beneficios en nuestro contexto actual, los microservicios representan una solución más práctica y alineada con las habilidades de nuestro equipo. Sin embargo, si el historial de transacciones es un requisito esencial, la EDA sería la opción más adecuada, a pesar de su complejidad. Este es un claro ejemplo de quid pro quo: sacrificamos simplicidad por funcionalidad o viceversa según las necesidades específicas del proyecto. El mejor lugar para documentar esta decisión son los ADRs, donde habrás registrado el razonamiento detrás de la elección y las implicaciones a largo plazo.

87 87 ISO/IEC para tener en cuenta: • ISO/IEC 25010:2011 - Sistemas y software de ingeniería – Requisitos y evaluación de calidad de producto (SQuaRE) – Modelos de calidad del sistema y del software. • ISO/IEC 27001:2013 - Tecnología de la información – Técnicas de seguridad – Sistemas de gestión de seguridad de la información – Requisitos. • ISO/IEC 20000-1:2018 - Tecnología de la información – Gestión del servicio – Parte 1: Requisitos del sistema de gestión del servicio. • ISO/IEC 12207:2017 - Sistemas y software de ingeniería – Procesos del ciclo de vida del software. • ISO/IEC 42010:2011 - Sistemas y software de ingeniería – Arquitectura de sistemas – Descripción de la arquitectura. • ISO/IEC 29119 - Pruebas de software. • ISO/IEC 38500:2015 - Gobernanza de la tecnología de la información para la organización. Otros enlaces de interés • ILUO • El Método Eisenhower, donde confrontas la funcionalidad con las características del software. • Shape your company’s decision style–and behaviors • DiSC • The Trust-Communication Trade-Off • Confirmation Bias: A Ubiquitous Phenomenon in Many Guises • 7 Strategies for Better Group Decision-Making • What Is The Rule Of 40 For SaaS? Here’s How To Calculate It • Teoría de la perspectiva: cómo tomamos decisiones de inversión Más Información: Amplia tus Conocimientos