¿Qué es Arquitectura de Software?

Un primer acercamiento para responder ¿qué es arquitectura de software? consiste en aislar la palabra software y buscar en el diccionario el concepto general de arquitectura. Conviene revisar diccionarios en inglés y español.

Como se aprecia en la siguiente figura, en español hay una definición de arquitectura en el contexto de la informática. Más allá del concepto tradicional de construir obras (como edificios, calles, puentes, acueductos, etc), arquitectura es "la estructura lógica y física" de un sistema. Si se consideran los dos primeros significados, la arquitectura es un hacer ("el arte de proyectar y construir") y también es el resultado de ese hacer ("el diseño", "la estructura"). Aparece la palabra diseño en el sentido de proyectar lo que se quiere construir y no tanto como un sinónimo.

Definiciones de arquitectura en el DRAE

Si se busca en inglés, el diccionario Cambridge coincide con el español y amplía el concepto. Además del hacer y del resultado del hacer, aparece la  profesión o trabajo de quien lo hace (el arquitecto). También aparece la arquitectura de una organización, que es cercano a lo que hoy se conoce como Arquitectura Empresarial.

En general, si se acude al diccionario y se piensa con detenimiento, la palabra arquitectura hace referencia a tres cosas diferentes:

1. Un hacer, algo que se hace, una actividad. Ese hacer consiste en proyectar algo que se quiere construir.
2. El resultado de ese hacer, la proyección de eso que se quiere construir, la arquitectura de algo.
3. La profesión de una persona responsable de ese hacer, la arquitectura como el rol o profesión del arquitecto.

Estas tres cosas se pueden resumir al proceso (y el proyecto), el producto y las personas, que son las 4P mencionadas en el tradicional libro de Jacobson, Booch y Rumbaugh. Y, aunque este libro está en el contexto del software, bien se podría afirmar que esta visión aplica para casi cualquier contexto de la arquitectura.

Pero conviene profundizar un poco más y retroceder en la historia de la palabra, para lo cual hay que remitirse a la disciplina de donde la palabra se tomó prestada. En últimas, en nuestra disciplina casi todas las palabras son metáforas y muchas vienen prestadas de otras disciplinas.

Históricamente existe un libro (o conjunto de libros) y una persona a quienes se reconoce el texto seminal o fundacional de la arquitectura: "De Architectura libri decem" o Los Diez libros de Arquitectura de Marco Vitruvio Polión, quien fue militar y  constructor (arquitecto e ingeniero) del emperador romano Julio Cesar.

Hay mucho por leer y comentar sobre este libro, pero, en aras de la brevedad, conviene destacar solo dos cosas: En primer lugar el principio de la triada "firmitas, utilitas y venustas", entendida como solidez, utilidad y belleza. No en vano una de las obras de Leonardo Davinci se conoce como El Hombre de Vitruvio.

En segundo lugar, un texto citado por la Asociación Colombiana de Facultades de Ingeniería (ACOFI) desde el año 2005, que resume la profesión del ingeniero desde la visión de Vitruvio.

Esta cita lleva a pensar que hay una relación muy estrecha entre la profesión del arquitecto y del ingeniero. Y surgen algunas preguntas: ¿Son lo mismo la ingeniería y la arquitectura? ¿Es la arquitectura parte de la ingeniería o son independientes? ¿Así como existen programas académicos de ingeniería del software, será necesario un programa de arquitectura de software? ¿Al estudiar Ingeniería del Software debería estudiarse algo sobre Arquitectura de Software? En general son más las preguntas que las respuestas y es amplia la confusión terminológica existente, lo cual no es bueno ni malo, simplemente es una realidad que no podemos ignorar... lo malo es ignorar esa diversidad de visiones y contradicciones...

Regresando a las 4P y olvidando un poco la historia, las 4P nos indican que podemos abordar el estudio del desarrollo de software desde esas cuatro aristas: la arista de las personas nos lleva a las competencias blandas. La arista del proyecto nos conduce a los aspectos metodológicos, con un enfoque en el alcance, el tiempo y el costo, la organización en el tiempo de las tareas y los recursos. La arista del proceso que se enfoca en cómo hacer las cosas bien, las buenas prácticas y la viabilidad de que sean repetibles. Y la arista del producto, muy cercana al código fuente, al software en operación y a su arquitectura. Esas cuatro aristas pueden involucrar componentes de burocracia y documentación y componentes de calidad y verificación mediante mediciones. De allí pueden surgir muchas definiciones y muchas escuelas de pensamiento, pero todas convergen a las 4P. Las 4P son suficientes para entender globalmente el mundo del software.

De la mano con las 4P, el libro de Peter Eeles y Peter Cripps sugiere que hay dos visiones de arquitectura de software: la de Grady Booch, centrada en el  producto,  en el resultado de la arquitectura y la de ellos, centrada en el proceso, en el cómo hacer la arquitectura, lo que llaman en inglés "architecting".

