Arquitectura de software

La arquitectura de software es el conjunto de estructuras necesarias para razonar sobre un sistema de software y la disciplina de crear dichas estructuras y sistemas. Cada estructura comprende elementos de software, relaciones entre ellos y propiedades tanto de los elementos como de las relaciones. ^{[ 1 ]}

La arquitectura de un sistema de software es una metáfora , análoga a la arquitectura de un edificio. ^{[ 2 ]} Funciona como los planos del sistema y del proyecto de desarrollo, que la gestión del proyecto puede utilizar posteriormente para extrapolar las tareas necesarias que deben ejecutar los equipos y las personas involucradas.

La arquitectura de software se trata de tomar decisiones estructurales fundamentales que son costosas de cambiar una vez implementadas. Las decisiones de arquitectura de software incluyen opciones estructurales específicas de las posibilidades en el diseño del software . Hay dos leyes fundamentales en la arquitectura de software: ^{[ 3 ] [ 4 ]}

1. Todo implica una compensación.
2. "El porqué es más importante que el cómo"

El "Kata arquitectónico" es un trabajo en equipo que permite generar una solución arquitectónica que se ajuste a las necesidades. Cada equipo extrae y prioriza las características arquitectónicas (también conocidas como requisitos no funcionales ) y, a continuación, modela los componentes en consecuencia. El equipo puede utilizar el Modelo C4 , un método flexible para modelar la arquitectura de forma precisa. Cabe destacar que la comunicación síncrona entre los componentes arquitectónicos los interrelaciona y deben compartir las mismas características arquitectónicas. ^{[ 4 ]}

Documentar la arquitectura del software facilita la comunicación entre las partes interesadas , registra las decisiones iniciales sobre el diseño de alto nivel y permite la reutilización de componentes de diseño entre proyectos. ^{[ 5 ] : 29–35}

El diseño de la arquitectura de software se suele contraponer al diseño de aplicaciones de software . Mientras que el diseño de aplicaciones se centra en el diseño de los procesos y los datos que dan soporte a la funcionalidad requerida (los servicios que ofrece el sistema), el diseño de la arquitectura de software se centra en el diseño de la infraestructura dentro de la cual se puede realizar y ejecutar la funcionalidad de la aplicación, de manera que dicha funcionalidad se proporcione de forma que cumpla con los requisitos no funcionales del sistema .

Las arquitecturas de software se pueden clasificar en dos tipos principales: arquitectura monolítica y arquitectura distribuida , cada una con sus propias subcategorías. ^{[ 4 ]}

La arquitectura de software tiende a volverse más compleja con el tiempo. Los arquitectos de software deberían usar " funciones de aptitud " para mantener la arquitectura bajo control de forma continua . ^{[ 4 ]}

Las opiniones varían en cuanto al alcance de las arquitecturas de software: ^{[ 6 ]}

• Estructura macroscópica del sistema : se refiere a la arquitectura como una abstracción de nivel superior de un sistema de software que consiste en una colección de componentes computacionales junto con conectores que describen la interacción entre estos componentes. ^{[ 7 ]}
• Lo importante —sea lo que sea— : esto se refiere al hecho de que los arquitectos de software deben preocuparse por aquellas decisiones que tienen un alto impacto en el sistema y sus partes interesadas. ^{[ 8 ]}
• Aquello que es fundamental para comprender un sistema en su entorno ^{[ 9 ]}
• Aspectos que la gente percibe como difíciles de cambiar : dado que el diseño de la arquitectura se realiza al inicio del ciclo de vida de un sistema de software, el arquitecto debe centrarse en las decisiones que "tienen que" ser correctas desde el principio. Siguiendo esta línea de pensamiento, los problemas de diseño arquitectónico pueden dejar de ser arquitectónicos una vez que se supera su irreversibilidad. ^{[ 8 ]}
• Un conjunto de decisiones de diseño arquitectónico : la arquitectura de software no debe considerarse simplemente un conjunto de modelos o estructuras, sino que debe incluir las decisiones que conducen a estas estructuras particulares y la lógica que las sustenta. ^{[ 10 ]} Esta perspectiva ha dado lugar a una investigación sustancial sobre la gestión del conocimiento de la arquitectura de software . ^{[ 11 ]}

