Qué es la arquitectura de software: las definiciones estándar y lo que tienen en común

Por qué hace falta definir la palabra

Pregunta a diez ingenieros con experiencia qué es la arquitectura de software y oirás diez respuestas distintas: el diagrama de cajas y flechas de la pared, la elección del proveedor de nube, el esquema de la base de datos, la división en servicios, las reglas sobre qué código puede llamar a cuál o, simplemente, "las decisiones difíciles". Cada respuesta capta algo real y, por sí sola, a cada una le falta algo. Por eso, un curso que va a enseñar arquitectura tiene que empezar por precisar de qué está hablando.

Esto importa por razones prácticas. Si un equipo cree que la arquitectura es "el diagrama", dejará de prestarle atención una vez dibujado el diagrama, aunque el sistema siga cambiando por debajo. Si cree que la arquitectura es "el stack tecnológico", discutirá sobre frameworks mientras ignora cómo se reparten las responsabilidades y cómo fluyen los datos. Una buena definición te dice qué mirar, qué proteger y qué hablar con los demás.

Las definiciones que siguen proceden de una norma internacional, del Software Engineering Institute (SEI) de la Universidad Carnegie Mellon y de profesionales del sector. Se escribieron con fines distintos, pero coinciden más de lo que discrepan, y los puntos en los que coinciden son el núcleo de la disciplina.

La definición estándar: ISO/IEC/IEEE 42010:2022

ISO/IEC/IEEE 42010 es la norma internacional para describir arquitecturas. Su edición actual, publicada en noviembre de 2022, sustituyó a la edición de 2011. Define la arquitectura, en una paráfrasis fiel, como los conceptos o propiedades fundamentales de una entidad en su entorno, junto con los principios que rigen la realización y la evolución de esa entidad y sus procesos del ciclo de vida relacionados.

Tres rasgos de esta definición merecen atención. Primero, habla de una entidad, no solo de un sistema de software. La edición de 2022 amplió deliberadamente el alcance para que las mismas ideas se apliquen al software, a los sistemas de sistemas, a los productos, a las líneas de productos y a empresas enteras. Segundo, sitúa la entidad en su entorno: no puedes entender una arquitectura sin los usuarios, los otros sistemas, la organización, las leyes y los presupuestos que la rodean. Tercero, incluye principios que rigen cómo se construye la entidad y cómo cambia. La arquitectura no es solo una instantánea de la estructura; incluye las reglas que mantienen la estructura coherente a medida que el sistema evoluciona, como "cada servicio es dueño de sus propios datos" o "el código del dominio nunca depende del framework web".

La norma también traza una línea clara entre una arquitectura y una descripción de arquitectura. La arquitectura es el conjunto de propiedades fundamentales que el sistema tiene realmente. La descripción es un producto de trabajo (documentos, modelos, diagramas, registros de decisiones) que la expresa. ISO/IEC/IEEE 42010 es sobre todo una norma sobre descripciones: dice qué debe contener una buena descripción, como las partes interesadas identificadas, sus inquietudes y las vistas que abordan esas inquietudes. No te dice cómo diseñar una arquitectura. La Sección 1.5 vuelve a las partes interesadas y las inquietudes, y el Capítulo 4 trata las vistas.

La definición del SEI: estructuras, elementos, relaciones y propiedades

La definición más enseñada procede de Software Architecture in Practice, de Len Bass, Paul Clements y Rick Kazman (4.ª edición, Addison-Wesley, 2021), cuyos autores trabajaron en el SEI. En sus palabras, parafraseadas: la arquitectura de software de un sistema es el conjunto de estructuras necesarias para razonar sobre el sistema, y esas estructuras constan de elementos de software, las relaciones entre ellos y las propiedades de ambos.

Cada parte de esa frase cumple una función. Estructuras, en plural: un sistema tiene muchas estructuras a la vez (sus módulos de código, sus procesos en ejecución, su despliegue en máquinas) y ninguna de ellas es por sí sola "la" arquitectura. Necesarias para razonar sobre el sistema: la prueba de si algo es arquitectónico es si lo necesitas para responder preguntas importantes, como "¿Aguantará esto la carga máxima?" o "¿Pueden dos equipos trabajar en esto de forma independiente?". Los elementos son las partes: módulos, servicios, bases de datos, colas. Las relaciones son cómo se conectan: usa, llama a, publica en, se despliega en. Las propiedades son lo que hace que los elementos y las relaciones se comporten como lo hacen: un servicio no tiene estado, una llamada es síncrona con un timeout de dos segundos, una base de datos contiene datos personales y debe permanecer en la UE.

La expresión sobre el razonamiento también explica lo que no es arquitectura. El nombre de una variable local, el algoritmo interno de una rutina de ordenación o la disposición de una pantalla de configuración normalmente no te ayudan a razonar sobre el sistema en su conjunto, así que pertenecen al diseño detallado y no a la arquitectura. La Sección 1.2 examina dónde cae esa línea.

Definiciones de los profesionales: entendimiento compartido, lo importante y decisiones

Los profesionales han propuesto definiciones más breves que ponen el acento en las personas y las decisiones más que en las estructuras. Martin Fowler ha popularizado dos de Ralph Johnson (uno de los cuatro autores del libro Design Patterns de 1994). La primera es que la arquitectura es el entendimiento compartido que tienen los desarrolladores expertos de cómo está diseñado el sistema. La segunda, de la misma discusión, es deliberadamente abierta: La arquitectura trata de lo importante. Sea lo que sea. Johnson también sugirió que la arquitectura es el conjunto de decisiones que te gustaría acertar al principio de un proyecto, no porque sea más probable acertarlas al principio, sino porque equivocarse en ellas sale muy caro.

