sábado, 24 de agosto de 2013

Sobre Arquitecturas y Arquitectos

No hay una definición única de Arquitectura en el mundo de sistemas. A menudo se habla de módulos, componentes y conectores, diseño de alto nivel, modelos conceptuales, estilos de arquitectura, patrones, gobierno, atributos de calidad, el sistema como un todo, el gran cuadro, liderazgo técnico, lineamientos, estrategia, visión y un muy largo etcétera.

Simon Brown, en su libro Software Architecture for Developers, define a la Arquitectura primero como sustantivo, como estructura: la descomposición de un producto en una colección de componentes e interacciones, y luego como verbo, como el entendimiento de lo que se debe construir, creando una visión que guíe dicha construcción y sirva para comunicar y tomar decisiones a lo largo de todo el proyecto. En resumen, dice Brown, la Arquitectura es una cuestión de estructura (sustantivo) y visión (verbo).

Pero dado que los sistemas son grandes y complejos, podemos afirmar que toda Arquitectura (estructura y visión) será consumida por muchos distintos usuarios: técnicos, no técnicos, de infraestructura, seguridad, redes, datos, base de datos, integración, negocio, procesos, etcétera. Podemos decir que toda Arquitectura presenta disonancia conceptual, ya que distintos tipos de usuarios consumen distintas vistas. Esto es lo que da origen a distintos tipos de Arquitectura y distintos tipos de Arquitectos.

Arquitectura de Aplicación

Los bloques de construcción de las aplicaciones son componentes de software e incluyen "cosas" como lenguajes de programación, librerías, frameworks, APIs, etc. La arquitectura de una aplicación es descrita en términos de clases, componentes, módulos, funciones, patrones de diseño, paquetes. En esencia, se trata de software y de la organización del código fuente.

Arquitectura de Sistema

Los bloques de construcción de los sistemas son un mix entre software y hardware. Subimos un nivel y encontramos que un sistema está compuesto por una colección de aplicaciones. Muchas de esas aplicaciones pueden utilizar distintas tecnologías; pongamos el ejemplo de un sistema web, en el que típicamente tenemos browsers que interpretan HTML, CSS y JavaScript, middleware que ejecuta código Java, y bases de datos que entienden de SQL; cada capa física cuenta con su propia arquitectura de aplicación.

Los sistemas de software nunca viven aislados. Hoy más que nunca, es común que muchos sistemas tengan que comunicarse entre sí. Por esto, la Arquitectura de Sistemas involucra también aspectos de integración e interacción entre distintos sistemas.

Arquitectura de Software

Simon Brown prefiere definir a la Arquitectura de Software como la combinación entre la Arquitectura de Aplicación y la Arquitectura de Sistema.


En otras palabras, Arquitectura de Sofware es todo lo relacionado con los elementos significativos de un sistema de software; desde la estructura y los fundamentos del código fuente hasta el despliegue exitoso de ese código fuente en un entorno real de ejecución. Por esta razón, la Arquitectura de Software, irónicamente, abarca software y también infraestructura.

Arquitectura de Empresa

Sigamos subiendo, alejándonos con la cámara para distinguir el bosque completo de sistemas de toda una empresa, la selva de artefactos de software, enlatados, desarrollados, tercerizados, legados, etc, etc, y las aristas que interconectan y/o concentran estos nodos, como pueden ser ESBs, BPMs, colas de mensajería, u otras tecnologías.

La Arquitectura de Empresa generalmente se refiere al tipo de trabajo que sucede en toda una organización. Los bloques de construcción de una empresa no son sólo piezas tecnológicas de hardware y software, sino también personas y procesos que hacen que la organización trabaje efectiva y eficientemente. La Arquitectura de Empresa no trata sobre detalles de implementación, detalles de cómo funciona esta tecnología o aquélla, sino de cómo utilizar la tecnología, las personas y los procesos en el contexto completo de la organización, y cómo interactúan todos ellos con el negocio.

Hace poco estuve leyendo un poco sobre ArchiMate, un estándar de lenguaje de modelado de Arquitecturas Empresariales que sirve para describir, analizar y visualizar la arquitectura completa de una organización a través de sus dominios de negocio de una forma no ambigua.

Bloques de Construcción del estándar ArchiMate
Creo que ArchiMate es un lenguaje de modelado extremadamente útil para entender lo que es la Arquitectura completa de una Empresa.

Otras Arquitecturas

Dependiendo del grado de adicción que una organización posea a las clasificaciones y a las especializaciones, podemos encontrar otros tipos de arquitecturas, como:
  • Arquitectura de Infraestructura
  • Arquitectura de Seguridad
  • Arquitectura de Solución
  • Arquitectura Técnica
  • Arquitectura de Red
  • Arquitectura de Datos
  • Arquitectura de Hardware
  • Arquitectura de Integración
  • Arquitectura de Base de Datos
  • Arquitectura de Información
  • Arquitectura de Proceso
  • Arquitectura de Negocio
Algunos tipos de arquitectura pueden ser más fáciles de describir que otros. ¿Qué significa Arquitectura de Solución? Para algunas organizaciones, un Arquitecto de Solución es lo mismo que un Arquitecto de Software pero con la diferencia de que el primero no se embarra con detalles de implementación. ¿Qué significa Arquitectura Técnica? ¿Es el complemento de la Arquitectura de Solución? ¿Un Arquitecto de Software es un Arquitecto de Solución más un Arquitecto Técnico? ¿La Arquitectura Técnica involucra aspectos de software y de hardware? ¿Qué diferencia un Arquitecto de Integración de un Arquitecto de Software?

Probablemente toda esta pesadilla de especializaciones y mezcla de dominios sea la que trae tanta confusión y ruido en la definición de Arquitectura de Software.

Sobre los Arquitectos y sus Roles

Por supuesto, hablar de Arquitectura y de Arquitectos es casi lo mismo. En el primer caso nos referimos a la disciplina en sí y en el segundo a los profesionales que llevan a cabo esa disciplina. Siguiendo con lo visto hasta ahora, los Arquitectos de Aplicación serán responsables por la estructura y la visión de la Arquitectura de una Aplicación, los Arquitectos de Empresa serán responsables por la estructura y la visión de la Arquitectura de una Empresa, y así.

El libro Software Architecture for Developers, como imaginarán por su título, se centra principalmente en la Arquitectura de Software. Uno de los temas más interesantes es tratado en el capítulo 3 y es el Rol del Arquitecto de Software a lo largo de todo el ciclo de vida de un proyecto de software.


El capítulo no tiene desperdicio. En 2010, Brown publicó un artículo en InfoQ llamado Are You a Software Architect? que resume bastante bien esta problemática del rol del Arquitecto de Software. Por supuesto, la versión del libro es mucho más completa y actual, ya que es posterior al artículo.