No existe una distinción tajante entre arquitectura de software y diseño e ingeniería de requisitos (véase Campos relacionados más adelante). Todos forman parte de una «cadena de intencionalidad» que va desde las intenciones de alto nivel hasta los detalles de bajo nivel. ^{[ 12 ] : 18}

Un patrón de arquitectura de software es una solución reutilizable y probada para un problema recurrente a nivel de sistema, que aborda aspectos relacionados con la estructura general, las interacciones entre componentes y los atributos de calidad del sistema. Los patrones de arquitectura de software operan a un nivel de abstracción superior al de los patrones de diseño de software , resolviendo desafíos más amplios a nivel de sistema. Si bien estos patrones suelen afectar aspectos a nivel de sistema, la distinción entre patrones arquitectónicos y estilos arquitectónicos a veces puede ser difusa. Un ejemplo es Circuit Breaker . ^{[ 13 ] [ 14 ] [ 15 ]}

El estilo de arquitectura de software es una organización estructural de alto nivel que define la organización general del sistema, especificando cómo se organizan los componentes, cómo interactúan y las restricciones sobre dichas interacciones. Los estilos de arquitectura suelen incluir un vocabulario de tipos de componentes y conectores, así como modelos semánticos para interpretar las propiedades del sistema. Estos estilos representan el nivel más general de organización del sistema. Algunos ejemplos son la arquitectura en capas , los microservicios y la arquitectura orientada a eventos . ^{[ 13 ] [ 14 ] [ 15 ]}

Los siguientes antipatrones arquitectónicos pueden surgir cuando los arquitectos toman decisiones. Estos antipatrones suelen seguir una secuencia progresiva, donde la resolución de uno puede dar lugar a la aparición de otro. ^{[ 4 ]}

• Un arquitecto puede retrasar o evitar tomar decisiones arquitectónicas por temor a equivocarse. Para abordar esto, suele ser necesaria una colaboración continua y estrecha con el equipo de desarrollo, ajustando las decisiones arquitectónicas en función de sus comentarios. Además, las decisiones generalmente se toman en el último momento posible, asegurando así que haya suficiente información para justificarlas y validarlas, evitando retrasos innecesarios que podrían provocar parálisis por análisis y obstaculizar el progreso del equipo. ^{[ 4 ]}
• Otro antipatrón puede surgir cuando las decisiones arquitectónicas se olvidan, no se documentan o no se comprenden, lo que lleva a discusiones repetidas sin resolución. Esto suele ocurrir cuando se utiliza el correo electrónico para comunicar decisiones arquitectónicas. Para abordar estos desafíos, los arquitectos suelen proporcionar justificaciones tanto técnicas como comerciales (a menudo relacionadas con el costo, la satisfacción del usuario y el tiempo de comercialización) en un único registro de la decisión arquitectónica (generalmente un Registro de Decisión Arquitectónica). Este registro puede mantenerse en un repositorio accesible, como una wiki. La comunicación por correo electrónico se centra en la naturaleza y el contexto del cambio y se dirige solo a las partes interesadas relevantes, con un enlace al registro centralizado. Esto garantiza que siempre haya una única fuente de información actualizada. Además, si una decisión arquitectónica no ofrece un valor comercial tangible, o si el valor comercial no está alineado con las partes interesadas, puede ser necesario reconsiderarla. ^{[ 4 ]}

La arquitectura de software presenta las siguientes características:

Multitud de partes interesadas: los sistemas de software deben satisfacer las necesidades de diversas partes interesadas, como gerentes, propietarios, usuarios y operadores. Cada una de estas partes interesadas tiene sus propias inquietudes respecto al sistema. Equilibrar estas inquietudes y demostrar que se abordan forma parte del diseño del sistema. ^{[ 5 ] : 29–31} Esto implica que la arquitectura implica lidiar con una amplia variedad de inquietudes y partes interesadas, y tiene un carácter multidisciplinario.

Separación de preocupaciones : la forma establecida para que los arquitectos reduzcan la complejidad es separar las preocupaciones que impulsan el diseño. La documentación de arquitectura muestra que todas las preocupaciones de las partes interesadas se abordan modelando y describiendo la arquitectura desde puntos de vista separados asociados con las diversas preocupaciones de las partes interesadas. ^{[ 16 ]} Estas descripciones separadas se denominan vistas arquitectónicas (véase, por ejemplo, el modelo de vista arquitectónica 4+1 ).