Grady Booch, uno de los creadores de UML, lo planteó en términos económicos: la arquitectura está formada por las decisiones de diseño significativas que dan forma a un sistema, donde la significancia se mide por el costo del cambio. Eso convierte una idea abstracta en una prueba utilizable. Elegir el color de un botón es barato de revertir. Elegir entre una base de datos relacional y un almacén de documentos, o entre una unidad desplegable y cuarenta, es caro de revertir una vez que los datos, el código y los equipos han crecido a su alrededor. Booch también observó que toda arquitectura es diseño, pero no todo diseño es arquitectura.

Estas definiciones añaden algo que las estructurales dejan implícito. La arquitectura vive en parte en la cabeza de las personas; un sistema cuyos ingenieros sénior comparten una imagen clara de cómo funciona tiene una arquitectura más coherente que uno en el que cada cual tiene una imagen distinta, aunque ninguno de los dos tenga un diagrama. Y la arquitectura se forma a partir de decisiones, muchas de las cuales implican un compromiso: elegir una opción significa renunciar a las ventajas de otra. La Sección 1.6 estudia en detalle las decisiones y los compromisos.

Lo que comparten las definiciones

Leídas en paralelo, las definiciones convergen en siete ideas, y juntas forman una definición de trabajo para el resto de este curso.

Tres tipos de estructura

El trabajo del SEI sobre documentación, publicado como Documenting Software Architectures: Views and Beyond (Clements y colaboradores, 2.ª edición, 2010), agrupa las estructuras en tres tipos, y Software Architecture in Practice usa la misma agrupación. Conocer los tres tipos te protege del error más común en las discusiones de arquitectura: hablar de un tipo de estructura mientras la otra persona está pensando en otro.

Las estructuras de módulos muestran cómo se divide el código en unidades de implementación, como paquetes, bibliotecas y espacios de nombres, y cómo dependen esos módulos unos de otros. Existen en tiempo de desarrollo. Responden a preguntas como: ¿qué equipo puede cambiar qué sin romper el trabajo de los demás, y qué código se puede reutilizar?

Las estructuras de componentes y conectores muestran lo que existe cuando el sistema se ejecuta: procesos, servicios, clientes, bases de datos y los conectores entre ellos, como las llamadas HTTP, las colas de mensajes y los flujos de eventos. Responden a preguntas de tiempo de ejecución: ¿qué rapidez tiene una solicitud, qué ocurre cuando falla una parte, dónde se guardan los datos?

Las estructuras de asignación hacen corresponder el software con elementos ajenos al software: con el hardware y la infraestructura en la nube (despliegue), con los equipos (asignación del trabajo) y con los archivos y repositorios (implementación). Responden a preguntas sobre costos, operaciones y organización: ¿dónde se ejecuta, quién lo construye, a quién despiertan de madrugada cuando falla?

Un mismo elemento puede aparecer en las tres. Una funcionalidad de pago es un paquete en la estructura de módulos, un servicio en ejecución en la estructura de componentes y conectores, y un conjunto de contenedores en una región de nube cuyo responsable es el equipo de pago en las estructuras de asignación. La correspondencia entre estructuras no siempre es de uno a uno: un solo módulo puede desplegarse como varios servicios, o varios módulos pueden ejecutarse en un mismo proceso. Es justo en ese desajuste donde se esconden muchas sorpresas.

Todo sistema tiene una arquitectura

Como la arquitectura consiste en estructuras y en las propiedades que estas tienen realmente, todo sistema de software tiene una arquitectura, la haya diseñado alguien a propósito o no, y esté documentada o no. Una macro de hoja de cálculo que acabó convirtiéndose en una herramienta crítica para el negocio tiene una arquitectura. También la tiene la base de código de una startup escrita a toda prisa por tres personas. La pregunta nunca es si un sistema tiene arquitectura, sino si esa arquitectura es adecuada para su propósito, la entienden las personas que trabajan en ella y se ha moldeado de forma deliberada.

Esto lleva a una distinción útil. La arquitectura prevista (o prescriptiva) es lo que el equipo cree o ha decidido que debe ser la estructura: el diagrama de la wiki, las reglas acordadas. La arquitectura real (o descriptiva) es lo que hacen de verdad el código y la infraestructura. Las dos se van separando con el tiempo, a menos que alguien las mantenga alineadas, y ese desajuste es una de las principales fuentes de deuda técnica, que se trata en la Sección 1.7. Una arquitectura sin documentar no está ausente; simplemente es más difícil de ver, de razonar sobre ella y de cambiar con seguridad.

Cómo usan las definiciones los profesionales

En la práctica, los arquitectos con experiencia rara vez recitan una definición, pero usan cada una como una lente. La visión de ISO les recuerda que deben mirar hacia fuera, al entorno, y separar lo que el sistema es de lo que dicen los documentos. La visión del SEI les da un vocabulario de estructuras, elementos, relaciones y propiedades para el análisis, y una prueba ("¿necesitamos esto para razonar sobre el sistema?"). La visión de Johnson les recuerda que un modelo mental compartido en todo el equipo es en sí mismo un activo que hay que mantener. La visión de Booch les dice dónde dedicar su tiempo limitado: a las decisiones que serían caras de revertir.

De ahí se deriva una regla práctica. Cuando no estés seguro de si algo es arquitectónico, hazte tres preguntas. ¿Sería caro o arriesgado cambiarlo más adelante? ¿Afecta a varias partes del sistema o a varios equipos? ¿Determina si el sistema cumple un objetivo de calidad importante, como la velocidad, la disponibilidad o la seguridad? Si la respuesta a cualquiera de ellas es sí, trátalo como arquitectura: decídelo de forma deliberada, registra las razones y asegúrate de que las personas afectadas lo entienden.