No existe una definición universal de arquitectura de software. El sitio web del Instituto de Ingeniería de Software recopila definiciones de la literatura y de profesionales de todo el mundo. Hasta ahora, se han recopilado más de 150 definiciones. Cuando se intenta comprender un sistema, es importante saber qué hacen realmente sus partes individuales, cómo funcionan juntas y cómo interactúan con el mundo que las rodea, en otras palabras, su arquitectura. Una definición ampliamente aceptada de arquitectura de software es:
“La arquitectura de un sistema es el conjunto de conceptos o propiedades fundamentales del sistema, plasmados en sus elementos, relaciones y los principios de su diseño.”
La pregunta de cómo la arquitectura de software es diferente del diseño ha llegado a los talones de la comunidad de desarrollo de software durante años, y en este contexto es importante, porque la pregunta trata de qué deberíamos poner en un documento de arquitectura y qué deberíamos poner en otro lugar.
Lo primero que podemos decir es que claramente la arquitectura es diseño, pero no todo diseño es arquitectura. Es decir, muchas de las decisiones de diseño quedan sin consolidar por la arquitectura, quedando, finalmente, a la discreción y buen juicio de los diseñadores y desarrolladores posteriores. La arquitectura establece restricciones en las actividades posteriores, y esas actividades deben producir artefactos (diseños y códigos más finos) que cumplan con la arquitectura.
Por lo tanto, las decisiones arquitectónicas son las que permiten que un sistema cumpla con sus atributos de calidad y requisitos de comportamiento. Todas las demás decisiones son no arquitectónicas y pertenecen al diseño del software.
¿Por qué documentar la arquitectura del software?
Incluso la mejor arquitectura, la más adecuada para el trabajo, será esencialmente inútil si las personas que necesitan usarla no saben lo que es, no pueden entenderlo lo suficiente como para aplicarlo, o -lo peor de todo- lo malinterpretan y aplican incorrectamente. Por lo tanto, crear una arquitectura no es suficiente; tiene que ser comunicada de manera que sus partes interesadas puedan usarla adecuadamente para hacer su trabajo. La documentación habla por el arquitecto, cuando él o ella hayan abandonado el proyecto, y ahora alguien más esté a cargo de su evolución y mantenimiento.
Los mejores arquitectos producen la mejor documentación, no porque sea «requerida», sino porque ven que es esencial para el asunto en cuestión: producir un producto de alta calidad, de manera predecible y con el menor trabajo posible. Ven a sus partes interesadas inmediatas como las personas más íntimamente involucradas en esta empresa: desarrolladores, implementadores, probadores y analistas.
Pero los mejores arquitectos también ven la documentación como un valor para sí mismos. La documentación sirve como receptáculo para guardar los resultados de las decisiones de diseño a medida que se toman. Un esquema de documentación bien pensado puede hacer que el proceso de diseño sea mucho más fluido y sistemático. La documentación ayuda al arquitecto mientras la arquitectura está en progreso, ya sea en una fase de diseño de seis meses o en un sprint ágil de seis días.
¿Cuáles son las características de una documentación de arquitectura de software?
La documentación de arquitectura debe servir para diversos propósitos: Debe ser lo suficientemente abstracto como para que los nuevos empleados lo entiendan rápidamente; debe ser lo suficientemente concreto como para servir como proyecto para la construcción y, por último, debe tener suficiente información para servir de base para el análisis.
La documentación de arquitectura es tanto prescriptiva como descriptiva. Para algunas audiencias, prescribe lo que debería ser cierto, imponiendo restricciones a las decisiones que aún deben tomarse. Para otras audiencias, describe lo que es verdad, relatando las decisiones ya tomadas sobre el diseño de un sistema.
Fundamentalmente, la documentación de arquitectura tiene tres usos.
- La arquitectura sirve como un medio de educación. El uso educativo consiste en introducir a las personas al sistema. La gente puede ser nuevos miembros del equipo, analistas externos o incluso un nuevo arquitecto. En muchos casos, la «nueva» persona es el cliente a quien le está mostrando su solución por primera vez, una presentación que espera dará como resultado la aprobación de fondos o aprobación.
- La arquitectura sirve como vehículo principal para la comunicación entre las partes interesadas. El uso preciso de una arquitectura como vehículo de comunicación depende de qué partes interesadas se estén comunicando. Quizás uno de los consumidores más ávidos de documentación de arquitectura no sea otro que el arquitecto en el futuro del proyecto. El futuro arquitecto puede ser la misma persona que el actual, o él o ella puede ser un reemplazo, pero en cualquier caso se le garantiza una enorme participación en la documentación. Los nuevos arquitectos están interesados en aprender cómo sus predecesores abordaron los difíciles problemas del sistema y por qué se tomaron decisiones particulares. Incluso si el futuro arquitecto es la misma persona, él o ella usará la documentación como depósito de pensamiento, un almacén de decisiones de diseño demasiado numerosas e irremediablemente entrelazadas para ser reproducibles solo de memoria.
- Documentar una arquitectura ayuda en el proceso de diseño de la arquitectura. Primero, la documentación proporciona compartimentos dedicados para registrar varios tipos de decisiones de diseño tan pronto como se toman. En segundo lugar, la documentación le brinda una forma aproximada pero útil de medir el progreso y el trabajo restante: a medida que «TBD» desaparece del documento, la finalización se acerca. Finalmente, la documentación proporciona un marco para el ataque sistemático en el diseño de la arquitectura. Las decisiones de diseño clave, generalmente hechas temprano, deben escribirse de manera que la sombra que arrojan sobre las decisiones de diseño posteriores sea explícita y recordada.
Stakeholders involucrados en la documentación de la arquitectura de software
Finalmente, es importante considerar quienes están involucrados en el proceso de documentación de arquitectura de software. Veamos:
- Arquitecto. Es el responsable del desarrollo de la arquitectura y su documentación. Usa la documentación de arquitectura para negociar y compensar entre requisitos competitivos y enfoques de diseño. Un recipiente para registrar decisiones de diseño. Aportando evidencia de que la arquitectura satisface sus requisitos.
- Analista de negocios. Responsable del funcionamiento de la entidad empresarial / organizacional propietaria del sistema. Incluye responsabilidad gerencial / ejecutiva, responsabilidad de definir procesos de negocios y más. La documentación de arquitectura le permite comprender la capacidad de dicha arquitectura para cumplir los objetivos comerciales.
- Administrador de Base de Datos. Implicado en muchos aspectos de los almacenes de datos, incluido el diseño de bases de datos, análisis de datos, modelado y optimización de datos, instalación de software de bases de datos, y el monitoreo y administración de seguridad de bases de datos. La documentación de arquitectura le permite comprender cómo los datos son creados, utilizados y actualizados por otros elementos arquitectónicos, y qué propiedades deben tener los datos y la base de datos para que el sistema general cumpla con sus objetivos de calidad.
- DevOp. Responsable de aceptar el sistema completo del esfuerzo de desarrollo y desplegarlo, para hacerlo operativo y cumplir con su función comercial asignada. La documentación de la arquitectura le sirve para comprender los elementos arquitectónicos que se entregan y se instalan en el sitio del cliente o del usuario final, y su responsabilidad general hacia la función del sistema.
- Diseñador. Responsable del diseño de sistemas y/o software aguas abajo de la arquitectura, aplicando la arquitectura para cumplir con los requisitos específicos de las partes de las que son responsables. La documentación de arquitectura le ayuda a resolver la contención de recursos y establecer el rendimiento y otros tipos de presupuestos de consumo de recursos en tiempo de ejecución, así como también comprender cómo su parte se comunicará e interactuará con otras partes del sistema.
- Administrador de Sistemas. Responsable del mantenimiento y supervisión del hardware y software de una red informática. Esto puede incluir la implementación, configuración, mantenimiento y monitoreo de componentes de red. La documentación de arquitectura le permite determinar las cargas de red durante varios perfiles de uso y comprender los usos de la red.
- Jefe de Proyectos. Es el responsable de planificar, secuenciar, programar y asignar recursos para desarrollar componentes de software y entregar componentes para actividades de integración y prueba. La documentación de arquitectura le ayuda a establecer el presupuesto y el cronograma, medir el progreso con respecto al presupuesto y cronograma establecidos, e identificar y resolver la contención de recursos en tiempo de desarrollo.
- Ingeniero QA. Responsable de las pruebas (independientes) y verificación del sistema o sus elementos contra los requisitos formales y la arquitectura. Con la documentación de arquitectura puede crear pruebas basadas en el comportamiento y la interacción de los elementos del software.
- Usuario. Es quien pertenece al grupo de usuarios finales reales del sistema. Puede haber distintos tipos de usuarios, como administradores, superusuarios, etc. Los usuarios, en el papel de revisores, pueden confiar en la documentación de la arquitectura para verificar si se está entregando la funcionalidad deseada. Los usuarios también pueden consultar la documentación para comprender cuáles son los principales elementos del sistema, que pueden ayudarlos en el mantenimiento de emergencia en el campo.