Orientado a la calidad: los enfoques clásicos de diseño de software (por ejemplo, Programación Estructurada de Jackson ) se basaban en la funcionalidad requerida y el flujo de datos a través del sistema, pero la perspectiva actual ^{[ 5 ] : 26–28} es que la arquitectura de un sistema de software está más estrechamente relacionada con sus atributos de calidad , como tolerancia a fallos , retrocompatibilidad , extensibilidad , fiabilidad , mantenibilidad , disponibilidad , seguridad, usabilidad y otras características similares . Las preocupaciones de las partes interesadas a menudo se traducen en requisitos sobre estos atributos de calidad, que se denominan de diversas maneras requisitos no funcionales , requisitos extrafuncionales, requisitos de comportamiento o requisitos de atributos de calidad.

Estilos recurrentes: al igual que en la arquitectura de edificios, la disciplina de la arquitectura de software ha desarrollado métodos estándar para abordar problemas recurrentes. Estos "métodos estándar" reciben diversos nombres en distintos niveles de abstracción. Los términos comunes para las soluciones recurrentes son estilo arquitectónico, ^{[ 12 ] : 273–277} táctica, ^{[ 5 ] : 70–72} arquitectura de referencia y patrón arquitectónico . ^{[ 17 ] [ 18 ] [ 5 ] : 203–205}

Integridad conceptual: término introducido por Fred Brooks en su libro de 1975, El hombre-mes mítico, para referirse a la idea de que la arquitectura de un sistema de software representa una visión general de lo que debería hacer y cómo debería hacerlo. Esta visión debe separarse de su implementación. El arquitecto asume el rol de "guardián de la visión", asegurándose de que las adiciones al sistema estén en consonancia con la arquitectura, preservando así la integridad conceptual . ^{[ 19 ] : 41–50}

Restricciones cognitivas: Una observación realizada por primera vez en un artículo de 1967 por el programador informático Melvin Conway que señala que las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones. ^{[ 20 ]} Fred Brooks la dio a conocer a un público más amplio cuando citó el artículo y la idea en The Mythical Man-Month , llamándola Ley de Conway .

La arquitectura de software es una abstracción "intelectualmente comprensible" de un sistema complejo. ^{[ 5 ] : 5–6} Esta abstracción proporciona una serie de beneficios:

• Proporciona una base para el análisis del comportamiento de los sistemas de software antes de su construcción. ^{[ 2 ]} La capacidad de verificar que un futuro sistema de software satisface las necesidades de sus partes interesadas sin tener que construirlo representa un ahorro sustancial de costos y una mitigación de riesgos. ^{[ 21 ]} Se han desarrollado varias técnicas para realizar dichos análisis, como ATAM ^{[ 22 ]} o mediante la creación de una representación visual del sistema de software.
• Proporciona una base para la reutilización de elementos y decisiones. ^{[ 2 ] [ 5 ] : 35} Una arquitectura de software completa o partes de ella, como estrategias y decisiones arquitectónicas individuales, pueden reutilizarse en múltiples sistemas cuyos interesados ​​requieren atributos de calidad o funcionalidad similares, ahorrando costos de diseño y mitigando el riesgo de errores de diseño.
• Apoya las decisiones de diseño tempranas que impactan el desarrollo, la implementación y la vida útil del mantenimiento de un sistema. ^{[ 5 ] : 31} Tomar las decisiones tempranas y de alto impacto correctas es importante para evitar sobrecostos y retrasos en el cronograma .
• Facilita la comunicación con las partes interesadas, contribuyendo a un sistema que satisface mejor sus necesidades. ^{[ 5 ] : 29–31} Comunicar sobre sistemas complejos desde el punto de vista de las partes interesadas les ayuda a comprender las consecuencias de sus requisitos declarados y las decisiones de diseño basadas en ellos. La arquitectura permite comunicar las decisiones de diseño antes de la implementación del sistema, cuando aún son relativamente fáciles de adaptar.
• Ayuda en la gestión de riesgos. La arquitectura de software ayuda a reducir los riesgos y la probabilidad de fallos. ^{[ 12 ] : 18}
• Permite la reducción de costos . La arquitectura de software es un medio para gestionar el riesgo y los costos en proyectos de TI complejos. ^{[ 23 ]}