Por otra parte,  si se busca en SCOPUS por "software architecture" y se procesa esa búsqueda (más de 4000 publicaciones) en la herramienta árbol de la ciencia, la raíz del árbol nos da pistas sobre los padres de la arquitectura, con autores como Bass, Shaw, Garlan y Clements.

Para muchos, Mary Shaw y David Garlan son los padres de la arquitectura de software moderna y su casa de estudios es el principal referente, la Universidad Carnegie Mellon. Esta Universidad tiene un glosario detallado sobre Arquitectura de Software, cuyas definiciones ofrecen las múltiples perspectivas existentes.

Hay un par de artículos clásicos de estos autores, que son de fácil acceso en Internet y altamente citados y que ofrecen una visión amplia y detallada de lo que fue y es la arquitectura de software.

En el segundo de estos artículos hay una imagen que simplifica la arquitectura como el intermediario o puente entre los requerimientos y el código fuente, entre la necesidad inicial y el producto final.

Para mi concepto, esta última figura simplifica y resume toda la complejidad que hay en torno a la arquitectura de software. Y no es una simplificación que busque trivializar las cosas sino que persigue pasar rápidamente a la práctica desde la teoría, tan amplia, compleja y a veces demasiado contradictoria. En ese mismo artículo,  la figura 2 detalla un poco más la tarea de arquitectura en lo referente a modelar, a diseñar, a representar usando lenguajes como UML o los ADLs.

Esa tarea de modelar a veces genera la percepción de que la arquitectura consiste en hacer muñequitos (matachos), representaciones gráficas. Pues se piensa siempre en modelar como representar gráficamente, como hacer planos. Pero se olvida que trabajamos con computadores y que el modelado computacional es matemático. Además, se genera la idea de que la arquitectura consiste en usar una herramienta y un lenguaje de modelado y en hacer documentos. Nada más equivocado que confundir la burocracia,  el trabajo de papel y escritorio, las tareas administrativas con lo que es hacer software... 

Responder qué es arquitectura de software no es sencillo. Una respuesta para pensar es la de Martin Fowller: "la arquitectura de software es sobre las cosas importantes, sea lo que sea": Es sobre la estructura física, la infraestructura, porque eso es importante. Es sobre la estructura lógica y a alto nivel. Sobre los atributos de calidad y los requerimientos. Sobre las personas, el proceso, el proyecto, el producto y las herramientas. Sobre los estilos y patrones, la reutilización, la agilidad y la automatización. Sobre la complejidad y simplificar. Sobre las personas, sus roles, habilidades y prácticas, sobre sus perfiles, los equipos de trabajo, el liderazgo y muchas cosas más.

Por eso el curso de Arquitectura de Software usa varios textos guía: uno para el proceso (y algo del proyecto), dos para el producto y uno para las personas.

A manera de resumen, y no tanto de conclusión, con fundamento en la experiencia y en varias lecturas, en especial todas  las citadas previamente en esta entrada,  aunque no solo esas:

1. En el mundo del software hablamos de ingeniería y arquitectura del software:
1. La  primera (la ingeniería de software) se suele asociar más con la gerencia de proyectos, los temas administrativos, burocráticos, metodológicos y documentales y no tanto con el sofware, su código fuente y la programación de computadores. En otras entradas conviene hablar sobre el proyecto y el proceso, el metamodelo SPEM que menciona y explica muy bien el libro de Peter Eeles y sobre la tendencia mundial de DevOps que automatiza todo, con lo cual la ingeniería del software está obligada a transformarse digitalmente.
2. La segunda (la arquitectura de software) es más reciente que la primera, tiene múltiples escuelas y visiones y está centrada en el producto, en el resultado, en el software y su estructura. En esta escuela se habla principalmente de estilos y patrones, de buenas prácticas repetibles y de cómo eso satisface los requerimientos y la calidad requerida.
2. La arquitectura de software tiene que ver con modelos, con modelar, con diseños a alto nivel. Para eso hay lenguajes y herramientas ayudan a automatizar, a ser ágiles, a no reinventar la rueda, a reutilizar y establecer bases que permitan crecer hacia sistemas más complejos.
3. No hay recetas. Lo escrito y hecho puede cambiar, puede desaparecer o evolucionar. De lo contrario no haríamos software ni trabajaríamos con tecnología sino que seríamos una tribu religiosa que busca conservar todo el pasado y no cambiar nada. Debemos aprender del pasado, investigar el presente y proponer y crear el futuro, de eso se trata la arquitectura. El primer paso es complejo, pues hay que  leer mucho. El segundo lo es más, pues el mundo es muy extenso y cambia muy rápido. Lo que observamos o descubrimos hoy será obsoleto mañana pero debemos aprenderlo también. Lo tercero, lo de proponer y crear, es fundamental, pero sin ignorar lo demás...