La comparación entre el diseño de software y la arquitectura (civil) se estableció por primera vez a finales de la década de 1960, ^{[ 24 ]} pero el término "arquitectura de software" no se generalizó hasta la década de 1990. ^{[ 25 ]} El campo de la informática había enfrentado problemas asociados con la complejidad desde su formación. ^{[ 26 ]} Los primeros problemas de complejidad fueron resueltos por los desarrolladores eligiendo las estructuras de datos adecuadas , desarrollando algoritmos y aplicando el concepto de separación de responsabilidades . Aunque el término "arquitectura de software" es relativamente nuevo en la industria, los principios fundamentales del campo han sido aplicados esporádicamente por pioneros de la ingeniería de software desde mediados de la década de 1980. Los primeros intentos de capturar y explicar la arquitectura de software de un sistema fueron imprecisos y desorganizados, a menudo caracterizados por un conjunto de diagramas de cajas y líneas . ^{[ 27 ]}

La arquitectura de software como concepto tiene su origen en las investigaciones de Edsger Dijkstra en 1968 y David Parnas a principios de la década de 1970. Estos científicos enfatizaron la importancia de la estructura de un sistema de software y la necesidad de una estructura adecuada. Durante la década de 1990, se realizó un esfuerzo conjunto para definir y codificar aspectos fundamentales de la disciplina, centrándose la investigación en estilos arquitectónicos ( patrones ), lenguajes de descripción de arquitectura , documentación de arquitectura y métodos formales . ^{[ 28 ]}

Las instituciones de investigación han desempeñado un papel fundamental en el desarrollo de la arquitectura de software como disciplina. Mary Shaw y David Garlan, de la Universidad Carnegie Mellon, publicaron en 1996 el libro « Arquitectura de software: Perspectivas sobre una disciplina emergente» , que promovió conceptos de arquitectura de software como componentes , conectores y estilos. Los esfuerzos del Instituto de Investigación de Software de la Universidad de California, Irvine, en el campo de la investigación en arquitectura de software se centran principalmente en estilos arquitectónicos, lenguajes de descripción de arquitectura y arquitecturas dinámicas.

La norma IEEE 1471-2000 , «Práctica recomendada para la descripción de la arquitectura de sistemas intensivos en software», fue la primera norma formal en el ámbito de la arquitectura de software. Fue adoptada en 2007 por la ISO como ISO/IEC 42010:2007. En noviembre de 2011, la norma IEEE 1471-2000 fue sustituida por la ISO/IEC/IEEE 42010:2011 , «Ingeniería de sistemas y software: descripción de la arquitectura» (publicada conjuntamente por la IEEE y la ISO). ^{[ 16 ]}

Mientras que en la norma IEEE 1471 la arquitectura de software se centraba en la arquitectura de "sistemas intensivos en software", definidos como "cualquier sistema en el que el software contribuye de manera esencial al diseño, la construcción, el despliegue y la evolución del sistema en su conjunto", la edición de 2011 va un paso más allá al incluir las definiciones de sistema de las normas ISO/IEC 15288 e ISO/IEC 12207 , que abarcan no solo el hardware y el software, sino también "personas, procesos, procedimientos, instalaciones, materiales y entidades que se dan de forma natural". Esto refleja la relación entre la arquitectura de software, la arquitectura empresarial y la arquitectura de soluciones .

La toma de decisiones arquitectónicas implica recopilar suficiente información relevante, proporcionar justificación para la decisión, documentar la decisión y su fundamento, y comunicarla eficazmente a las partes interesadas pertinentes. ^{[ 4 ]}

Es responsabilidad del arquitecto de software hacer coincidir las características arquitectónicas (también conocidas como requisitos no funcionales ) con los requisitos del negocio. Por ejemplo: ^{[ 4 ]}

• Para lograr un alto nivel de satisfacción del cliente , el sistema requiere disponibilidad, tolerancia a fallos, seguridad, capacidad de prueba, capacidad de recuperación, agilidad y rendimiento.
• Las fusiones y adquisiciones (M&A) requieren extensibilidad, escalabilidad, adaptabilidad e interoperabilidad.
• Un presupuesto y un tiempo limitados exigen viabilidad y simplicidad.
• Para acelerar la comercialización, se requiere facilidad de mantenimiento, capacidad de prueba y facilidad de despliegue.

Hay cuatro actividades centrales en el diseño de arquitectura de software. ^{[ 29 ]} Estas actividades centrales de arquitectura se realizan de forma iterativa y en diferentes etapas del ciclo de vida inicial del desarrollo de software, así como a lo largo de la evolución de un sistema.

El análisis arquitectónico es el proceso de comprender el entorno en el que operará un sistema propuesto y determinar los requisitos para dicho sistema. Los insumos o requisitos para la actividad de análisis pueden provenir de diversos interesados ​​e incluir elementos como:

• qué hará el sistema cuando esté operativo (los requisitos funcionales)
• qué tan bien el sistema cumplirá con los requisitos no funcionales en tiempo de ejecución, tales como confiabilidad, operabilidad, eficiencia de rendimiento, seguridad, compatibilidad definidos en la norma ISO/IEC 25010 :2011 ^{[ 30 ]}
• tiempo de desarrollo de requisitos no funcionales como mantenibilidad y transferibilidad definidos en la norma ISO 25010:2011 ^{[ 30 ]}
• requisitos comerciales y contextos ambientales de un sistema que pueden cambiar con el tiempo, como preocupaciones legales, sociales, financieras, competitivas y tecnológicas ^{[ 31 ]}

Los resultados de la actividad de análisis son aquellos requisitos que tienen un impacto medible en la arquitectura de un sistema de software, denominados requisitos arquitectónicamente significativos. ^{[ 32 ]}

La síntesis o diseño arquitectónico es el proceso de creación de una arquitectura. Considerando los requisitos arquitectónicamente significativos determinados por el análisis, el estado actual del diseño y los resultados de las actividades de evaluación, se crea y mejora el diseño. ^{[ 29 ] [ 5 ] : 311–326}

La evaluación de la arquitectura es el proceso de determinar qué tan bien el diseño actual, o una parte del mismo, satisface los requisitos derivados durante el análisis. Una evaluación puede ocurrir cuando un arquitecto considera una decisión de diseño, después de que se haya completado una parte del diseño, después de que se haya completado el diseño final o después de que se haya construido el sistema. Algunas de las técnicas de evaluación de arquitectura de software disponibles incluyen el Método de Análisis de Compromisos de Arquitectura (ATAM) y TARA. ^{[ 33 ]} Los marcos para comparar las técnicas se discuten en marcos como el Informe SARA ^{[ 21 ]} y Architecture Reviews: Practice and Experience . ^{[ 34 ]}

La evolución de la arquitectura es el proceso de mantener y adaptar una arquitectura de software existente para satisfacer los cambios en los requisitos y el entorno. Dado que la arquitectura de software proporciona la estructura fundamental de un sistema de software, su evolución y mantenimiento necesariamente impactan en dicha estructura. Por lo tanto, la evolución de la arquitectura se centra tanto en añadir nuevas funcionalidades como en mantener las existentes y el comportamiento del sistema.

La arquitectura requiere actividades de apoyo fundamentales. Estas actividades se desarrollan a lo largo de todo el proceso central de la arquitectura de software e incluyen la gestión del conocimiento y la comunicación, el razonamiento y la toma de decisiones en el diseño, y la documentación.

La arquitectura de software se enfrenta inherentemente a incertidumbres, y el tamaño de los componentes arquitectónicos puede influir significativamente en los resultados de un sistema, tanto positiva como negativamente. Neal Ford y Mark Richards proponen un enfoque iterativo para abordar el desafío de identificar y dimensionar correctamente los componentes. Este método enfatiza el refinamiento continuo a medida que los equipos desarrollan una comprensión más profunda del comportamiento y los requisitos del sistema. ^{[ 4 ]}

El enfoque generalmente implica un ciclo con varias etapas: ^{[ 4 ]}

• Se establece una estrategia de particionamiento de alto nivel, que suele clasificarse como técnica o basada en dominios. Se definen las directrices para la unidad desplegable más pequeña y significativa, denominada «quanta». Si bien estas decisiones fundamentales se toman al inicio del ciclo, pueden revisarse posteriormente si fuera necesario.
• Los componentes iniciales se identifican en función de la estrategia establecida.
• Se asignan requisitos a los componentes identificados.
• Se analizan las funciones y responsabilidades de cada componente para garantizar la claridad y minimizar la superposición de funciones.
• Se evalúan características arquitectónicas como la escalabilidad, la tolerancia a fallos y la facilidad de mantenimiento.
• Los componentes pueden reestructurarse en función de los comentarios de los equipos de desarrollo.

Este ciclo sirve como marco general y puede adaptarse a diferentes ámbitos.

• Richards, Mark (2020). Fundamentos de la arquitectura de software: Un enfoque de ingeniería . O'Reilly Media . ISBN 978-1-4920-4345-4.
• Len, Bass (2012). Arquitectura de software en la práctica (3.ª  ed.). Addison-Wesley Professional . ISBN 978-0-321-81573-6.Este libro abarca los conceptos fundamentales de la disciplina. El tema central es cómo lograr atributos de calidad en un sistema.
• Clements, Paul (2010). Documentación de arquitecturas de software: vistas y más allá (2.ª  ed.). Addison-Wesley Professional . ISBN 978-0-321-55268-6.Este libro describe qué es la arquitectura de software y muestra cómo documentarla desde múltiples perspectivas, utilizando UML y otras notaciones. También explica cómo complementar las vistas de arquitectura con documentación sobre el comportamiento, la interfaz de software y la justificación. El libro incluye una wiki con un ejemplo de documentación de arquitectura de software .
• Bell, Michael (2008). Bell, Michael (ed.). Modelado orientado a servicios: análisis, diseño y arquitectura de servicios . Wiley. doi : 10.1002/9781119198864 . ISBN 978-0-470-25570-4.
• Shan, Tony; Hua, Winnie (octubre de 2006). «Mecanismo de arquitectura de soluciones». 10.ª Conferencia Internacional IEEE de Computación Distribuida de Objetos Empresariales (EDOC'06) de 2006. págs. 23-32 . doi : 10.1109/EDOC.2006.54 . ISBN  978-0-7695-2558-7. S2CID 8361936 . 
• Garzás, Javier; Piattini, Mario (2005). "Una ontología para el conocimiento del diseño microarquitectónico". IEEE Software . 22 (2): 28– 33. Bibcode : 2005ISoft..22b..28G . doi : 10.1109/MS.2005.26 . S2CID 17639072 . 
• Fowler, Martin (septiembre de 2003). "¿Quién necesita un arquitecto?" (PDF) . IEEE Software . 20 (5): 11. Bibcode : 2003ISoft..20e..11F . doi : 10.1109/MS.2003.1231144 . S2CID 356506 . 
• Kazman, Rick (mayo de 2003). "Arquitectura, diseño, implementación" (PDF) . Software Engineering Institute . Archivado (PDF) del original el 21 de septiembre de 2015.- Sobre la distinción entre diseño arquitectónico y diseño de detalle.
• Kruchten, Philippe (1995). "Planos arquitectónicos: el modelo de vista '4+1' de la arquitectura de software" (PDF) . IEEE Software . 12 (6): 42– 50. arXiv : 2006.04975 . doi : 10.1109/52.469759 . S2CID 219558624. Archivado (PDF) del original el 13 de junio de 2006. 
• Pautasso, Cesare (2020). Arquitectura de software: notas visuales de clase . LeanPub. pág.  689.
• Magee, J., Dulay, N., Eisenbach, S., & Kramer, J. (1995, septiembre). Especificación de arquitecturas de software distribuidas. En Conferencia europea de ingeniería de software (pp. 137-153). Berlín, Heidelberg: Springer Berlin Heidelberg.

• Explicación sobre IBM Developerworks
• Colección de definiciones de arquitectura de software en el Instituto de Ingeniería de Software (SEI), Universidad Carnegie Mellon (CMU).
• Asociación Internacional de Arquitectos de TI (IASA Global) , anteriormente conocida como Asociación Internacional de Arquitectos de Software (IASA)
• SoftwareArchitecturePortal.org – sitio web del Grupo de Trabajo 2.10 de IFIP sobre Arquitectura de Software
• SoftwareArchitectures.com Archivado el 29/10/2023 en Wayback Machine , un recurso independiente de información sobre la disciplina.
• Arquitectura de software , capítulo 1 de la tesis doctoral de Roy Fielding sobre REST.
• Cuando la buena arquitectura se vuelve mala
• El desarrollo impulsado por la arquitectura en espiral ( SDLC basado en el modelo espiral) tiene como objetivo reducir los riesgos de una arquitectura ineficaz.
• Estudios de casos reales sobre arquitectura de software